1

Object-Oriented Modeling
Using UML
2
Object-Oriented Modeling
Uses object-orientation as a basis of modeling
Models a system as a set of objects that interact with
each others
No semantic gap (or impedance mismatch)
Seamless development process
Data-oriented
Conceptual/computational world
Real world
Abstraction
Interpretation
Object-oriented
3
Key Ideas of O-O Modeling
Abstraction
Encapsulation
Relationship
Association: relationship between objects
Inheritance: mechanism to represent similarity among
objects
Object-oriented
= object (class) + inheritance + message send
4
Objects vs. Classes
Interpretation in the
Real World
Representation in the
Model
Object
An object represents
anything in the real world
that can be distinctly
identified.
An object has an identity,
a state, and a behavior.
Class
A class represents a set
of objects with similar
characteristics and
behavior. These objects
are called instances of
the class.
A class characterizes the
structure of states and
behaviors that are shared
by all of its instances.
5
Object = Identity + State + Behavior
Identity
Distinguishes an object from all other objects.
State
Consists of a set of attributes (or fields), which have
names, types, and values.
Behavior
Defined by the set of operations (or methods) that may
operate on the object.
Each method has a name, a type, and a value, where
The type consists of the return type and the list of parameter
types of the method, often called signature.
The value is the implementation of the method often
expressed as a sequence of statements, in languages like
Java and C++.
6
Class
Characterizes the structure of states and
the behaviors shared by all instances.
Defines a template for creating or
instantiating instances.
Names and types of all fields
Names, signatures, and implementations of
all methods.
7
Unified Modeling Language (UML)
Notation for object-oriented modeling
Standardized by Object Management Group
(OMG)
Consists of 12+ different diagrams
Use case diagram
Class diagram
Statechart diagram
Sequence diagram
Collaboration diagram
Component diagram

8
Static vs. Dynamic Models
Static model
Describes static structure of a system
Consists of a set of objects (classes) and their
relationships
Represented as class diagrams
Dynamic model
Describes dynamic behavior of a system, such as
state transitions and interactions (message sends)
Represented as statechart diagram, sequence
diagrams, and collaboration diagrams
Use Case Diagram

Use case diagrams are created to visualize
the relationships between actors and use
cases
An actor is someone or some thing that must
interact with the system under development
A use case is a pattern of behavior the system
exhibits
Use cases are written from an actor point of view
Details what the system must provide to the actor
when the use cases is executed

9
10
Class Diagrams

A class diagram describes the types of objects in the system
and the various kinds of static relationships that exist among
them.
A graphical representation of a static view on declarative static
elements.
A central modeling technique that runs through nearly all object-
oriented methods.
The richest notation in UML.
A class diagram shows the existence of classes and their
relationships in the logical view of a system

11
Essential Elements of a UML Class
Diagram
Class
Attributes
Operations
Relationships
Associations
Generalization
Dependency
Realization

12
Constraint Rules and Notes
Constraint Rules and Notes A class is the description
of a set of objects having similar attributes, operations,
relationships and behavior
13
Attributes

Classes have attributes that describe the characteristics of their
objects.
Attributes are atomic entities with no responsibilities.
Attribute syntax (partial):
[visibility] name [ : type ] [ = defaultValue ]
Class scope attributes are underlined

14
15
UML Class Diagram
Most common diagram in OO modeling
Describes the static structure of a system
Consist of:
Nodes representing classes
Links representing of relationships among
classes
Inheritance
Association, including aggregation and
composition
Dependency
16
Notation for Classes
The UML notation for classes is a rectangular
box with as many as three compartments.
ClassName
field
1

field
n

method
1

method
n

The top compartment show the class name.

The middle compartment contains the
declarations of the fields, or attributes, of
the class.

The bottom compartment contains the
declarations of the methods of the class.
17
Example
Point
- x: int
- y: int
+ move(dx: int, dy: int): void

Point
x
y
move

Point
18
Field and Method Declarations in UML
Field declarations
birthday: Date
+duration: int = 100
-students[1..MAX_SIZE]: Student
Method declarations
+move(dx: int, dy: int): void
+getSize(): int
Visibility Notation
public +
protected #
package ~
private -
19
Exercise
Draw a UML class diagram for the following
Java code.
class Person {
private String name;
private Date birthday;
public String getName() {
//
}
public Date getBirthday() {
//
}
}
20
Notation for Objects
Rectangular box with one or two compartments
objectName: Classname
field
1
= value
1

field
n
= value
n
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
x = 10
y = 20
p2:Point
x = 20
y = 30
21
UML Notation for Interfaces

interface Drawable {
void draw(Graphics g);
}
+ draw(g: Graphics): void

Drawable
+ draw(g: Graphics): void

<<interface>>
Drawable
22
Inheritance in Java
Important relationship in OO modeling
Defines a relationship among classes and
interfaces.
Three kinds of inheritances
extension relation between two classes (subclasses
and superclasses)
extension relation between two interfaces
(subinterfaces and superinterfaces)
implementation relation between a class and an
interface
UML modeling elements in class diagrams

Classes and their structure, association,
aggregation, dependency, and
inheritance relationships
Multiplicity and navigation indicators, etc.

23
24
Inheritance in UML
An extension relation is called specialization and
generalization.
An implementation relation is called realization.
Superclass
Subclass
Superinterface
Subinterface
Interface
Class
extension of
classes
implementation
of interfaces
extension of
interfaces
25
Inheritance in UML (Cont.)
Interpretation
Models the is-a relationship
Extension relation between classes: reusing or sharing
of implementation (code)
Extension relation between interfaces: expansion of
service contracts.
Implementation relation: implementation of contractual
interfaces by classes
26
Example
Student
{abstract}
Undergraduate
Graduate
{abstract}
Nondegree
Master PhD
27
Exercise
Draw a UML class diagram showing
possible inheritance relationships among
classes Person, Employee, and Manager.
Associations
A semantic relationship between two or more classes that specifies
connections among their instances.
A structural relationship, specifying that objects of one class are
connected to objects of a second (possibly the same) class.
Example: An Employee works for a Company
An association between two classes indicates that objects at one
end of an association recognize objects at the other end and
may send messages to them.
This property will help us discover less trivial associations using
interaction diagrams

28
29
Association
General binary relationships between classes
Commonly represented as direct or indirect
references between classes
Student Course
30
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
Course
enroll
31
Association (Cont.)
An arrow may be attached to the end of path to
indicate that navigation is supported in that
direction
What if omitted?
Student
Course
enroll
32
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 Faculty
advisee advisor
1
0..*
33
Example
Student Course
enroll
advisee
advisor
Faculty
teach
1..*
6..*
0..*
1
1
0..*
34
Exercise
Identify possible relationships among the
following classes and draw a class
diagram
Employee
Manager
Department
35
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
36
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
37
Example
Department
member-of
Faculty
College
chair-of
Student
1
1
1
1
1 1
1..*
0..*
1..*
1..*
University
38
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 Class2
<<use>>
Realization
A realization relationship indicates that one class implements a
behavior specified by another class (an interface or protocol). An
interface can be realized by many classes. A class may realize
many interfaces
39
40
Example
Registrar
+ addCourse(s: CourseSchedue, c: Course): void
+ removeCourse(s: CourseSchedue, c: Course): void
+ findCourse(title: String): Course
+ enroll(c: Course, s: Student): void
+ drop(c: Course, s: Student): void
CourseSchedule
Course
Student
Dependencies are most often omitted from the diagram unless they
convey some significant information.
41
Group Exercise: E-book Store
Develop an OO model for an e-bookstore. The core requirements of the e-
bookstore are to allow its customers to browse and order books, music CDs,
and computer software through the Internet. The main functionalities of the
system are to provide information about the titles it carries to help customers
make purchasing decisions; handle customer registration, order processing,
and shipping; and support management of the system, such as adding,
deleting, and updating titles and customer information.

1. Identify classes. Classes can represent physical objects, people, organizations
places, events, or concepts. Class names should be noun phrases.
2. Identify relevant fields and methods of the classes. Actions are modeled as
the methods of classes. Method names should be verb phrases.
3. Identify any inheritance relationships among the classes and draw the class
diagram representing inheritance relationships.
4. Identify any association relationships among the classes and draw the class
diagram representing association relationships.
5. Identify any aggregation and composition relationships among the classes and
draw the class diagram representing dependency relationships.
Packages
A package is a general purpose grouping mechanism. Can be used
to group any UML element (e.g. use case, actors, classes,
components and other packages. Commonly used for specifying
the logical distribution of classes. A package does not necessarily
translate into a physical sub-system.
42


Packages and Class Diagrams


Emphasize the logical structure of the system (High level view)
Emphasize the interface between packages by showing relations
and dependencies between public classes,Add package
information to class diagrams
43
Interaction Diagrams
Interaction diagrams describe how groups of objects collaborate to get the
job done. Interaction diagrams capture the behavior of a single use case,
showing the pattern of interaction among objects
The purpose of Interaction diagrams is to:
Model interactions between objects
Assist in understanding how a system (a use case) actually works
Verify that a use case description can be supported by the existing
classes
Identify responsibilities/operations and assign them to classes
Interaction diagrams:
Sequence diagrams Collaboration diagrams
44
Collaboration Diagrams
UML provides two sorts of interaction diagram,
sequence and collaboration diagrams.
Collectively, the objects which interact to perform some task, together with
the links between them, are known as a collaboration
Objects
Each object is shown as rectangle, which is labelled objectName: className
Links
Links between objects are shown like associations in the class model.
Actors
Actors can be shown as on a use case diagram
A collaboration diagram represents a set of objects related in a particular
context, and the exchange of their messages to achieve a desired outcome.
Used for design of: components, object, subsystems
Diagrams show entity event responses
Event receiving a message

45
46
State Diagram
A statechart diagram (also called a state diagram) shows the sequence of
states that an object goes through during its life in response to outside
stimuli and messages. A statechart diagram is a view of a state machine
that models the changing behavior of a state. Statechart diagrams show
the various states that an object goes through, as well as the events that
cause a transition from one state to another. State chart diagram model
elements The common model elements that state chart diagrams contain
are:
States
Start and end states
Transitions
Entry, do, and exit actions
A state represents a condition during the life of an object during which it
satisfies some condition or waits for some event. Start and end states
represent the beginning or ending of a process. A state transition is a
relationship between two states that indicates when an object can move
the focus of control on to another state once certain conditions are met.
47
Actions in a Statechart diagram

Each state on a state chart diagram can contain multiple internal
actions.
An action is best described as a task that takes place within a state.
There are four possible actions within a state:
On entry
On exit
Do
On event

48
Activity Diagram
Activity Diagram a special kind of Statechart diagram, but showing the
flow from activity to activity (not from state to state).
Activity an ongoing non-atomic execution within a state machine.
Activities ultimately result in some action.
A real world process or execution of a software routine
Action made up of executable atomic computations that results in a
change in state of the system or the return of a value (i.e., calling another
operation, sending a signal, creating or destroying an object, or some
pure computation).
Activity diagrams commonly contain:
Activity states and action states , Transitions, Objects
Action states - executable, atomic computations (states of the system, each
representing the execution of an action) cannot be decomposed. Activity
states non-atomic; can be further decomposed; can be represented by
other activity diagrams a composite whose flow of control is made up of
other activity states and action states
49
50
Deployment Diagram
Shows the configuration of run-time
processing elements and the software
processes living on them. The
deployment diagram visualizes the
distribution of components across the
enterprise
51
Deployment Diagram
52

53