Week 5:

System Modeling
Nguyễn Thị Minh Tuyền

Adapted from slides of Ian Sommerville

 Topics covered
1. Context models
2. Interaction models
3. Structural models
4. Behavioral models
5. Model-driven engineering

2
 System modeling
£ Is the process of developing abstract models
of a system
p each model presents a different view or
perspective of that system.
£ Represent a system using some kind of
graphical notation
p based on notations in the Unified Modeling
Language (UML).
£ Helps the analyst to understand the
functionality of the system and models are
used to communicate with customers.
3
 Existing and planned system models

£ Models of the existing system are used during

requirements engineering.
p Clarify what the existing system does and
p Are used as a basis for discussing its strengths and
weaknesses.
£ Models of the new system are used during
requirements engineering
p Help explain the proposed requirements to other system
stakeholders.
p Are used for discussing design proposals and for
documenting 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. 4
 Model the interactions
System perspectives between a system and its
environment, or between the
Model the context or components of a system
environment of the
system

external interaction
perspective perspective

System

behavioral structural
perspective perspective

Model the dynamic Model the organization

behavior of the of a system or the
system and how it structure of the data
responds to events. that is processed by the
system.
5
 Các loại biểu đồ UML

NGUYỄN Thị Minh

 UML diagram types
The UML has many diagram types and supports many different types of system model.
Five diagram types could represent the essentials of a system:

Activity diagram
Show the activities involved in a process or in data processing.

Use case diagram

Show the interactions between a system and its environment.

Sequence diagram
Show interactions between actors and the system and between system
components.
Class diagram
Show the object classes in the system and the associations between
these classes.
State diagram
Show how the system reacts to internal and external events. 7
 Use of graphical models
£ As a means of facilitating discussion about an
existing or proposed system
p Incomplete and incorrect models are OK as their role is
to support discussion.
£ As a way of documenting an existing system
p Models should be an accurate representation of the
system but need not be complete.
£ As a detailed system description that can be used
to generate a system implementation
p Models have to be both correct and complete.

8
 Topics covered
1. Context models
2. Interaction models
3. Structural models
4. Behavioral models
5. Model-driven engineering

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

10
 System boundaries
£ System boundaries are established to define what
is inside and what is outside the system.
p 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
p There may be pressures to develop system boundaries
that increase / decrease the influence or workload of
different parts of an organization.

11
 The context of the Mentcare
system
«system»
Patient record
system
«system»
«system»
Management
Admissions
reporting
system
system
«system»
Mentcare

«system» «system»
HC statistics Prescription
system system
«system»
Appointments
system

12
 The context of the ATM system

<<system>>
<<system>> Security system
<<system>>
Branch Accounting
Account DB
system

<<system>>
ATM System

<<system>>
<<system>>
Branch counter
Usage DB
system <<system>>
Mantainance
system

Nguyễn Thị Minh Tuyền 13

 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.

14
 Process model of involuntary detention

Transfer to
[not available] police station
Confirm
detention
decision Find secure
place
Transfer to
Inform
[available] secure hospital
[dangerous] social care
Inform
patient of Inform next
rights of kin

Record Update
Admit to
detention register
hospital
decision [not
dangerous]
«system»
«system» Mentcare
«system» Admissions
Mentcare system

15
 Topics covered
1. Context models
2. Interaction models
3. Structural models
4. Behavioral models
5. Model-driven engineering

16
 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.
£ Two approaches to interaction modeling:
p Use case diagrams and
p sequence diagrams.
17
 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 diagrammatically to provide an
overview of the use case and in a more detailed
textual form.
18
 Transfer-data use case
£ A use case in the Mentcare system

Transfer data

Medical receptionist Patient record system

19
 Use cases in the Mentcare system
involving the role ‘Medical Receptionist’

Register
patient

Unregister
patient

View patient
info.
Medical
receptionist
Transfer data

Contact
patient

20
Example: Use-case specification
 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.
24
 Sequence diagram for View patient
information Object
and actor
Medical Receptionist

P: PatientInfo D: Mentcare-DB AS: Authorization

ViewInfo (PID)
report (Info, PID,
UID) lifeline
authorize (Info,
message UID)

Execution
authorization
specification
alt
[authorization OK] Patient info
return
message
Condition
[authorization fail] Error (no access)

Alternatives
25
Sequence diagram for Transfer Data
Medical Receptionist PRS

P: PatientInfo D: MHCPMS-DB AS: Authorization

login ( )
ok

alt
[sendInfo]
updateInfo( ) updatePRS (UID )
authorize (TF, UID)
authorization
update (PID)
update OK
Message (OK)

[sendSummary]
UpdateSummary( )
summarize (UID )
authorize (TF, UID)
authorization

:summary

update (PID)
update OK
Message (OK)

logout ( )
26
 Topics covered
1. Context models
2. Interaction models
3. Structural models
4. Behavioral models
5. Model-driven engineering

27
 Structural models
£ Display the organization of a system in terms of
the components that make up that system and
their relationships.
£ May be
p static models, which show the structure of the system
design, or
p dynamic models, which show the organization of the
system while executing.
£ Create structural models of a system when you are
discussing and designing the system architecture.

28
 Class diagrams
£ 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.
£ During the early stages of the software
engineering process, objects represent
something in the real world.
p For example: a patient, a prescription, doctor, etc.

29
 UML classes and association

1 1 Patient
Patient record

Association

Class

30
Classes and associations in the MHC-
PMS
Consultant
1
referred-to
1..*
1..* 1..* 1..* 1
Condition Patient General
referred-by practitioner
diagnosed-
with 1..*
attends
1..*
prescribes
Consultation Medication
1..* 1..*
1..*
runs prescribes
1..4 Treatment
1..*
Hospital
Doctor
31
The Consultation class
Class name
Consultation

Doctors
Date Attributes
Time
Clinic
Reason
Medication prescribed
Treatment prescribed
Voice notes
Transcript
...
Operations

New ( )
Prescribe ( )
RecordNotes ( )
Transcribe ( )
...
32
 Generalization [1]
£ Is an everyday technique to manage complexity.
£ Rather than learn the detailed characteristics of
every entity, we place these entities in more
general classes (animals, cars, houses, etc.) and
learn the characteristics of these classes.
£ Allows us to infer that different members of these
classes have some common characteristics.

33
 Generalization [2]
£ In object-oriented languages, such as Java,
generalization is implemented using the class
inheritance mechanisms built into the language.
£ In a generalization:
p The attributes and operations associated with higher-
level classes are also associated with the lower-level
classes.
p The lower-level classes are subclasses inherit the
attributes and operations from their superclasses.
These lower-level classes then add more specific
attributes and operations.

34
 A generalization hierarchy

Doctor

Hospital General
doctor practitioner

Consultant Team doctor

Trainee Qualified
doctor doctor
35
A generalization hierarchy with
added detail
Doctor
Name
Phone #
Email

register ( )
de-register ( )

Hospital doctor General practitioner

Staff # Practice
Pager # Address

36
 Object class aggregation models
£ Show how classes that are collections are
composed of other classes.
£ Are similar to the part-of relationship in semantic
data models.

37
The aggregation association

Patient record

1 1
1 1..*
Patient Consultation

38
 Topics covered
1. Context models
2. Interaction models
3. Structural models
4. Behavioral models
5. Model-driven engineering

39
 Behavioral models
£ Models of the dynamic behavior of a system as it
is executing.
p 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:
p Data Some data arrives that has to be processed by the
system.
p Events Some event happens that triggers system
processing. Events may have associated data, although
this is not always the case.
40
 Data-driven modeling
£ Many business systems are data-processing
systems that are primarily driven by data.
p 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.

41
 An activity model of the insulin pump’s
operation
data flow processing step
(represented as objects) (represented as activities)

Blood sugar Get sensor Sensor Compute Blood sugar

sensor value data sugar level level

Calculate
insulin
delivery

Control Calculate
Insulin Pump control Insulin
pump pump
pump commands requirement
commands

42
 Order processing
Purchase officer Supplier

«datastore»
:Order Budget
Orders

Fillin ( )
Validate ( )

[validation ok]

Update (amount)

Save ( )
Send ( )

43
 Event-driven modeling
£ Real-time systems are often event-driven, with
minimal data processing.
£ Event-driven modeling shows how a system
responds to external and internal events.
£ It is based on the assumption that
p a system has a finite number of states and
p events (stimuli) may cause a transition from one state to
another.

44
 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.
p When an event occurs, the system moves from one
state to another.
£ State charts are an integral part of the UML and
are used to represent state machine models.
45
 State diagram of a microwave
Full
oven
power Full power
do: set power
= 600

Timer
Waiting
Number
do: display Operation
Full Set time
time
power do: get number do: operate
exit: set time oven
Half
Half power
Door
power Cancel
Timer closed
Start
Door
open Door
Half power Enabled Waiting
open
do: set power Door do: display do: display
= 300 closed 'Ready' time

Disabled
do: display
'Waiting'

46
 States for the microwave oven

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’.
The cooking time is set to the user’s input value. The display shows
Set time
the cooking time selected and is updated as the time is set.
Oven operation is disabled for safety. Interior oven light is on.
Disabled
Display shows ‘Not ready’.
Oven operation is enabled. Interior oven light is off. Display shows
Enabled
‘Ready to cook’.
Oven in operation. Interior oven light is on. Display shows the timer
countdown. On completion of cooking, the buzzer is sounded for five
Operation
seconds. Oven light is on. Display shows ‘Cooking complete’ while
buzzer is sounding.

47
 Stimuli for the microwave oven

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.

48
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

49
Questions?

50