System Modeling

in the textbook

System Modeling • 5.1 Context models

• 5.2 Interaction models
• 5.3 Structural models

Chapter 5 • 5.4 Behavioral models

• 5.5 Model-driven engineering

1 2

System Modeling System Perspectives

• System modeling is Different perspectives presented by models:
- the process of developing abstract representations of a
system • external (or context): shows context or
- each model presents a different perspective of that system. environment of the system
• interaction: shows interaction
• System models are Abstract - between the system and its environment, or
- Not an alternate representation - between components within the system
- Some details are left out
- Incomplete
• structural: shows organization of the system
or structure of data
• behavioral: shows dynamic behavior,
including how the system responds to events
3 4
 System Modeling UML Diagrams
• Notation used to represent the models: We’ll discuss these UML Diagrams
-
❖
Graphical (diagrams)
UML=Unified Modeling Language
• Activity diagrams: the activities in a process.
- Formal/mathematical (ch 12) • Use case diagrams: interactions between a
system and its environment.
• Models of the system are used in: • Sequence diagrams: interactions between
- Requirements development
❖ clarification, discussion
actors and the system and components.
- Design process • Class diagrams: classes in the system and
❖ represent plans for implementation the associations between these classes.
- Model-driven engineering
• State diagrams: how the system reacts to
• Precision and completeness: not always necessary events.
5 6

5.1 Context Models Simple Context Model

Static view

• Primarily an external perspective • Used to define system boundaries

- shows how the system is situated or involved in its - determines what is done by the system, and what will be
context done manually or by some other system
- stakeholders must decide on this early

• Two sub-views within the perspective:

• Represented as a box and line diagram:
- Static view: shows what other systems the system will - Boxes show each of the systems involved
interact with - Lines show interaction between systems
- Technically NOT a UML diagram
- Dynamic View: shows how the system is involved in
business processes

7 8
 Fig 5.1: The context of the MHC-PMS UML Activity Diagram
Dynamic view

«system»
Patient record
• Used to show how the system is used in
«system»
system business processes
«system»
Management

•
Admissions
reporting
system
system Shows activity and flow of control
«system»
MHC-PMS

«system»
«system»
Prescription
filled circle: start
HC statistics
system system filled concentric circle: finish
«system»
Appointments rounded rectangles: activities
system
rectangles: other objects (ie the different systems in fig 5.2)
arrows: flow of work
diamonds: branch (and merge)
Note: <<system>> is an example of a “stereotype” in UML
guards: condition under which flow is taken out of branch
A mechanism to categorize an element in some way
solid bar: activity coordination/concurrency control (fork, join)

9 10

Fig 5.2: Process model of involuntary detention 5.2 Interaction Models

Example of a UML Activity diagram
• These model interactions
- between the system and environment or users
- between components within the system
Transfer to
[not available]

• Uses:
Confirm police station
detention
decision Find secure
place

[dangerous]
[available]
Transfer to
secure hospital
Inform
social care
- between user and system: developing requirements
Inform
patient of Inform next
- between system components: help to understand flow of
rights of kin
control in an object oriented system, used in design
Record Update
Admit to

• UML Use Case Diagrams:

detention register
hospital
decision [not
dangerous]
«system»

«system»
«system»
Admissions
MHC-PMS - represent user-system interactions
MHC-PMS system

• UML Sequence Diagrams:

Note: This diagram is missing one branch and 2 merge diamonds - represent interactions between components (and actors)
11 12
 5.2.1 Use Case Modeling Fig 5.3: Transfer data use case

• Main purpose: requirements elicitation + analysis Example of a UML Use case diagram

• Use Case: overview of one user/system interaction

- Focused on one goal of the actor

• Use Case Diagram components: Transfer data

- stick figure: actor (user or system)
Medical receptionist Patient record system
- ellipse: named interaction (verb-noun)
- line: indicates involvement in interaction

• Diagram is supplemented with further details Note: arrows are not part of UML, but shows direction of data flow

describing the use case: Note: primary actor on left, supporting actor on right
- simple textual description or
- structured description (form/template/table) or
- sequence diagram(s)
13 14

Fig 5.4: Tabular description of

Fig 5.5: Use cases involving Medical Receptionist
Transfer data use case
A composite use case diagram:
MHC-PMS: Transfer data all interactions involving a given actor

Actors Medical receptionist, patient records system (PRS)

Register
patient
Description A receptionist may transfer data from the MHC-PMS to a
general patient record database that is maintained by a health
authority. The information transferred may either be updated
Unregister
personal information (address, phone number, etc.) or a
summary of the patient’s diagnosis and treatment. patient

Data Patient’s personal information, treatment summary

View patient
info.
Stimulus User command issued by medical receptionist
Medical
Response Confirmation that PRS has been updated receptionist
Transfer data

Comments The receptionist must have appropriate security permissions

to access the patient information and the PRS.
Contact
patient

15 16
 5.2.2 Sequence Diagram Fig 5.6: View patient information
Example of a UML Sequence diagram
• Models the interactions between actors and/or
objects or components within the system in detail Medical Receptionist
A window from the user interface

• Can be used to show the sequence of interactions P: PatientInfo D: MHCPMS-DB AS: Authorization

in a given use case ViewInfo (PID)

report (Info, PID,
UID)

• Diagram notes: authorize (Info,

UID) PID: patient ID
UID: user ID
Read sequence from top to bottom: it’s chronological authorization Info: kind of info
to be returned
alt
objects and actors: listed across top with dotted lines going down [authorization OK] Patient info
boxes on dotted line: lifetime of operation (in this interaction)
dotted arrows between lines from objects: interactions [authorization fail] Error (no access)
annotations on arrows: calls to objects with parameters, return values
box named alt with conditions in brackets: for branching/alternatives
17 18

Sequence Diagram Uses 5.3 Structural Models

• Requirements Development: • Display the organization of the system in terms
- To document/discuss requirements (especially operations) of its components and relationships
- These diagrams must leave out detail (objects)
❖ so as not to constrain developers
- For example:
Minimal sequence diagram: only two components: user and system
• Static Models
- shows the structure of the system
Use to show sequence of interactions between user and system
- or just the structure of the data
• Design/Implementation:
- Details are required: • Dynamic Models
- Messages must match objects’ methods - shows organization of system when it is executing
(processes/threads)
- Include arguments in method calls between objects
- (won’t be discussing these)
- Source of the arguments should be indicated
19 20
 5.3.2 UML Class Diagrams Fig 5.8: UML Classes and association

• Static model
Patient
1 1 Patient
record
• Shows classes and associations between them
• Uses: Two classes and one association
(a one-to-one relationship)
- developing requirements: model real-world objects
- during design phase: add implementation objects
1 1
• Simple class diagrams: Patient
Instructor
1..* Patient
Course
record
Section
- Box represents a class (with a name)
- Lines show associated between classes (name optional) Two classes and one association
- Number at each end to show how many objects can be (a one-to-many relationship)
involved in the association (multiplicity)
How many instructors does a Course Section have?

21 22

Fig 5.9: Classes and associations in the

Fig 5.10: Consultation class, in more detail
MHC-PMS

Consultant Consultation
1
referred-to Doctors
1..* Date
1..* 1..* 1..* 1 Time
General Clinic
Condition Patient
practitioner Attributes, Note: Don’t record
diagnosed- referred-by Reason
with 1..* types optional Medication prescribed associated classes here
attends Treatment prescribed
1..* Voice notes
prescribes Transcript
Consultation Medication ...
1..* 1..*
1..*
runs prescribes New ( )
Treatment Operations, param + Prescribe ( )
1..4 RecordNotes ( )
1..* return types optional
Hospital Transcribe ( )
Doctor ...

23 24
 5.3.2 Generalization Fig 5.11: Generalization hierarchy

• Act of identifying commonality among concepts,

defining: Doctor

- a general concept (superclass)

- specialized concept(s) (subclasses). Hospital
doctor
General
practitioner

• Example: University personnel Consultant Team doctor

- Faculty, Staff, Students (graduate, undergrad)
- All university personnel have ID numbers
- All students have majors Trainee
doctor
Qualified
doctor

• Common attributes are stored in superclass only

- avoids duplication
Arrow points to superclass
- changes affecting how ID number is implemented happens
in University personnel class only
25 26

Fig 5.12: Generalization with added detail 5.3.3 Aggregation

Doctor
• When objects are composed of separate parts
Attributes + operations of Name - ex: a (university) class is composed of a faculty member
superclass also belong to Phone # and several students
Email
subclass objects
(they are inherited) register ( )
de-register ( ) • UML: aggregation is a special kind of association
- diamond at end of line closest to “whole” class

Hospital doctor General practitioner • When implemented, the composite usually has
Staff # Practice instance variables for each “part” object
Pager # Address

Subclass adds more specific

attributes + operations

27 28
 Fig 5.13: Aggregation association 5.4 Behavioral models
• Represent dynamic behavior of the system as it is
Class
Patient record executing
Section

1 1 • More of an “internal” view of the system

1 1..*
• Sequences of Actions:
Patient
Faculty Consultation
Student - UML Activity diagrams (flow of actions, slide 10)
- UML Sequence diagrams (sequence of interactions, slide 17)
- Data-flow diagrams (DFD)

• States of an object or system, with transitions

- UML state diagrams

29 30

Example Data Flow Diagram:

5.4.1 Data-flow diagram Order Processing

• Many systems are (were?) data-processing systems,

primarily driven by data.
- One of the first graphical software models (pre UML)

• DFD models the flow of data through a process

- collection of connected functions, each with input and output data
- shows dependencies of functions
- more functional or procedural -oriented

• Useful during requirements analysis:

- simple and intuitive, users can validate proposed system Oval: functional processing
Rectangle: data store
Labeled arrow: data input/output and movement
31 32
 Fig 5.16
5.4.2 UML State diagrams State diagram of a microwave oven
• Describes Full
power Full power

- all the states an (object or component or system) can get into do: set power
= 600

- how state changes in response to events (transitions) Timer

Waiting
Number

•
do: display
Useful when object/component/system is changed by Full Set time Operation
time
power do: get number do: operate
exit: set time oven
events (real time and embedded systems, etc.) Half
Half
power
Door
power Cancel
Timer closed

•
Start
Components of a state diagram Door
open
Enabled
Door
Waiting
Half power open
- Rounded rectangles: system states do: set power
= 300
Door
closed
do: display
'Ready'
do: display
time

‣ includes what action to do in that state

Disabled
- Labeled arrow: stimuli to force transition between states do: display
'Waiting'

‣ optional guard: transition allowed only when guard is true

‣ unlabeled arrow: transition occurs automatically when Diagram is missing (at least) one arrow
action is complete
33 34

5.5 Model Driven Engineering (MDE)

• Software development where models (rather than
source code) are the principal outputs of the
development process.
- Developers generate programs automatically from the models.
- Developers test and debug models rather than source code.

• Models are often extensions of UML models

• Some problems:
- Models are inherently too abstract to be a basis for the
implementation (need alternate representation)
- Not enough good tools supporting model compilation and
debugging yet.

35