Software

Engineering

Analysis: Dynamic Modeling

Part II

27
Outline of the Lecture

z Dynamic Modeling
z Mapping use cases to Objects with Sequence diagrams
z Modeling Interactions among Objects with CRC CARDS
z Identifying Associations
z Identifying Aggregates
z Identifying Attributes
z Modeling State-Dependent behavior of individual Objects
z Modeling Inheritance Relationships between Objects
z Reviewing the analysis model

z Managing requirements analysis

28
 Dynamic Modeling

z Definition of dynamic model:

- The behavioral view of a
system:
- shows
z Sequence interaction between classes and object in a time ordered
Diagram
way
- Detect and supply methods for the object
z Purpose:
model
z -How
Startdo weuse
with do this?
case or scenario
- Model interaction between objects => sequence diagram
- Model dynamic behavior of a single object => statechart diagram

29
Dynamic Modeling with UML

z Diagrams for dynamic modeling

- Interaction diagrams describe the dynamic behavior between
objects
- Statecharts describe the dynamic behavior of a single
z object
- Sequence
Interaction Diagram:
diagrams
ËDynamic behavior of a set of objects arranged in time
sequence.
ËGood for real-time specifications and complex scenarios
- Collaboration Diagram :
ËShows the relationship among objects. Does not show
z time
-A stateChart
State machine that describes the response of an object of a
Diagram:
given class to the receipt of outside stimuli (Events).
- Activity Diagram: A special type of statechart diagram, where
all states are action states
30
Classes from Dynamic modeling

z How to identify classes from dynamic models

z Sequence diagrams

- Distribution of behavior of use cases among

participating objects.
- Model sequence of interactions among objects.
- Activity lines in sequence diagrams are candidates for
objects.
z State chart diagrams

- Actions and activities in state chart diagrams are

candidates for public operations in classes

31
What is an Event?

z Something that happens at a point in time

- Example “the WatchUser presses the left
button”
z-Relation
Causallyofrelated:
events to each after,
Before, other:
- Causally unrelated: concurrent
z An event sends information from one object to another

32
Mapping Use Cases to Objects with Sequence Diagrams

z Sequence diagrams tie use cases and objects together

z Objects that participate in use case form columns
- Vertical dashed line is called the lifeline
z Time progresses from top to bottom
z Horizontal arrows represent messages sent from one object to
another
z Rectangles represent the activation of an operation

33
 UML First Pass: Sequence Diagram

Object

:SimpleWatch :LCDDisplay :Time

:WatchUser

pressButton1() blinkHours()
pressButton1() blinkMinutes()

pressButton2() incrementMinutes()
refresh()
pressButtons1And2()
commitNewTime()
stopBlinking()

Message
Activation
Sequence diagrams represent the behavior as interactions

34
 Example Sequence Diagram

Report ReportEmergencyControl ReportEmergency Emergency Manage

FieldOfficer
EmergencyButton Form Report EmergencyControl

press()
create()
create()

fillContents()

submit()
submitReport()
create()

submitReportToDispatcher()

35
Heuristics for drawing sequence diagrams

z Actor who initiates - on the left

z Next - the boundary object that the actor uses to initiate
z Next - the first use case control object
z Boundary objects are created by control objects
z Entity objects are accessed by control objects and boundary
objects

36
What else can we get out of sequence diagrams?

z Sequence diagrams are derived from the use cases. We

therefore see the structure of the use cases.
z The structure of the sequence diagram helps us to determine
how decentralized the system is.

37
Modeling Interactions among Objects with CRC CARDS

Class name
Responsibilities Collaborators

tasks that the class is the classes

required to carry out that request
(will become operations on the class) the tasks

Î helps us to “think object”

z too many responsibilities ∅ low cohesion

z too many collaborators ∅ high coupling
38
Modeling Interactions among Objects with CRC CARDS
CRC cards for the ReportEmergencyControl and the Incident
classes.

ReportEmegencyControl
Incident
Responsibilities Collaborators
Responsibilities Collaborators
Collects input from Field- EmergencyReportForm
officer EmergencyReport Track all information Resource
Controls sequence of AcknowledgementNotrelated to a single inci-
forms during emegrency dent.
reporting

39
Identifying Associations
z Association
- Relationship between two or more
classes
An -to-many
z -One association
example of association between the
EmergencyReport and the FieldOfficer
classes.

EmergencyReport
FieldOfficer
1 writes *

author document

40
Identifying Associations

Country Has-capital City

name:String name:String

One-to-one association

Many-to-many association
Mechanics Plane
* Work on *

41
Identifying Aggregation

z Models "part of" hierarchy

z Useful for modeling the breakdown of a product into its component
parts
z UML notation: uses a small diamond to indicate the assembly end of
the relationship.

42
Identifying Aggregation

Automobile
Engine serial number
1 year
horsepower manufacturer
model
volume
on color
off weight
drive
purchase

3,4,5 1
* 2,4
Wheel Brakelight Door Battery
diameter amps
number of bolts open volts
on close
off charge
discharge

43
Identifying Aggregation
z Aggregation
- Special types of associations; whole-part
relationship
- Existence ofAggregation
z Composition the parts depends on the
whole
z Shared Aggregation

State FireStation

County
FireFighter LeadCar

FireEngine Ambulance

Township

44
Identifying Attribute
z Attributes
- Proprieties of individual objects

z Attributes
- Name
- A brief description
- Type; legal values

EmergencyReport

emergencyType:{fire,traffic,other}
location:String
description:String

45
Statechart Diagrams

z Graph whose nodes are states and whose directed arcs are
transitions labeled by event names.
z A statechart diagram relates events and states for one class
- An object model with a set of objects has a set of state diagrams

46
 State
z State
- State is a defined set of properties which
describe an object or thing at a given time.
- State may change when the properties making
up the state change.

z An abstraction of the attribute of a class

- A condition that is satisfied by the attribute values of an
object or subsystem
- State is the aggregation of several attributes of a class
- Incident: Active, Inactive, Closed and
Archived
z State has duration

47
UML Statechart Diagram Notation

Event trigger
With parameters

State1 Event1(attr) [condition]/action State2

do/Activity
entry /action Guard
condition
exit/action

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

48
UML statechart for Incident.

all reports
are submitted

Active Inactive Closed Archived

numAllocatedResource == 0 when incident.date > 1yr.

49
Statechart diagram for 2Bwatch

Initial state State

button1&2Pressed butt
on2Pressed Increment
HoursBlink Hours

Transition button1Pressed Event

button1&2Pressed button2Pressed
Blink Increment
Minutes Minutes

button1Pressed

button2Pressed
Stop Blink
Blinking Increment
Seconds Seconds
button1&2Pressed

Final state
50
Modeling Inheritance Relationship between Objects
z Generalization
- Eliminate redundancy from the analysis model
- Two or more classes share attributes or behavior
- Similarities are consolidated into super class
- badgeNumber

PoliceOfficer

badgeNumber:Integer

FieldOfficer Dispatcher

51
 Define
Analysis activities
use cases
(UML activities
Define diagram).
participating
objects

Define Define Define

entity boundary control
objects objects objects

Define
interactions

Define
nontrivial Define Define
behavior attributes associations

Consolidate
model

Review
model
Reviewing the Analysis Model

z Analysis model built incrementally and iteratively

- omission discovered during analysis may lead to new use case
- E.g. What happens to student applications after students have
been selected for a term? Do we need an archive or purge
applications use case?
z Reviews conducted to ensure that the necessary attributes are
met

53
Model Correct?

z Is the glossary of entity objects understandable by the user?

z Do abstract classes correspond to user-level concepts?
z Are all descriptions in accordance with users’ definitions?
z Do all use cases and control objects have meaningful verb
phrases as names?
z Etc.

54
Model Consistent?

z Are there multiple classes or use cases with the same name?
z Do entities (e.g. use cases, classes, attributes) with similar
names denote similar phenomena?
z Are all entities described at the same level of detail?

55
Model Realistic?

z Are there any novel features of the system? Were any studies
or prototypes built to ensure their feasibility?
z Can the performance and reliability be met?
z Etc.

56
Managing Analysis

z Documenting
z Assigning Responsibilities
z Communicating
z Client Sign-off

57
Requirements Analysis Document Template
1. Introduction
2. Current system
3. Proposed system
3.1 Overview
3.2 Functional requirements
3.3 Nonfunctional requirements
3.4 Constraints (“Pseudo requirements”)
3.5 System models
3.5.1 Scenarios
3.5.2 Use case model
3.5.3 Object model
3.5.3.1 Data dictionary
3.5.3.2 Class diagrams
3.5.4 Dynamic models
3.5.5 User interface
4. Glossary
58
Documenting Analysis

z RAD documents both requirements elicitation and analysis

activities
z Many sections written during requirements elicitation
z Those sections are reviewed and revised
z New sections are added
- Object models
- Dynamic models
- User interface: screen mockups, forms

59
Object Models

z Document the domain objects identified

- Attributes
Ë As complete as possible
Ë No data types needed
- Operations
Ë From sequence diagrams
Ë List may be incomplete
Ë No logic
- Class diagrams showing relationships
- Data Dictionary with text descriptions

60
Dynamic Models

z Statechart diagrams for complex behavior of objects

z Sequence diagrams for use cases
- Although they contain redundant information (have textual flow of
events with use cases) useful because they are more precise and
will help the designers understand the system

61
Assigning Responsibilities

z Analysis involves many individuals

- User and client
- Analyst, architect, document editor, configuration manager,
reviewer
z Challenging to coordinate and communicate
z Assign types of roles:
- Generation of information
- Integration
- Review

62
User and Client

z User
- Domain expert
- Generates information about the current system and about the
tasks that the future system should support
- Corresponds to one or more actors
Ë Helps identify their use cases
z Client
- Integration of user requests
- Defines the scope of the system based on (sometimes conflicting)
user requirements

63
Analyst and Architect

z Analyst
- Development domain expert
- Models current system
- Generates information about the future
system
z -Architect
Integrates the use case and object models
- Ensures consistency and completeness
- Develops system philosophy

64
Editor, Reviewer, Configuration Manager

z Editor
- Integration of document
- Format of
document
z Reviewer
- Validates document against requirements
qualities
z -Configuration
Maintains revision history
Manager
- Coordinates traceability with other documents

65
Communicating

z Challenges
- Different backgrounds
- Different expectations
- Passing information to new teams
- Evolving system
z Guidelines
- Define clear territories
- Define clear objectives and success criteria
- Brainstorm

66
Client Sign-off

z Acceptance of the analysis model (RAD) by client

z Also client and developer must agree on:
- Priorities
- Criteria by which to accept or reject system
- Schedule
- Budget
- Revision process

67
 Client Developer

Report problem Design change

or and
change request estimate impact

Example of a
Review proposed
change
[change approved]
revision
process
Update Archive
requirements request

Design Update
test design

Update code
(if applicable)

Execute all
relevant tests

Review actual
change
Summary: Analysis
z 1. What are the transformations?
Functional Modeling
- Create scenarios and use case diagrams
Ë Talk to client, observe, get historical records, do thought experiments

z 2. What is the structure of the system?

- Create class diagrams Object Modeling
Ë 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?
z 3. What is its behavior?
- Create sequence diagrams Dynamic Modeling
Ë 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.

69