OBJECT-ORIENTED ANALYSIS AND

MODELING USING THE UML

Introduction to Object Modeling

Object-oriented analysis (OOA) – an approach used to

1. study existing objects to see if they can be reused or
adapted for new uses
2. define new or modified objects that will be combined with
existing objects into a useful business computing
application

Object modeling – a technique for identifying objects

within the systems environment and the relationships
between those objects.
Introduction to the UML

Unified Modeling Language (UML) – a set of

modeling conventions that is used to specify or
describe a software system in terms of objects.
– The UML does not prescribe a method for
developing systems—only a notation that is now
widely accepted as a standard for object modeling.
Objects, Attributes, & Instances

Object – something that is or is capable of being seen,

touched, or otherwise sensed, and about which users
store data and associate behavior.
– Person, place, thing, or event
– Employee, customer, instructor, student
– Warehouse, office, building, room
– Product, vehicle, computer, videotape

Attribute – the data that represent characteristics of

interest about an object.
Object instance – each specific person, place, thing, or
event, as well as the values for the attributes of that
object.
Objects, Attributes, & Instances (cont.)
Behavior & Encapsulation

Behavior – the set of things that the object can do that

correspond to functions that act on the object’s data (or
attributes).
– In object-oriented circles, an object’s behavior is
commonly referred to as a method, operation, or
service.

Encapsulation – the packaging of several items

together into one unit.
Object Classes

Class – a set of objects that share common attributes and

behavior. Sometimes referred to as an object class.
Inheritance

Inheritance – the concept wherein methods and/or

attributes defined in an object class can be inherited or
reused by another object class.
Inheritance (cont.)
Generalization/Specialization, Supertype, and Subtype

Generalization/specialization – a technique wherein the

attributes and behaviors that are common to several types of object
classes are grouped (or abstracted) into their own class, called a
supertype. The attributes and methods of the supertype object
class are then inherited by those object classes.
Supertype – an entity that contains attributes and behaviors that
are common to one or more class subtypes.
– Also referred to as abstract or parent class.

Subtype – an object class that inherits attributes and behaviors

from a supertype class and then may contain other attributes and
behaviors that are unique to it.
– Also referred to as a child class and, if it exists at the lowest level
of the inheritance hierarchy, as concrete class.
UML Representation of Generalization/Specialization
Object/Class Relationships

Object/class relationship – a natural business

association that exists between one or more objects and
classes.
Multiplicity and UML Multiplicity Notations

Multiplicity – the
minimum and
maximum number
of occurrences of
one object/class
for a single
occurrence of the
related
object/class.
Aggregation

Aggregation – a relationship in which one larger “whole” class

contains one or more smaller “parts” classes. Conversely, a smaller
“part” class is part of a “whole” larger class.
Composition

Composition – an
aggregation
relationship in
which the “whole”
is responsible for
the creation and
destruction of its
“parts.” If the
“whole” were to
die, the “part”
would die with it.
Messages

Message – communication that occurs when one object

invokes another object’s method (behavior) to request
information or some action
Polymorphism
Polymorphism –
literally meaning “many
forms,” the concept that
different objects can
respond to the same
message in different
ways.

Override – a technique
whereby a subclass
(subtype) uses an
attribute or behavior of
its own instead of an
attribute or behavior
inherited from the class
(supertype).
UML Diagrams
• Use-Case Model Diagrams
• Static Structure Diagrams
– Class diagrams
– Object diagrams
• Interaction Diagrams
– Sequence diagrams
– Collaboration diagrams
• State Diagrams
– Statechart diagrams
– Activity diagrams
• Implementation Diagrams
– Component diagrams
– Deployment diagrams
The Process of Object Modeling

1. Modeling the functions of the system.

2. Finding and identifying the business objects.
3. Organizing the objects and identifying their
relationships.
Modeling the Functions of the System

The following steps evolve the requirements use-case

model into an analysis use-case model:
1. Identify, define, and document new actors.
2. Identify, define, and document new use cases.
3. Identify any reuse possibilities.
4. Refine the use-case model diagram (if necessary).
5. Document system analysis use-case narratives.

System analysis use case – a use case that

documents the interaction between the system user
and the system. It is highly detailed in describing what
is required but is free of most implementation details
and constraints.
 Use Case Diagrams

• To describe what a system does from the

standpoint of an external observer.

• A use case is a summary of scenarios for a single

task or goal. An actor is who or what initiates the
events involved in that task. Actors are simply
roles that people or objects play.

• To successfully apply use case diagrams, we must

first understand the types of elements used in use
case diagrams.
 A use case diagram

is a collection of actors, use cases, and their

communications.

•Use case diagrams are helpful in three areas.

•determining features (requirements). New use cases

often generate new requirements as the system is analyzed
and the design takes shape.
•communicating with clients. Their notational simplicity
makes use case diagrams a good way for developers to
communicate with clients.
•generating test cases. The collection of scenarios for a
use case may suggest a suite of test cases for those
scenarios.
• A number of scenarios are usually collected into a Use
Case and expressed graphically by a Use Case Diagram.
The elements of a Use Case often include:
• Name of the use case
• Summary
• Actors involved
• Basic sequence of steps
• Alternate sequence
• Exceptions that can occur
• Extension points
• Trigger
• Assumptions
• Preconditions
• Postconditions
• Author and Date
 Actors
• Actor classes are used to model and represent roles for
"users" of a system, including human users and other
systems. Actors are denoted as stick person icons. They
have the following characteristics:
• Actors are external to a system.
• Actors interact with the system. Actors may use the
functionality provide by the system, including
application functionality and maintenance functionality.
Actors may provide functionality to the system. Actors
may receive information provided by the system.
Actors may provide information to the system.
• Actor classes have actors instances or objects that
represent specific actors.
 USE CASE DIAGRAM

The picture below is a Make Appointment use

case for the medical clinic.
The actor is a Patient.
The connection between actor and use case is a
communication association
 USE CASE EXERCISE

ระบบการสั่งซื้อของทางโทรศัพท์ ต้องประกอบด้วย
สิ่งที่มาเกี่ยวข้อง (Actor) และหน้าที่ หรือเหตุการณ์
(Use Case) ที่จะเกิดขึ้นของแต่ละ Actor ดังนี้

ลูกค้าโทรศัพท์ไปหาเซลล์ เพื่อตรวจสอบว่ามีสินค้า
หรือไม่ ถ้ามีสินค้าก็จะทำการสั่งซื้อ ฝ่ ายจัดส่งสินค้าก็
จะกรอกแบบฟอร์มรายละเอียดของลูกค้าเพื่อจัดส่ง
ลูกค้าก็จะทำการจ่ายเงินด้วยเครคิตกับผู้จัดการ

จากข้อมูลข้างต้นจงเขียน USE CASE ของระบบการ

สั่งซื้อของทางโทรศัพท์
 USE CASE EXERCISE

ระบบการสอบของมหาวิทยาลัยแห่งหนึ่งเป็ นดังนี้

อาจารย์ผู้สอนเป็ นผู้เตรียม และตรวจสอบความถูกต้องของข้อสอบ

โดยมีผู้ช่วยอาจารย์ตรวจทานข้อสอบอีกครั้ง รวมทั้งเป็ นคนตรวจ
ข้อสอบและให้คะแนน ส่วนนักศึกษาก็มีหน้าที่สอบอย่างเดียว
เท่านั้น

จากข้อมูลข้างต้นจงเขียน USE CASE ของระบบการสอบ

ของมหาวิทยาลัยแห่งนี้
• a project manager may publish a project schedule by
sending e-mail to project team members using an e-
mail system or by generating a web-site on a web-site
host.

• In either case, there will be common functionality

used from the generalized use case, for example:
inputting project name, extracting the relevant project
information form the project database, etc.
A project management system with a project manager actor and a project
database actor.

The project manager is a user who is responsible for ensuring the success of
project and uses the system to manage projects.

The project database is a system that is responsible for housing project

management data.
There are two types project mangers, full-time and part-time, and that there are two
types of project database, relational database management systems (R-DBMS) and
object oriented database management systems (OO-DBMS).
Any type of project manager may publish a project schedule using any type of project
database.
Revised System Use-Case Model Diagram
Use-Case Narrative
Use-Case Narrative (cont.)
Abstract Use-Case Narrative
 Sequence Diagrams
- Illustrate the objects that participate in a
use case and the messages that pass
between them over time for one use case.

- A dynamic model showing the explicit

sequence of messages that are passed
between objects.

- Emphasise the time-based ordering.

56
Sequence Diagram
 Elements of a Sequence
Diagram
• Actor
• Object
• Lifeline
• Focus on control
• Message
• Object destruction

58
 Actor
- A person or system that derives benefit
from and is external to the system.
- Participates in a sequence by sending
and/or receiving messages.
- Is placed across the top of the diagram.

anActor
59
 Object
- Participates in a sequence by sending
and/or receiving messages.
- Is placed across the top of the diagram.
- The name of the class that they are an
instance of is given after the object’s
name.

60
 Lifeline
- Denotes the life of an object during a
sequence.
- Runs vertically below each actor and
object.
- Contains an “X” at the point at which the
class no longer interacts.

61
 anObject:aClass

anActor

62
 Focus of Control
- Is a long, narrow rectangle placed
atop a lifeline.
- Denotes when an object is sending
or receiving messages.

63
 Message
- Conveys information from one object to
another one.
- If there is a condition to be met, the
condition is placed between a set of [ ] in
front of the message name.
- If a message is repeated, an * is placed
in front of the message name.

64
aMessage()

[condition] aMessage()

* aMessage()

65
 Object Destruction
- An “X” is placed at the end of an object’s
lifeline to show that it is going out of
existence.

66
Sometimes an object will create
another object.

This is shown by the message

being sent directly to an object
instead of its lifeline.

67
The actor aReceptionist creates an
object anAppt.

aReceptionist
CreateAppt()
anAppt:Appointment

68
http://bdn.borland.com/article/0,1410,31863,00.htm
 Building a Sequence Diagram
1. Determine the context.
The context of the diagram can be a
system, a use case, a scenario of a use
case, or an operation of a class. Most
commonly, it is one use-case scenario.

75
2. Identify which objects will participate.
The objects are identified during the
development of the structural model.
These are the classes on which the
objects of the sequence diagram for this
scenario will be based.

3. Set the lifeline for each object.

76
4. Lay out the messages from the top to the
bottom of the diagram based on the
order in which they are sent.

5. Add the focus of control to each object’s

lifeline.

6. Validate the sequence diagram.

77
 Ecat:Catalog :LibraryItem Lib1:NetServer

:LibraryUser
Lookup()

Display()

Issue()

IssueLicence()

AcceptLicence()
Compress()

Deliver()

78
จาก USE CASE การออกสอบข้างต้น จงแสดงลำดับการส่งข้อมูลกันอย่างไร

An instructor first notifies the students of the exam date and the
material to be covered.

An instructor then prepares the exam paper (with sample

solutions), gets it copied to produce enough copies for the class,
and hands it out to students on the designated time and
location.

The students write their answers to exam questions and hand in

their papers to the instructor.

The instructor then gives the exam papers to the TAs, along
with sample solutions to each question, and gets them to mark
it. She then records all marks and returns the papers to the
students.

Draw a sequence diagram that represents this process. Make

sure to show when is each actor participating in the process.
Also, show the operation that is carried out during each
interaction, and what its arguments are.
Use Case 1: Sales Clerk checks out an item
1. Customer sets item on counter.
2. Sales clerk swipes UPC reader across UPC code on
item
3. System looks up UPC code in database procuring
item description and price
4. System emits audible beep.
5. System announces item description and price over
voice output.
6. System adds price and item type to current invoice.
7. System adds price to correct tax subtotal
• To buy a book electronically from chapters.com, a
customer needs to select the book from a list
provided by Chapters’ eCommerce system,
provide credit card information to the system,
then the system gets authorization from the bank
for the payment, and -- if positive -- confirms the
sale. The order is then sent to the orders
department and when the book becomes
available, it is shipped to the customer. Also, the
order department charges the customer’s credit
card by informing the bank of the amount.

• Draw a sequence diagram that models this

process. Make sure to model all relevant actors
and the interactions between them. Do show
explicitly the time intervals when different actors
actively participate in the process you are
modeling
 Sequence Diagram Exercise
ระบบ Key card
การใช้ Key card ของพนักงาน เพื่อเข้าไปในสถานที่ทำงาน เริ่มจาก
พนักงานต้องใส่บัตรไปที่ช่องหน้าประตู ที่เรียกว่า Assess point
จากนั้นก็ต้องใส่รหัส เมื่อพนักงานใส่รหัสเรียบร้อยแล้ว ก็ต้องมีการตรวจ
สอบความถูกต้องของข้อมูล ระบบก็จะส่งมาเพื่อให้เปิ ดประตูได้ โดยตั้ง
เวลาไว้ 10 วินที จากนั้นประตูก็จะเปิ ดให้เข้าได้ภายใน 30 วินาที แล้ว
คำสั่งก็จะถูกส่งไปที่ประตูเพื่อปิ ด และล็อกเหมือนเดิม
88
 Collaboration Diagrams
- Provide a view of the dynamic aspects of
an object-oriented system.
- An object diagram that shows message
passing relationship.

89
- Equivalent to sequence diagrams:

Sequence diagrams: the time

ordering of the messages being passed.

Collaboration diagrams: the flow of

messages through a set of objects; no
explicit time dimension.

90
 Elements of a Collaboration
Diagram
• Actor
• Object
• Association
• Message

91
 Actor
- A person or system that derives benefit
from and is external to the system.
- Participates in a sequence by sending
and/or receiving messages.

anActor
92
 Object
- Participates in a sequence by sending
and/or receiving messages.

anObject:aClass

93
 Association
- Shows an association between actors
and/or objects.
- Messages are sent over associations.

94
 Message
- Conveys information from one object to
another.
- Direction is shown using an arrowhead.
- Sequence is shown by a sequence
number.
- If there is a condition to be met, the
condition is placed between a set of [ ] in
front of the message name.
95
- If a message is repeated, an * is placed
in front of the message name.

1:aMessage()

96
 Building a Collaboration
Diagram
1. Set the context.
2. Identify which objects and associations
between the objects will participate in the
collaboration.
3. Lay out the collaboration diagram.
4. Add messages.
5. Validate the collaboration diagram.

97
 Ecat:Catalog :LibraryItem Lib1:NetServer

:LibraryUser
Lookup()

Display()

Issue() เปลี่ยน sequence diagram

IssueLicence()
เป็ น collaboration diagram
AcceptLicence()
Compress()
1:Lookup()
Deliver() 2:Display()
Ecat:Catalog

sequence diagram LibraryUser 4 3

5: :Iss :Is
A c u su
c e eL i e(
pt ce )
Lic ns

7:Deliver()
en e(
se )
()

Lib1:NetServer :LibraryItem
6:Compress()
98

collaboration diagram
Class diagrams
Class diagram gives an overview of a system by showing its
classes and the relationships among them. Class diagrams are
static -- they display what interacts but not what happens
when they do interact.
Attribute specification
The class diagram below models a customer order from a
retail catalog. The central class is the Order. Associated
with it are the Customer making the purchase and the
Payment. A Payment is one of three kinds: Cash,
Check, or Credit. The order contains OrderDetails (line
items), each with its associated Item.
Sr. Relation Symbol Description
No.
1 Association When two classes are connected to each
other in any way, an association relation
is established. For example: A "student
studies in a college" association can be
shown as:

1 a. Multiplicity An example of this kind of association is

many students belonging to the same
college. Hence, the relation shows a star
sign near the student class (one to
many, many to many, and so forth kind
of relations).

1 b. Directed Association between classes is bi-

Association directional by default. You can define the
flow of the association by using a
directed association. The arrowhead
identifies the container-contained
relationship.
Sr. Relation Symbol Description
No.
1 c. Reflexive No separate An example of this kind of
Association symbol. relation is when a class has a
However, the variety of responsibilities. For
relation will example, an employee of a
point back at college can be a professor, a
the same housekeeper, or an administrative
class. assistant.
2 Aggregation When a class is formed as a
collection of other classes, it is
called an aggregation relationship
between these classes. It is also
called a "has a" relationship.
2 a. Composition Composition is a variation of the
aggregation relationship.
Composition connotes that a
strong life cycle is associated
between the classes.
Sr. Relation Symbol Description
No.
3 Inheritance/ Also called an "is a" relationship,
Generalizatio because the child class is a type of
n the parent class. Generalization is
the basic type of relationship used
to define reusable elements in the
class diagram. Literally, the child
classes "inherit" the common
functionality defined in the parent
class.
4 Realization In a realization relationship, one
entity (normally an interface)
defines a set of functionalities as a
contract and the other entity
(normally a class) "realizes" the
contract by implementing the
functionality defined in the contract.
Bank Accounts Management System
This system provides the basic services to manage bank accounts at
a bank called OOBank. OOBank has many branches, each of which
has an address and branch number. A client opens accounts at a
branch. Each account is uniquely identified by an account number;
it has a balance and a credit or overdraft limit. There are many
types of accounts, including: A mortgage account (which has a
property as collateral), a chequing account, and a credit card
account (which has an expiry date and can have secondary cards
attached to it). It is possible to have a joint account (e.g. for a
husband and wife). Each type of account has a particular interest
rate, a monthly fee and a specific set of privileges (e.g. ability to
write cheques, insurance for purchases etc. OOBank is divided into
divisions and subdivisions (such as Planning, Investments and
Consumer), the branches are considered subdivisions of the
Consumer Division. Each division has a manager and a set of other
employees. Each customer is assigned a particular employee as his
or her ‘personal banker’.
Marking nouns: potentially good classes, definitely bad
classes, and classes we are unsure about

•This system provides the basic services to manage bank accounts at a bank
called OOBank. OOBank has many branches, each of which has an address
and branch number. A client opens accounts at a branch. Each account is
uniquely identified by an account number; it has a balance and a credit or
overdraft limit. There are many types of accounts, including: A mortgage
account (which has a property as collateral), a chequing account, and a
credit card account (which has an expiry date and can have secondary
cards attached to it). It is possible to have a joint account (e.g. for a husband
and wife). Each type of account has a particular interest rate, a monthly fee
and a specific set of privileges (e.g. ability to write cheques, insurance for
purchases etc. OOBank is divided into divisions and subdivisions (such as
Planning, Investments and Consumer), the branches are considered
subdivisions of the Consumer Division. Each division has a manager and a
set of other employees. Each customer is assigned a particular employee as
his or her ‘personal banker’.
Draft Class Diagram with clsses Client and
Account, and their association
Client
1..2
accountHolder

*
Account
accountNumber
type
Draft Class Diagram with Account attributes and
subclasses
Client
* 1..2
accountHolder

*
Account
accountNumber
openedDate
closedDate
interestRate
monthlyFee
balance
creditOrOverdraftLimit

ChequingAccount MortgageAccount CreditCardAccount

Draft Class Diagram with CreditCard and attributes of Account
subclasses
Client
* 1..2
accountHolder

*
Account
accountNumber
openedDate
closedDate
interestRate
monthlyFee
balance CreditCard
creditOrOverdraftLimit
name
1..*

ChequingAccount MortgageAccount CreditCardAccount

collateralProperty expiryDate
brand
Draft Class Diagram with Branch and Employee
Employee Client
* 1..2
personalBanker accountHolder

Branch
* *
Account
accountNumber
openedDate
closedDate
interestRate
monthlyFee
balance CreditCard
creditOrOverdraftLimit
name
1..*

ChequingAccount MortgageAccount CreditCardAccount

collateralProperty expiryDate
brand
Draft Class Diagram with OrganizationalUnit
worksFor

subdivision
*
OrganizationalUnit 0..1
manager
0..1 *
0..1
Employee Client
* 1..2
personalBanker accountHolder

Branch
* *
Account
accountNumber
openedDate
closedDate
interestRate
monthlyFee
balance CreditCard
creditOrOverdraftLimit
name
1..*

ChequingAccount MortgageAccount CreditCardAccount

collateralProperty expiryDate
brand
Draft Class Diagram with AccountType
worksFor

subdivision
*
OrganizationalUnit 0..1
manager
0..1 *
0..1
AccountType Employee Client
* 1..2
interestRate personalBanker
monthlyFee accountHolder
checksAllowed
insuranceAvailable

Branch *
* *
Account
accountNumber
openedDate
closedDate
interestRate
monthlyFee
balance CreditCard
creditOrOverdraftLimit
name
1..*

ChequingAccount MortgageAccount CreditCardAccount

collateralProperty expiryDate
brand
Bank Account System Class diagram with final touches
worksFor

Person
subdivision name
*
OrganizationalUnit 0..1
manager
0..1 *
0..1
AccountType Employee Client
* 1..2
interestRate personalBanker
monthlyFee accountHolder
checksAllowed
insuranceAvailable
periodicFee
period

Branch *
* *
address Account
number accountNumber
openedDate
closedDate
interestRate
monthlyFee
balance CreditCard
creditOrOverdraftLimit
name
1..*

ChequingAccount MortgageAccount CreditCardAccount

collateralProperty expiryDate
brand
 Shifting from ERD to UML
It is not difficult to shift from basic ERD to UML terminology as shown
below

ERD Term UML Term

entity class
instance of an entity object
relationship association
supertype/subtype generalization
relationship dependency composition (usually, but
(UID bar) not always)
attributes attributes
Organizing the Objects and Identifying their Relationships

1. Identifying Associations and Multiplicity

2. Identifying Generalization/Specialization
Relationships
3. Identifying Aggregation Relationships
4. Prepare the Class Diagram

Class diagram – a graphical depiction of a system’s

static object structure, showing object classes that the
system is composed of as well as the relationships
between those object classes.
Generalization/Specialization Hierarchies
Class Diagram

Refer to Figure 11-20

in text for a more
readable copy
CLASS diagram to JAVA code