Object-Oriented Modeling:
Static Models
Grady Booch, James Rumbaugh, and Ivar Jacobson,
The Unified Modeling Language User Guide, 2nd
edition, Addison Wesley, 2005.
Object-Oriented Modeling
• Object-orientation as a base for modeling
– System as a number of objects that interact.
– Our surroundings consist of objects, such as
people, trees, cars, towns and houses which are
in some way related to each other.
– Often easy to understand and maintain
• Directly related to reality
• I.e., no "semantic gap" or “impendence mismatch”
2
Key Object-Oriented Ideas
•
•
•
•
•
•
•
Identity
Abstraction
Classification
Encapsulation
Inheritance
Polymorphism
Persistence
3
Key Object-Oriented Ideas
• Identity
– Data are organized into discrete entities
called objects.
– Objects have behavior and state.
• Abstraction
• Classification
• Encapsulation
• Inheritance
• Polymorphism
• Persistence
4
Key Object-Oriented Ideas
• Identity
• Abstraction
– OO design uses different abstractions to
capture different parts of the system.
•
•
•
•
•
Classification
Encapsulation
Inheritance
Polymorphism
Persistence
5
Key Object-Oriented Ideas
• Identity
• Abstraction
• Classification
– Objects are grouped together by
commonalities.
– Groups of objects become the basis of
classes.
• Encapsulation
• Inheritance
• Polymorphism
• Persistence
6
Key Object-Oriented Ideas
•
•
•
•
Identity
Abstraction
Classification
Encapsulation
– Classes encapsulate behavior and data.
– Encapsulated aspects of classes hide
details from other classes.
• Inheritance
• Polymorphism
• Persistence
7
Key Object-Oriented Ideas
•
•
•
•
•
Identity
Abstraction
Classification
Encapsulation
Inheritance
– Different OO objects can reuse common
behaviors through inheritance.
• Polymorphism
• Persistence
8
Key Object-Oriented Ideas
•
•
•
•
•
•
Identity
Abstraction
Classification
Encapsulation
Inheritance
Polymorphism
– Objects inherit types from parent classes
as well as behavior
• Persistence
9
Key Object-Oriented Ideas
•
•
•
•
•
•
•
Identity
Abstraction
Classification
Encapsulation
Inheritance
Polymorphism
Persistence
– Objects have lifetime.
– Attributes of an object may change over its
lifetime.
10
Advantages of O-O Approach
• Shifting of development effort into analysis.
– Some development effort is moved to the analysis phase.
• Emphasis on data before function.
• Seamless development process.
– Models developed during analysis are used for design and
implementation. The work is progressively refined rather
than converting from one representation to another.
• Iterative rather than sequential.
– Each iteration adds or clarifies features rather than modifies
work that has already been done.
11
OO Analysis Objective
• To develop precise, concise,
understandable, and correct models of
the problem context.
12
Object Modeling
• Involves systems analysis and design
based on three different views of the
system:
– Object Models
– Dynamic Models
– Functional Models
13
Activities and Products of
OOA
0. State the requirements
1. Build an Object Model
2. Develop a Dynamic Model
3. Construct a Functional Model
4. Verify, iterate, and refine the three
models
14
1. Build an Object Model
• Identify objects and classes
• Identify associations between objects
• Identify attributes of objects and
associations
• Organize and simplify object classes
using inheritance
• Verify that access paths exist for likely
queries
15
2. Develop a Dynamic Model
• Prepare scenarios of typical interaction
sequences
• Identify events between objects and prepare
an event trace
• Build a state machine diagram, sequence
diagram, or communication diagram
• Match events between objects to verify
consistency
16
3. Construct a Functional
Model
• Identify input and output values
• Build use case scenarios
• Build data flow diagrams (DFD) showing
functional dependencies
• Describe functions
• Identify constraints
• Specify optimization criteria
17
Three Orthogonal Models
• Object model (class diagram)
– specifies static structure of objects and their
relationships
– specifies what objects a system contains
• Dynamic model (state machine diagrams)
– specifies aspects of a system that change over
time (when objects change)
• Functional model (data flow diagrams)
– specifies data value transformations in a system
(how objects change)
18
Object Model --- Objects
• An Object is
–
–
–
–
A real world entity
Related to the problem domain
With crisply defined boundaries
Encapsulated along with its attributes and
behaviors
– Whose behavior and attributes must be
understood in order to understand the problem.
19
Examples
• Objects usually correspond to nouns in a "natural"
language.
• Objects may represent physical entities (such as
companies, people, lumber, I/O devices, etc.),
concepts (such as "business process", "data
analysis", etc.), and everything in between.
• Examples of objects include: IBM, Juan Mendoza, a
2’ 2x4, the ZIP drive, the interview protocol, and zerocrossing analysis.
20
Classes
• A class is a "template" describing a set
of objects with
– similar properties (attributes),
– common behavior (operations),
– common relationships to other objects, and
– common semantics.
21
Instances
An instance of a class is an object
• created at runtime
• based on a class (template).
• Sometimes class and object are used to
mean the same thing (by mistake).
• An instance is used to refer to exactly
one thing.
22
Terminology
• Class:
– A category
– A type
– A set
• Instance (of a class)
– Something in the category, is of the type,
or an element of the set
– Object
23
How to Recognize Objects
• Tangible things
– These are the easier to find. They correspond to
physical things: airplane, vehicle, book
• Roles played by persons or organizations
– Example: patient, employee, client, etc.
• Incidents
– Used to represent an occurrence or event:
something which happens at a specific time.
Example: flight, accident, performance, etc.
24
More objects
• Interactions
– A "transaction" or "contract", and relate to two or
more other objects in the model.
– Examples are: Purchase (related to buyer, seller,
and thing purchased). Marriage (related to man
and woman)
• Specifications
– A standard or a definition. For example: a
refrigerator model, the specification of what it
means to be a certain model can be an object.
25
Attributes
Abstraction of a single characteristic possessed
by all the instances of a class.
– May corresponds to an adjective or possessive
phrase in a natural language.
– It is any property, quality, characteristic that can
be assigned to an object.
– E.g., color, size, name, . . .
26
Good Attributes
complete: includes all the information
pertaining an object
 factorized. Each attribute captures one
separated aspect of the objects'
abstraction
 mutually independent. The attributes take
on their values independently of one
another

27
How to Recognize Attributes
• Descriptive attributes.
– Provide facts intrinsic to each instance of an object.
– E.g., length, width
• Naming attributes.
– Provide facts about the arbitrary labels and names
carried by each instance of an object.
– E.g., user-name, part-number
• Referential attributes.
– Capture the facts that tie an instance of one object to
an instance of another object.
– E.g., is-controlled-by, is-driven-by
28
Operations and Methods
• Behavior of objects is realized via
operations.
– A function or transformation that may be applied
• to objects in a class.
• by objects in a class
– All objects in a class share the same operations.
• Method: the implementation of an operation.
• Operations usually correspond to verbs in a
natural language (print, open, transform, mail)
29
Recognizing Operations
• Manipulate data
– add, delete, format, select, access.
• Perform a calculation
– The calculation is performed according to the
value of the attributes of the object student.
• Monitor the object to verify the occurrence of
an event that is controlling the object.
– Think about monitoring an object needs to do to
respond to an external change. Verify the time
continually to activate a process at exactly 12:00
Hrs.
30
In Class
• Pairs (2 minutes): create a class list with
attributes and operations:
A student may take up to five courses in a semester.
Each course may have as many as 30 students in
each section. Each course has one section per
semester. A class room can hold at most one course
at a time.
31
UML Class Diagram --Notation for Classes
Class Name
Class Name
These may be abstract
or at the source code
level
Attributes
Operations
32
Attributes and Operations
Car
speed
wheel
Level of detail varies
with level of
abstraction: start with
high abstraction
33
Attributes and Operations
Car
Car
speed
speed: Integer
wheel
wheel: Wheel[*]
Refine with
Types
34
Attributes and Operations
Car
Car
speed
speed: Integer
wheel
wheel: Wheel[*]
Car
Refine with
Types
Visibility
Defaults
Multiplicities
Properties
+speed: Integer = 0
+wheel: Wheel[0..4] {unique}
35
Attributes and Operations
Types
correspond to the
types from an
implementation
language
Visibility is:
“+” for public,
“-” for private,
# for protected,
~ for package
Default is
attribute=value
Multiplicity is
3, 2..4, 0..*, etc.
Car
Refine with
Types
Visibility
Defaults
Multiplicities
Properties
+speed: Integer = 0
PropertyTuple
string {readOnly}
is {}
+direction:
with one or more of
readOnly, ordered,
unique, etc.
36
Notation for Objects
• Rectangular box with one or two compartments
objectName: Classname
field1 = value1
……
fieldn = valuen
The top compartment shows
the name of the object and its
class.
The bottom compartment
contains a list of the fields and
their values.
p1:Point
p2:Point
x = 10
y = 20
x = 20
y = 30
37
Interfaces and Abstract
Classes
<<interface>>
Runnable
+run(): void
Shape
{abstract}
38
Enumeration Class
• Special kind of class defining a fixed set of
distinct values
Account
type: AccountType
<<enumeration>>
AccountType
checking
saving
39
Class Relationships
• Class relationships of different types and
strengths
Association
Aggregation
Composition
Generalization
Realization
Dependency
40
Q: Strength of Relationship?
Stronger
Weaker
Association
Aggregation
Composition
Generalization
Realization
Dependency
41
Association
• General binary relationships between classes
• Commonly represented as direct or indirect
references between classes
Student
Course
42
Association (Cont.)
• May have an optional label consisting of a name
and a direction drawn as a solid arrowhead with
no tail.
• The direction arrow indicates the direction of
association with respect to the name.
Student
enroll
Course
43
Association (Cont.)
• An arrow may be attached to the end
of path to indicate that navigation is
supported in that direction
• If omitted?
Student
enroll
Course
44
Association (Cont.)
• May have an optional role name and an optional
multiplicity specification.
• The multiplicity specifies an integer interval, e.g.,
– l..u closed (inclusive) range of integers
– i
singleton range
– 0..* entire nonnegative integer, i.e., 0, 1, 2, …
Student
0..*
advisee
1
advisor
Faculty
45
Example
Student
6..*
has enrolled 1
Course
1..*
advisee 0..*
teach
1
1
advisor
Faculty
46
Aggregation
• Special form of association representing has-a or
part-whole relationship.
• Distinguishes the whole (aggregate class) from its
parts (component class).
• No relationship in the lifetime of the aggregate
and the components (can exist separately).
Aggregate
Component
47
Composition
• Stronger form of aggregation
• Implies exclusive ownership of the component
class by the aggregate class
• The lifetime of the components is entirely included
in the lifetime of the aggregate (a component can
not exist without its aggregate).
Composition
Component
48
Example
University
1
1..*
College
1
1..*
Department
1
1
0..*
Student
1
member-of
chair-of
1
1..*
Faculty
49
Dependency
• Relationship between the entities such that the
proper operation of one entity depends on the
presence of the other entity, and changes in one
entity would affect the other entity.
• The common form of dependency is the use
relation among classes.
Class1
<<use>>
Class2
50
Complex Associations
• Associations may be: binary, ternary, or higher
order.
• Binary associations involve two classes. This is
the most common.
• Higher order associations are more complicated
to draw, implement, and think about than binary
associations. Ternary associations involve 3
objects:
– It is an atomic unit
– The division of a ternary association into binary
associations may loose information
– The associations are represented by a diamond
51
Example
Class diagram
Project
Language
Programmer
Instance diagram
p1: Project
C: Language
Joe: Programmer
p2: Project
Java: Language
52
Notation: Association Class
0..2
Person
0..*
Company
employer
Employment
period: DateRange
Association
class
Employment keeps information about the association that is not part of
either object. Person could have two jobs. Employment is a 1-person/1company relation.
53
Alternate Diagram
0..2
Person
0..*
Company
Employer
1
1
0..2
Employment
period: DateRange
0..*
54
Recursive Associations
0..*
node1
Node
node2
node3
0..*
node4
node5
node6
node7
node8
55
In Class: Draw the Class
Diagram
There are four classes: Program, Block,
CompoundStatement, and SimpleStatement
<program> ::= program <name> : <block> .
<block> ::= <statement>*
<statement> ::= <simple statement> | <compound>
<compound> ::= <block>
56
Generalization and
Specialization
Customer
Corporate
Customer
Every attribute of
Customer is also an
attribute of its
subclasses.
Private
Customer
57
In Class: Draw the Diagram
• A figure is either a group or a polygon.
• A group contains any number of figures.
58