System Design

Modeling
with
Unified Modeling Language (UML)

System modeling 1
System modeling
● Abstract models of a system
● Ignores system details
● Different perspectives of system
● Helps understanding the functionality of
the system
● Used to communicate with customers and
teams

System modeling 2
Let’s take a familiar example
● Proposal for Web (1989) by

● Big issues:
● security,
● surveillance
● privacy
● open infrastructure Sir Tim Berners-Lee
● net neutrality
● content protection History of the Web
● …

System modeling 3
Proposal for Information
Management at CERN by TBL

Written:
March1989
Redistributed:
May 1990

'Vague, but exciting’

Mike Sendall
(Boss)

System modeling 4
System Image

System modeling 5
 The Xerox "Star" System

Source:
http://www.digibarn.com/friends/curbow/star/retrospect/
First Graphical
Web Browser
MOSAIC
Developed in 1992 at
National Center for
Supercomputing
Applications (NCSA)
U of Illinois @
Urbana–Champaign
by
for Unix (X-Windows)
by two students Marc
Andreessen and Eric Bina

License: Free for

non-commercial
https://en.wikipedia.org/wiki/Mosaic_(web_browser)
System modeling 7
Models various perspectives
● External perspective ● Structural perspective
● the context or ● organization of a system
environment of the ● the structure of the data
system.

● Interaction perspective ● Behavioral perspective

● between system and its ● dynamic behavior
environment ● how it responds to events
● between components of
a system

System modeling 8
Overview of UML Diagrams
Behavioral
behavioral features of a system /
Structural business process
● Activity
● element of spec.
● State machine
● Class
● Use case
● Component
● Object
Interaction
object interaction
irrespective of time
● Communication
(collaboration)
● Sequence
UML
● Graphical Language

● Describe the blueprint of software system

● Visualize
● Specify
● Construct
● Document
Who Uses UML
● Software teams
● Overview of system
● Functionality of system

● Customers during communication

Who needs to understand the system?
Owners: To assure they are ● Technical Writers: To know
getting what they paid for how to document the system
Developers: To know what to ● IT Operations/Support: To
develop know how to install and
maintain the system
Testers: To know what to test
● Users: To know how to use
Managers: To know where the system
the system will be deployed
Unified Modeling Language (UML)
Visual Notation for modeling perspectives of a system

● Use case diagrams ● Sequence diagrams interactions

● interactions between between
system & environment ● actors & system
● system components
● Class diagrams
● object classes ● Activity diagrams
● associations between ● Activities in a process
classes
● State diagrams
● system response to internal
and external events

System modeling 13
Context models
● Operational context

● Relationship to other system

● Shows boundaries
● what is inside and what is outside

● Boundary setting is important

● Huge impact on requirements

System modeling 14
Context Models
<<system>>
Appointment System

<<system>> <<system>> <<system>>

Patient Information Clinic Prescription

<<system>>
Reporting

15
Interaction models: Use-case
● User interaction with system
● What kinds of users exist?
● What can each kind of user do?
● Useful for requirements
● Reveals communication issues during
requirement elicitation

System modeling 16
Use case modeling
● Describes what users can do?
● Each use case represents a discrete task
● Involves external interactions
● Actors
● People
● Organizations
● Other systems

System modeling 17
Use Cases
● High-level, User-centric requirements
● A use case specifies
● a sequence of actions

● observable to users

● includes variants

▪ Used for eliciting/elaborating user requirements

Use Case
● Focuses on user perspective
● Actors interact with the System under discussion
● Actors can be
● People
● Systems
● Organizations
● Need to define system boundaries
i.e. ATM of a Bank
● Who are the actors?
● Card holders
● Bank customers
● Note that not all card holders are bank customers
● VISA authorization system
● Bank Information System
● Maintenance Operators
Use Case Diagram Symbols

Generalization
Specialized Behavior <<extend>>
«extend» relationships modifies base use case
Example Use Cases -- <<include>>
Use case: Registration System
Registration System

Consent
Request

Submit
Program
student

Make Payment

Login Payment
system

Teacher Approve
Note: This diagram is illustrative. There are
Program
many more use-cases.

System modeling 24
Description Add class use-case
Registration

Actor Student
Description A student may add a course to their program
during the registration period provided that they
have made their payments and have fulfilled all
prerequisite courses.
Data Course code and section
Stimulus Add course information during creating program
Response See course in the tentative course program list
Comments Student must be logged in. The quota of the
course must not have been exceeded.

System modeling 25
Structural models
● Organization of a system
● components of the system
● relationships between components

● Useful in designing the system architecture

System modeling 26
Class diagrams
● Object-oriented system model

● Classes in a system

● Relationships between classes

System modeling 27
UML classes and association

1 1 Transcript
Student

System modeling 28
 Book Class

System modeling 29
Generalization
● Represents shared properties and behavior
● OOP
● Inheritance
● Superclasses – shared properties
● Low level classes have specific details

System modeling 30
Generalization / Inheritance

31
 Association

Composition - Vanishes if parent ceases to exist

engine is destroyed if car is destroyed
Aggregation - Has own lifecycle
passenger goes on living if car is destroyed
32
Interaction models: Sequence
● Shows interaction between system components

● How they are related?

● What data flows between them to handle a

use case?
● Useful to determine if the system design will

satisfy requirements

33
 Sequence Diagrams
● Shows interactions between objects with lifelines

● Objects are arranged in a time sequence

(shows temporal sequence relations)

● Typically shows object interaction for one use case

34
Sequence diagrams
● Actors & Objects are listed at the top
● Lifelines (dotted line) drawn vertically from them.
● Shows the duration of the involvement

Get_Info(PID) PatientInfo

● Interactions between objects

● shown with annotated arrows
● shows the data being sent (via message) to
components

System modeling 35
Sequence
Diagrams
● Lifelines
● Objects
● Subsystems
● Lifelines are arranged horizontally.
● Time represented vertically
● Messages
● represented with a solid horizontal arrows
● return values with dashed lines
● The execution or activation of an operation
● represented with a rectangle
● placed on relevant lifeline.
36
 Message Calls
● Synchronous messages
● denoted with full arrowhead
● caller’s execution is suspended until flow of control
is returned to it.
● Asynchronous messages
● denoted with line arrowheads
● processing continues without waiting for response

37
Reply Message
● A reply message returns the control to the caller
object

● Shown with a dashed arrow

● Their use is optional when obvious (to reduce clutter).

In our class we will always indicate them.

● Assume that control is returned to caller object

38
Basic Sequence Diagram
Notice:

r1 through r3
hide
information.
Should
explicitly show
how r2 is
obtained via
self call.

39
Self calls and clear returns

40
 External API
(Can also
SD-1 Fetch Tweets by Keywords denote with
Stick Figure

System modeling 41
Conditions/Exception Handling

42
Focus of Control
● Indicates when processing happens in an object
(activation)

● When an activation is waiting, it does not have

focus of control.

43
Activation - Shows Control

44
Repetition

45
Notes

46
References

47
Refer to other Sequence Diagrams
Show Activations
Activations

Shows focus
of control

Obtained from http://www.plantuml.com/plantuml

49
Asynchronous Message
● Asynchronous message
● drawn with an open arrowhead
● does not halt execution to wait for a return
● Real-time systems
● Concurrency
● Callback to caller can be used to signal
completion

50
Interaction Operators
Interaction Explanation and use
Operator
alt Alternatives represents alternative behaviours, each choice of behaviour being shown in a separate
operand. The operand whose interaction constraint is evaluated as true executes.
opt Option describes a single choice of operand that will only execute if its interaction constraint evaluates
as true.
break Break indicates that the combined fragment is performed instead of the remainder of the enclosing
interaction fragment.
par Parallel indicates that the execution operands in the combined fragment may be merged in any
sequence once the event sequence in each operand is preserved.
seq Weak Sequencing results in the ordering of each operand being maintained but event occurrence from
different operands on different lifelines may occur in any order. The order of event occurrences on
common operands is the same as the order of the operands.
strict Strict Sequencing imposes a strict sequence on execution of the operands but does not apply to nested
fragments.
neg Negative describes an operand that is invalid.

critical Critical Region imposes a constraint on the operand that none of its event occurrences on the lifelines in
the region can be interleaved.
ignore Ignore indicates the message types, specified as parameters, that should be ignored in the interaction.

consider Consider states which messages should be consider in the interaction. This is equivalent to stating that
all others should be ignored.
assert Assertion states that the sequence of messaging in the operand is the only valid continuation.

loop Loop is used to indicate an operand that is repeated a number times until the interaction constraint for
the loop is no longer true.

51
Guidelines for Sequence Diagrams
1. Decide a level of modelling the
interaction
2. Identify the main elements involved
in the interaction
3. Identify alternative scenarios
4. Draw an outline
5. Refine with detail

52
Behavioral models
● Dynamic behavior of a system as it is executing.
● How system responds to a stimulus from its
environment.
● Stimulus:
● Data data to be processed reaches system
● Event triggers some action – may have data

System modeling 53
Behavior perspective
● Shows how the system is used
● Process-oriented
● Activities and their relationships
● UML activity diagrams

System modeling 54
Data-driven modeling
● Controlled by the data input to the system
● Models show the sequence of I/O actions:
● Processing input data
● Generating output

System modeling 55
Activity Diagrams
● Model user requirements:
● Describe a business process
● Flow between users and system

● Model use case:

● Describe steps performed in a use case

● Model System Functions:

● Describe a method, function or operation in software

System modeling 56
Activity Diagrams
● Models flow of control
● Start node (filled circle)
● Finish node (a circle that contains a filled circle)
● Activity node – Actions, process (rectangle with
rounded corner)
● Object node – Data (rectangle)
● Conditions (Diamond)
● Parallelism
● Fork (Bar that splits flow control)
● Join (Bar that joins flow of control)

System modeling 57
Process model:
Handle Order

System modeling 58
Order initial

Handling
action

fork

decision
guard

merge

join

Created using UMLet final

59
Event-driven modeling
● How does system respond to external and internal
events.

● System has a finite number of states

● Events cause a transition from one state to

another

System modeling 60
Statecharts:
State machine models
● States are represented as nodes

● Events are represented with arcs between nodes

● When an event occurs

● the system moves from one state to another

System modeling 61
State diagram of a microwave oven

System modeling 62
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’.
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.

System modeling 63
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.

System modeling 64
Microwave oven operation

System modeling 65
Process model: involuntary detention

System modeling 66
References
The Original Proposal of WWW

CERN 2019 WorldWideWeb Rebuild

Drawing diagrams:
https://plantuml-documentation.readthedocs.io

Some examples refer to Sommerville’s book on “Software

Engineering”

67