CH 7

System models
● Abstract descriptions of
systems whose requirements
are being analysed
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1

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)
● To show how CASE workbenches support
system modelling

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

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

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

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

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
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

B
racsB
ayoruannecctm S
hihgAseyc u
ri
t
y
m A
c
o
u
n
d
a
t
b
a
st
e
us t
yo e
l
m r
The context of an ATM system
csoyutm er M asinytem
ance U
s
a
g
e
d
t
b
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

S
p
ieqe
fruEc
m y
trquE
q
nu
i
p
m
s
ce
n
t
.
sV
p
ea
c l
i
fd ate
i
o
nC
he
c
k
d
s
p
.G
e
s
it

c
mo
as
et D enl
i
v
e
r
o
t
A
d
e
l
i y
c
vep
r
yt

o f D
el
i
v
e
r
y
n
o
tC
d h
l
ivec
r kd
d Spc
.

+ q
u m n t m s
Equipment procurement process
iS
u p sp
m
e
n
c
.t
ldatbaiser suF Su
p
l
ie
r

l
i
s
t
ipnlders sCh
os
u
est
m
el
i
e
r
a
t
uplirBO
rd d n o
e O
t
i
f rd
e
c
a
t
i
o
P
e
q
u
o n
l
ia
p
m
r
dc
en t I
e
q
u n
is
pta
l
m I
i
en
ns
t
a
l
r
u
c
tt
i
o
n
s
len
tfakrilm
os +
rsigC
h
e
c k d A
d
e
nd oreanfodrmqum c
l
iv e
p
r I
ac
t
d
ns
a
l
e
pt
i
o
n
c
e
E
q u
idatpbm Equ
i
p
m
d
e
t
a
easnte
n
t
l
s
Behavioural models
● Behavioural models are used to describe the
overall behaviour of a system
● Two types of behavioural model are shown here
• 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

Dataprocessing models
● Data flow diagrams are used to model the
system’s data processing
● These show the processing steps as data flows
through a system
● Intrinsic part of many analysis methods
● Simple and intuitive notation that customers can
understand
● Show endtoend processing of data

O
rodrebtad
einlfsok r+C
o
m
p
l
r
d
e

f
oC
o
m
r
d
e
t
r
m
m Op
l
e
t

f
o
rd
m
Va
l
i
d
a
t
e
o
rS
o
r
di
g
n
e
d

f
o
rm Roo
e r
c
r
d S
di
g
n

fe
od
rm sS
e
u
A pn
d d
j
l
ut
i
e
so
r
t C
h
e
s
i
g
+
oc
k
d
n
o

t
f
i
c
a
a
n
d
r
e
t
i
n
rtd
eailsorS av
iblagbe+
Order processing DFD
idgn
e fodrm a

dO
r
d
e
m
o
u
n
c
e
t
i
lt
s
O rfd
eilsB ufidlget
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

Idnepsu
tignR
D
sedD
ifede g
tdatsiebgo n V
da
l
i
d
e
s
g
n
rnacsnsedC D
cdrhoesike si
g
n
gcnhkC
h
d
e
rdC
ae
sc
nk
i
g
d nd D
an es
i
g
n
l
y
erD
ae
ns
i
g
n
l
ys
gR
n ep oartU
s
e
r
r
p
ot
O
u t
p
CASE toolset DFD
ogden skrealtroncodedD
eatsbigane
State machine models
● These model 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 realtime 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

F
uw
p
olerd
F
u
o
:
= l
s 6e
p
t
0o
we
r
T
im
e
r
W
iH a
tadlof: dm
n
s
pg
l
ay N
u
mb
e
r
Microwave oven model
pow
er d e pH
o wa lf
ep
rF
u
o
wl
e
r
T
id
o
m
e
r:
x S
ige t
s i
n m
u te b
r
cD
o
r
l
s
e
d O
p
e
r
a
t
d
o
:

vi
o
n
eC
a
nc
e
l
H a
l o:=
fs3e t0pow
erD Dpoe nrcDlo
r
s
edE
n
a
d
o
:

d
'
RS
b
l
e
d
i
s
p
at
a
r
y
' D
o
r
p
e
n W
a
d
o
:
i
t
n
g
d
s
p
l
a
m
ey
©Ian Sommerville 2000
ido:'W
s dabp
ltinedgy'
Software Engineering, 6th edition. Chapter 7 Slide 18
Microwave oven state description

Microwave oven stimuli

Statecharts
● Allow the decomposition of a model into sub
models (see following slide)
● A brief description of the actions is included
following the ‘do’ in each state
● Can be complemented by tables describing the
states and the stimuli

C
d h
o
s : te

a c k
ui
sn gO
p
e
O
Kr
a
t
i
on
d
oC
o
:

r
u
n
g
e k
r
aT
i
t
o
rm
e
T
ufrntabdloA
e:l deavirsm E
m
it
e
r T
i
m
e
ou
t
Microwave oven operation
f
a
ul
pnltayD d
oD
o
:

b
u
fzn
5er

o
n
s
c
.
D
isabled W o
p
er
naitng C
a
n
ce
l
Semantic data models
● Used to describe the logical structure of data
processed by the system
● Entityrelationattribute 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

1
is

a n
d
C
M D
a
m
c
e
r
as
i
g
n
p
t
o
e 1 h
a
s
l
i
n
k
s
hasnodensN 1
Software design semantic model
tyn
o
d
e
a
m
p1
2 h a
s
l
i
nl
i
n
k
s
k
s n
1L
i
n
k
a
m
e
t
y
pn
1
haslbelsnntiecL
axom
beln 1
h
a
s
l
b
e
l
s
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

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

Object models
● Natural ways of reflecting the realworld 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 superclasses. these may then
be specialised as necessary
● Class hierarchy design is a difficult process if
duplication in different branches is to be avoided

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

AL
iC
aT
tN
lA
cS
q
u
iC b
o
g
s
tytoacapm r
u a
eo y
n ite m
qteusbligre uo(f)cudoaptbieesr
D
I
Ri
s
p
u
t o
s
e
(
)
r
n
Library class hierarchy
lTPu b
iitlesrhed item T MR
e
c
o
i
t
l
d
ur
d
e

mi
t
em
Au
tE
d
iPh
b
lISB
o
r
nk
on date P
c
a
tB
iN Y
IseM
a
g
z
a
r
ui
n
e D i
ar
se c
tF
o
f
bi
l
m
r
e
a
us
e V
e rsC
p
io
m
p
u
t
e
r
g
a
m
n
latfomr
P
RL
iN
aA
m
d
h
o
g
iD b
e
nrsa y us
tesrea (io)rn #er
A Read
r
filtion S ItafM
team Bor wer
xs. nlsanS
User class hierarchy
D eparm
en phoneM a
jH
o
rm tude n
t
esabjrcs
Multiple inheritance
● 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 superclasses
● Can lead to semantic conflicts where
attributes/services with the same name in
different superclasses have different semantics
● Makes class hierarchy reorganisation more
complex

A
du
tE
iP
Multiple inheritance
h
b
lISB
o
r
n
c
a
tB
iNk
on dateR V
S
p
D
uo
i
a
rc
e

r
k
t
i
oc
nordin
g
ecdg date
T a
l# pkeisng bok
Object aggregation
● Aggregation model shows how classes which are
collections are composed of other classes
● Similar to the partof relationship in semantic
data models

Object aggregation
S
tC
N
o
rY
m u
s
bd
ey pac
k
tIneatucoirle
A
sC
iredtgnm
entS OH P
lideslidesT L
excotusreT
n V
iapd eost.ape
# D
PE xer
c
rosblmi
se
ptonD TeS
xto
lu
t
i
o
n
s
iagrm
Object behaviour modelling
● A behavioural model shows the interactions
between objects to produce some particular
system behaviour that is specified as a usecase
● Sequence diagrams (or collaboration diagrams) in
the UML are used to model interaction between
objects

:L
ibray U
seL
roD E
c
a
t
:
C
lo
g :
L
i
br
a
y

I
te
mL
i
N
eb
1
:
t
S
r
ve
k u p
Issue of electronic items
iAscIeuppet llaiycenIsue licen
Deliver C
o
mp
r
e
s
CASE workbenches
● A coherent set of tools that is designed to support
related software process activities such as
analysis, design or testing
● Analysis and design workbenches support system
modelling during both requirements engineering
and system design
● These workbenches may support a specific design
method or may provide support for a creating
several different types of system model

tdiconry dS
D a tiagruocm
Ce n
tlsreidng gfR
tral
eancp
Q
o
rlaietsn
u
e ry
C
gceF
no o d
reartm e ien
aitsnr D frsigo m
ipn,s aoy n l
fa
n cg
i
l a
t g e
s
An analysis and design workbench
a d
l tos facils
c h e k ly
ns
i
g I
mpo rt
/
e x po
r
t
Analysis workbench components
● Diagram editors
● Model analysis and checking tools
● Repository and associated query language
● Data dictionary
● Report definition and generation tools
● Forms definition tools
● Import/export translators
● Code generation tools

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
● Object models describe the logical system entities
and their classification and aggregation
● CASE workbenches support the development of
system models

CH 7

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CH 7

Uploaded by

Copyright:

Available Formats

System models

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 2

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 3

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 4

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 5

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 6

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 8

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 10

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 12

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 13

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 15

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 17

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 19

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 20

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 21

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 23

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 25

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 26

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 27

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 28

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 29

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 30

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 33

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 35

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 37

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 39

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 41

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 43

You might also like