TUM

Requirements Analysis II:

Dynamic Modeling

Bernd2Brügge
Technische Universität München
Lehrstuhl für Angewandte Softwaretechnik
8 June 1999

Bernd Bruegge 15-413 Software Engineering 1

Outline of Class

v Dynamic Modeling
Sequence Diagrams
State Diagrams
v Using dynamic modeling for the design of user interfaces
v Requirements Analysis Example
v Requirements Analysis Template

Bernd Bruegge 15-413 Software Engineering 2

How do you find classes?
v From previous lectures
Application domain analysis: Talk to client to identify
abstractions
Apply general world knowledge and intuition
Scenarios
u Natural language formulation of a concrete usage of the system
Use Cases
u Natural language formulation of the functions of the system
Textual analysis of problem statement (Abbot)
v From this lecture
Dynamic model
u Events: Candiates for operations to be offered by classes
u Sequence diagrams as sources for objects
v From future lectures
Design Patterns
Bernd Bruegge 15-413 Software Engineering 3
Dynamic Modeling with UML
v Diagrams for dynamic modeling
Interaction diagrams describe the dynamic behavior between
objects
Statecharts describe the dynamic behavior of a single object
v Interaction diagrams
Sequence Diagram:
u Dynamic behavior of a set of objects arranged in time sequence.
u Good for real-time specifications and complex scenarios
Collaboration Diagram :
u Shows the relationship among objects. Does not show time
v State Charts:
A state machine that describes the response of an object of a
given class to the receipt of outside stimuli (Events).
v Activity Diagram:
Special type of statechart where all states are action states
Bernd Bruegge 15-413 Software Engineering 4
Dynamic Modeling
v Definition of Dynamic Model:
A collection of multiple state chart diagrams, one state chart
diagram for each class with important dynamic behavior.
v Purpose:
Detect and supply methods for the object model
v How do we do this?
Start with use case or scenario
Model interaction between objects => Sequence Diagram
Model dynamic behavior of single objects => Statechart
Diagram

Bernd Bruegge 15-413 Software Engineering 5

Start with Scenario or Use case

v Flow of events from “Dial a Number” Use case:

Caller lifts receiver
Dail tone begins
Caller dials
Phone rings
Callee answers phone
Ringing stops
....

Bernd Bruegge 15-413 Software Engineering 6

What is an Event?

v Something that happens at a point in time

v Relation of events to each other:
Causally related: Before, after,
Causally unrelated: concurrent
v An event sends information from one object to another
v Events can be grouped in event classes with a
hierarchical structure. ‘Event’ is often used in two ways:
Instance of an event class: “Light Failure on Thursday
September 25 at 9:14 AM”.
u Event class “Failure”, Subclass “Light Failure”
Attribute of an event class
u Dial tone begins(4:20AM)
u Car starts at ( 4:45pm, Monroeville Mall, Parking Lot 23a)
u Mouse button down(button#, tablet-location)
Bernd Bruegge 15-413 Software Engineering 7
Sequence Diagram

v From the flow of events in the use case or scenario we

can proceed to the sequence diagram
v A sequence diagram is a graphical description of a use
case or scenario using a DAG notation
v It illustrates the interaction between objects
Assumes that objects/classes have been identified or it helps to
identify classes/objects
v Events always have a sender and a receiver. Find them
for each event => These are the participating objects

Bernd Bruegge 15-413 Software Engineering 8

 Sequence Diagram

v Direct acyclic graph

(DAG) showing the
interaction between two
or more objects. Objects
are shown as vertical
rectangles, events are
horizontal arrows from
the sending to the
receiving object, time
increases from top to
bottom, spacing is
irrelevant.

Bernd Bruegge 15-413 Software Engineering 9

An Example

v Flow of events in a “Get SeatPosition” use case :

1. Establish connection between smart card and

onboard computer

2. Establish connection between onboard computer

and sensor for seat

3. Get current seat position and store on smart card

v Who are the objects?

Bernd Bruegge 15-413 Software Engineering 10

Sequence Diagram for “Get SeatPosition”
Smart Card Onboard Computer Seat
1. Establish
connection
between Establish Connection
smart card Establish Connection
and onboard
computer

2. Establish
connection
between Accept Connection
onboard
computer
and sensor Accept Connection
for seat

3. Get
current seat Get SeatPosition
position and
store on “500,575,300”
smart card

Bernd Bruegge 15-413 Software Engineering 11

Heuristics for Sequence Diagrams

v Layout:
1st column: Should correspond to the actor who initiated the
use case
2nd column: Should be an interface object
3rd column: Should be the control object that manages the rest
of the use case
v Creation:
Control objects are created by interface objects initiating use
cases
Interface objects are created by control objects,
v Access:
Entity objects are accessed by control and interface objects,
Entity objects never access interface or control objects, this
makes it easier to share entity objects across use cases.

Bernd Bruegge 15-413 Software Engineering 12

Is this a good Sequence Diagram?
Smart Card Onboard Computer Seat
• Did the
modeler follow Establish Connection
the layout
Establish Connection
heuristics?

• Did the
modeler follow
the creation Accept Connection
heuristics?

• Did the Accept Connection

modeler follow
the access
heuristics? Get SeatPosition
“500,575,300”

Bernd Bruegge 15-413 Software Engineering 13

Relating states and events: State Chart Diagrams

Event1
Event2
State1
State2 Event3

Bernd Bruegge 15-413 Software Engineering 14

UML Statechart Diagram Notation
Event trigger
With parameters

State1 Event1(attr) [condition]/action State2

do/Activity
entry /action Guard
condition
exit/action

Also: internal transition

and deferred events

v Notation based on work by Harel

Added are a few object-oriented modifications

v A UML statechart diagram can be mapped into a finite state machine

Bernd Bruegge 15-413 Software Engineering 15

Statechart Diagrams

v Graph whose nodes are states and whose directed arcs

are transitions labeled by event names.
v Distinguish between two types of operations:
Activity: Operation that takes time to complete
u associated with states
Action: Instantaneous operation
u associated with events
u associated with states (reduces drawing complexity): Entry, Exit,
Internal Action
v A statechart diagram relates events and states for one
class
An object model with a set of objects has a set of state
diagrams

Bernd Bruegge 15-413 Software Engineering 16

State
v An abstraction of the attribute of a class
State is the aggregation of several attributes a class
v Basically an equivalence class of all those attribute values
and links that do no need to be distinguished as far as the
control structure of the system is concerned
Example: State of a bank
u A bank is either solvent or insolvent
v State has duration

Bernd Bruegge 15-413 Software Engineering 17

Example of a StateChart Diagram

coins_in(amount) / set balance

Collect Money
Idle coins_in(amount) / add to balance
cancel / refund coins

[item empty] [select(item)] [change<0]

do: test item and compute change

[change=0] [change>0]

do: dispense item do: make change

Bernd Bruegge 15-413 Software Engineering 18

Nested State Diagram

v Activities in states are composite items denoting other

lower-level state diagrams
v A lower-level state diagram corresponds to a sequency of
lower-level states and events that are invisible in the
higher-level diagram.
v Sets of substates in a nested state diagram denoting a
superstate are enclosed by a large rounded box, also
called contour.

Bernd Bruegge 15-413 Software Engineering 19

Example of a Nested Statechart Diagram

coins_in(amount) / set balance

Collect Money
Idle coins_in(amount) / add to balance
cancel / refund coins

[item empty] [select(item)] [change<0]

Superstate
do: test item and compute change

[change=0] [change>0]

do: dispense item do: make change

Bernd Bruegge 15-413 Software Engineering 20

Expanding activity “do:dispense item”

‘Dispense item’ as
an atomic activity: [change=0]

do: dispense item

‘Dispense item’ as a composite activity:

do: move arm do: move arm do: push item

to row to column off shelf
Arm Arm
ready ready

Bernd Bruegge 15-413 Software Engineering 21

Superstates

v Goal:
Avoid spaghetti models
Reduce the number of lines in a state diagram
v Transitions from other states to the superstate enter the
first substate of the superstate.
v Transitions to other states from a superstate are inherited
by all the substates (state inheritance)

Bernd Bruegge 15-413 Software Engineering 22

Modeling Concurrency

v Two types of concurrency

v 1. System concurrency
State of overall system as the aggregation of state diagrams, one for
each object. Each state diagram is executing concurrently with the
others.
v 2. Object concurrency
The object can be partitioned into subsets of states (attributes and
links) such that each of them has its own subdiagram.
The state of the object consists of a set of states: one state from each
subdiagram.
State diagrams are divided into subdiagrams by dotted lines.

Bernd Bruegge 15-413 Software Engineering 23

Example of Concurrency within an Object

Splitting control Synchronization

Emitting

Do: Dispense Cash taken

Cash

Setting Ready
Up Ready to reset
Do: Eject
Card
Card taken

Bernd Bruegge 15-413 Software Engineering 24

State Chart Diagram vs Sequence Diagram

v State Chart Diagrams help to identify:

Changes to objects over time

v Sequence Diagrams help to identify

The temporal relationship of between objects over
time
Sequence of operations as a response to one ore
more events

Bernd Bruegge 15-413 Software Engineering 25

Dynamic Modeling of User Interfaces
v Statechart diagrams can be used for the design of user
interfaces
Also called Navigation Path
v States: Name of screens
Graphical layout of the screen associated with the state (think
instance diagram!) helps significantly when presenting the
dynamic model of the user interface
v Activities and Actions are shown as bullets under screen
name
Often only the exit action is shown
v State transitions: Result of exit action
Button click
Menu selection
Cursor movements

Bernd Bruegge 15-413 Software Engineering 26

Navigation Path Example (15-499 Spring 96)
Diagnostics
•User can move cursor to Control Panel or Graph
Graph
Control panel
• User can select data group
• User can select functionality of sensors
and type of graph

Selection
Define
• User selects data group
• User defines a sensor event
• Field site
from a list of events
• Car
Enable Disable • Sensor group
• User can enable a • User can disable a • Time range
sensor event from a sensor event from a • User selects type of graph
list of sensor list of sensor events • time line
events • histogram
List of events
• pie chart
• User selects event(s) Visualize
List of sensor events • User views graph
• User selects sensor • User can add data groups for
event(s) being viewed
Link
• User makes a link
Bernd Bruegge 15-413 Software Engineering (doclink) 27
Practical Tips for Dynamic Modeling

v Use use cases and scenarios when constructing statechart

diagrams (ask the client)
v Construct dynamic models only for classes with
significant dynamic behavior
v Consider only relevant attributes
Use abstraction if necessary
v Look at the granularity of the application when deciding
on actions and activities
v Reduce notational clutter
Try to put actions into state boxes (look for identical actions on
events leading to the same state)

Bernd Bruegge 15-413 Software Engineering 28

Summary: Requirements Analysis
v 1. What are the transformations? Functional Modeling
Create scenarios and use case diagrams
u Talk to client, observe, get historical records, do thought experiments
v 2. What is the structure of the system?
Create class diagrams Object Modeling
u Identify objects. What are the associations between them? What is
their multiplicity?
u What are the attributes of the objects?
u What operations are defined on the objects?
v 3. What is its control structure? Dynamic Modeling
Create sequence diagrams
u Identify senders and receivers
u Show sequence of events exchanged between objects. Identify event
dependencies and event concurrency.
Create state diagrams
u Only for the dynamically interesting objects.
Bernd Bruegge 15-413 Software Engineering 29
Let’s Do Requirements Analysis

1. Analyze the Problem Statement

Identify functional requirements
Identify nonfunctional requirements
Identify constraints
2. Build the Functional Model:
Develop use cases to illustrate functionality requirements
3. Build dynamic model:
Develop sequence diagrams to illustrate the interaction
between objects
Develop state diagrams for objects with interesting behavior
4. Build object model:
Develop Class diagrams showing the structure of the system

Bernd Bruegge 15-413 Software Engineering 30

Problem Statement:
Direction Control for a Toy Car

v Power is turned on v Power is turned off

Car moves forward and car Car stops and headlight goes
headlight shines out.
v Power is turned off v Power is turned on
Car stops and headlight goes Headlight shines
out. v Power is turned off
v Power is turned on Headlight goes out.
Headlight shines v Power is turned on
v Power is turned off Car runs forward with its
headlight shining.
Headlight goes out.
v Power is turned on
Car runs backward with its
headlight shining.

Bernd Bruegge 15-413 Software Engineering 31

Find the Functional Model: Do Use Case
Modeling
v Use case 1: System Initialization
Entry condition: Power is off, car is not moving
Flow of events:
u Driver turns power on
Exit condition: Car moves forward, headlight is on
v Use case 2: Turn headlight off
Entry condition: Car moves forward with headlights on
Flow of events:
u Driver turns power off, car stops and headlight goes out.
u Driver turns power on, headlight shines and car does not move.
u Driver turns power off, headlight goes out
Exit condition: Car does not move, headlight is out

Bernd Bruegge 15-413 Software Engineering 32

Use Cases continued
v Use case 3: Move car backward
Entry condition: Car is stationary, headlights off
Flow of events:
u Driver turns power on

Exit condition: Car moves backward, headlight on

v Use case 4: Stop backward moving car
Entry condition: Car moves backward, headlights on
Flow of events:
u Driver turns power off, car stops, headlight goes out.

u Power is turned on, headlight shines and car does not move.

u Power is turned off, headlight goes out.

Exit condition: Car does not move, headlight is out.

v Use case 5: Move car forward
Entry condition: Car does not move, headlight is out
Flow of events
u Driver turns power on

Exit condition:
u Car runs forward with its headlight shining.

Bernd Bruegge 15-413 Software Engineering 33

Use Case Pruning

v Do we need use case 5?

v Use case 1: System Initialization

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

v Use case 5: Move car forward

Entry condition: Car does not move, headlight is out
Flow of events
u Driver turns power on

Exit condition:
u Car runs forward with its headlight shining.

Bernd Bruegge 15-413 Software Engineering 34

Find the Dynamic Model:
Create sequence diagram

v Name: Drive Car

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

Bernd Bruegge 15-413 Software Engineering 35

Sequence Diagram for Drive Car Scenario

:Headlight Billy:Driver :Wheel

Power(on)
Power(on)

Power(off)
Power(off)

Power(on)
Power(on)

Bernd Bruegge 15-413 Software Engineering 36

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

Stationary Stationary
On

power
power on
off

Backward

Bernd Bruegge 15-413 Software Engineering 37

Toy Car: Object Model

Power Headlight Wheel

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

Backward,
TurnOn() Switch_On() Stationary)
TurnOff() Switch_Off()
Start_Moving()
Stop_Moving()

Bernd Bruegge 15-413 Software Engineering 38

When is a model dominant?
v Object model:: The system has non-trivial data structures.
v Dynamic model: The model has many different types of
events: Input, output, exceptions, errors, etc.
v Functional model:: The model performs complicated
transformations such as difficult computations consisting of
many steps.
v Examples:
Compiler: Functional model most important. Dynamic model is
trivial because there is only one type input and only a few outputs.
Database systems: Object model most important. Functional model
is trivial, because their purpose is usually only to store, organize
and retrieve data.
Spreadsheet program: Functional model most important. Object
model is trivial, because the spreadsheet values are trivial and
cannot be structured further. The only interesting object is the cell.

Bernd Bruegge 15-413 Software Engineering 39

Collaborative Requirements Analysis

v A system is a collection of subsystems providing services

v Analysis of services is provided by a set of the teams
who provide the models for their subsystems
v Integration of team models into the full system model by
the architecture team
v Analysis integration checklist:
Are all the classes mentioned in the data dictionary?
Are the names of the methods consistent with the
names of actions, activities, events or processes?
Check for assumptions made by each of the services
u Missing methods, classes
u Unmatched associations

Bernd Bruegge 15-413 Software Engineering 40

Object Model Integration in JAMES
All Teams

Revised System
Model Model
Analysis Changes
Review
Team 1

User Interface
Analysis Analysis Team
Integrated
System
Model User Interface
Module 1
Module

Integration Architecture Team

Module 2 Module 3 Module 4 Module 5

Analysis Analysis Analysis Analysis

Team 3 Team 4 Team 5

Team 2

Bernd Bruegge 15-413 Software Engineering 41

Consistency, Completeness, Ambiguities

v Consistency
Identification of crossed “wires” between classes
Naming of classes, attributes, methods
v Completeness:
Identification of dangling associations (associations pointing to
nowhere)
Identification of double- defined classes
Identification of missing classes (referred to by one subsystem
but not defined anywhere)
v Ambiguities
Misspelling of names
Classes with the same name but different meanings

Bernd Bruegge 15-413 Software Engineering 42

Requirements Analysis Document Template
v 1.0 General Goals
v 2.0 Current System
Description of current system
v 3.0 Proposed System
3.1 Overview
3.2 Functional Requirements
3.3 Nonfunctional requirements
3.4 Constraints
3.5 System Model

Bernd Bruegge 15-413 Software Engineering 43

Section 3.5 System Model

3.5.1 Use case model

- Actors
- Use cases

3.5.2 Object model

- Data dictionary
- Class diagrams (classes, associations, attributes and operations)

3.5.3 Dynamic model

- State diagrams for classes with significant dynamic behavior

3.5.4 User Interface

- Navigational Paths

Bernd Bruegge 15-413 Software Engineering 44

Section 3.3 Nonfunctional Requirements

3.3.1 User interface and human factors

3.3.2 Documentation
3.3.3 Hardware considerations
3.3.4 Performance characteristics
3.3.5 Error handling and extreme conditions
3.3.6 System interfacing
3.3.7 Quality issues
3.3.8 System modifications
3.3.9 Physical environment
3.3.10 Security issues
3.3.11 Resources and management issues

Bernd Bruegge 15-413 Software Engineering 45

Nonfunction Requirements: Trigger Questions
v 3.3.1 User interface and human factors
What type of user will be using the system?
Will more than one type of user be using the system?
What sort of training will be required for each type of user?
Is it particularly important that the system be easy to learn?
Is it particularly important that users be protected from making errors?
What sort of input/output devices for the human interface are available,
and what are their characteristics?
v 3.3.2 Documentation
What kind of documentation is required?
What audience is to be addressed by each document?
v 3.3.3 Hardware considerations
What hardware is the proposed system to be used on?
What are the characteristics of the target hardware, including memory
size and auxiliary storage space?

Bernd Bruegge 15-413 Software Engineering 46

Global Requirements, ctd

v 3.3.4 Performance characteristics

Are there any speed, throughput, or response time constraints on the
system?
Are there size or capacity constraints on the data to be processed by the
system?
v 3.3.5 Error handling and extreme conditions
How should the system respond to input errors?
How should the system respond to extreme conditions?
v 3.3.6 System interfacing
Is input coming from systems outside the proposed system?
Is output going to systems outside the proposed system?
Are there restrictions on the format or medium that must be used for
input or output?

Bernd Bruegge 15-413 Software Engineering 47

Global Requirements, ctd
v 3.3.7 Quality issues
What are the requirements for reliability?
Must the system trap faults?
Is there a maximum acceptable time for restarting the system after a
failure?
What is the acceptable system downtime per 24-hour period?
Is it important that the system be portable (able to move to different
hardware or operating system environments)?
v 3.3.8 System Modifications
What parts of the system are likely candidates for later modification?
What sorts of modifications are expected?
v 3.3.9 Physical Environment
Where will the target equipment operate?
Will the target equipment be in one or several locations?
Will the environmental conditions in any way be out of the ordinary
(for example, unusual temperatures, vibrations, magnetic fields, ...)?

Bernd Bruegge 15-413 Software Engineering 48

Global Requirements, ctd

v 3.3.10 Security Issues

Must access to any data or the system itself be controlled?
Is physical security an issue?
v 3.3.11 Resources and Management Issues
How often will the system be backed up?
Who will be responsible for the back up?
Who is responsible for system installation?
Who will be responsible for system maintenance?

Bernd Bruegge 15-413 Software Engineering 49