System Models

A description of the various models that

can be used to specify software
systems.
Objectives

◼ To explain why the context of a system

should be modelled as part of the RE process
◼ To describe behavioural modelling, data
modelling and object modelling
◼ To introduce some of the notations used in
the Unified Modeling Language (UML)
Topics covered

◼ Context models
◼ Behavioural models
◼ Data models
◼ Object models
System modelling

◼ System modelling helps the analyst to understand

the functionality of the system and models are used
to communicate with customers.
◼ Different models present the system from different
perspectives
❑ External perspective showing the system’s context or
environment;
❑ Behavioural perspective showing the behaviour of the
system;
❑ Structural perspective showing the system or data
architecture.
Model types

◼ Data processing model showing how the data is

processed at different stages.
◼ Composition model showing how entities are
composed of other entities.
◼ Architectural model showing principal sub-systems.
◼ Classification model showing how entities have
common characteristics.
◼ Stimulus/response model showing the system’s
reaction to events.
Context models

◼ Context models are used to illustrate the

operational context of a system - they show
what lies outside the system boundaries.
◼ Social and organisational concerns may
affect the decision on where to position
system boundaries.
◼ Architectural models show the system and its
relationship with other systems.
The context of an ATM system

Security
sy stem

Branch
Account
accounting
da tabase
sy stem

Auto-teller
sy stem

Branch
Usage
counter
database
sy stem

Maintenance
sy stem
Process models

◼ Process models show the overall process

and the processes that are supported by the
system.
◼ Data flow models may be used to show the
processes and the flow of information from
one process to another.
Equipment procurement process
Behavioural models

◼ Behavioural models are used to describe the

overall behaviour of a system.
◼ Two types of behavioural model are:
❑ Data processing models that show how data is
processed as it moves through the system;
❑ State machine models that show the systems
response to events.
◼ These models show different perspectives so
both of them are required to describe the
system’s behaviour.
Data-processing models

◼ Data flow diagrams (DFDs) may be used to

model the system’s data processing.
◼ These show the processing steps as data
flows through a system.
◼ DFDs are an intrinsic part of many analysis
methods.
◼ Simple and intuitive notation that customers
can understand.
◼ Show end-to-end processing of data.
What is a Data Flow Diagram?

◼ A data flow diagram (DFD) is a graphical

representation of the movement of data
between external entities, processes and data
stores within a system.

◼ Simply put, DFD’s show how data moves

through an information system.
DFD Symbols
DFD Symbols

15
DFD Symbols (cont.)

◼ Process: work or actions performed on data

(inside the system)
◼ Data store: data at rest (inside the system)
◼ Source/sink: external entity that is origin or
destination of data (outside the system)
◼ Data flow: arrows depicting movement of data
Process
1.0

Grade Detail Grade Report

Produce
Grade
Report

❑ The work or actions performed on data so that

they are transformed, stored, or distributed.

❑ Process labels should be verb phrases!

17
Data Flow
2.1
Payment Detail

D1 Accounts
Post Invoice Detail Receivable
Payment

❑ A path for data to move from one part of the

system to another.
❑ Data in motion!
◼ Arrows depict the movement of data.
❑ NO VERBS

18
Data Store

D1 Students

❑ Used in a DFD to represent data that the system

stores
❑ Data at rest!
❑ Labels should be noun phrases
◼ (NO VERBS)

19
External Entity or Source/Sink

1.0
Order

CUSTOMER Invoice
Verify
Order

❑ The origin or destination of data!

◼ This represents things outside of the system.
❑ Source – Entity that supplies data to the system.
❑ Sink – Entity that receives data from the system.
❑ The labels should be noun phrases!
20
DFD Diagramming Rules
Process

No process can have

only outputs or only
inputs…processes
must have both
outputs and inputs.

Process labels should be verb phrases.

DFD Diagramming Rules
Data Store

All flows to or from a data store must

move through a process.

Data store labels should be noun phrases.

DFD Diagramming Rules
Source/Sink

No data moves directly between external entities

without going through a process.

Interactions between external entities without

intervening processes are outside the system and
therefore not represented in the DFD.

Source and sink labels should be noun phrases.

DFD Diagramming Rules
Data Flow
Bidirectional flow
between process
and data store is
represented by two
separate arrows.

Forked data flow

must refer to exact
same data item (not
different data items)
from a common
location to multiple
destinations.
DFD Diagramming Rules
Data Flow (cont.)
Joined data flow
must refer to exact
same data item (not
different data items)
from multiple
sources to a
common location.

Data flow cannot

go directly from a
process to itself,
must go through
intervening
processes.
DFD Diagramming Rules
Data Flow (cont.)
◼ Data flow from a process to a data store
means update (insert, delete or change).
◼ Data flow from a data store to a process
means retrieve or use.
◼ Data flow labels should be noun phrases.
General DFD Rules

YES NO
A process to another process

A process to an external entity

A process to a data store

An external entity to another external entity

An external entity to a data store

A data store to another data store

27
Advantages of DFDs

❑ Simple graphical techniques which are easy to

understand
❑ Helps define the boundaries of the system
❑ Useful for communicating current system
knowledge to users
❑ Explains the logic behind the data flow within the
system
❑ Used as the part of system documentation file

28
Order processing DFD
Data flow diagrams

◼ DFDs model the system from a functional

perspective.
◼ Tracking and documenting how the data
associated with a process is helpful to
develop an overall understanding of the
system.
◼ Data flow diagrams may also be used in
showing the data exchange between a
system and other systems in its environment.
Insulin pump DFD
Process Modeling

◼ Graphically represent the processes that

capture, manipulate, store, and distribute data
between a system and its environment and
among system components
◼ Utilize information gathered during requirements
determination
◼ Processes and data structures are modeled
Process Modeling (cont.)
Deliverables and Outcomes
◼ Context data flow diagram (DFD)
❑ Scope of system
◼ DFDs of current physical and logical system
❑ Enables analysts to understand current system
◼ DFDs of new logical system
❑ Technology independent
❑ Show data flows, structure, and functional
requirements of new system
◼ Thorough description of each DFD component
Data Flow Diagram (DFD)

◼ A picture of the movement of data between

external entities and the processes and data
stores within a system
◼ Difference from system flowcharts:
❑ DFDs depict logical data flow independent of
technology
❑ Flowcharts depict details of physical systems
Functional Decomposition

◼ An iterative process of breaking a system

description down into finer and finer detail
◼ High-level processes described in terms of
lower-level sub-processes
◼ DFD charts created for each level of detail
DFD Levels

◼ Context DFD
❑ Overview of the organizational system
◼ Level-0 DFD
❑ Representation of system’s major processes at high
level of abstraction
◼ Level-1 DFD
❑ Results from decomposition of Level 0 diagram
◼ Level-n DFD
❑ Results from decomposition of Level n-1 diagram
Context Diagram

Context diagram
shows the
system
boundaries,
external entities
that interact with
the system, and
major
information flows
between entities
and the system.

NOTE: only one process symbol, and no data stores shown.

 Level-0 DFD

Level-0 DFD
shows the
system’s major
processes, data
flows, and data
stores at a high
level of
abstraction.

Processes are labeled 1.0, 2.0, etc. These will be decomposed into
more primitive (lower-level) DFDs.
Level-1 DFD

Level-1 DFD shows

the sub-processes
of one of the
processes in the
Level-0 DFD.

This is a Level-1
DFD for Process
4.0.

Processes are labeled 4.1, 4.2, etc. These can be further

decomposed in more primitive (lower-level) DFDs if necessary.
Level-n DFD

Level-n DFD shows

the sub-processes
of one of the
processes in the
Level n-1 DFD.

This is a Level-2
DFD for Process
4.3.

Processes are labeled 4.3.1, 4.3.2, etc. If this is the

lowest level of the hierarchy, it is called a primitive DFD.
More DFD Rules
Guidelines for Drawing DFDs

◼ Completeness
❑ DFD must include all components necessary for
system.
❑ Each component must be fully described in the
project dictionary or CASE repository.
◼ Consistency
❑ The extent to which information contained on one
level of a set of nested DFDs is also included on
other levels.
Guidelines for Drawing DFDs (cont.)

◼ Timing
❑ Time is not represented well on DFDs.
❑ Best to draw DFDs as if the system has never
started and will never stop.
◼ Iterative Development
❑ Analyst should expect to redraw diagram several
times before reaching the closest approximation
to the system being modeled.
Guidelines for Drawing DFDs (cont.)

◼ Primitive DFDs
❑ Lowest logical level of decomposition
❑ Decision has to be made when to stop
decomposition
Semantic data models

◼ Used to describe the logical structure of data

processed by the system.
◼ An entity-relation-attribute model sets out the
entities in the system, the relationships between
these entities and the entity attributes
◼ Widely used in database design. Can readily be
implemented using relational databases.
◼ No specific notation provided in the UML but objects
and associations can be used.
Data dictionaries

◼ Data dictionaries are lists of all of the names

used in the system models. Descriptions of
the entities, relationships and attributes are
also included.
◼ Advantages
❑ Support name management and avoid duplication;
❑ Store of organisational knowledge linking analysis,
design and implementation;
◼ Many CASE workbenches support data
dictionaries.
Data dictionary entries

Name Description Type Date

Details of the published article that may be ordered by
Article Entity 30.12.2002
people using LIBSYS.
The names of the authors of the article who may be due
authors Attribute 30.12.2002
a share of the fee.
The person or organisation that orders a co py of the
Buyer Entity 30.12.2002
article.
A 1:1 relationship between Article and the Copyright
fee- Relation 29.12.2002
Agency who should be paid the copyright fee.
payable-to
The address of the buyer. This is used to any paper
Address Attribute 31.12.2002
billing information that is required.
(Buyer)
Object models

◼ Object models describe the system in terms of

object classes and their associations.
◼ An object class is an abstraction over a set of
objects with common attributes and the services
(operations) provided by each object.
◼ Various object models may be produced
❑ Inheritance models;
❑ Aggregation models;
❑ Interaction models.
Object models

◼ Natural ways of reflecting the real-world

entities manipulated by the system
◼ More abstract entities are more difficult to
model using this approach
◼ Object class identification is recognised as a
difficult process requiring a deep
understanding of the application domain
◼ Object classes reflecting domain entities are
reusable across systems
Inheritance models

◼ Organise the domain object classes into a hierarchy.

◼ Classes at the top of the hierarchy reflect the
common features of all classes.
◼ Object classes inherit their attributes and services
from one or more super-classes. These may then be
specialised as necessary.
◼ Class hierarchy design can be a difficult process if
duplication in different branches is to be avoided.
Object models and the UML

◼ The UML is a standard representation devised by

the developers of widely used object-oriented
analysis and design methods.
◼ It has become an effective standard for object-
oriented modelling.
◼ Notation
❑ Object classes are rectangles with the name at the top,
attributes in the middle section and operations in the
bottom section;
❑ Relationships between object classes (known as
associations) are shown as lines linking objects;
❑ Inheritance is referred to as generalisation and is shown
‘upwards’ rather than ‘downwards’ in a hierarchy.
Object aggregation

◼ An aggregation model shows how classes

that are collections are composed of other
classes.
◼ Aggregation models are similar to the part-of
relationship in semantic data models.
Object behaviour modelling

◼ A behavioural model shows the interactions

between objects to produce some particular
system behaviour that is specified as a use-
case.
◼ Sequence diagrams (or collaboration
diagrams or interaction diagrams) in the UML
are used to model interaction between
objects.
Structured methods

◼ Structured methods incorporate system

modelling as an inherent part of the method.
◼ Methods define a set of models, a process for
deriving these models and rules and
guidelines that should apply to the models.
◼ CASE tools support system modelling as part
of a structured method.
Key points

◼ A model is an abstract system view. Complementary

types of model provide different system information.
◼ Context models show the position of a system in its
environment with other systems and processes.
◼ Data flow models may be used to model the data
processing in a system.
◼ State machine models model the system’s
behaviour in response to internal or external events
Key points

◼ Semantic data models describe the logical

structure of data which is imported to or
exported by the systems.
◼ Object models describe logical system
entities, their classification and aggregation.
◼ Sequence models show the interactions
between actors and the system objects that
they use.
◼ Structured methods provide a framework for
developing system models.
Entity-Relationship Diagrams

◼ ER-modeling is a data modeling method used

in software engineering to produce a
conceptual data model of an information
system.
◼ Diagrams created using this ER-modeling
method are called Entity-Relationship
Diagrams or ER diagrams or ERDs.
Purpose of ERD

◼ The database analyst gains a better

understanding of the data to be contained in
the database through the step of constructing
the ERD.
◼ The ERD serves as a documentation tool.
◼ Finally, the ERD is used to connect the
logical structure of the database to users. In
particular, the ERD effectively communicates
the logic of the database to users.
Components of an ER Diagrams

◼ Entity
◼ Attributes
◼ Relationships
Entity
◼ An entity can be a real-world object, that can
be identifiable.
◼ An entity is denoted as a rectangle in an ER
diagram.
◼ All these entities have some attributes or
properties that give them their identity.
◼ For example, a Student set may contain all
the students of a school; likewise, a Teacher
set may include all the teachers of a school
from all faculties.
Entity Set

◼ An entity set is a collection of related types of

entities.
◼ An entity set may include entities with
attributes sharing similar values.
◼ Entity set need not be disjoint.
Attributes

◼ Entities are denoted utilizing their properties,

known as attributes.
◼ All attributes have values.
◼ For example, a student entity may have
name, class, and age as attributes.
Types of Attributes

◼ Key attribute: Key is an attribute or collection

of attributes that uniquely identifies an entity
among the entity set. Eg, Roll num
◼ Composite attribute: An attribute that is a
combination of other attributes is called a
composite attribute. Eg Address
◼ Single-valued attribute, eg id
◼ Multi-valued attribute eg Phone num
◼ Derived attribute, eg Age
Relationships
◼ The association among entities is known as
relationship.
◼ Relationships are represented by the
diamond-shaped box.
◼ For example, an employee works_at a
department, a student enrolls in a course.
Degree of a Relationship Set
◼ The number of participating entities in a
relationship describes the degree of the
relation
◼ Unary (degree1)

◼ Binary (degree2)

◼ Ternary (degree3)
Cardinality

◼ Cardinality describes the number of entities in

one entity set, which can be associated with
the number of entities of other sets via
relationship set.
Types of Cardinalities

◼ One to One:

◼ One to many:
◼ Many to One:

◼ Many to Many: