Lecturer: Sebastian Coope
Ashton Building, Room G.18
E-mail: coopes@liverpool.ac.uk
COMP 201 web-page:
http://www.csc.liv.ac.uk/~coopes/comp201
Lecture 7 – System Models
COMP201 - Software Engineering
1
Lecture Overview
 System models are abstract descriptions of systems
whose requirements are being analysed
 Objectives - To explain why the context of a system should
be modelled as part of the RE process
 To describe
 Behavioural modelling (FSM, Petri-nets),
 Data modelling and
 Object modelling (Unified Modelling Language, UML)
COMP201 - Software Engineering
2
System Models
 User requirements must be written in such a way that
non-technical experts can understand them, e.g., by using
natural language
 Detailed system requirements may be expressed in a
more technical way however
 One widely used technique is to document the system
specification as a set of system models
 These are graphical representations which describe
business processes and the system to be developed
 They are an important bridge between the analysis and
design processes
COMP201 - Software Engineering
3
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
COMP201 - Software Engineering
4
“A Picture Paints a Thousand Words”
Person
#name : String
#ssn : String
#dob : Date
#spouse : Person
#children : Set
+Person()
+setName() : void
+setSsn() : void
+setDob() : void
+setSpouse() : void
+setChildren() : Set
+getName() : String
+getSsn() : String
+getDob() : Date
+getSpouse() : Person
+getChildren() : Set
+getAge() : int
Student
-major : String
-classStanding : String
-gpa : float
+setMajor() : void
+setClassStanding() : void
+computeGpa() : void
-is taken by
0..*
-takes
«extends»
0..*
«extends»
Professor
-rank : String
-tenureDate : Date
-department : String
+Professor()
+setRank() : void
+setTenureDate() : void
+setDepartment() : void
+getRank() : String
+getTenureDate() : Date
+getDepartment() : String
COMP201 - Software Engineering
1..1
CourseOffering
-sectionNo : int
-course : Course
-instructor : Professor
-schedule : String
-location : String
-maxEnrollment : int
-enrollment : int
-prerequisites : Set
+CourseOffering()
+setSectionNo() : void
+setCourse() : void
+setInstructor() : void
+setSchedule() : void
+setLocation() : void
+setMaxEnrollment() : void
+get...()
+calcAvailable() : int
0..*
-teaches
-is taught by
5
System Model Advantages
 They can be easier to understand than using a verbose
natural language description
 System models can leave out unnecessary details of the
system so way may focus on what is important
 A system representation should maintain all the
information of a system
 An abstraction deliberately simplifies the system and picks
out its most salient characteristics
 Different models can focus on different approaches to
abstraction
COMP201 - Software Engineering
6
System Model Weaknesses
 They do not model non-functional system requirements
 They do not usually include information about whether a
method is appropriate for a given problem
 They may produce too much documentation
 System models are sometimes too detailed and difficult
for users to understand
COMP201 - Software Engineering
7
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
COMP201 - Software Engineering
8
Context Models
 Context models are used to illustrate the boundaries of a
system
 Identifying the boundaries of the system to be developed is
not always straightforward
 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
COMP201 - Software Engineering
9
Example – Architectural Model of an ATM System
Security
system
Branch
accounting
system
Account
database
Auto-teller
system
Branch
counter
system
Usage
database
Maintenance
system
COMP201 - Software Engineering
10
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
COMP201 - Software Engineering
11
Example Process Model
Equipment Procurement Process
Specify
equipment
requir ed
Equipment
spec.
Validate
specification
Equipment
spec.
Supplier
database
Delivery
note
Checked
spec.
Supplier list
Find
suppliers
Accept
delivery of
equipment
Get cost
estimates
Spec. +
supplier +
estima te
Choose
supplier
Order
notification
Order
details +
Blank order
form
Within system
boundary
Place
equipment
order
Checked and
signed order form
Delivery
note
Check
delivered
items
Installation
instructions
Install
equipment
Installation
acceptance
Accept
delivered
equipment
Equipment
details
Equipment
database
COMP201 - Software Engineering
12
Behavioural Models
 Behavioural models are used to describe the overall
behaviour of a system
 Two types of behavioural model
 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
 Both of these models are required for a description of the
system’s behaviour
COMP201 - Software Engineering
13
Data-Processing Models
 Data flow diagrams are used to model the system’s data
processing
 These show the processing steps as data flows through a
system
 IMPORTANT part of many analysis methods
 Simple and intuitive notation
 Show end-to-end processing of data
COMP201 - Software Engineering
14
Example - Order Processing Data Flow Diagram
Or der
details +
blank
order form
Completed
order form
Complete
order form
Signed
order form
Valida te
order
Signed
order form
Send to
supplier
Record
order
Order
details
Signed
order form
Checked and
signed order
+ order
notification
Adjust
available
budget
Order
amount
+ account
details
Orders
file
COMP201 - Software Engineering
Budget
file
15
Data Flow Diagrams
 Data Flow Diagrams track and document 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
COMP201 - Software Engineering
16
Data Flow Diagrams
 Data Flow Diagrams have an advantage in that they are
simple and intuitive and can thus be shown to users who
can help in validating the analysis
 Developing data flow diagrams is usually a top-down
process
 We begin by evaluating the overall process we wish to
model before considering sub-processes
 Data flow diagrams show a functional perspective where
each transformation represents a single function or
process which is particularly useful during requirements
analysis since it shows end-to-end processing.
COMP201 - Software Engineering
17
DFD Context diagram
Dried
ingredients
hoppers
Numeric key
pad
Key codes
Drink choice
Hopper
on/off
cup solenoid
Paper
on/off
cup
mechanism cup in place
Pricing information
Availability information
Service inforation
Hopper
low signal
Drinks machine
controller
r
Hot water system
te re
a
t w a tu
Ho per
m
te
Electric
element on/off Hot water valve
open/close
Holding
vessel valve
open/close
Holding
vessel
Coin codes
Service
request
Stirrer on/off
Coin sense
mechanism
Alphanumeric
display
Modem
Stirrer
Temperature
control
Hot water
temperature
Key
Pad
ke y
co d
Level 0 DFD
es
door
service
price a
nd
availab
ility
informa
tion
Alpha
display
hot water element on/off
Operation
control
ta
holding vesse
l
control
Dr
e
alv
rv
ate f
t w n/of
ata
o
ed
da
Sales
data
ci p
es
Modem
hopper motors
on/off
Re
l
Sa
Service data
Maintenance
mode
control
Make
drinks
control
ho
Control
service
request
k
dr
co
in
de
k
st m
at ad
us e
engineering
codes
ink
d a sa l e
ta
s
ON/OFF
Coin
mechanism
oid
n
e
ol f
?
p s n/of
ce
u
a
l
c
o
p
in
p
cu
dr
in
Hopper low?
se d
Coin codes
Hopper low?
Hoppers
open/clo
Drink
recipes
Sales log
3SFE519 S Coope 2004
slide 19
ke
yc
od
Engineering
codes
es
key codes
Drink
code
Product availability
information
Control
maintenance
mode
rd
Passwo
d
receive
Process key
codes
Echo
Alpha
display
k
rin
D ata
d
Coin
codes
Coin
mechanism
reader
Current
Credit
Drink
recipes
Cu
Cr rren
ed t
it
Coin
mechanism
Drink
dispense
control
for
id de
Pa k co
in
Dr
t
Hoppers
ena
bl
mai e disab
nten
le
a
n
mod ce
e
Drink
queue
Alpha
display P
ro
p a mp
ym t f
en or
Drink
Available Drink
availability
code
Hopper low?
checker
door
service en
op
closed
P
Dri aid fo
nk
r
co d
e
Key
Pad
Credit
Update
Credit
Store
COMP201 - Software Engineering
Level 1 DFD
Operation control
3SFE519 S Coope 2004
slide 20
20
Statechart Diagrams
 Statechart Diagrams (or State machine models ) show the
behaviour of the system in response to external and
internal events
 They show the system’s responses to stimuli (the eventaction paradigm) so are often used for modelling real-time
systems
 Statechart diagrams show system states as nodes and
events as arcs between these nodes. When an event
occurs, the system moves from one state to another
 Statecharts are an integral part of the Unified Modeling
Language (UML)
COMP201 - Software Engineering
21
Statechart Diagrams
 An initial state is denoted by a solid circle and is optional
(sometimes the system will start in different places and
thus the initial state should be omitted).
 If required, a final state can also be used; this is denoted
by a solid circle with a ring around it.
 We use a level of abstraction so that we can observe the
essential behaviour of the system we want to model.
 Rounded rectangles are used for states. Each state contains
two components, the state name and a brief description of
the action performed in that state (see next slide).
COMP201 - Software Engineering
22
Example - Microwave Oven Model
Full
power
Timer
Waiting
do: display
time
Half
power
A state machine model
does not show flow of
data within the system
Full power
do: set power
= 600
Number
Full
power
Half
power
Door
closed
Timer
Door
open
Half power
do: set power
= 300
Operation
do: operate
oven
Set time
do: get number
exit: set time
Door
closed
Cancel
Start
Enabled
do: display
'Ready'
Door
open
Waiting
do: display
time
Disabled
Q: Why is there
no final state?
do: display
'Waiting'
COMP201 - Software Engineering
23
Microwave Oven Stimuli
Stimulus
Half power
Full power
Timer
Number
Door open
Door closed
Start
Cancel
Description
The user has pressed the half power button
The user has pressed the full power button
The user has pressed one of the timer buttons
The user has pressed a numeric key
The oven door switch is not closed
The oven door switch is closed
The user has pressed the start button
The user has pressed the cancel button
COMP201 - Software Engineering
24
Statecharts
 Statecharts also allow the decomposition of a model
into sub-models (see figure on next slide).
 A brief description of the actions is included following
the ‘do’ in each state (the word “do” is optional).
 Can be complemented by tables describing the states
and the stimuli.
COMP201 - Software Engineering
25
Statechart Diagram
Operation
Checking
do: check
status
Cook
do: run
generator
OK
Emitter
fault
Turntable
fault
Time
Timeout
Done
do: buzzer on
for 5 secs.
Alarm
do: display
event
Door
open
Disabled
COMP201 - Software Engineering
Cancel
Waiting
26
Statechart Diagrams
 The label on an arc can denote the method called to
move from one state to the next (the event).
 A guard is used to ensure that the system only moves
from one state to the other if the expression is
satisfied.
 A state can contain a subdiagram within it (also called
a composite state). This is useful for example when we
wish to model a subsystem or substates.
 On the next slide, we can see all these elements of a
UML statechart diagram
COMP201 - Software Engineering
27
Statechart Diagrams
Guard
Initial state
Final state
COMP201 - Software Engineering
Composite
States
Actions
28
Finite State Machines
• Finite State Machines (FSM), also known as Finite
State Automata (FSA) are models of the behaviours
of a system or a complex object, with a limited
number of defined conditions or modes, where
mode transitions change with circumstance.
Question: What
language does this
FSA recognise?
COMP201 - Software Engineering
29
Finite State Machines - Definition

A model of computation consisting of
 a set of states,
 a start (initial) state,
 an input alphabet, and
 a transition function that maps input symbols
What language
is recognised
by this FSA?
and current states to a next state
 You may recall finite state
machines (or automata)
from COMP209.
COMP201 - Software Engineering
30
Finite State Machines - Definition
 Computation begins in the start state with an input
string. It changes to new states depending on the
transition function.
 states define behaviour and may produce actions
 state transitions are movement from one state to another
 rules or conditions must be met to allow a state transition
 input events are either externally
or internally generated, which
may possibly trigger rules and
lead to state transitions.
COMP201 - Software Engineering
31
Lecture 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