Object-Oriented Software Engineering

Conquering Complex and Changing Systems

Object Modeling
Chapter 5, Analysis:
Exercise 2.6

Draw a sequence diagram for the warehouseOnFire scenario (as

described in the requirements elicitation lecture).
Include the objects bob, alice, john, system, and instances of other
classes you may need.
Draw only the first five message sends.

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 2
Solutions to exercise 2.6

Initiating actor should Dispatcher should be

be on this side. All objects involved in on this side
this scenario are instances.
This is how an object
:FRIEND creation looks like.
bob alice john
new EmergencyForm()
reportEmergency()
:EmergencyForm
specifyIncident()

requestResource(fireTruck)

commit() notifyDispatcher()

Note: this exercise can have many other acceptable solutions.

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 3
Exercise 2.7

Draw a sequence diagram for the ReportIncident use case (as

described in the requirements elicitation lecture).
Make sure it is consistent with the sequence diagram of the previous
exercise.
Draw only the first five message sends.

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 4
Sample solution to exercise 2.7
Class and operation This is a use case,
names should be the hence, we are dealing
same as in the previous with classes.
diagram.
FRIEND
FieldOfficer Dispatcher
new EmergencyForm()
reportEmergency()
EmergencyForm
specifyIncident()

*requestResource()

commit() notifyDispatcher()
This is how an iteration
is specified.

Note: this exercise can have many other acceptable solutions, as before.

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 5
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
w Aggregation
w Inheritance

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 6
 User
From Use Cases to Objects Tasks

Level 1 Level 1 Use Case

Le vel 2 Le vel 2 Level 2 Use Cases

Le vel 3 Le vel 3 Le vel 3 Level 3 Use Cases

Operations
Le vel 4 Le vel 4

A B
Participating
Objects

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 7
From Use Cases to Objects: Why Functional
Decomposition is not Enough
Level 1 Scenarios

Le vel 2 Le vel 2 Level 1 Use Cases

Le vel 3 Le vel 3 Le vel 3 Level 2 Use Cases

Operations
Le vel 4 Le vel 4

A B
Participating
Objects

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 8
 How do we describe complex systems (Natural Systems, Social
Systems, Artificial Systems)?
Epistemology
Describes our knowledge about the system

Knowledge about Causality Knowledge about Relationships Knowledge about Functionality

(Dynamic Model) (Object model) (Functional model)

Sequence Formal Neural

State Diagrams Diagrams Networks
Specifications
(Harel) Activity
(Liskov)
Diagrams DataFlow Diagrams
(SA/SD)
Petri Nets(Petri) Scenarios/Use Cases
Inheritance Data Relationship (Jacobson)
Frames,SemanticNetw (E/R Modeling, Chen)
orks (Minsky)
Uncertain Knowledge
Fuzzy Sets (Zadeh)

Class Diagrams Hierarchical Network Relational

Fuzzy Frames (“E/R + Inheritance”, Database Database Database Model
(Graham) Rumbaugh) Model (IMS) Model (Codd)
(CODASYL)
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 9
Definition: Object Modeling
♦ Main goal: Find the important abstractions
♦ What happens if we find the wrong abstractions?
w Iterate and correct the model
♦ Steps during object modeling
w 1. Class identification
t Based on the fundamental assumption that we can find abstractions
w 2. Find the attributes
w 3. Find the methods
w 4. Find the associations between classes
♦ Order of steps
w Goal: get the desired abstractions
w Order of steps secondary, only a heuristic
w Iteration is important

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 10
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:
w 1. We can find the classes for a new software system (Forward
Engineering)
w 2. We can identify the classes in an existing system (Reverse
Engineering)
♦ Why can we do this?
w Philosophy, science, experimental evidence

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 11
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
w How can we identify the purpose of a system?
w Scenarios and use cases
♦ Another important problem: Define system boundary.
w What object is inside, what object is outside?

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 12
What is This?

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 13
Pieces of an Object Model
♦ Classes
♦ Associations (Relations)
w Part of- Hierarchy (Aggregation)
w Kind of-Hierarchy (Generalization)
♦ Attributes
w Detection of attributes
w Application specific
w Attributes in one system can be classes in another system
w Turning attributes to classes
♦ Methods
w Detection of methods
w Generic methods: General world knowledge, design patterns
w Domain Methods: Dynamic model, Functional model

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 14
Object vs Class
♦ Object (instance): Exactly one thing
w The lecture on November 2 on Software Engineering from 14:30 -16:00
♦ A class describes a group of objects with similar properties
w IETM, Author, Corrosion, Work order
♦ Object diagram: A graphic notation for modeling objects, classes and
their relationships ("associations"):
w Class diagram: Template for describing many instances of data. Useful for
taxonomies, patters, schemata...
w Instance diagram: A particular set of objects relating to each other. Useful
for discussing scenarios, test cases and examples
♦ Together-J: CASE Tool for building object diagrams, in particular
class diagrams
w Tutorial on November 10

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 15
UML: Class and Instance Diagrams

Inspector Class Diagram

joe: mary: anonymous:

Inspector Inspector Inspector

Instance Diagram

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 16
Attributes and Values

Inspector

name:string
age: integer

joe:Inspector mary: Inspector

name = “Joe” name = “Mary”

age = 24 age = 18

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 17
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) Workorder
♦ Signature: Number & types of File_name: String
arguments, type of result value. All Size_in_bytes: integer
methods of a class have the same Last_update: date
signature (Object Design Phase) Stickies: array[max]
♦ Method: Implementation of an print()
operation for a class (Implementation delete()
Phase) open()
Polymorphic operation: The same close()
operation applies to many different write()
classes. read()

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 18
Links and Associations

♦ Links and associations establish relationships among objects and

classes.
♦ Link:
w A connection between two object instances. A link is like a tuple.
w A link is an instance of an association
♦ Association:
w Basically a bidirectional mapping.
w One-to-one, many-to-one, one-to-many,
w 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 19
1-to-1 and 1-to-many Associations

Country Has- City

capital
name:String name:String

One-to-one association

StickyNote
Workorder
* x: Integer
y: Integer
schedule() z: Integer

One-to-many association
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 20
Object Instance Diagram

Example for 1-to-many

:Sticky :WorkOrder :Sticky

x,y,z=(-1,0,5) 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 21
Many-to-Many Associations

Mechanics Plane
* Work on *

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 22
Roles in Associations

♦ Client Role:
w An object that can operate upon other objects but that is never operated
upon by other objects.

♦ Server Role:
w An object that never operates upon other objects. It is only operated upon
by other objects.

♦ Agent Role:
w 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 23
Do UML associations have direction?
w A association between two classes is by default a bi-directional mapping.

A B

t Class A can access class B and class B can access class A

t Both classes play the agent role.

If you wantName
to toofmake A a client, and B a server, you can make the
association
Name Direction
association unidirectional. The arrowhead points to the server
role:
accesses
A 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 24
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 25
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

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 26
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

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 27
Aggregation vs Inheritance

♦ Both associations describe trees (hierarchies)

w Aggregation tree describes a-part-of relationships (also called
and-relationship)
w 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 28
Other Associations

♦ Uses:
w A subsystem uses another subsystem (System Design)
♦ Contains:
w Sometimes called “spatial aggregation”
w ... contains ...
w Example: A UML package contains another UML package
♦ Parent/child relationship:
w ... is father of ...
w ... is mother of ...
♦ Seniority:
w ... is older than ...
w ... is more experienced than ...

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 29
Odds and Ends

♦ Hoererschein for the book:

w Participating Bookstores: If you say you are taking this class, you get 10%
off at:
t Buchladen am Obelisk (Barerstrasse),
t Kanzler (Gabelsbergerstrasse),
t Lachner (Theresienstrasse)
♦ Solution to last exercise
♦ Finding a superclass

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 30
Object Types11/2/00
♦ Entity Objects
w Represent the persistent information tracked by the system (Application
domain objects, “Business objects”)
♦ Boundary Objects
w Represent the interaction between the user and the system
♦ Control Objects:
w Represent the control tasks performed by the system
♦ Having three types of objects leads to models that are more resilient
to change.
w The boundary of a system changes more likely than the control
w The control of the system change more likely than the application domain
♦ Object types originated in Smalltalk:
w Model, View, Controller (MVC) => Observer Pattern

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 31
Example: 2BWatch Objects

♦ UML provides several mechanisms to extend the language

♦ UML provides the stereotype mechanism to present new modeling
elements

<<entity>> <<control>> <<boundary>>

Year ChangeDateControl ButtonBoundary

<<entity>> <<boundary>>
Month LCDDisplayBoundary

<<entity>>
Day

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 32
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?
w Necessary for associations between two objects of the same class
w Also useful to distinguish between two associations between the same pair
of classes
♦ When do you not use role names?
w 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 33
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
* Creates Workorders

Person inspector Person

* Creates Workorders
repairperson

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 34
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.

1 * File
Directory
filename

1 0..1
Directory filename 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 35
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, DCX.

* lists * Company
StockExchange
tickerSym

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 36
Use of Qualification reduces multiplicity

* * Company
StockExchange
tickerSym

1 0..1
StockExchange tickerSym Company

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 37
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 38
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
transitive verb method enter
intransitive verb method (event) depends on

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 39
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 40
Object Modeling in Practice: Class Identification

Foo

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 41
Object Modeling in Practice:
Encourage Brainstorming

“Dada” Foo

Balance Balance
CustomerId CustomerId

Deposit() Deposit()
Withdraw() Withdraw()
GetBalance() GetBalance()
Account

Balance
CustomerId

Deposit()
Naming is important! Withdraw()
GetBalance()

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 42
Object Modeling in Practice

Account

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

Find New Objects

Iterate on Names, Attributes and Methods

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 43
Object Modeling in Practice: A Banking System

Account

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

Find New Objects

Iterate on Names, Attributes and Methods
Find Associations between Objects
Label the assocations
Determine the multiplicity of the assocations
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 44
Object Modeling in Practice: Categorize!
Account
Bank Customer

Name
* Amount * Has Name
AccountId
CustomerId
AccountId
Deposit()
Withdraw()
GetBalance() CustomerId

Savings Checking Mortgage

Account Account Account

Withdraw() Withdraw() Withdraw()

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 45
Avoid Ravioli Models
Account
Bank Customer

Name
* Amount * Has Name
AccountId
CustomerId
AccountId
Deposit()
Withdraw()
GetBalance() CustomerId

Don’t put too many classes into the same package:

7+-2 (or even 5+-2)

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 46
Avoid Ravioli Models: Put Taxonomies in a separate View
Account

Amount
AccountId
CustomerId
AccountId
Deposit()
Withdraw()
GetBalance()

Savings Checking Mortgage

Account Account Account

Withdraw() Withdraw() Withdraw()

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 47
Object Modeling in Practice: Heuristics

♦ Explicitly schedule a team meeting for object identification

♦ Try to differentiate between entity, boundary and control objects
♦ Find associations and their multiplicity
w 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 48
Software Engineers are not the only System Analysts
Ontology
Object and System boundary identification

Religion Phenomenology Realism

Objects are user defined

Idealism Materialism

Naive Idealism Critical Idealism Marx Naive Realism

Objects exist only in my Reality is determined by Ideas are determined Things are exactly
imagination. If I close my eyes, they our ideas by the economic how we experience
don't exist (Berkeley) (Kant, Hegel, reality them
Schopenhauer)

Dualistic Idealism David Hume

Monistic Idealism

Schopenhauer
Plato Goethe Steiner
Reality can never be
seen only its shadow. Kant
Ideas are made up by humans
"Ding an sich" :Reason for
perception but can never be
seen itself Dialectism
Ideas are determined by the
dialog between the user and
reality
(Sokrates, Hegel, Marx)

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 49
What is a Software Engineer?

♦ From the point of view of phenomenology, Software

Engineers are dialectic monistic idealists:
w Idealists:
t They accept that ideas (called requirements or “customer’s wishlist”)
are different from reality.
t The reality might not yet exist (“Vaporware is always possible ”)
w They are monistic:
t They are optimistic that their ideas can describe reality.
w Dialectic:
t They do this in a dialogue with the customer

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 50
Summary

In this lecture, we reviewed the construction of the object model from

use case model. In particular, we described:
♦ Identification of objects
♦ Refinement of objects with attributes and operations
♦ Generalization of concrete classes
♦ Identification of associations
♦ Reduction of multiplicity using qualification.

In the next lecture, we describe the construction of the dynamic model

from the use case and object models.

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 51
Exercises

5.6 Consider the object model below (adapted from [Jackson, 1995]):
Year

Month

Week

Day
Given your knowledge of the Gregorian calendar, list all the problems
with this model. Modify it to correct each of them.

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 52
Exercises (cont’d)

5.7 Consider the object model of the previous exercise. Using

association multiplicity only, can you modify the model such that a
developer unfamiliar with the Gregorian calendar could deduce the
number of days in each month? Identify additional classes if
necessary.

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 53
Next Steps

♦ For all students:

w Tomorrow: Requirements Elicitation Tutorial (REQ/QOC)
w Next Thursday: Configuration Management
w Next Friday: TogetherJ Tutorial

♦ For STARS students:

w GUI Mockup due tomorrow on Notes Bboard
t 2-3 slides + name of presenter for each team
w GUI Mockup review on Monday 14:15

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 54