Software Engineering
System Models
Software Engineering
System Models
Slide 1
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 Modeling Language, UML)
Software Engineering
System Models
Slide 2
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
Software Engineering
System Models
Slide 3
System models 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
The system models are sometimes too
detailed and difficult for users to understand
Software Engineering
System Models
Slide 4
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
Software Engineering
System Models
Slide 5
1. Context models



Context models are used to illustrate the
boundaries of a system
Social and organisational concerns may affect
the decision on where to position system
boundaries
Architectural models show the a system and
its relationship with other systems
Software Engineering
System Models
Slide 6
The context of an ATM system
Security
system
Branch
accounting
system
Account
database
Auto-teller
system
Branch
counter
system
Usage
database
Maintenance
system
Software Engineering
System Models
Slide 7
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
Software Engineering
System Models
Slide 8
Equipment procurement process
Delivery
note
Specify
equipment
requir ed
Equipment
spec.
Validate
specification
Equipment
spec.
Supplier
database
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
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
Software Engineering
System Models
Slide 9
2 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
Software Engineering
System Models
Slide 10
2.1 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 that customers
can understand
Show end-to-end processing of data
Software Engineering
System Models
Slide 11
Order processing DFD
Or der
details +
blank
order form
Signed
order form
Completed
order form
Complete
order form
Signed
order form
Send to
supplier
Record
order
Valida te
order
Order
details
Signed
order form
Checked and
signed order
+ order
notification
Adjust
available
budget
Order
amount
+ account
details
Orders
file
Software Engineering
System Models
Budget
file
Slide 12
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
Software Engineering
System Models
Slide 13
2.2 State machine models




State Machine models the behaviour of the
system in response to external and internal
events
They show the system’s responses to stimuli so
are often used for modelling real-time systems
State machine models 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 UML
Software Engineering
System Models
Slide 14
Microwave oven model
Full
power
Timer
Waiting
do: display
time
Half
power
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
Cancel
Door
open
Half power
do: set power
= 300
Operation
do: operate
oven
Set time
do: get number
exit: set time
Door
closed
Start
Enabled
do: display
'Ready'
Door
open
Waiting
do: display
time
Disabled
do: display
'Waiting'
Software Engineering
System Models
Slide 15
Microwave oven stimuli
Stimulus
Half power
Full power
Timer
Number
Door open
Door closed
Start
Cancel
Software Engineering
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
System Models
Slide 16
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.
Software Engineering
System Models
Slide 17
Finite state machines - Definition
A model of computation consisting of
• a set of states,
• a start state,
• an input alphabet, and
• a transition function that maps input symbols and current states
to a next state

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
Software Engineering
System Models
Slide 18
Variants of FSMs

There are many variants, for instance,
• machines having actions (outputs) associated with
transitions (Mealy machine) or states (Moore
machine),
• multiple start states,
• transitions conditioned on no input symbol (a null) or
more than one transition for a given symbol and
state (nondeterministic finite state machine),
• one or more states designated as accepting states
(recognizer), etc.
Software Engineering
System Models
Slide 19
Finite State Machines with Output
(Mealy and Moore Machines)


Finite automata are like computers in that they
receive input and process the input by changing
states. The only output that we have seen finite
automata produce so far is a yes/no at the end
of processing.
We will now look at two models of finite
automata that produce more output than a
yes/no.
Software Engineering
System Models
Slide 20
Moore machine

Basically a Moore machine is just
a FA with two extras.
1. It has TWO alphabets, an input and output alphabet.
2. It has an output letter associated with each state. The machine
writes the appropriate output letter as it enters each state.
This machine might be
considered as a
"counting" machine.
The output produced by the machine contains a 1 for each
occurrence of the substring aab found in the input string.
Software Engineering
System Models
Slide 21
Mealy machine

Mealy Machines are exactly as powerful as Moore
machines


(we can implement any Mealy machine using a Moore machine,
and vice versa).
However, Mealy machines move the output function from
the state to the transition. This turns out to be easier to
deal with in practice, making Mealy machines more
practical.
Software Engineering
System Models
Slide 22
A Mealy machine produces output on a
transition instead of on entry into a state.
Transitions are labelled i/o where
•
•
i is a character in the input alphabet and
o is a character in the output alphabet.
The following Mealy machine takes the one's
complement of its binary input. In other words, it
flips each digit from a 0 to a 1 or from a 1 to a 0.


Mealy machine are complete in the sense that there is a
transition for each character in the input alphabet leaving
every state.
There are no accept states in a Mealy machine because
it is not a language recogniser, it is an output producer.
Its output will be the same length as its input.
Software Engineering
System Models
Slide 23
Statecharts



Allow the decomposition of a model into sub-models (see a figure)
A brief description of the actions is included following the ‘do’ in each
state
Can be complemented by tables describing the states and the
Operation
stimuli
Time
Checking
do: check
status
Turntable
fault
Cook
do: run
generator
OK
Emitter
fault
Timeout
Done
do: buzzer on
for 5 secs.
Alarm
do: display
event
Door
open
Disabled
Software Engineering
Cancel
Waiting
System Models
Slide 24
Petri Nets Model



Petri Nets were developed originally by
Carl Adam Petri, and were the subject of his
dissertation in 1962.
Since then, Petri Nets and their concepts have
been extended, developed, and applied in a
variety of areas.
While the mathematical properties of Petri Nets
are interesting and useful, the beginner will find
that a good approach is to learn to model
systems by constructing them graphically.
Software Engineering
System Models
Slide 25
The Basics



A Petri Net is a collection of
directed arcs connecting places
and transitions.
Places may hold tokens.
The state or marking of a net is
its assignment of tokens to
places.
Place with
token
P1
Arc with capacity 1
T1
Place
P2
Software Engineering
System Models
Transition
Slide 26
Capacity





Arcs have capacity 1 by default; if other than
1, the capacity is marked on the arc.
Places have infinite capacity by default.
Transitions have no capacity, and cannot store
tokens at all.
Arcs can only connect places to transitions
and vice versa.
A few other features and considerations will be
added as we need them.
Software Engineering
System Models
Slide 27
Enabled transitions and firing


A transition is enabled when the number of tokens in
each of its input places is at least equal to the arc weight
going from the place to the transition.
An enabled transition may fire at any time.
Software Engineering
System Models
Slide 28
When arcs have different weights…


When fired, the tokens in the input places are moved to
output places, according to arc weights and place
capacities.
This results in a new marking of the net, a state
description of all places.
Software Engineering
System Models
Slide 29
A collection of primitive structures that
occur in real systems
Software Engineering
System Models
Slide 30
3. Semantic data models




Used to describe the logical structure of data
processed by the system
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
Software Engineering
System Models
Slide 31
Software design semantic model
Design
1
name
description
C-date
M-date
is-a
has-nodes
1
has-links
1
n
n
1
Node
has-links
1
name
type
2
Link
n
1
links
1
name
type
1
has-labels
has-labels
Label
n
Software Engineering
name
text
icon
n
System Models
Slide 32
Data dictionary entries
Data dictionaries are lists of all of the names used
in the system models.
Descriptions of the entities, relationships and
attributes are also included
Name
Description
1:N relation between entities of type Node or
has-labels
Link and entities of type Label.
Holds structured or unstructured information
Label
about nodes or links. Labels are represented by
an icon (which can be a transparent box) and
associated text.
A 1:1 relation between design entities
Link
represented as nodes. Links are typed and may
be named.
Each label has a name which identifies the type
name (label) of label. The name must be unique within the
set of label types used in a design.
Each node has a name which must be unique
name (node) within a design. The name may be up to 64
characters long.
Software Engineering
System Models
Type
Date
Relation
5.10.1998
Entity
8.12.1998
Relation
8.12.1998
Attribute
8.12.1998
Attribute
15.11.1998
Slide 33
4. Object models



Object models describe the system in terms
of object classes
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
Software Engineering
System Models
Slide 34
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
Software Engineering
System Models
Slide 35
The Unified Modeling Language



Devised by the developers of widely used object-oriented
analysis and design methods
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
Software Engineering
System Models
Slide 36