Chapter 5: Analysis Part I: Object Modeling Part II: Dynamic Modeling

1
Chapter 5 AnalysisPart I Object ModelingPart
II Dynamic Modeling

• Qutaibah Malluhi
• Software Engineering
• Qatar University

Based on slides by Bernd Bruegge Allen H.
Dutoit
2
Introduction
3
Summary of Previous Discussion

• Pure functional decomposition is bad
• Leads to unmaintainable code
• Pure object identification is bad
• May lead to wrong objects, wrong attributes,
  wrong methods

4
Ambiguity what do you see?
5
General Approach for Identifying Objects

• The key to successful analysis
• Start with use cases and then find the
  participating objects
• If somebody asks What is this?, do not answer
  right away. Return the question or observe the
  end user What is it used for?
• Identify system boundary
• What object is inside, what object is outside?

6
From Use Cases to Objects

Level 1 Use Case
Le
v
el 1
Level 2 Use Cases
Le
v
el 2
Le
v
el 2
Level 3 Use Cases
Le
v
el 3
Le
v
el 3
Le
v
el 3
Operations
Le
v
el 4
Le
v
el 4
A
B
Participating Objects
7
Why Functional Decomposition is not Enough

Scenarios
Le
v
el 1
Level 1 Use Cases
Le
v
el 2
Le
v
el 2
Level 2 Use Cases
Le
v
el 3
Le
v
el 3
Le
v
el 3
Operations
Le
v
el 4
Le
v
el 4
A
B
Participating Objects
8
Analysis Overview
9
Introduction
Analysis
Requirements
Design
System Arch. Design
Implementation
Detailed Design
Testing
10
Object Oriented Analysis (Modeling)

• Requirement elicitation leads to requirements
  specifications
• Functional model (use-case and scenarios)
• Non-functional requirements and constraints
• Analysis focuses on producing a model of the
  system analysis model
• Analysis model is composed of 2 individual models
• analysis object model (class and object diagram)
• dynamic model (statechart, sequence diagrams)

11
Analysis Phase

• Inputs - requirements specifications (use cases)
• Outputs the components of the Analysis Model
• dynamic model
• Develop preliminary sequence diagrams to
  illustrate the interaction between objects
• Develop state diagrams for objects with
  interesting behavior
• static model
• Analysis object model
• Develop preliminary object and class diagrams
  showing the structure of the system
• Heuristics to help create the Analysis Model

12
Requirements Model, Analysis Model, Design Models

• 1. Analyze the problem statement
• Identify functional requirements
• Identify nonfunctional requirements
• Identify constraints (pseudo requirements)
• 2. Build the functional model
• Develop use cases to illustrate functionality
  requirements
• 3. Build the dynamic model
• Develop sequence diagrams to illustrate the
  interaction between objects
• Develop state diagrams for objects with
  interesting behavior
• 4. Build the static model
• Develop object and class diagrams showing the
  structure of the system
• 5. Use the analysis model (static and dynamic) to
  create
• system (architecture) design model, and
• detailed object design model

13
Figure 5-2, Products of requirements elicitation
and analysis.
Requirements
Specification
nonfunctional
requirements
functional
model
Analysis Model
dynamic model
analysis object
model
System design
Object design
14
Object Modeling
15
Outline

• Activities during object modeling
• Object identification
• Object types
• entity, boundary and control objects
• Object naming
• Abbotts technique helps in object identification
• Users of class diagrams

16
Activities during Object Modeling

• Main goal Find the important abstractions
• What happens if we find the wrong abstractions?
• Iterate and correct the model
• Steps during object modeling
• 1. Class identification
• Based on the fundamental assumption that we can
  find abstractions
• 2. Find the attributes
• 3. Find the methods
• 4. Find the associations between classes
• Order of steps
• Goal get the desired abstractions
• Order of steps secondary, only a heuristic
• Iteration is important

17
Class Identification

• Identify the boundaries of the system
• Identify the important entities in the system
• Class identification is crucial to
  object-oriented modeling
• Should be able to
• Find the classes for a new software system
  (Forward Engineering)
• Identify the classes in an existing system
  (Reverse Engineering)

18
Pieces of an Object Model

• Classes
• Associations (Relations)
• Generic associations
• Canonical associations
• Part of- Hierarchy (Aggregation)
• Kind of-Hierarchy (Generalization)
• Attributes
• Application specific
• Attributes in one system can be classes in
  another system
• Operations
• Generic operations Get/Set, General world
  knowledge, design patterns
• Domain operations Dynamic model, Functional model

19
Object vs. Class

• Object (instance) Exactly one thing
• This lecture on Software Engineering on
  November 15 from 1430 -1600
• A class describes a group of objects with similar
  properties
• Game, Tournament, mechanic, car, database
• Object diagram A graphic notation for modeling
  objects, classes and their relationships
  ("associations")
• Class diagram Template for describing many
  instances of data. Useful for taxonomies,
  patters, schemata...
• Instance diagram A particular set of objects
  relating to each other. Useful for discussing
  scenarios, test cases and examples

20
Class identification

• Finding objects is the central piece in object
  modeling
• Approaches
• Application domain approach
• Ask application domain expert to identify
  relevant abstractions
• Syntactic approach (this set of slides)
• Start with use cases. Extract participating
  objects from flow of events
• Use noun-verb analysis (Abbots technique) to
  identify components of the object model
• Design patterns approach (will discuss in later
  chapters)
• Use reusable design patterns
• Component-based approach (will discuss later
  chapters)
• Identify existing solution classes

21
Finding Classes from Use Cases

• The analysis activities are guided by heuristics
• Quality of output very much depends on experience
• Heuristics for identifying objects
• Find terms that developers or users need to
  clarify in order to understand the flow of events
• Look for recurring nouns (e.g., Incident),
• Identify real world entities that the system
  needs to keep track of (e.g., FieldOfficer,
  Dispatcher, Resource),
• Identify real world procedures that the system
  needs to keep track of (e.g., EmergencyOperationsP
  lan),
• Identify data sources or sinks (e.g., Printer)
• Be prepared that some objects are still missing
  and need to be found
• Refine when you model flow of events with a
  sequence diagram
• Always use the users terms

22
Object Types

• Entity Objects
• Represent the persistent information tracked by
  the system (Application domain objects, Business
  objects)
• Boundary Objects
• Represent the interaction between the user and
  the system
• Control Objects
• Represent the control tasks performed by the
  system
• In charge of realizing use cases
• Having three types of objects leads to models
  that are more resilient to change.
• The interface of a system changes more likely
  than the control
• The control of the system change more likely than
  the application domain
• Concept is similar to Model, View, Controller
  design pattern
• Model, View, Controller (MVC)

23
Example 2BWatch Objects
Button
Year
ChangeDate
Month
LCDDisplay
Day
Entity Objects
Control Objects
Interface Objects
24
Naming of Object Types in UML

• UML provides several mechanisms to extend the
  language
• UML provides the stereotype mechanism to present
  new modeling elements
• Stereotypes can be used to distinguish different
  object types

ltltBoundarygtgt Button
ltltEntitygtgt Year
ltltControlgtgt ChangeDate
ltltEntitygtgt Month
ltltBoundarygtgt LCDDisplay
ltltEntitygtgt Day
Entity Objects
Control Objects
Boundary Objects
25
Naming Conventions to Distinguish Object Types

• Can distinguish the different object types on a
  syntactical basis. E.g., can use suffixes
• Objects ending with the _Boundary suffix are
  boundary objects
• Objects ending with the _Control suffix are
  control objects
• Entity objects do not have any suffix appended to
  their name

Button_Boundary
Year
ChangeDate_ Control
Month
LCDDisplay_Boundary
Day
26
Example Flow of events

• The customer enters a store with the intention of
  buying a toy for his child with the age of n.
• Help must be available within less than one
  minute.
• The store owner gives advice to the customer. The
  advice depends on the age range of the child and
  the attributes of the toy.
• The customer selects a dangerous toy which is
  kind of unsuitable for the child.
• The store owner recommends a more yellow doll.

27
Mapping parts of speech to object model
components Abbott, 1983
Part of speech
Model component
Example
Proper noun
object
Jim Smith
Improper noun
class
Toy, doll
Doing verb
method
Buy, recommend
Being verb
inheritance
is-a (kind-of)
Having verb
aggregation
has an
Modal verb
constraint
must be
Adjective
attribute
3 years old
Transitive verb
method
enter
Intransitive verb
method (event)
depends on
28
Abbots Analysis Example
Flow of events

• The customer enters the store to buy a toy.
• It has to be a toy that his daughter likes and it
  must cost less than 50.
• He tries a videogame, which uses a data glove and
  a head-mounted display. He likes it.

Is this a good use Case?
An assistant helps him. The suitability of the
game depends on the age of the child. His
daughter is only 3 years old. The assistant
recommends another type of toy, namely the board
game "Monopoly".
Not quite!
Monopoly is probably a left over from the
scenario 3 years old also indicates Scenario
rather than use case
The use case should terminate with the customer
leaving the store
29
Textual Analysis using Abbots technique
Grammatical construct
UML Component
Example
Concrete Person, Thing
Object
Monopoly"
Noun
class
toy"
Adjective
Attribute
"3 years old"
Verb
Operation
enters"
Intransitive verb
Operation (Event)
depends on."
Classifying verb
Inheritance
is a" ,either .. or", kind of"
Having Verb
Aggregation
"Has a ", consists of"
Modal Verb
Constraint
must be", less than"
30
Class diagram from flow of events
Flow of events
Customer

• The customer enters the store to buy a toy. It
  has to be a toy that his daughter likes and it
  must cost less than 50. He tries a videogame,
  which uses a data glove and a head-mounted
  display. He likes it.

customer
store
enters
buy
daughter
toy
less than 50
likes
videogame
An assistant helps him. The suitability of the
game depends on the age of the child. His
daughter is only 3 years old. The assistant
recommends another type of toy, namely a board
game. The customer buy the game and leaves the
store
depends
age
type of toy
board game
31
Example Identify Classes

• Title Search for Supplier Information
• Preconditions Dental Office System has been
  initialized
• Post-conditions If the search is successful,
  then the supplier information is displayed. If
  the search is not successful, then an error
  message is displayed.
• Normal Flow
• The Operator requests to search for supplier. The
  Operator may perform a keyword search using the
  Boolean operators not, and, and or. The
  Operator may enter up to three keywords
• The system displays the name, phone number, fax
  number, and address of the suppliers that match
  the search criteria.
• Alternate Flow
• The Operator requests to search for supplier. The
  Operator may perform a keyword search using the
  Boolean operators not, and, and or.
• If no matches are found, then the system displays
  an error message to the Operator.

32
Example Identify Classes

• Title Search for Supplier Information
• Preconditions Dental Office System has been
  initialized
• Post-conditions If the search is successful,
  then the supplier information is displayed. If
  the search is not successful, then an error
  message is displayed.
• Normal Flow
• The Operator requests to search for supplier. The
  Operator may perform a keyword search using the
  boolean operators not, and, and or. The
  Operator may enter up to three keywords.
• The system displays the name, phone number, fax
  number, and address of the suppliers that match
  the search criteria to the Operator.
• Alternate Flow
• The Operator requests to search for supplier. The
  Operator may perform a keyword search using the
  boolean operators not, and, and or.
• If no matches are found, then the system displays
  an error message to the Operator.

33
Order of activities in modeling

• Formulate a few scenarios with help from the end
  user and/or application domain expert.
• Extract the use cases from the scenarios, with
  the help of application domain expert.
• Analyze the flow of events, for example with
  Abbot's textual analysis.
• Generate the class diagrams, which includes the
  following steps
• Class identification (textual analysis, domain
  experts).
• Identification of attributes and operations
  (sometimes before the classes are found!)
• Identification of associations between classes
• Identification of multiplicities
• Identification of roles (label associations)

34
Object Modeling in Practice Class Identification
Foo
RoutingNo
CustomerId
Deposit()
Withdraw()
GetBalance()
Class Identification Name of Class, Attributes
and Methods
35
Object Modeling in Practice Encourage
Brainstorming
Foo
Balance
CustomerId
Deposit()
Withdraw()
GetBalance()
Naming is important! Is Foo the right name?
36
Object Modeling in Practice ctd
CustomerId
CustomerId
1) Find New Objects
2) Iterate on Names, Attributes and Methods
37
Object Modeling in Practice A Banking System

Has
1) Find New Objects
2) Iterate on Names, Attributes and Methods
3) Find Associations between Objects
4) Label the associations
5) Determine the multiplicity of the associations
38
Practice Object Modeling Iterate, Categorize!


Has
CustomerId()
39
Improving Readability of Class Diagrams

• Naming
• Representative names
• Naming conventions
• Dont put too many classes into the same package
  or page
• 7-2 (or even 5-2)
• Put Taxonomies (inheritance relationships) on a
  separate diagram

40
Summary

• System modeling
• Object model
• Dynamic model
• Functional model
• Object modeling is the central activity
• Class identification is a major activity of
  object modeling
• There are some easy syntactic rules to find
  classes/objects

41
Dynamic Modeling
42
Outline of the Lecture

• Dynamic modeling
• Sequence diagrams
• State diagrams
• Analysis example

43
Dynamic Modeling Diagrams

• Diagrams for dynamic modeling
• Interaction diagrams describe the dynamic
  behavior between objects
• Statecharts describe the dynamic behavior of a
  single object
• Interaction diagrams
• Sequence Diagram
• Dynamic behavior of a set of objects arranged in
  time sequence.
• Models the system from a single use case point of
  view
• Good for real-time specifications and complex
  scenarios
• Statechart Diagram
• A state machine that describes the response of an
  object of a given class to the receipt of outside
  stimuli (Events).

44
How do you find classes?

• We have already established the following sources
• Application domain analysis Talk to client to
  identify abstractions
• Application of general world knowledge and
  intuition
• Scenarios
• Natural language formulation of a concrete usage
  of the system
• Use Cases
• Natural language formulation of the functions of
  the system
• Textual analysis of problem statement (Abbott)
• Now we show how identify classes from dynamic
  models
• Actions and activities in statechart diagrams are
  candidates for public operations in classes
• Vertical activity lines in sequence diagrams are
  also candidates for objects

45
Find Methods with Dynamic Modeling

• Purpose
• Detect and supply methods for the object model
• How do we do this?
• Start with use case or scenario
• Model interaction between objects
• sequence diagram
• Model dynamic behavior of a single object
• statechart diagram

46
Sequence Diagram

• From the flow of events in the use case or
  scenario proceed to the sequence diagram
• Relation to object identification
• Objects/classes have already been identified
  during object modeling
• Objects are identified as a result of dynamic
  modeling
• Heuristic
• A event (message) always has a sender and a
  receiver.
• Find them for each event gt These are the objects
  participating in the use case

47
Sequence Diagram for ReportEmergency Use Case
48
(No Transcript)
49
Sequence diagram for the ReportEmergency use case
(acknowledgment on the FieldOfficerStation).
50
Heuristics for Sequence Diagrams

• Layout
• 1st column Should correspond to the actor who
  initiated the use case
• 2nd column Should be a boundary object
• 3rd column Should be the control object that
  manages the rest of the use case
• Creation
• Control objects are created by (input) boundary
  objects at the initiation of a use case
• Boundary objects (for output) are created by
  control objects
• Access
• Entity objects are accessed by control and
  boundary objects,
• Entity objects should never call boundary or
  control objects This makes it easier to share
  entity objects across use cases and makes entity
  objects resilient against technology-induced
  changes in boundary objects.

51
Sequence Diagram Impact on Object Model

• Help identify new classes
• The Sequence Diagram also supplies us with a lot
  of (new) events/messages
• For each object that receives an event there is a
  public operation in the associated class
• The name of the operation is usually the name of
  the event.
• Help distribute behavior on objects

52
What else can we get out of sequence diagrams?

• Sequence diagrams are derived from use cases
• See/inspect the internal structure of the use
  cases.
• Determine how decentralized the system is.
• We distinguish two structures for sequence
  diagrams
• Fork diagrams
• Stair diagrams

53
Fork Diagram

• Much of the dynamic behavior is placed in a
  single object, usually the control object. It
  knows all the other objects and often uses them
  for direct questions and commands.

54
Stair Diagram

• The dynamic behavior is distributed. Each object
  delegates some responsibility to other objects.
  Each object knows only a few of the other objects
  and knows which objects can help with a specific
  behavior.

55
Fork or Stair?

• Which of these diagram types should be chosen?
• Generally, stair structure is better
• The more the responsibility is spread out, the
  better
• However, this is not always true
• Decentralized control structure
• The operations have a strong connection
• always be performed in the same order
• Centralized control structure (better support of
  change)
• The operations can change order
• New operations can be inserted as a result of new
  requirements

56
Statechart Diagrams

• Graph whose nodes are states and whose directed
  arcs are transitions labeled by event names.
• We distinguish between two types of operations in
  statecharts
• Activity Operation that takes time to complete
• associated with states
• Action Instantaneous operation
• associated with events
• associated with states (reduces drawing
  complexity) Entry, Exit, Internal Action
• A statechart diagram relates events and states
  for one class
• An object model with a set of objects has a set
  of state diagrams

57
UML Statechart Diagram Notation
Event trigger With parameters
State1
State2
Event1(attr) condition/action
do/Activity
Guard condition
entry /action
exit/action
Also internal actions
58
Vending Machine StateChart Diagram
59
Nested State Diagram

• Activities in states are composite items denoting
  other lower-level state diagrams
• A lower-level state diagram corresponds to a
  sequence of lower-level states and events that
  are invisible in the higher-level diagram.
• Sets of substates in a nested state diagram
  denote a superstate are enclosed by a large
  rounded box.

60
Nested Statechart for Incident.
61
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

62
Summary Requirements Analysis
1. What are the transformations? Create
scenarios and use case diagrams Talk to client,
observe, get historical records, do thought
experiments
2. What is the structure of the system? 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? 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.
63
Lets Do Analysis

• 1. Analyze the problem statement
• Identify functional requirements
• Identify nonfunctional requirements
• Identify constraints (pseudo requirements)
• 2. Build the functional model
• Develop use cases to illustrate functionality
  requirements
• 3. Build the dynamic model
• Develop sequence diagrams to illustrate the
  interaction between objects
• Develop state diagrams for objects with
  interesting behavior
• 4. Build the object model
• Develop class diagrams showing the structure of
  the system

64
Problem Statement Direction Control for a Toy
Car

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

• Power is turned off
• Car stops and headlight goes out.
• Power is turned on
• Headlight shines
• Power is turned off
• Headlight goes out.
• Power is turned on
• Car runs forward with its headlight shining.

65
Find the Functional Model Do Use Case Modeling

• Use case 1 System Initialization
• Entry condition Power is off, car is not moving
• Flow of events
• 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
• Driver turns power off, car stops and headlight
  goes out.
• Driver turns power on, headlight shines and car
  does not move.
• Driver turns power off, headlight goes out
• Exit condition Car does not move, headlight is
  out

66
Use Cases continued

• Use case 3 Move car backward
• Entry condition Car is stationary, headlights
  off
• Flow of events
• 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
• Driver turns power off, car stops, headlight
  goes out.
• Power is turned on, headlight shines and car
  does not move.
• Power is turned off, headlight goes out.
• Exit condition Car does not move, headlight is
  out.
• Use case 5 Move car forward
• Entry condition Car does not move, headlight
  is out
• Flow of events
• Driver turns power on
• Exit condition
• Car runs forward with its headlight shining.

67
Use Case Pruning

• Do we need use case 5?
• Use case 1 System Initialization
• Entry condition Power is off, car is not moving
• Flow of events
• 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
• Driver turns power on
• Exit condition
• Car runs forward with its headlight shining.

68
Find the Dynamic Model Create 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
• . . .

69
Sequence Diagram for Drive Car Scenario
70
Toy Car Dynamic Model
Wheel
Forward
power

power

off
on
Stationary
Stationary
power

power

on
off
Backward
71
Toy Car Object Model
Car
Wheel
Headlight
Status (On, Off)
Motion (For
ward,
Backward,
Switch_On()
Stationary)
Switch_Off()
Star
t_Moving()
Stop_Moving()
72
Analysis UML Activity Diagram
Generalization relationships, suppress
redundancies
correct, consistent complete, and realistic?