System Modeling

Dynamic Modeling
 Dynamic Modeling

• Dynamic Modeling
– Dynamic Modeling with UML
– Dynamic Modeling overview
– How do we detect Operations?
– Event
• Sequence diagrams
• State diagrams
• Using dynamic modeling for the design of user interfaces
• Dominant Models based on system features
 Dynamic Modeling with UML

• Two UML diagrams types for dynamic modeling:

– Interaction diagrams describe the dynamic behavior between
objects
– Statechart diagrams describe the dynamic behavior of a single
object.
 UML Interaction Diagrams

– Sequence Diagram:
• Describes the dynamic behavior of several objects over time
• Good for real-time specifications
 UML State Chart Diagram

• State Chart Diagram:

– A state machine that describes the response of an object of a given
class to the receipt of outside stimuli (Events).
 Dynamic Modeling

• Definition of a dynamic model:

– Describes the components of the system that have interesting
dynamic behavior
• The dynamic model is described with
– State diagrams: One state diagram for each class with interesting
dynamic behavior
• Classes without interesting dynamic behavior are not modeled with state
diagrams
– Sequence diagrams: For the interaction between classes
• Purpose:
– Detect and supply operations for the object model.
 How do we detect Operations?

• We look for objects, who are interacting and extract their

“protocol”
• We look for objects, who have interesting behavior on their own
• Good starting point: Flow of events in a use case description
• From the flow of events we proceed to the sequence diagram to
find the participating objects.
 What is an Event?

• Something that happens at a point in time

• An event sends information from one object to another
• Events can have associations with each other:
– Causally related:
• An event happens always before another event
• An event happens always after another event
– Causally unrelated:
• Events that happen concurrently
• Events can also be grouped in event classes with a hierarchical
structure => Event taxonomy
 Dynamic Modeling

• Dynamic Modeling
• Sequence diagrams
– Sequence Diagram Overview
– Purpose Sequence Diagram
– Stair Diagram
– Fork Diagram
– Sequence Diagram UML Representation
– Sequence Diagram Examples
• State diagrams
• Using dynamic modeling for the design of user interfaces
• Dominant Models based on system features
 Sequence Diagram

• A sequence diagram is a graphical description of the objects

participating in a use case
• Heuristic for finding participating objects:
– A event always has a sender and a receiver
– Find them for each event => These are the objects participating in
the use case.
• Sequence Diagrams are interaction diagrams that detail how
operations are carried out.
• Are time focused and show the order of the interaction visually by
using the vertical axis of the diagram to represent time what
messages are sent and when.
 Purpose of Sequence Diagram

• Model high-level interaction between active objects in a system

• Model the interaction between object instances within a
collaboration that realizes a use case
• Model the interaction between objects within a collaboration that
realizes an operation
• Either model generic interactions (showing all possible paths
through the interaction) or specific instances of a interaction
(showing just one path through the interaction)
 What else can we get out of Sequence
Diagrams?
• Sequence diagrams are derived from use cases

• The structure of the sequence diagram helps us to determine

how decentralized the system is
• We distinguish two structures for sequence diagrams
– Fork Diagrams and Stair Diagrams
 Fork Diagram
• The dynamic behavior is placed in a single object, usually a
control object
– It knows all the other objects and often uses them for direct questions
and commands

Control
Object
 Stair Diagram

• The dynamic behavior is distributed. Each object delegates

responsibility to other objects
– Each object knows only a few of the other objects and knows which
objects can help with a specific behavior
 Fork or Stair?

• Object-oriented supporters claim that the stair structure is better

• Modeling Advice:
– Choose the stair - a decentralized control structure - if
• The operations have a strong connection
• The operations will always be performed in the same order
– Choose the fork - a centralized control structure - if
• The operations can change order
• New operations are expected to be added as a result of new
requirements.
 Sequence Diagrams at a Glance
Sequence Diagrams show elements as they interact over time and they
are organized according to object (horizontally) and time (vertically):
• Object Dimension
– The horizontal axis shows the elements that are involved in the
interaction
– Conventionally, the objects involved in the operation are listed from
left to right according to when they take part in the message
sequence. However, the elements on the horizontal axis may appear
in any order
• Time Dimension
– The vertical axis represents time proceedings (or progressing) down
the page.
• Note that:
– Time in a sequence diagram is all a about ordering, not duration.
 Sequence Diagram UML Notation
• Actor
– a type of role played by an entity that interacts with the
subject (e.g., by exchanging signals and data)
– represent roles played by human users, external
hardware, or other subjects.
• Lifeline
– A lifeline represents an individual participant in the
Interaction. Represented with a vertical dotted line.
• Object
– drawn as a rectangle containing the name of the object,
underlined.
– An object can be named in one of three ways:
• the object name,
• the object name and its class, or
• just the class name (anonymous object).
 Sequence Diagram Notation

• Activations
– A thin rectangle on a lifeline) represents the period during
which an element is performing an operation.
– The top and the bottom of the of the rectangle are aligned
with the initiation and the completion time respectively
 Sequence Diagram Notation - Messages
• Messages depict the invocation of operations are shown horizontally.
• They are drawn from the sender to the receiver.
• Ordering is indicated by vertical position
• The line type and arrowhead type indicates the type of message
being used:
• A synchronous message
– (typically an operation call) is shown as a solid line with a filled
arrowhead.
– It is a regular message call used for normal communication between
sender and receiver.
– typically represents operation call - send message and suspend
execution while waiting for response.
 Sequence Diagram Notation - Messages
• An asynchronous message
– has a solid line with an open arrowhead.
– A signal is an asynchronous message that has
no reply.
– send message and proceed immediately
without waiting for return value

• Return message
– uses a dashed line with an open arrowhead..
– Return message is a kind of message that
represents the pass of information back to the
caller of a corresponded former message.
 Sequence Diagram Notation - Creation and
Destruction Messages
• Create Message / Constructor message
– creates its receiver.
– The sender that already exist at the start of the
interaction are placed at the top of the
diagram. Targets that are created during the
interaction by a constructor call are
automatically placed further down the diagram.
– Create message is a kind of message that
represents the instantiation of (target) lifeline.
• Destroy Message / Destructor message
– destroys its receiver.
– Destroy message is a kind of message that
represents the request of destroying the
lifecycle of target lifeline.
– Only when a target's destruction is set to 'after
destructor' do you have to use a destructor.
 Sequence Diagram Notation - Creation and
Destruction Messages
• Non instantaneous message / Duration
Message
– Messages are often considered to be
instantaneous, thus, the time it takes to arrive
at the receiver is negligible. The messages are
drawn as a horizontal arrow. To indicate that it
takes a certain while before the receiver
actually receives a message, a slanted arrow
is used.
– Duration message shows the distance
between two time instants for a message
invocation.
 Sequence Diagram Notation - Event and Focus
of Control
• An Event : is any point in an interaction where something occurs.
• Focus of control: also called execution occurrence, an execution
occurrence
• It shows as tall, thin rectangle on a lifeline)
• It represents the period during which an element is performing an
operation. The top and the bottom of the rectangle are aligned with
the initiation and the completion time respectively.
 Sequence Diagram Notation - Sequence
Fragments
• Sequence fragments make it easier to create and maintain accurate
sequence diagrams
• A sequence fragment is represented as a box, called a combined
fragment, which encloses a portion of the interactions within a
sequence diagram
• The fragment operator (in the top left cornet) indicates the type of
fragment
• Fragment types: ref, assert, loop, break, alt, opt, neg
 Sequence Diagram Notation - Sequence
Fragments
Operator Fragment Type
Alternative multiple fragments: only the one whose condition is true will
alt
execute.

Optional: the fragment executes only if the supplied condition is true.

opt
Equivalent to an alt only with one trace.

par Parallel: each fragment is run in parallel.

Loop: the fragment may execute multiple times, and the guard indicates
loop
the basis of iteration.
Critical region: the fragment can have only one thread executing it at
region
once.
neg Negative: the fragment shows an invalid interaction.

Reference: refers to an interaction defined on another diagram. The

ref frame is drawn to cover the lifelines involved in the interaction. You can
define parameters and a return value.

sd Sequence diagram: used to surround an entire sequence diagram.

Sequence Diagram Notation - Sequence
Fragments - Example
Sequence Diagram Notation - Sequence
Fragments - Example
 Sequence Diagram for Modeling Use Case
Scenarios
Main scenario
• The Customer specifies an author on the Search Page and then
presses the Search button.
• The system validates the Customer's search criteria.
• If author is entered, the System searches the Catalog for books
associated with the specified author.
• When the search is complete, the system displays the search results
on the Search Results page.

Alternate path
• If the Customer did not enter the name of an author before pressing
the Search button, the System displays an error message
Sequence Diagram for Modeling Use Case
Scenarios
 Dynamic Modeling

• Dynamic Modeling
• Sequence diagrams
• State diagrams
– State Diagram Overview
– State Chart Diagram vs Sequence Diagram
– State Diagram Components
– State Diagram Examples
• Using dynamic modeling for the design of user interfaces
• Dominant Models based on system features
 State Diagrams

• We distinguish between two types of operations:

– Activity: Operation that takes time to complete
• associated with states
– Action: Instantaneous operation
• associated with events
• A state chart diagram relates events and states for one class
• An object model with several classes with interesting behavior
has a set of state diagrams
 State

• An abstraction of the attributes of a class

– State is the aggregation of several attributes a class
• A state is an equivalence class of all those attribute values and
links that do no need to be distinguished
– Example: State of a bank
• State has duration
 State Chart Diagram vs Sequence Diagram

• State chart diagrams help to identify:

– Changes to an individual object over time

• Sequence diagrams help to identify:

– The temporal relationship of between objects over time
– Sequence of operations as a response to one ore more events.
 State Chart Diagram

• State Diagram: Depicts data and behavior of a single object

throughout its lifetime.
– set of states (including an initial start state)
– transitions between states
– entire diagram is drawn from that object's perspective

• similar to finite state machines

• What objects are best used with state diagrams?

– large, complex objects with a long lifespan
– domain ("model") objects
– not useful to do state diagrams for every class in the system!
 State Diagrams

• As an example, the following state • The door can be in one of three states:
machine diagram shows the states "Opened", "Closed" or "Locked".
that a door goes through during its • It can respond to the events Open,
lifetime. Close, Lock and Unlock.
• Notice that not all events are valid in
all states;
– for example, if a door is opened,
you cannot lock it until you close
it.
• Also notice that a state transition can
have a guard condition attached:
– if the door is Opened, it can only
respond to the Close event if the
condition doorWay->isEmpty is
fulfilled.
State diagram example
 States
• A state is a condition during the life of an object which it may
either satisfy some condition for performing some activities,
or waiting for some events to be received.
• A state has five parts:
– State Name – Name of State
– Entry – Action performed on entry to state
– Do Activity – Action performed while on the state
– Exit State – Action performed on leaving state
– Deferrable Trigger – A list of events that are not handled in that state
but, rather, are postponed and queued for handling by the object in
another state
 States

• state: conceptual description of the data in the object

– represented by object's field values

• entire diagram is drawn from the

central object's perspective
– only include states / concepts that
this object can see and influence
– don't include every possible value
for the fields; only ones that are
conceptually different
• Initial and Final States - The initial state is denoted by a filled
black circle and may be labeled with a name. The final state is
denoted by a circle with a dot inside and may also be labeled
with a name.
 Transitions
• transition: movement from one state to another
– A transition may have a trigger, a guard and an effect, as below.

• trigger [guard] / effect

– trigger: event that triggers (potential) state change, which could be a
signal, an event, a change in some condition, or the passage of time
– guard: boolean condition that must be true in order for the trigger
to cause the transition
– effect: is an action which will be invoked directly on the object that
owns the state machine as a result of the transition.
• transitions must be mutually exclusive (deterministic)
– must be clear what transition to take for an event
– most transitions are instantaneous, except "do" activities
 Transitions
• Self-Transitions - A state can have a transition that returns to itself, as
in the following diagram. This is most useful when an effect is
associated with the transition
 Transitions
Event is a discrete signal that happens at a point in time. It also known as a stimulus and in
a kind of input to an object. Here is the characteristics of events:
• May cause a change in state
• May trigger actions – Actions can be internal or external
• May have associated conditions
• Signal events can be used to communicate between state machines

Guard Condition
• State transition label – Event [Guard Condition]
• Condition is a Boolean function
– Conditions are optional on state machines
– Condition is true for finite period of time
• When event occurs, condition must be true for state transition to occur. If
condition is false, state transition does not occur.
Actions (effect)
Action is executed as a result of instantaneously of state transition. State transition label
can be expressed as the following format
• Event / action(s)
• Event [condition] / action(s)
• Entry/exit actions
 Choice pseudo state
• Realizes a dynamic conditional branch. It evaluates the guards of the
triggers of its outgoing transitions to select only one outgoing transition.
• It allows splitting of transitions into multiple outgoing paths such that
the decision on which path to take.

• Example:
 State Diagrams

• Junction Pseudo-State - Junction pseudo-states are used to chain together

multiple transitions. A single junction can have one or more incoming, and one
or more outgoing, transitions; a guard can be applied to each transition. Junctions
are semantic-free. A junction which splits an incoming transition into multiple
outgoing transitions realizes a static conditional branch, as opposed to a choice
pseudo-state which realizes a dynamic conditional branch.
 State Diagrams
• Terminate Pseudo-State - Entering a terminate pseudo-state
indicates that the lifeline of the state machine has ended. A
terminate pseudo-state is notated as a cross.

• History States - A history state is used to remember the previous state of a

state machine when it was interrupted. The following diagram illustrates
the use of history states. The example is a state machine belonging to a
washing machine.
 State Diagrams
• Concurrent Regions - A state may be divided into regions containing sub-
states that exist and execute concurrently. The example below shows that
within the state "Applying Brakes", the front and rear brakes will be
operating simultaneously and independently.
 Composite State

• A simple state is one which has no substructure.

• Composite States can be further broken down into substates
(either within the state or in a separate diagram).
• A state which has substates (nested states) is called
a composite state.
 Composite State

• Substates may be nested to any level.

• A nested state machine may have at most one initial state and
one final state.
• Substates are used to simplify complex flat state machines by
showing that some states are only possible within a particular
context (the enclosing state).
ATM software states at a bank
State diagram example
• ATM is initially turned off. After the power is turned on, ATM performs startup
action and enters Self Test state.
• If the test fails, ATM goes into Out of Service state, otherwise there
is triggerless transition to the Idle state. In this state ATM waits for customer
interaction.
• The ATM state changes from Idle to Serving Customer when the customer
inserts banking or credit card in the ATM's card reader.On entering the Serving
Customer state, the entry action readCard is performed.
• Note, that transition from Serving Customer state back to the Idle state could
be triggered by cancel event as the customer could cancel transaction at any
time.
• Serving Customer state is a composite state with sequential
substates Customer Authentication, Selecting Transaction and Transaction.
• Customer Authentication and Transaction are composite states by
themselves which is shown with hidden decomposition indicator icon.
• Serving Customer state has triggerless transition back to the Idle state after
transaction is finished.
• The state also has exit action ejectCard which releases customer's card on
leaving the state, no matter what caused the transition out of the state.
 State Diagram Examples
• The Digital Clock State Machine diagram example below
shows the interface of a simple digital clock:

• The Digital Clock State Machine diagram example below

shows the interface of a simple digital clock:
 Dynamic Modeling

• Dynamic Modeling
• Sequence diagrams
• State diagrams
• Practical Tips for Dynamic Modeling
• Dominant Models based on system features
 Practical Tips for Dynamic Modeling

• Construct dynamic models only for classes with significant

dynamic behavior
– Avoid “analysis paralysis”
• Consider only relevant attributes
– Use abstraction if necessary
• Look at the granularity of the application when deciding on
actions and activities
• Reduce notational clutter
– Try to put actions into superstate boxes (look for identical actions on
events leading to the same state).
 Let’s Do Analysis: A Toy Example

• Analyze the problem statement

– Identify functional requirements
– Identify nonfunctional requirements
– Identify constraints (pseudo requirements)
• Build the functional model:
– Develop use cases to illustrate functional requirements
• Build the dynamic model:
– Develop sequence diagrams to illustrate the interaction between
objects
– Develop state diagrams for objects with interesting behavior
• Build the object model:
– Develop class diagrams for the structure of the system
 Problem Statement:
Direction Control for a Toy Car

• Power is turned on • Power is turned off

– Car stops and headlight goes
– Car moves forward and car
headlight shines out
• Power is turned on
• Power is turned off
– Headlight shines
– Car stops and headlight goes
• Power is turned off
out.
– Headlight goes out
• Power is turned on • Power is turned on
– Headlight shines – Car runs forward with its
• Power is turned off headlight shining
– Headlight goes out
• Power is turned on
– Car runs backward with its
headlight shining
 Find the Functional Model: Use Cases
• Use case 1: System Initialization
– Entry condition: Power is off, car is not moving
– Flow of events:
1. Driver turns power on
– Exit condition: Car moves forward, headlight is on

• Use case 2: Turn headlight off

– Entry condition: Car moves forward with headlights on
– Flow of events:
1. Driver turns power off, car stops and headlight goes out.
2. Driver turns power on, headlight shines and car does not move.
3. Driver turns power off, headlight goes out
– Exit condition: Car does not move, headlight is out
 Use Cases continued
• Use case 3: Move car backward
– Entry condition: Car is stationary, headlights off
– Flow of events:
1. Driver turns power on
– Exit condition: Car moves backward, headlight on

• Use case 4: Stop backward moving car

– Entry condition: Car moves backward, headlights on
– Flow of events:
1. Driver turns power off, car stops, headlight goes out.
2. Power is turned on, headlight shines and car does not move.
3. Power is turned off, headlight goes out.
– Exit condition: Car does not move, headlight is out
 Use Cases Continued

• Use case 5: Move car forward

– Entry condition: Car does not move, headlight is out
– Flow of events
1. Driver turns power on
– Exit condition:
• Car runs forward with its headlight shining
 Use Case Pruning

• Do we need use case 5?

• Let us compare use case 1 and use case 5:

Use case 1: System Initialization

– Entry condition: Power is off, car is not moving
– Flow of events:
1. Driver turns power on
– Exit condition: Car moves forward, headlight is on

Use case 5: Move car forward

– Entry condition: Car does not move, headlight is out
– Flow of events
1. Driver turns power on
– Exit condition:
• Car runs forward with its headlight shining
 Dynamic Modeling:
Create the Sequence Diagram
• Name: Drive Car
• Sequence of events:
– Billy turns power on
– Headlight goes on
– Wheels starts moving forward
– Wheels keeps moving forward
– Billy turns power off
– Headlight goes off
– Wheels stops moving
– ...
Sequence Diagram for Drive Car Scenario

:Headlight Billy:Driver :Wheel

Power(on) Power(on)

Power(off) Power(off)

Power(on) Power(on)
 Toy Car: Dynamic Model
Wheel
Headlight
Forward
Off power
power off
on
power power
off on

Stationary Stationary
On

power power
on
off

Backward
 Toy Car: Object Model
Car

Power Headlight Wheel

Status: (On, Off) Status: (On, Off) Motion: (Forward,

Backward,
TurnOn() Switch_On() Stationary)
TurnOff() Switch_Off()
Start_Moving()
Stop_Moving()
 Tutorials and references

• https://www.visual-paradigm.com/
 Dynamic Modeling

• Dynamic Modeling
• Sequence diagrams
• State diagrams
• Practical Tips for Dynamic Modeling
• Dominant Models based on system features
 When is a Model Dominant?

• Object model:
– The system has classes with nontrivial states and many relationships
between the classes
• Dynamic model:
– The model has many different types of events: Input, output,
exceptions, errors, etc.
• Functional model:
– The model performs complicated transformations (eg. computations
consisting of many steps).
• Which model is dominant in these applications?
– Compiler
– Database system
– Spreadsheet program
 Examples of Dominant Models
• Compiler:
– The functional model is most important
– The dynamic model is trivial because there is only one type input and
only a few outputs
• Is that true for IDEs?
• Database systems:
– The object model most important
– The functional model is trivial, because the purpose of the functions is
to store, organize and retrieve data
• Spreadsheet program:
– The functional model most important
– The dynamic model is interesting if the program allows computations
on a cell
– The object model is trivial.
 Requirements Analysis Questions
1. What are the transformations? Functional Modeling
Create scenarios and use case diagrams
- Talk to client, observe, get historical records

2. What is the structure of the system? Object Modeling

Create class diagrams
- Identify objects.
- What are the associations between them?
- What is their multiplicity?
- What are the attributes of the objects?
- What operations are defined on the objects?
3. What is its behavior?
Dynamic Modeling
Create sequence diagrams
- Identify senders and receivers
- Show sequence of events exchanged between objects.
- Identify event dependencies and event concurrency.
Create state diagrams
- Only for the dynamically interesting objects.