Chapter 5 – System Modeling
30/10/2014 Chapter 5 System Modeling 1
Topics covered
Context models
Interaction models
Structural models
Behavioral models
Model-driven engineering
30/10/2014 Chapter 5 System Modeling 2
System modeling
System modeling is the process of developing abstract
models of a system, with each model presenting a
different view or perspective of that system.
System modeling has now come to mean representing a
system using some kind of graphical notation, which is
now almost always based on notations in the Unified
Modeling Language (UML).
System modelling helps the analyst to understand the
functionality of the system and models are used to
communicate with customers.
30/10/2014 Chapter 5 System Modeling 3
Existing and planned system models
Models of the existing system are used during requirements
engineering. They help clarify what the existing system does
and can be used as a basis for discussing its strengths and
weaknesses. These then lead to requirements for the new
system.
Models of the new system are used during requirements
engineering to help explain the proposed requirements to
other system stakeholders. Engineers use these models to
discuss design proposals and to document the system for
implementation.
In a model-driven engineering process, it is possible to
generate a complete or partial system implementation from
the system model.
30/10/2014 Chapter 5 System Modeling 4
System perspectives
An external perspective, where you model the context or
environment of the system.
An interaction perspective, where you model the
interactions between a system and its environment, or
between the components of a system.
A structural perspective, where you model the
organization of a system or the structure of the data that
is processed by the system.
A behavioral perspective, where you model the dynamic
behavior of the system and how it responds to events.
30/10/2014 Chapter 5 System Modeling 5
UML diagram types
Activity diagrams, which show the activities involved in a
process or in data processing .
Use case diagrams, which show the interactions
between a system and its environment.
Sequence diagrams, which show interactions between
actors and the system and between system components.
Class diagrams, which show the object classes in the
system and the associations between these classes.
State diagrams, which show how the system reacts to
internal and external events.
30/10/2014 Chapter 5 System Modeling 6
Context models
30/10/2014 Chapter 5 System Modeling 7
Context models
Context models are used to illustrate the operational
context of a system - they show what lies outside the
system boundaries.
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.
30/10/2014 Chapter 5 System Modeling 8
System boundaries
System boundaries are established to define what is
inside and what is outside the system.
They show other systems that are used or depend on the
system being developed.
The position of the system boundary has a profound
effect on the system requirements.
Defining a system boundary is a political judgment
There may be pressures to develop system boundaries that
increase / decrease the influence or workload of different parts
of an organization.
30/10/2014 Chapter 5 System Modeling 9
The context of the Mentcare system
30/10/2014 Chapter 5 System Modeling 10
Process perspective
Context models simply show the other systems in the
environment, not how the system being developed is
used in that environment.
Process models reveal how the system being developed
is used in broader business processes.
UML activity diagrams may be used to define business
process models.
30/10/2014 Chapter 5 System Modeling 11
Process model of involuntary detention
30/10/2014 Chapter 5 System Modeling 12
enter password
and user ID
Activity Diagram valid passwords/ ID invalid passwords/ ID
select major function prompt for reentry
other f unctions
may also be
selected
input t ries remain
select surveillance
no input
t ries remain
t humbnail views select a specif ic camera
select specific
select camera icon
camera - thumbnails
view camera output
in labelled window
prompt for
another view
These slides are designed to accompany Software Engineering: A Practitioner’s
exit this f unctApproach,
ion 7/e see anot her camera
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 13
h o m e o wn e r c a m e ra i n t e rf a c e
Swimlane enter password
and user ID
Diagrams valid passwo rd s/ ID
in valid
p asswo rds/ ID
select major function
Allows the modeler
to represent the flow o th er f u n ctio n s
may also be
prompt for reentry
of activities selected
described by the use- select surveillance
inp u t tries
remain
case and at the same
time indicate which n o in p ut
tries remain
actor (if there are
multiple actors
involved in a specific thu mb n ail views select a sp ecif ic camera
use-case) or analysis
class has
select specific
responsibility for the camera - thumbnails
select camera icon
action described by
an activity rectangle
generate video
output
view camera output prompt for
in labelled window another view
exit th is
f u n ctio n
see
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e an o th er
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. camera 14
Interaction models
30/10/2014 Chapter 5 System Modeling 15
Interaction models
Modeling user interaction is important as it helps to
identify user requirements.
Modeling system-to-system interaction highlights the
communication problems that may arise.
Modeling component interaction helps us understand if a
proposed system structure is likely to deliver the required
system performance and dependability.
Use case diagrams and sequence diagrams may be
used for interaction modeling.
30/10/2014 Chapter 5 System Modeling 16
Use case modeling
Use cases were developed originally to support
requirements elicitation and now incorporated into the
UML.
Each use case represents a discrete task that involves
external interaction with a system.
Actors in a use case may be people or other systems.
Represented diagramatically to provide an overview of
the use case and in a more detailed textual form.
30/10/2014 Chapter 5 System Modeling 17
Transfer-data use case
A use case in the Mentcare system
30/10/2014 Chapter 5 System Modeling 18
Tabular description of the ‘Transfer data’ use-
case
MHC-PMS: Transfer data
Actors Medical receptionist, patient records system (PRS)
Description A receptionist may transfer data from the Mentcase
system to a general patient record database that is
maintained by a health authority. The information
transferred may either be updated personal information
(address, phone number, etc.) or a summary of the
patient’s diagnosis and treatment.
Data Patient’s personal information, treatment summary
Stimulus User command issued by medical receptionist
Response Confirmation that PRS has been updated
Comments The receptionist must have appropriate security
permissions to access the patient information and the
PRS.
30/10/2014 Chapter 5 System Modeling 19
Use cases in the Mentcare system involving the
role ‘Medical Receptionist’
30/10/2014 Chapter 5 System Modeling 20
Sequence diagrams
Sequence diagrams are part of the UML and are used to
model the interactions between the actors and the
objects within a system.
A sequence diagram shows the sequence of interactions
that take place during a particular use case or use case
instance.
The objects and actors involved are listed along the top
of the diagram, with a dotted line drawn vertically from
these.
Interactions between objects are indicated by annotated
arrows.
30/10/2014 Chapter 5 System Modeling 21
Sequence diagram for View patient information
30/10/2014 Chapter 5 System Modeling 22
Sequence
diagram for
Transfer Data
30/10/2014 Chapter 5 System Modeling 23
homeowner control panel system sensors
sensors
system reading
A
ready
password entered
request lookup
comparing
result
password = correct
numberOfTries > maxTries request activation
locked
timer > lockedTime
A
selecting
activation successful activation successful
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 24
Figure 8.27 Sequence diagram (partial) for SafeHome security function
:Product :Billof FloorPlan BoM
:Room :FloorPlan
Component Materials Repository Repository
new customer
desc ribes
room*
plac es room
in f loor plan
save f loor plan c onf iguration
selec ts produc t c omponent*
add to BoM
save bill of materials
Figure 18.5 Sequence diagram for use-case:select SafeHome components
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 25
Structural models
30/10/2014 Chapter 5 System Modeling 26
Structural models
Structural models of software display the organization of
a system in terms of the components that make up that
system and their relationships.
Structural models may be static models, which show the
structure of the system design, or dynamic models,
which show the organization of the system when it is
executing.
You create structural models of a system when you are
discussing and designing the system architecture.
30/10/2014 Chapter 5 System Modeling 27
Class diagrams
Class diagrams are used when developing an object-
oriented system model to show the classes in a system
and the associations between these classes.
An object class can be thought of as a general definition
of one kind of system object.
An association is a link between classes that indicates
that there is some relationship between these classes.
When you are developing models during the early stages
of the software engineering process, objects represent
something in the real world, such as a patient, a
prescription, doctor, etc.
30/10/2014 Chapter 5 System Modeling 28
UML classes and association
30/10/2014 Chapter 5 System Modeling 29
Classes and associations in the MHC-PMS
30/10/2014 Chapter 5 System Modeling 30
The Consultation class
30/10/2014 Chapter 5 System Modeling 31
A generalization hierarchy
30/10/2014 Chapter 5 System Modeling 32
A generalization hierarchy with added detail
30/10/2014 Chapter 5 System Modeling 33
Object class aggregation models
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.
30/10/2014 Chapter 5 System Modeling 34
The aggregation association
30/10/2014 Chapter 5 System Modeling 35
CRC Models
Class-responsibility-collaborator (CRC)
modeling [Wir90] provides a simple
means for identifying and organizing the
classes that are relevant to system or
product requirements. Ambler [Amb95]
describes CRC modeling in the following
way:
A CRC model is really a collection of standard
index cards that represent classes. The cards
are divided into three sections. Along the top
of the card you write the name of the class. In
the body of the card you list the class
responsibilities on the left and the
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
collaborators
(McGraw-Hill, 2009). Slides on the right.
copyright 2009 by Roger Pressman. 36
CRC Modeling
Class:
Class:
Description:
Class:
Description:
Class:FloorPlan
Description:
Responsibility:
Description: Collaborator:
Responsibility: Collaborator:
Responsibility: Collaborator:
Responsibility: Collaborator:
defines floor plan name/type
manages floor plan positioning
scales floor plan for display
scales floor plan for display
incorporates walls, doors and windows Wall
shows position of video cameras Camera
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 37
Class Types
Entity classes, also called model or business classes, are
extracted directly from the statement of the problem (e.g.,
FloorPlan and Sensor).
Boundary classes are used to create the interface (e.g.,
interactive screen or printed reports) that the user sees and
interacts with as the software is used.
Controller classes manage a “unit of work” [UML03] from start to
finish. That is, controller classes can be designed to manage
the creation or update of entity objects;
the instantiation of boundary objects as they obtain information from
entity objects;
complex communication between sets of objects;
validation of data communicated between objects or between the
user and the application.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 38
Responsibilities
System intelligence should be distributed across classes
to best address the needs of the problem
Each responsibility should be stated as generally as
possible
Information and the behavior related to it should reside
within the same class
Information about one thing should be localized with a
single class, not distributed across multiple classes.
Responsibilities should be shared among related
classes, when appropriate.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 39
Collaborations
Classes fulfill their responsibilities in one of two ways:
A class can use its own operations to manipulate its own
attributes, thereby fulfilling a particular responsibility, or
a class can collaborate with other classes.
Collaborations identify relationships between classes
Collaborations are identified by determining whether a class
can fulfill each responsibility itself
three different generic relationships between classes [WIR90]:
the is-part-of relationship
the has-knowledge-of relationship
the depends-upon relationship
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 40
Composite Aggregate Class
Player
PlayerHead PlayerBody PlayerArms PlayerLegs
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 41
Associations and Dependencies
Two analysis classes are often related to one
another in some fashion
In UML these relationships are called associations
Associations can be refined by indicating multiplicity
(the term cardinality is used in data modeling
In many instances, a client-server relationship
exists between two analysis classes.
In such cases, a client-class depends on the server-
class in some way and a dependency relationship is
established
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 42
Multiplicity
Wall
1 1 1
is used to build is used to build
1..* 0..* is used to build 0..*
WallSegment Window Door
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 43
Dependencies
DisplayWindow Camera
<<access>>
{password}
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 44
Analysis Packages
Various elements of the analysis model (e.g., use-cases,
analysis classes) are categorized in a manner that
packages them as a grouping
The plus sign preceding the analysis class name in each
package indicates that the classes have public visibility
and are therefore accessible from other packages.
Other symbols can precede an element within a
package. A minus sign indicates that an element is
hidden from all other packages and a # symbol indicates
that an element is accessible only to packages
contained within a given package.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 45
Analysis Packages
package name
Environment
+Tree
+Landscape
+Road
+Wall
+Bridge
+Building RulesOfTheGame
+VisualEffect
+Scene +RulesOfMovement
+ConstraintsOnAction
Characters
+Player
+Protagonist
+Antagonist
+SupportingRole
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 46
Behavioral models
30/10/2014 Chapter 5 System Modeling 47
Behavioral models
Behavioral models are models of the dynamic behavior
of a system as it is executing. They show what happens
or what is supposed to happen when a system responds
to a stimulus from its environment.
You can think of these stimuli as being of two types:
Data Some data arrives that has to be processed by the system.
Events Some event happens that triggers system processing.
Events may have associated data, although this is not always
the case.
30/10/2014 Chapter 5 System Modeling 48
Data-driven modeling
Many business systems are data-processing systems
that are primarily driven by data. They are controlled by
the data input to the system, with relatively little external
event processing.
Data-driven models show the sequence of actions
involved in processing input data and generating an
associated output.
They are particularly useful during the analysis of
requirements as they can be used to show end-to-end
processing in a system.
30/10/2014 Chapter 5 System Modeling 49
An activity model of the insulin pump’s
operation
30/10/2014 Chapter 5 System Modeling 50
Order processing
30/10/2014 Chapter 5 System Modeling 51
Event-driven modeling
Real-time systems are often event-driven, with minimal
data processing. For example, a landline phone
switching system responds to events such as ‘receiver
off hook’ by generating a dial tone.
Event-driven modeling shows how a system responds to
external and internal events.
It is based on the assumption that a system has a finite
number of states and that events (stimuli) may cause a
transition from one state to another.
30/10/2014 Chapter 5 System Modeling 52
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 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 and are used
to represent state machine models.
30/10/2014 Chapter 5 System Modeling 53
State diagram of a microwave oven
30/10/2014 Chapter 5 System Modeling 54
Microwave oven operation
30/10/2014 Chapter 5 System Modeling 55
States and stimuli for the microwave oven (a)
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 set 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 five
seconds. Oven light is on. Display shows ‘Cooking complete’ while
buzzer is sounding.
30/10/2014 Chapter 5 System Modeling 56
States and stimuli for the microwave oven (b)
Stimulus Description
Half power The user has pressed the half-power button.
Full power The user has pressed the full-power button.
Timer The user has pressed one of the timer buttons.
Number The user has pressed a numeric key.
Door open The oven door switch is not closed.
Door closed The oven door switch is closed.
Start The user has pressed the Start button.
Cancel The user has pressed the Cancel button.
30/10/2014 Chapter 5 System Modeling 57
State Diagram for the ControlPanel Class timer < lockedTime
timer > lockedTime locked
password = incorrect
& numberOfTries < maxTries
reading comparing numberOfTries > maxTries
key hit
password
entered do: validatePassword
password = correct
selecting
activation successful
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 58