System Models: October 14, 2009

System models
October 14, 2009
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 1

System modelling
 System modelling helps the analyst to
understand the functionality of the system
and models are used to communicate with
customers.

System models
 Different models present the system from
different perspectives
• External (or Context) perspective
• Show the system’s context or environment;
• Behavioural perspective
• Show the behaviour of the system;
• Structural perspective
• Show the system or data architecture.

Model types

Data processing model
• Shows how data is processed at different stages

Composition model
• Shows how entities are composed of other entities

Architectural model
• Shows principal sub-systems

Model types
 Classification model
• Shows how entities have common
characteristics
 Stimulus/response model
• Shows the system’s reaction to events.

Context Models

Context models

Context models
• Illustrate the operational context of a system
• Show what lies outside system boundaries

Social and organisational concerns may affect the
decision on where to position system boundaries.
 Ideally, the boundaries between the system and its

environment are identified clearly.

Context models
 Various models can be used for context
modeling:
• Very simple, high-level architectural models
• Show the system and its connections with
environmental components
• High-level process models
• Indicate main process activities
• High-level data-flow diagrams
• Depict data transformations and data transfers

The context of an ATM system
Security
system
Branch
Account
accounting
da tabase
system
Auto-teller
system
Branch
Usage
counter
database
system
Maintenance
system

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
Delivery
note
Checked Delivery
Equipment spec. note
Specify spec. Accept Check
Valida te Get cost
equipment deli very of delivered
specification estima tes
requir ed equipment items
Spec. +
supplier + Installa tion
Equipment estima te Order instructions
spec. Supplier list notifica tion
Place
Supplier Find Choose Install
equipment
da tabase suppliers supplier Order equipment
order
details plus
blank or der Installa tion
for m acceptance
Accept
delivered
Check ed and
equipment
signed or der form
Equipment
details
Equipment
da tabase

Behavioral Models

Behavioural models
 Behavioural models
• Describe overall behaviour of a system.
 Two types of behavioural model are:

• Data processing models
• State machine models

Data-processing models
 Data flow diagrams (DFDs)
• Used to model the system’s data processing.
 Show processing steps as data flows through a system.
 Part of many analysis methods.
 Simple and intuitive notation
 Show end-to-end processing of data.

Order processing DFD
Checked and
Completed Signed Signed Send to signed or der
order for m order for m order form supplier + or der
Order
notifica tion
details + Complete Valida te Record
blank or der form order or der
or der form Adjust
Order availab le
Signed
details budget
order form
Order
amount
+ account
details
Orders Budget
file file

Data flow diagrams
 Model systems from a functional
perspective.
 May show data exchange between a system

and other systems in its environment.

Insulin pump DFD
Blood
Blood parameters
Blood sugar Blood sugar
Blood sugar
sensor analysis level
Insulin
requir ement
computa tion
Pump contr ol
Insulin commands Insulin Insulin
Insulin delivery requir ement
pump contr oller

State machine models
 Model the behaviour of the system in response to
external and internal events.
 Show the system’s responses to stimuli
 Often used for modelling real-time systems.
 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
 Allow the decomposition of a model into sub-
models.
 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.

Microwave oven model
Full
po w er Full po wer
do: set power
= 600
Timer
Waiting
Number
do: display Operation
Full Set time
time
po wer do: get number do: operate
exit: set time oven
Half
Half po wer
Door
po wer Timer closed Cancel
Start
Door
open
Door
Half po wer Enabled Waiting
open
do: set power Door do: display do: display
= 3 00 closed 'Ready' time
Disab led
do: display
'Waiting'

Microwave oven state description
State Description
Waiting The oven is waiting for input. The display shows the current time.
Half power The oven power is set to 300 watts. The display shows ŌHalf powerÕ.
Full power The oven power is set to 600 watts. The display shows ŌFull powerÕ.
Set time The cooking time is s et to the userÕs input value. The display shows the cooking time
selected and is updated as the time is set.
Disabled Oven operation is disabled for safety. Interior oven light is on. Display shows ŌNot
readyÕ.
Enabled Oven operation is enabled. Interior oven light is off. Display shows ŌReady to cookÕ.
Operation Oven in operation. Interior oven light is on. Display shows the timer countdown. On
completion of cooking, the buzzer is sounded for 5 s econds. Oven light is on. Display
shows ŌCooking completeÕ while buzzer is sounding.

Microwave oven stimuli

Microwave oven operation
Operation
Time
Checking
OK Cook
do: check
do: run
status
generator
Turntable Emitter Timeout

fault fault
Done
Alarm
do: buzzer on
do: display
for 5 secs.
event
Door open Cancel
Disabled Waiting

Semantic data models
 Describe the logical structure of data
processed by the system.
 Entity-relation-attribute (ERA) model

Widely used in database design.
• Can readily be implemented using relational
databases.

Library semantic model
Article Source
published-in
title m n title
authors publisher
pdf file fee-payable-to issue
1 date
fee
pages
1
1
delivers
1 in
n 1
Order Copyright Country
Agency 1 in 1
order number copyright form
total payment name tax rate
has-links
address
date
tax status
n
places
1
Buyer
name
address
e-mail
billing info

Data dictionaries

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
 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.

Distinguishing Principles of OO
 Principles that distinguish object-orientation
from function-orientation (imperative
programming)
• Encapsulation
• Inheritance
• Polymorphism

Types of Relationships in OO
1. “is a” - inheritance
2. “has a” - encapsulation (aggregation)
3. “association” - anything else

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
• Requires 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.

Library class hierarchy
Library item
Catalo gue n umber

Acquisition da te
Cost
Type
Status
Number of copies
Acquire ()
Catalo gue ()
Dispose ()
Issue ()
Return ()
Pub lished item Recorded item

Title Title
Pub lisher Medium
Book Magazine Film Computer

pro gram
Author Year Director
Edition Date of release Version
Issue
Pub lication da te Distrib utor Pla tfor m
ISBN

User class hierarchy
Library user
Name
Address
Phone
Reg istration #
Reg ister ()
De-reg ister ()
Reader Borrower
Affiliation Items on loan
Max. loans
Staff Student
Depar tment Major subject
Depar tment phone Home ad dress

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 super-classes.
 This can lead to semantic conflicts where

attributes/services with the same name in different
super-classes have different semantics.
 Multiple inheritance makes class hierarchy

reorganisation more complex.

Multiple inheritance
Book Voice recording

Author Speak er
Edition Duration
Pub lication da te Recording da te
ISBN
Talking book
# Tapes

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 aggregation
Study pack
Course title
Number
Year
Instructor
Assignment OHP slides Lecture Videota pe

notes
Credits Slides Text Tape ids .
Exercises Solutions
#Pr ob lems Text
Description Diagrams

Object behaviour modelling
 Shows interactions between objects.
 Sequence diagrams (or collaboration

diagrams) in the UML are used to model
interaction between objects.

Issue of electronic items
Ecat: Lib1:
:Library Item NetServer
Catalog
:Library User
Lookup
Display
Issue
Issue licence
Accept licence
Compress
Deliver

System Models: October 14, 2009

Uploaded by

Document Information

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

System Models: October 14, 2009

Uploaded by

Copyright:

Available Formats

System models

October 14, 2009

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 1

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 2

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 3

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 4

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 5

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

 Ideally, the boundaries between the system and its

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

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

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 9

 Data flow models may be used to show the

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 10

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 11

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 12

 Two types of behavioural model are:

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 13

 Show processing steps as data flows through a system.

 Part of many analysis methods.

 Simple and intuitive notation

 Show end-to-end processing of data.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 14

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 15

 May show data exchange between a system

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 16

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 17

 Show the system’s responses to stimuli

 Often used for modelling real-time systems.

 Show system states as nodes and events as arcs

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 18

 A brief description of the actions is included

 Can be complemented by tables describing

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 19

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 20

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 21

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 22

Turntable Emitter Timeout

Door open Cancel

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 23

 Entity-relation-attribute (ERA) model

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 24

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 25

 Many CASE workbenches support data dictionaries.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 26

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 27

 An object class is an abstraction over a set of

 Various object models may be produced

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 28

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 29

2. “has a” - encapsulation (aggregation)

3. “association” - anything else

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 30

 Object class identification is recognised as a difficult

 Object classes reflecting domain entities are

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 31

 Class hierarchy design can be a difficult process if

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 32

 It has become an effective standard for

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 33

Catalo gue n umber

Pub lished item Recorded item

Book Magazine Film Computer