Software Engineering
September 26, 2001
Analysis – Part 1
(Object Modeling)
Joseph Conron
Computer Science Department
New York University
[email protected]
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
1
Outline








From use cases to objects
Object modeling
Class vs instance diagrams
Attributes
Operations and methods
Links and associations
Examples of associations
Two special associations
 Aggregation
 Inheritance
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
2
From Use Cases to Objects
Level 1 Use Case
Level 1
Level 2
Level 3
A
Level 3
Level 3
Level 4
Level 2 Use Cases
Level 2
Level 3 Use Cases
Operations
Level 4
B
Participating
Objects
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
3
From Use Cases to Objects: Why Functional
Decomposition is not Enough
Scenarios
Level 1
Level 2
Level 3
A
Level 3
Level 3
Level 4
Level 1 Use Cases
Level 2
Level 2 Use Cases
Operations
Level 4
B
Participating
Objects
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
4
How do we describe complex systems (Natural Systems,
Social Systems, Artificial Systems)?
Epistemology
Describes our knowledge about the system
Knowledge about Causality
(Dynamic Model)
State Diagrams
(Harel)
Sequence
Diagrams
Activity
Diagrams
Petri Nets(Petri)
Uncertain Knowledge
Fuzzy Sets (Zadeh)
Fuzzy Frames
(Graham)
Bernd Bruegge & Allen Dutoit
Knowledge about Relationships
(Object model)
Knowledge about Functionality
(Functional model)
Formal
Specifications
(Liskov)
Neural
Networks
DataFlow Diagrams
(SA/SD)
Scenarios/Use Cases
Data Relationship (Jacobsen)
Inheritance
Frames,SemanticNet (E/R Modeling, Chen)
works (Minsky)
Class Diagrams
(“E/R + Inheritance”,
Rumbaugh)
Hierarchical
Database
Model (IMS)
Network
Relational
Database
Database Model
Model
(Codd)
(CODASYL)
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
5
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

Order of steps
 Goal: get the desired abstractions
 Order of steps secondary, only a heuristic
 Iteration is important
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
6
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)
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
7
Class identification is an ancient problem



Objects are not just found by taking a picture of a scene or
domain
The application domain has to be analyzed.
Depending on the purpose of the system different objects might
be found
 How can we identify the purpose of a system?
 Scenarios and use cases

Another important problem: Define system boundary.
 What object is inside, what object is outside?
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
8
Pieces of an Object Model


Classes
Associations (Relations)
 Part of- Hierarchy (Aggregation)
 Kind of-Hierarchy (Generalization)

Attributes





Detection of attributes
Application specific
Attributes in one system can be classes in another system
Turning attributes to classes
Methods
 Detection of methods
 Generic methods: General world knowledge, design patterns
 Domain Methods: Dynamic model, Functional model
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
9
Object vs Class

Object (instance): Exactly one thing
 The lecture on September 19 on Software Engineering from 7:00 –
9:00


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, patters, schemata...
 Instance diagram: A particular set of objects relating to each other.
Useful for discussing scenarios, test cases and examples
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
10
UML: Class and Instance Diagrams
Inspector
joe:
Inspector
mary:
Inspector
Class Diagram
anonymous:
Inspector
Instance Diagram
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
11
Attributes and Values
Inspector
name:string
age: integer
joe:Inspector
name = “Joe”
age = 24
Bernd Bruegge & Allen Dutoit
mary: Inspector
name = “Mary”
age = 18
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
12
Operation, Signature or Method? What when?



Operation: A function or
transformation applied to objects
in a class. All objects in a class
share the same operations
(Analysis Phase)
Signature: Number & types of
arguments, type of result value. All
methods of a class have the same
signature (Object Design Phase)
Method: Implementation of an
operation for a class
(Implementation Phase)
Polymorphic operation: The same
operation applies to many different
classes.
Bernd Bruegge & Allen Dutoit
Workorder
File_name: String
Size_in_bytes: integer
Last_update: date
Stickies: array[max]
print()
delete()
open()
close()
write()
read()
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
13
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.
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
14
1-to-1 and 1-to-many Associations
Hascapital
Country
name:String
City
name:String
One-to-one association
Workorder
StickyNote
*
schedule()
x: Integer
y: Integer
z: Integer
One-to-many association
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
15
Object Instance Diagram
Example for 1-to-many
:Sticky
:WorkOrder
x,y,z=(-1,0,5)
:Sticky
x,y,z=(1,10,1)
:Sticky
x,y,z=(10,1,2)
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
16
Many-to-Many Associations
Mechanics
Bernd Bruegge & Allen Dutoit
*
Work on
*
Plane
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
17
Do UML associations have direction?
 A association between two classes is by default a bi-directional
mapping.
B
A


Class A can access class B and class B can access class A
Both classes play the agent role.
If you want to
to make
A a client, and B a server, you can make the association
Name
of association
unidirectional. The arrowhead points to the server
Namerole:
Direction
A
accesses
B
Association Direction
Class A ( the “client”) accesses class B (“the server”). B is also called navigable
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
18
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.
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
19
Aggregation
Automobile
Engine
serial number
year
manufacturer
model
color
weight
horsepower
volume
on
off
drive
purchase
3,4,5
Wheel
diameter
number of bolts
Bernd Bruegge & Allen Dutoit
*
Brakelight
on
off
2,4
Door
open
close
Battery
amps
volts
charge
discharge
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
20
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
Red
Bernd Bruegge & Allen Dutoit
White
MuscleCell
Smooth
Striate
NerveCell
Cortical
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
Pyramidal
21
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)
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
22
Other Associations

Uses:
 A subsystem uses another subsystem (System Design)

Contains:
 Sometimes called “spatial aggregation”
 ... contains ...
 Example: A UML package contains another UML package

Parent/child relationship:
 ... is father of ...
 ... is mother of ...

Seniority:
 ... is older than ...
 ... is more experienced than ...
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
23
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

Having three types of objects leads to models that are more
resilient to change.
 The boundary of a system changes more likely than the control
 The control of the system change more likely than the application
domain

Object types originated in Smalltalk:
 Model, View, Controller (MV)
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
24
Example: 2BWatch Objects


UML provides several mechanisms to extend the language
UML provides the stereotype mechanism to present new
modeling elements
<<entity>>
Year
<<entity>>
Month
<<control>>
ChangeDateControl
<<boundary>>
ButtonBoundary
<<boundary>>
LCDDisplayBoundary
<<entity>>
Day
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
25
Roles



A role name is the name that uniquely identifies one end of an
association.
A role name is written next to the association line near the class
that plays the role.
When do you use role names?
 Necessary for associations between two objects of the same class
 Also useful to distinguish between two associations between the
same pair of classes

When do you not use role names?
 If there is only a single association between a pair of distinct classes,
the names of the classes serve as good role names
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
26
Example of Role
Problem Statement : A person assumes the role of repairer
with respect to another person, who assumes the role of
inspector with respect to the first person.
Person
Person
*
Person
Bernd Bruegge & Allen Dutoit
Creates Workorders
inspector
Creates Workorders
*
repairperson
Person
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
27
Roles in Associations

Client Role:
 An object that can operate upon other objects but that is never
operated upon by other objects.

Server Role:
 An object that never operates upon other objects. It is only
operated upon by other objects.

Agent Role:
 An object that can both operate upon other objects and be operated
upon by other objects. An agent is usually created to do some work
on behalf of an actor or another agent.
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
28
Qualification


The qualifier improves the information about the multiplicity of
the association between the classes.
It is used for reducing 1-to-many multiplicity to 1-1
multiplicity
Without qualification: A directory has many files. A file belongs only to
one directory.
Directory
Directory
1
*
File
filename
filename
1
0..1
File
With qualification: A directory has many files, each with a unique name
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
29
Example
Problem Statement : A stock exchange lists many companies.
However, a stock exchange lists only one company with a
given ticker symbol. A company may be listed on many stock
exchanges, possibly with different ticker symbols.
Find company with ticker symbol AAPL.
StockExchange
Bernd Bruegge & Allen Dutoit
*
lists
*
Company
tickerSym
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
30
Use of Qualification reduces multiplicity
StockExchange
StockExchange
Bernd Bruegge & Allen Dutoit
*
*
Company
tickerSym
tickerSym
1
0..1
Company
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
31
How do you find classes?







Learn about problem domain: Observe your client
Apply general world knowledge and intuition
Take the flow of events and find participating objects in use cases
Apply design patterns
Try to establish a taxonomy
Do a textual analysis of scenario or flow of events (Abbott
Textual Analysis, 1983)
Nouns are good candidates for classes
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
32
Example: Scenario from Problem Statement





Jim Smith enters a store with the intention of buying a toy for
his 3 year old child.
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.
Jim selects a dangerous toy which is unsuitable for the child.
The store owner recommends a more yellow doll.
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
33
Mapping parts of speech to object model components
[Abbot 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
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
34
Object Modeling: Identifying Entity Objects





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)
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
35
Object Modeling: Identifying Boundary Objects



Represent system interface with actors
Each use case interacts with at least one boundary object
Windows and forms
 Example: EmergencyReportForm

Events and messages
 Example: ReportEmergencyButton

External systems
 Example: Hand held computer use by FieldOfficer
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
36
Object Modeling: Identifying Control Objects





Coordinate entity and boundary objects
Close relationship between use case and control object
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
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
37
Object Modeling in Practice: Class Identification
Account
Balance
CustomerId
Deposit()
Withdraw()
GetBalance()
Class Identification: Name of Class, Attributes and Methods
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
38
Object Modeling in Practice
Account
Balance
AccountId
Bank
Deposit()
Withdraw()
GetBalance()
Name
Customer
Name
CustomerId
Find New Objects
Iterate on Names, Attributes and Methods
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
39
Object Modeling in Practice: A Banking System
Account
Bank
Name
Balance
AccountId
Customer
*
Has
Deposit()
Withdraw()
GetBalance()
Name
CustomerId
Find New Objects
Iterate on Names, Attributes and Methods
Find Associations between Objects
Label the associations
Determine the multiplicity of the associations
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
40
Object Modeling in Practice: Categorize!
Account
Bank
*
Name
Balance
AccountId
Customer
*
Has
Deposit()
Withdraw()
GetBalance()
Name
CustomerId
Savings
Account
Checking
Account
Mortgage
Account
Withdraw()
Withdraw()
Withdraw()
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
41
Object Modeling in Practice: Heuristics



Explicitly schedule meetings for object identification
Try to differentiate between entity, boundary and control
objects
Find associations and their multiplicity
 Unusual multiplicities usually lead to new objects or categories

Identify Aggregation
Identify Inheritance: Look for a Taxonomy, Categorize

Allow time for brainstorming , Iterate, iterate

Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
42