Chapter 5: AnalysisPart I: Object ModelingPart II: Dynamic Modeling

Qutaibah MalluhiSoftware EngineeringQatar University

Based on slides by Bernd Bruegge & Allen H. Dutoit

Introduction

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

Ambiguity: what do you see?

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?

From Use Cases to ObjectsLevel 1 Use Case

Level 2 Use Cases

Level 3 Use Cases

Operations

ParticipatingObjects

Level 2

Level 1

Level 2

Level 3 Level 3

Level 4 Level 4

Level 3

A B

Why Functional Decomposition is not Enough

Scenarios

Level 1 Use Cases

Level 2 Use Cases

Operations

ParticipatingObjects

Level 2

Level 1

Level 2

Level 3 Level 3

Level 4 Level 4

Level 3

A B

Analysis Overview

Introduction

Requirements

Design

Implementation

Testing

Analysis

System Arch. Design

Detailed Design

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)

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

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

Figure 5-2, Products of requirements elicitation and analysis.

Analysis

functionalmodel

nonfunctionalrequirements

analysis objectmodel

Requirementselicitation

dynamic model

Requirements

Analysis Model

Specification

System design

Object design

Object Modeling

Outline

Activities during object modeling Object identification Object types

entity, boundary and control objects

Object naming Abbott’s technique helps in object identification Users of class diagrams

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

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:

1. Find the classes for a new software system (Forward Engineering)

2. Identify the classes in an existing system (Reverse Engineering)

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

Object vs. Class

Object (instance): Exactly one thing This lecture on Software Engineering on November 15 from 14:30 -

16:00 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

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

EmergencyOperationsPlan), 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 user’s terms

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)

Example: 2BWatch Objects

Year

Month

Day

ChangeDateButton

LCDDisplay

Entity Objects Control Objects Interface Objects

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

<<Entity>>Year

<<Entity>>Month

<<Entity>>Day

<<Control>>ChangeDate

<<Boundary>>Button

<<Boundary>>LCDDisplay

Entity Objects Control Objects Boundary Objects

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

Year

Month

Day

ChangeDate_Control

Button_Boundary

LCDDisplay_Boundary

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.

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

Abbot’s Analysis Example 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.

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

Flow of events:

Is this a good useCase?

“Monopoly” is probably a left over from the scenario3 years old also indicates

Scenario rather than use case

The use case should terminate with the

customer leaving the store

Not quite!

Grammatical construct UML Component

Concrete Person, Thing Object

Noun class

Verb Operation

Classifying verb Inheritance

Having Verb Aggregation

Modal Verb Constraint

Adjective Attribute

Intransitive verb Operation (Event)

Textual Analysis using Abbot‘s technique

Example

“Monopoly"

“toy"

“enters"

“is a" ,“either .. or", “kind of…"

"Has a ", “consists of"

“must be", “less than…"

"3 years old"

“depends on…."

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.

Class diagram from flow of events

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

type of toy

customer

depends

storeentersCustomer

?

enter()

toy

daughter

suitable

*

less than $50store

enter()

daughterage

toy

buy()

videogame boardgame

toy

age

videogame

daughter

board game

Flow of events:

toypricebuy()like()

buy

likes

Example: Identify Classes

Title: Search for Supplier InformationPreconditions: Dental Office System has been initializedPost-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.

Example: Identify Classes

Title: Search for Supplier InformationPreconditions: Dental Office System has been initializedPost-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.

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)

Object Modeling in Practice: Class Identification

Foo

RoutingNo

CustomerId

Deposit()Withdraw()GetBalance()

Class Identification: Name of Class, Attributes and Methods

Object Modeling in Practice: Encourage Brainstorming

Foo

Balance

CustomerId

Deposit()Withdraw()GetBalance()

Account

Balance

CustomerId

Deposit()Withdraw()GetBalance()

Naming is important! Is Foo the right name?

“Dada”

Balance

CustomerId

Deposit()Withdraw()GetBalance()

Object Modeling in Practice ctd

Account

Balance

Deposit()Withdraw()GetBalance()

Customer

NameCustomerId

1) Find New Objects

CustomerIdAccountId

2) Iterate on Names, Attributes and Methods

Bank

Name

Object Modeling in Practice: A Banking System

Account

Betrag

Deposit()Withdraw()GetBalance()

Customer

NameCustomerId

CustomerIdAccountId

AccountIdBank

Name

1) Find New Objects

2) Iterate on Names, Attributes and Methods

3) Find Associations between Objects

Has

4) Label the associations5) Determine the multiplicity of the associations

*

Practice Object Modeling: Iterate, Categorize!

Customer

Name

CustomerId()

Account

Balance

Deposit()Withdraw()GetBalance()

CustomerIdAccountId

AccountId

Bank

Name Has**

SavingsAccount

Withdraw()

CheckingAccount

Withdraw()

MortgageAccount

Withdraw()

Improving Readability of Class Diagrams

NamingRepresentative namesNaming conventions

Don’t put too many classes into the same package or page7+-2 (or even 5+-2)

Put Taxonomies (inheritance relationships) on a separate diagram

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

Dynamic Modeling

Outline of the Lecture

Dynamic modelingSequence diagramsState diagrams

Analysis example

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

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

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

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 => These are the objects

participating in the use case

FieldOfficer Report

EmergencyButton ReportEmergencyControl ReportEmergency

Form Emergency

Report Manage

EmergencyControl

press()

create()create()

submit()

fillContents()

submitReport()create()

submitReportToDispatcher()

Sequence Diagram for ReportEmergency Use Case

ManageEmergencyControl

IncidentForm Incident Acknowledgment Dispatcher

create()

createIncident()

create()

submit()

create()

submitReportToDispatcher() view()

Boundary

Sequence diagram for the ReportEmergency use case

(acknowledgment on the FieldOfficerStation).

FieldOfficer ReportEmergency

Control Acknowledgment

Notice Manage

EmergencyControl

create

view

acknowledgeReport()

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.

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

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

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.

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.

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

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

UML Statechart Diagram Notation

State2State1 Event1(attr) [condition]/action

entry /action

exit/action

do/Activity

Also: internal actions

Event triggerWith parameters

Guardcondition

Vending Machine StateChart Diagram

do: test item and compute change

do: make changedo: dispense item

Idle

[item empty] [select(item)]

[change=0] [change>0]

[change<0]

Collect Moneycoins_in(amount) / add to balance

coins_in(amount) / set balance

cancel / refund coins

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.

Nested Statechart for Incident.

Active

Inactive Closed Archived

all

when date > 1yr.

resourcessubmitted reports

Reported Assessment

DisengagementResponse

field officerarrives on site

field officerreleases resources

dispatcherallocates resources

field officer requestsadditional resources

all resourcesdeallocated

State Chart Diagram vs Sequence Diagram State chart diagrams help to identify:

Changes to an individual object over time

Sequence diagrams help to identifyThe temporal relationship of between objects

over timeSequence of operations as a response to one

ore more events

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 receiversShow sequence of events exchanged between objects. Identify event dependencies and event concurrency.

Create state diagrams Only for the dynamically interesting objects.

Summary: Requirements Analysis

Dynamic Modeling

Functional Modeling

Object Modeling

Let’s 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

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

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.

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

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.

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.

Find the Dynamic Model: Create sequence diagram Name: Drive Car Sequence of events:

Billy turns power onHeadlight goes onWheels starts moving forwardWheels keeps moving forwardBilly turns power offHeadlight goes offWheels 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 ModelWheel

Forward

Backward

Stationary Stationary

poweron

poweroff

poweroff

poweron

Headlight

poweron

poweroff

Off

On

Toy Car: Object Model

Wheel

Motion: (Forward,

Stationary) Backward,

Start_Moving()Stop_Moving()

Headlight

Status: (On, Off)

Switch_On()Switch_Off()

Power

Status: (On, Off)

TurnOn()TurnOff()

Car