Chapter- 4

Software Project Management

Reading Assignment

Chapter-5

Analysis
Definition: 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

2
Class Identification
• Identify the boundaries of the system
• Identify the important entities in the system
• Class identification is crucial to object-oriented modeling
• Basic assumption:
1. We can find the classes for a new software system (Forward Engineering)
2. We can identify the classes in an existing system (Reverse Engineering)

3
Pieces of an Object Model

• Classes
• Associations (Relations)
• Part of- Hierarchy (Aggregation)
• Kind of-Hierarchy (Generalization)
• Attributes
• Detection of attributes
• Application specification
• Attributes in one system can be classes in another system
• Turning attributes to classes
• Methods
• Detection of methods
• Domain Methods: Dynamic model, Functional model

5
Object vs Class
• Object (instance): Exactly one thing
• A class describes a group of objects with similar properties
• 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, patterns, schemata...
• Instance diagram: A particular set of objects relating to each other.
Useful for discussing scenarios, test cases and examples

6
UML: Class and Instance Diagrams

Inspector Class Diagram

joe: mary: anonymous:

Inspector Inspector Inspector

Instance Diagram

7
Attributes and Values
Inspector

name:string
age: integer

joe:Inspector mary: Inspector

name = “Joe” name = “Mary”

age = 24 age = 18

8
Links and Associations
• Links and associations establish relationships among objects and
classes.
• Link:
• A connection between two object instances. A link is like a tuple.
• A link is an instance of an association
• Association:
• Basically a bidirectional mapping.
• One-to-one, many-to-one, one-to-many,
• An association describes a set of links like a class describes a set of objects.

9
1-to-1, 1-to-many & many-to-many Associations

Country Has-capital City

name:String name:String

One-to-one association

StickyNote
Workorder
* x: Integer
y: Integer
schedule() One-to-many association z: Integer

Mechanics Plane
* Work on *
Many-to-Many Association

10
Aggregation
• Models "part of" hierarchy
• Useful for modeling the breakdown of a product into its component
parts (sometimes called bills of materials (BOM) by manufacturers)
• UML notation: Like an association but with a small diamond indicating
the assembly end of the relationship.

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

3,4,5 * 2,4

Wheel Brakelight Door Battery

diameter amps
number of bolts open volts
on close
off charge
discharge

12
Inheritance
• Models "kind of" hierarchy
• Powerful notation for sharing similarities among classes
while preserving their differences
• UML Notation: An arrow with a triangle
Cell

BloodCell MuscleCell NerveCell

Red White Smooth Striate Cortical Pyramidal

13
Aggregation vs Inheritance
• Both associations describe trees (hierarchies)
• Aggregation tree describes a-part-of relationships (also called and-
relationship)
• Inheritance tree describes "kind-of" relationships (also called or-relationship)

• Aggregation relates instances (involves two or more different objects)

• Inheritance relates classes (a way to structure the description of a

single object)

14
Object Modeling: Identifying Entity Objects

• Entity: models information that is long-lived and often persistent

• represents concepts such as an individual, a real-life object or a real-life event
è often derived directly from domain model
è will likely be implemented as part of a database
• Recurring nouns from use cases (e.g. account)
• Real-world entities (e.g. depositor)
• Real-world activities that system must track (e.g. transaction)
• Use cases (e.g., withdraw cash)
• Data sources or sinks (ATM, printer)

15
Object Modeling: Identifying Boundary Objects

• Represent system interface with actors

• Each use case interacts with at least one boundary object
• Windows and forms
• Boundary class: models the interaction between the system and its
actors
• interacts with actors outside the system as well as with classes within the system
• represents an abstraction of UI elements (windows, forms, panes, etc.) or devices
(printer interfaces, sensors, terminals, etc.)
• Example: EmergencyReportForm
• Events and messages
• Example: ReportEmergencyButton
• External systems
• Example: Hand held computer use by FieldOfficer
16
… Analysis Concepts

• Control objects: models coordination, sequencing, transaction and

control behavior for one or more use cases
• Control objects are responsible for coordinating boundary and entity
objects.
• usually does not have a correspondence in the application domain
• initially, we assign one control class for each actor/use case pair
• responsible for the flow of events in the use case
• complicated behavior may need to be divided among several control classes later
on
• may also combine/eliminate some control classes later on

è a control class should only be tied to at most one actor

• a control object is usually created at the beginning of a use case and
ceases to exist at its end. 17
Object Modeling: Identifying Control Objects

• Coordinate entity and boundary objects

• Control object is “born” when use case starts and “dies” when use
case ends.
• Collects information from boundary object and gives it to entity
object
• Example: customer withdraws cash from account using ATM.
• ATM is boundary object
• Account is entity object
• WithdrawRequest is control object

18
Identifying Control Objects
• Control objects are responsible for coordinating boundary and entity
objects
• Control objects usually do not have a concrete counterpart in the real
world
• a control object is usually created at the beginning of a use case and
ceases to exist at its end.
• It is responsible for collecting information from the boundary objects
and dispatching it to entity objects
• Heuristics for identifying control objects:
• Identify one control object per use case.
• Identify one control object per actor in the use case.
• The life span of a control object should cover the extent of the use case or the
extent of a user session. 19
Object Modeling in Practice: A Banking System

Account

Balance Customer
*
AccountId
Bank Has
Name
Name Deposit() CustomerId
Withdraw()
GetBalance()

Find New Objects

Iterate on Names, Attributes and Methods
Find Associations between Objects
Label the associations
Determine the multiplicity of the associations
20
Object Modeling in Practice: Categorize!

Account
Bank Customer
* Balance *
Name AccountId Has Name

Deposit()
Withdraw()
GetBalance() CustomerId

Savings Checking Mortgage

Account Account Account

Withdraw() Withdraw() Withdraw()

21
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:
• Two types of interaction diagrams:
• Sequence Diagram:
• Describes the dynamic behavior of several objects over time
• Good for real-time specifications
• Collaboration Diagram:
• Shows the temporal relationship among objects
• Position of objects is based on the position of the classes in the UML class diagram.
• Does not show time,

22
Sequence Diagram
• A sequence diagram is a graphical description of the objects
participating in a use case
• Heuristic for finding participating objects:
• An event always has a sender and a receiver
• Find them for each event => These are the objects participating in the use
case.

23
Mapping Use Cases to Objects with
Sequence Diagrams
• A sequence diagram ties use cases with objects.
• It shows how the behavior of a use case (or scenario) is distributed
among its participating objects.
• Sequence diagrams are usually not as good a medium for
communication with the user as use cases are,
• A Sequence diagram requires more background about the notation
which makes it difficult to be understood by the user
• Sequence diagrams allow developers to find missing objects or grey
areas in the requirements specification
• Sequence diagrams model the sequence of interactions among
objects needed to realize the use case
24
Use cases .. To Sequence diagram

• The columns of a sequence diagram represent the objects that

participate in the use case.
• The left-most column is the actor who initiates the use case.
• Horizontal arrows across columns represent messages, or stimuli, that
are sent from one object to the other.
• Time proceeds vertically from top to bottom.
• The receipt of a message by an object triggers the activation of an
operation.
• The activation is represented by a vertical rectangle from which other
messages can originate.
• The length of the rectangle represents the time the operation is
active. 25
Mapping use case to sequence …

• Sequence diagram for the ReportEmergency use case

26
SEQUENCE DIAGRAMS
• shows the interactions among objects arranged in time sequence

: Registrar : CourseFormUI : CurriculumMgr : Course

set(course info) iteration
relative marker guard
time process() condition
change course(course)
[course exists]
* change course(course)

message

activation return
time (optional)

lifeline
27
Sequence diagram…
:NewRegistrationButton :RegistrationForm
<<UI>> :RegistrationControll : Member
:Personnel
:Member <<UI>> :PayrooSection

• Want to Register()
Press Button()
Creat() Creat()

Fill()

Submit()
Validate()

Creat()

Acknowledge()
Message()

Report()

Figure 3.3. Sequence Diagram for member registration

28
SEQUENCE DIAGRAMS (cont’d)
objects go across horizontally and can be named or anonymous
• first column –> the actor who initiates the use case
• second column –> a boundary object (that the actor uses to initiate the use
case)
• third column –> the control object that manages the use case

time axis goes downward

• not linear, but should be regarded as event controlled;
• shows precedence, not actual time

lifeline of an object is represented by a vertical dashed line

• order among lifelines is not significant
• all behavior of an object will be attached to its lifeline
29
SEQUENCE DIAGRAMS (cont’d)
messages are named and represented by (solid head) arrows that
point from sender to receiver
• order of messages is shown from top to bottom
• return value (open head, dashed) arrow is optional and is usually omitted
è mark the lifeline to which a message is sent with a rectangle
representing the operation

self-delegation (a message an object sends to itself) is shown by

sending the message arrow back to the same lifeline

can also include the following control information:

• guard condition: indicates condition under which a message is sent
• iteration marker: shows that a message is sent many times to multiple
receiver objects (e.g., iterating over a collection)
30