System Models

Khalifa University

Software Engineering, Slide 1

 Objectives
l To explain why the context of a system
should be modelled as part of the SE
process
l To describe behavioural modelling, data
modelling and object modelling
l To introduce some of the notations used in
the Unified Modeling Language (UML)
l To show how CASE workbenches support
system modelling

Software Engineering, Slide 2

 Topics covered
l Context models
l Behavioural models
l Data models
l Object models
l CASE workbenches

Software Engineering, Slide 3

 System modelling
l System modelling helps us understand the
functionality of the system and models are used to
communicate with customers.
l 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.

Software Engineering, Slide 4

 System modelling

A system model is an abstract view of the system being

studied that ignores some system details.
Examples of system models
l Data flow (processing) model
l Composition/aggregation model
l Architectural model showing principal sub-systems.
l Classification model.
l Stimulus/response model

Software Engineering, Slide 5

 Model types
l Data flow (processing) model
Showing how the data is processed at different stages.
l Composition/aggregation model
Showing how entities are composed of other entities.
l Architectural model
Showing principal sub-systems.
l Classification model
(Object/class inheritance) showing how entities have common
characteristics.
l Stimulus/response model
showing the system’s reaction to internal and external
events.

Software Engineering, Slide 6

 Context models

l Simple representation of the entire system under

investigation.
l Context models are used to illustrate the operational
context of a system - they show what lies outside the
system boundaries.
l Organisational concerns may affect the decision on
where to position system boundaries.
l Architectural models show the system and its
relationship with other systems.

Software Engineering, Slide 7

 Example 1: 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

Software Engineering, Slide 8

 Example 2: The context of a
temperature monitoring system

Temperature
Sensor Temperature

Processed Operator
Data
Timer Temperature Display
Synchronisation Monitoring
Signal System

Operator Operator
Request

Software Engineering, Slide 9

 Behavioural models

l Behavioural models are used to describe the

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

Software Engineering, Slide 10

 Data-processing models
l Data flow diagrams (DFDs) may be used to model the
system’s data processing.
l These show the processing steps as data flows through
a system.
l DFDs are an intrinsic part of many analysis methods.
l Simple and intuitive notation that customers can
understand.
l Show end-to-end processing of data.
l The model development is top-down process starting
from the overall process down to each sub-process.

Software Engineering, Slide 11

 Order processing DFD

Software Engineering, Slide 12

 Data flow diagrams

l DFDs model the system from a functional

perspective.
l A graphical system model that shows all of the
main requirements for an information system:
inputs, outputs, processes and data storage
l Tracking and documenting how the data
associated with a process is helpful to develop
an overall understanding of the system.
l Data flow diagrams may also be used in
showing the data exchange between a system
and other systems in its environment.
Software Engineering, Slide 13
 Data flow diagrams

• Everyone working on the project (and end

users) can see all the aspects of the project in
the diagram with minimal training (simple – only
5 symbols)

Software Engineering, Slide 14

 Data flow diagram symbols

A process:
A process shows a transformation or manipulation of
data flows within the system.

Step by step instructions that transform inputs into

outputs (algorithm or procedure)

The process may contain two descriptive elements:

- An identification number
- A descriptive title is placed in the centre of the box. This
should be a simple imperative sentence with a specific
verb, for example ‘save customer data' or 'find driver'.
Software Engineering, Slide 15
 Data flow diagram symbols

External Entity:

An external entity is a source or destination of a

data flow which is outside the system
The external entity must contain a meaningful
and unique identifier.

Software Engineering, Slide 16

 Data flow diagram symbols

Data flow

A data flow shows the flow of information from

its source to its destination. The arrowheads show
the direction of flow.

Information always flows to or from a process

Software Engineering, Slide 17

 Data flow diagram symbols

Data Store

A data store is a holding place for

information within the system:
It is represented by an open-ended narrow
rectangle.
Data stores may be long-term files or a
short-term accumulators

Software Engineering, Slide 18

 Data flow diagram symbols

l Real time link

Represents a communication back and forth

between an external agent and a process as
the process is executing.

Software Engineering, Slide 19

 Data flow diagram: Example

l A DFD showing the process: “Look for item

availability”

Software Engineering, Slide 20

 Data flow diagram

l Exercise: Draw the DFD for the following

scenario:
A student consults a bookshop webpage
looking for a particular book. The webpage
searches the database of books and reports
that the book is out of stock

Software Engineering, Slide 21

 Evaluating DFD quality

l A quality set of DFDs is

• Readable
• Internally consistent
• Accurately represents system requirements

Software Engineering, Slide 22

 Evaluating DFD quality

l Minimizing complexity
• Want to avoid information overload
• Occurs when too much information is presented to a user
at one time
• Two ways to avoid information overload: use 7 + or – 2
rule (which limits the number of components) and
interface minimization (which minimizes the number of
interfaces and connections between components)
! A single DFD should have no more than 7 + or – 2
processes
! No more than 7 + or – 2 data flows into or out of a process

Software Engineering, Slide 23

 Evaluating DFD quality

l Data Flow Consistency

• Want consistency in DFDs

• Common errors:

• Differences in data flow for a process and its

decomposition (want to have balancing: equivalence
of data content between data flows entering and
leaving a process or its decomposition)

Software Engineering, Slide 24

 Evaluating DFD Quality

l Data Flow Consistency

Common errors
• Black hole
! A process with data input that is never
used to produce a data output

Software Engineering, Slide 25

 Evaluating DFD quality
l Data Flow Consistency
Common errors
• Miracle
! A process with a data output that is
created out of nothing (i.e. “miraculously
appears”)

Software Engineering, Slide 26

 Evaluating DFD quality

l Common errors

Software Engineering, Slide 27

 Evaluating DFD quality

Software Engineering, Slide 28

 DFD fragment

l DFD fragment: A DFD that represents the

system response to one event within a single
process symbol

• A fragment is created for each event in the

event list – it is a self-contained model showing
how the system responds to a single event

• Created one at a time

Software Engineering, Slide 29

 DFD fragment: Example

Software Engineering, Slide 30

 Creating DFDs

Creating DFDs is a highly iterative process of

gradual refinement.
General steps:
1. Create a preliminary Context Diagram
2. Identify Use Cases, i.e. the ways in which
users most commonly use the system
3. Create DFD fragments for each use case
4. Create a Level 0 diagram from fragments
5. Decompose to Levels 1, 2, …
6. Go to step 1 and revise as necessary
7. Validate
Software Engineering,
DFDs with users. Slide 31
 Context diagrams
l Context Diagram: A DFD that summarizes all
processing activities within the system in a
single process symbol
• Describes highest level view of a system
• All external agents and all data flows into and out
of a system are shown in the diagram
• The whole system is represented as one process

Software Engineering, Slide 32

 Notes on context diagram

l Useful for showing system boundaries

l External agents are outside the software scope
(which is represented by the single process) (But
not from System Analysis
l Data stores are not usually shown in the context
diagram since they are considered to be in the
system scope (i.e. the single process)
l It is the highest level DFD
l Context diagram does not show any details of what
takes place within the system (i.e. that single
process)
Software Engineering, Slide 33
 Context diagrams: Example

A student enrolment system:

A student applies online for a given course, the
university checks for course availability then sends
back confirmation if course available, rejection,
otherwise.
Analysis
l External entity: Student
l Process - Student Administration process
application
l Data Flows - Application Form,
Confirmation/Rejection Letter

Software Engineering, Slide 34

 Context Diagrams: Example

Software Engineering, Slide 35

 Level-0 DFD

l Shows the system’s major processes, data

flows, and data stores at a high level of
abstraction
l When the Context Diagram is expanded into
DFD level-0, all the connections that flow
into and out of process 0 needs to be
retained.

Software Engineering, Slide 36

 Level-0 DFD: Example

Software Engineering, Slide 37

 Level-0 DFD: Methodolgy
1-Read the problem description carefully looking for:
l “Things” that supply information to or use information from the system
=> external entities (EE)

l Actions/doing words/verbs => Processes (P)

l Movement/exchange of information/data between external entities to

processes, and processes to processes => data flows (DF)
l Store/record information/data => data stores(DS)

2- It often helps to walk through the system in its logical sequence; eg

starting with an external entity (source), add data flows, processes and
data stores as the data provided by the entity is manipulated by the
system.

Software Engineering, Slide 38

 Lower-level diagrams

l Functional Decomposition
l Balancing

Software Engineering, Slide 39

 Decomposition of DFDs

l Functional decomposition
• An iterative process of breaking a system
description down into finer and finer detail
• Uses a series of increasingly detailed DFDs
• Act of going from one single system to many
component processes
• Repetitive procedure
• Lowest level is called a primitive DFD
l Level-N Diagrams
• A DFD that is the result of n nested
decompositions of a series of subprocesses
from a process on a level-0 diagram

Software Engineering, Slide 40

 Balancing DFDs
l When decomposing a DFD, you must conserve
inputs to and outputs from a process at the next
level of decomposition
l Ensures that the input and output data flows of the
parent DFD are maintained on the child DFD
l This is called balancing
l Example: Hoosier Burgers
• In Figure 1, notice that there is one input to the
system, the customer order
• Three outputs:
• Customer receipt
• Food order
• Management reports

Software Engineering, Slide 41

 Balancing DFDs: Example

Level-0 DFD
One input to the system: the
customer order
Three outputs:
Customer receipt
Food order
Management reports

Software Engineering, Slide 42

 Balancing DFDs: Example

Level-1 DFD
One input to the system:
the customer order
Three outputs:
Customer receipt
Food order
Management
reports

Software Engineering, Slide 43

 Balancing DFDs: Example

l Notice that we still have the same inputs

and outputs
l No new inputs or outputs have been
introduced
l We can say that the context diagram and
level-0 DFD are balanced

Software Engineering, Slide 44

 Semantic data models
l Used to describe the logical structure of data
processed by the system.
l An entity-relation-attribute (ERA) model sets out the
entities in the system, the relationships between
these entities and the entity attributes
l Widely used in database design. Can readily be
implemented using relational databases.
l No specific notation provided in the UML but objects
and associations can be used.

Software Engineering, Slide 45

 Library semantic model

Software Engineering, Slide 46

 Data dictionaries

l Data dictionaries are lists of all of the names used in

the system models. Descriptions of the entities,
relationships and attributes are also included.
l Advantages
• Support name management and avoid duplication;
• Store of organisational knowledge linking analysis, design
and implementation;
l Many CASE workbenches support data dictionaries.

Software Engineering, Slide 47

 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)

Software Engineering, Slide 48

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

Software Engineering, Slide 49

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

Software Engineering, Slide 50

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

Software Engineering, Slide 51

 Object models and the UML

l The UML is a standard representation devised by

the developers of widely used object-oriented
analysis and design methods.
l It has become an effective standard for object-
oriented modelling.
l 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.

Software Engineering, Slide 52

 Library class hierarchy
Li brary item

Catalogue n umb er
Acqui sition da te
Cost
Type
Status
Number of co pies
Acqui re ()
Catalogue ()
Di spo se ()
Issue ()
Return ()

Pub lished i tem Reco rded item

Title Title
Pub lisher Medium

Book Magazine Fi lm Computer

pro gram
Author Year Di rector
Editio n Da te o f release Version
Issue
Pub lication da te Di stributor Platfor m
ISB N

Software Engineering, Slide 53

 User class hierarchy
Li brary user
Name
Address
Phone
Reg istration #
Reg ister ()
De-reg ister ()

Reader Borrower
Affi liation Items on loan
Max. loans

Staff Student
Depar tment Maj or subject
Depar tment phone Home ad dress

Software Engineering, Slide 54

 Multiple inheritance
l Rather than inheriting the attributes and services
from a single parent class, a system which supports
multiple inheritance allows object classes to inherit
from several super-classes.
l This can lead to semantic conflicts where
attributes/services with the same name in different
super-classes have different semantics.
l Multiple inheritance makes class hierarchy
reorganisation more complex.

Software Engineering, Slide 55

 Multiple inheritance
Book Voice recording
Author Speak er
Edition Duration
Publication da te Recording da te
ISBN

Talking book

# Tapes

Software Engineering, Slide 56

 Object aggregation
l An aggregation model shows how classes
that are collections are composed of other
classes.
l Aggregation models are similar to the part-of
relationship in semantic data models.

Software Engineering, Slide 57

 Object aggregation

Software Engineering, Slide 58

 Object behaviour modelling

l A behavioural model shows the interactions

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

Software Engineering, Slide 59

 Issue of electronic items

Software Engineering, Slide 60

 Structured methods

l Structured methods incorporate system

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

Software Engineering, Slide 61

 Method weaknesses

l They do not model non-functional system

requirements.
l They do not usually include information
about whether a method is appropriate for a
given problem.
l The may produce too much documentation.
l The system models are sometimes too
detailed and difficult for users to understand.

Software Engineering, Slide 62

 CASE workbenches

l A coherent set of tools that is designed to

support related software process activities
such as analysis, design or testing.
l Analysis and design workbenches support
system modelling during both requirements
engineering and system design.
l These workbenches may support a specific
design method or may provide support for a
creating several different types of system
model.

Software Engineering, Slide 63

An analysis and design workbench

Structured Report
Da ta
diag ramming generation
dictionary
tools facilities

Central Query
Code
information language
gener ator
repository facilities

Forms Design, anal ysis

Import/export
crea tion and checking
facilities
tools tools

Software Engineering, Slide 64

 Analysis workbench components
l Diagram editors
l Model analysis and checking tools
l Repository and associated query language
l Data dictionary
l Report definition and generation tools
l Forms definition tools
l Import/export translators
l Code generation tools

Software Engineering, Slide 65

 Key points
l A model is an abstract system view.
Complementary types of model provide
different system information.
l Context models show the position of a
system in its environment with other systems
and processes.
l Data flow models may be used to model the
data processing in a system.
l State machine models model the system’s
behaviour in response to internal or external
events
Software Engineering, Slide 66
 Key points
l Semantic data models describe the logical
structure of data which is imported to or
exported by the systems.
l Object models describe logical system
entities, their classification and aggregation.
l Sequence models show the interactions
between actors and the system objects that
they use.
l Structured methods provide a framework for
developing system models.

Software Engineering, Slide 67