What is Object-Oriented?
? Object orientation is an approach to
software development that organizes both
the problem and its solution as a collection
of discrete objects;
? It is a kind of representation that describe
object’s data structure and behavior.
? It is a kind of modeling technology.
Characteristics of OO Representation
? Identity—name,reference,handle
? Abstraction
? Classification
? Encapsulation
? Inheritance
? Polymorphism
? Persistence
The OO Development Process
? Be consistency of terminology and of
–The problem and the solution were described in
same terms, classes,objects methods,attributes,and
behaviors,
? Be consistency of perspective
–Static views
–Dynamic views
–Restrictions
Tendency for Change when Using OO Paradigm
(Jacobson et al,1995)
Characteristic of software product/project Probability for change
Objects derived from the application Low
Long-lived information structures Low
Passive object’s attribute Medium
Sequences of behavior Medium
Interface with the outside world High
Functionality High
OO Requirements
? OO requirements analysis is usually done in the user’s
language.
? OO requirements analysis discusses the concepts and
scenarios likely in application domain.
– The concepts include information,service,and
responsibilities.
– Domain knowledge enables both developers and users to
understand the problems.
? The requirements definition can be independent of
implement.
OO Design
? Requirement specification,the first steps of design.
? To represent a system design
– First,to identify and represent classes and objects.
– Second,to identify the interactions and relationships
among objects and classes.
? Associations
? Compositions
? Aggregations
? Inheritance
? To provide the details in program design.
– Insert computational features in the models
– Insert some class library details
– Consider nonfunctional requirements
Use Cases (用例）
? Describe particular functionality to exhibit how
a user,external system,and other entity dialog
with the system.
? Scenario 场景
? Script 脚本
Use case diagrams（用例图）
? Actor（角色）
– A entity interacting with the system
– Or a role that an entity plays with respect of the system
? User
? Device
? Another system
? Cases（用例）
– A depiction of some aspect of functionality
? Extensions
– To extend a use case to illustrate a different or deeper
perspective.
? Uses
– Actually a reuse of an already-defined use case
Overview of royal service station
Billing
Services
MaintenanceParkingRefueling
Customer
Stand for a case
A actor
First extension to include preventive maintenance
Preventive
Maintenance
Maintenance
Parking
Refueling
Customer Manager
extends
Second extension to include credit card system
Billing
Services
MaintenanceParkingRefueling
Customer
Manager
Credit Card
System
Third extension to include inventory and accounting
Billing
Services
MaintenanceParkingRefueling
Customer
Manager
Credit Card
System
Printer system
Accounting
System
Controlling
Inventory
Fuel Ordering
system
Parts Ordering
system
Use UML to Represent OO
? OMG(Object Management Group)have adopted
UML as the OO notational standard.
? UML can be used to visualize,specify,or
document a problem.
? UML can be used throughout the software
development process.
UML diagrams
? Static view is depicted with
– Use cases(用例图）
– Class diagrams（类图）
– Package diagrams(包图）
– Deployment diagrams(配置图）
? Dynamic view is depicted with
– State diagrams(状态图）
– Activity diagrams(活动图）
– Sequence diagrams（顺序图）
– Collaboration diagrams（合作图）
? Restrictions and formalization
– Be expressed with OCL(object constraint language)
OO System Design
? Five levels of OO design
– Identify subjects
– Identify classes and objects
– Identify attributes
– Identify structures
– Identify services
Determine candidate classes
? Some questions can help us to group the
candidate classes and objects.
– What needs to be ―processed‖ in some way?
– What items have multiple attributes?
– When do you have more than one object in a class?
– What is based on the requirement themselves,not
derived from your understanding of the
requirements?
– What attributes and operations are always applicable
to a class or object?
Related Requirement Statements
A customer has the option to be billed automatically at the time of
purchase(of fuel,maintenance,or parking) or to be sent a monthly
paper bill,In either case,customers can pay using cash,credit card,
or personal check,Royal Service Station fuel is sold according to
price per gallon,depending on whether the fuel is diesel,regular,or
premium,Service is priced according to the cost of parts and labor,
Parking is sold according to daily,weekly,and monthly rates,The
prices for fuel,maintenance services,parts,and parking may vary;
only Manny,the station manager,can enter or change prices,At his
discretion,Manny may designate a discount on purchase for a
particular customer; this discount may vary from one customer to
another,A 5% local sales tax apples to all purchase.
Tentative classes of Royal Service Station
? Personal check
? Paper bill
? Credit card
? Customer
? Station manager
? Purchase
? Fuel
? Services
? Discounts
? Tax
? Parking
? Maintenance
? Cash
? Prices
First Grouping of Attributes and Classes, Step1
Classes Attributes
Customer
Maintenance
Services
Parking
Fuel
Paper bill
Purchase
Station manager
Personal check
Tax
Price
Cash
Credit card
Discounts
Related Requirement Statements
The system applies only to regular repeat
customers,A regular repeat customer means a
customers identified by name,address and birth-
date who uses the station’s service at least once
per month for at least six months,
The system will send periodic messages to
customers,reminding them when their vehicles
are due for maintenance,Normally,maintenance
is needed every six mouths,
First Grouping of Attributes and Classes, Step2
Classes Attributes
Customer
Maintenance
Services
Parking
Fuel
Paper bill
Purchase
Periodic message
Station manager
Personal check
Tax
Price
Cash
Credit card
Discounts
Birth_date
Name
Address
For the full set of requirements,we
might expand our table to include
all of the classes.
First Grouping of Attributes and Classes, Step3
Classes Attributes
Customer
Maintenance
Services
Parking
Fuel
Paper bill
Purchase
Periodic message
Station manager
Warning letter
Parts
Accounts
Inventory
Credit card system
Part-ordering system
Fuel-ordering system
Personal check
Tax
Price
Cash
Credit card
Discounts
Birth_date
Name
Address
Identify Behavior
? Look for particular items that suggest behaviors,
(Extract verbs from the requirements statement)
– Imperative verbs
– Passive verbs
– Actions
– Things or reminded events
– Roles
– Operating procedures
– Service provided by an organization
? The behaviors will become actions or
responsibilities.
Use UML to describe the relationship
among the object,classes,and behaviors
bill
Issue_date, Date
Payment_date, Date
Price( )
Taxes( )
Customers( )
Purchase( )
Add_to_bill( customer,amount,date)
Inheritance
Service
Discount_rate,number
Price( )
Parking
Price,number=5.00
Super-class
Sub-class
Inheritance( is a)
Four kinds of relationship
? Generalization
? Aggregation
? Association
? composition
association
composition
aggregation
dependency
navigation
UML notations
Association of classes
Salesperson
Customer
Order
Ordered item
receives
1 1..*
has
1
1..*
includes
Qualified association
Qualified association
qualifier
目录
文件名
文件
Periodic
Messages
text
Customer
name
Address
Birth_date
Warning letter
text
Credit Card system
Account
account_number Billissue_date
Payment_date
Vehicle Maintenance
issue_date
Payment_date
Inventory
Purchase
date
tax_rate
Fuel
price
discount_rate
min_quantity=100
Parking
location
price
Parking
Ordering
system
Fuel
Ordering
system
Station
Manager
Part
part_number
Price
discount_rate
First cut at Royal Service Station Design
Sway Back and Forth
? Abstract a Message Class from warning letter and
periodic message.
? The fuel class should be connected to inventory class
? Delete the account class(has only one attribute) and add
the account number to the customer class.
? Add three new class,refuel,parking space,service.
– For taking advantage of the polymorphism
? The price and discount can be different depending on what service is
required,
– Remove the discount rate from the fuel class and put it in the
part class.
– Remove the price from the fuel class and add it to the refuel
class.
– Put the price of a parking space,location in the parking class.
Periodic
Messages
text
Customer
name
Address
Birth_date
Warning letter
text
Credit Card system
Refuelgallons
price
Bill
issue_date
Payment_date
Vehicle Maintenance
issue_date
Payment_date
Inventory
Purchase
date
tax_rate
Fuel
min_quantity=100
Current_quantity
Parking
location
price
Parks
Ordering
system
Fuel
Ordering
system
Station
Manager
Part
part_number
Price
discount_rate
Second cut at Royal Service Station Design
Message
text
Parking Space
location
Services
price
discount_rate
Sway Back and Forth
? Delete Station Manager class
? Add service station to handle the tracking of
dormant accounts
Third cut at Royal Service Station Design
Periodic
Messages
Customer
name
Address
Birth_date
Warning letter
text
Credit Card system
Refuelgallons
price
Bill
issue_date
price( )
tax ( )
Vehicle Maintenance
issue_date
Payment_date
Inventory
order_fuel( )
order_part( )
Purchase
date
tax_rate
Fuel
min_quantity=100
Current_quantity
Parking
location
price
Parks
Ordering
system
Fuel
Ordering
system
Part
part_number
Price
discount_rate
Message
text
Parking
Space
location
Services
price
discount_rate
0..*
1
0..*
1
1..* 0..*
0..*
Service Station
dormant_account( )
0..*
1
0..*
0..* 1
1
1
1
1..*
Other UML Diagrams
? Class description template
? Package diagrams
? Sequence diagrams
? Collaboration diagrams
? State diagrams
? Activity diagrams
Class description template
? Template tell us
– the position of the class in the overall hierarchy
– export controls
– cardinality
– associations
? Template also specifies
– the operations in the class
– the public interface to the class
Template for the refuel class
Class name, refuel
Category,service
External documents:
Export control,Public
Cardinality,n
Hierarchy:
Super-classes,services
Associations,
Operation name,price
Public member of,refuel
Documentation:
Preconditions:
Gallons > 0
Object diagram,unspecified
Semantics:
final_price = gallons * price
Concurrency,sequential
Public interface:
Operation:
price
Private interface:
Attributes:
Gallons
price
Implementation:
Attributes:
Gallons
price
State machine,no
Concurrency,sequential
Persistence,transient
Package diagrams
Products ExternalSystem
Customer Services
Refuel
gallons
price
price( )
Vehicle
Maintenance
price
price( )Parkingprice
Parking Space
location
is_available( )
Services
discount_rate
price( )
0..*
1
Stand for
dependent
Interaction diagrams
? To describe how operations and behaviors
are handled by objects.
? To describe how the objects are connected
statically.
? Based on each use case
? Two kinds of interaction diagrams
– Sequence diagrams
– Collaboration diagrams
Sequence diagram for the refuel use case
Customer Service Station Credit Card
System
Purchase Refuel
refuel( )
Verify customer
(credit_card_sum,
amount )
new_purchase
(customer,refuel,
date,gallons) new_refuel
(customer,
date,gallons)
cancel
credit card
transaction transaction
okay
pay_by_cash( )
object’s lifeline
start or
end of a
messag
e
message
message
name
condition
object
Collaboration diagram for the parking use case
Customer
Parking Space
Purchase
Parking
Service Station
1,parking( )
2,next_available( )
3,parking_at(location)
4,new_purchase(customer,
parking,date,location)
5,new_parking(customer,
location)
State diagrams for fuel class
Normal stock Low stock
[delivery of new fuel]
[amount of fuel >= minimum ]
Fuel
min_quantity=100
Current_quantity
[amount of fuel < minimum ]
condition transition state
start
end
State diagrams for inventory class
Inventory
order_fuel( )
order_part( )
Low fuel
Order partsOrder fuel
Normal stock Low parts
[deliver parts][deliver fuel]
[parts low
in stock]
[fuel low
in stock]
Activity diagrams
Activity A
Output X
Activity B
Activity BActivity B
decision
broadcast
start
end
Activity diagrams for inventory class
Verify stock
Order partsOrder fuel
Verify
fuel stock
Verify
parts stock
okayokay
? Object orientation is an approach to
software development that organizes both
the problem and its solution as a collection
of discrete objects;
? It is a kind of representation that describe
object’s data structure and behavior.
? It is a kind of modeling technology.
Characteristics of OO Representation
? Identity—name,reference,handle
? Abstraction
? Classification
? Encapsulation
? Inheritance
? Polymorphism
? Persistence
The OO Development Process
? Be consistency of terminology and of
–The problem and the solution were described in
same terms, classes,objects methods,attributes,and
behaviors,
? Be consistency of perspective
–Static views
–Dynamic views
–Restrictions
Tendency for Change when Using OO Paradigm
(Jacobson et al,1995)
Characteristic of software product/project Probability for change
Objects derived from the application Low
Long-lived information structures Low
Passive object’s attribute Medium
Sequences of behavior Medium
Interface with the outside world High
Functionality High
OO Requirements
? OO requirements analysis is usually done in the user’s
language.
? OO requirements analysis discusses the concepts and
scenarios likely in application domain.
– The concepts include information,service,and
responsibilities.
– Domain knowledge enables both developers and users to
understand the problems.
? The requirements definition can be independent of
implement.
OO Design
? Requirement specification,the first steps of design.
? To represent a system design
– First,to identify and represent classes and objects.
– Second,to identify the interactions and relationships
among objects and classes.
? Associations
? Compositions
? Aggregations
? Inheritance
? To provide the details in program design.
– Insert computational features in the models
– Insert some class library details
– Consider nonfunctional requirements
Use Cases (用例）
? Describe particular functionality to exhibit how
a user,external system,and other entity dialog
with the system.
? Scenario 场景
? Script 脚本
Use case diagrams（用例图）
? Actor（角色）
– A entity interacting with the system
– Or a role that an entity plays with respect of the system
? User
? Device
? Another system
? Cases（用例）
– A depiction of some aspect of functionality
? Extensions
– To extend a use case to illustrate a different or deeper
perspective.
? Uses
– Actually a reuse of an already-defined use case
Overview of royal service station
Billing
Services
MaintenanceParkingRefueling
Customer
Stand for a case
A actor
First extension to include preventive maintenance
Preventive
Maintenance
Maintenance
Parking
Refueling
Customer Manager
extends
Second extension to include credit card system
Billing
Services
MaintenanceParkingRefueling
Customer
Manager
Credit Card
System
Third extension to include inventory and accounting
Billing
Services
MaintenanceParkingRefueling
Customer
Manager
Credit Card
System
Printer system
Accounting
System
Controlling
Inventory
Fuel Ordering
system
Parts Ordering
system
Use UML to Represent OO
? OMG(Object Management Group)have adopted
UML as the OO notational standard.
? UML can be used to visualize,specify,or
document a problem.
? UML can be used throughout the software
development process.
UML diagrams
? Static view is depicted with
– Use cases(用例图）
– Class diagrams（类图）
– Package diagrams(包图）
– Deployment diagrams(配置图）
? Dynamic view is depicted with
– State diagrams(状态图）
– Activity diagrams(活动图）
– Sequence diagrams（顺序图）
– Collaboration diagrams（合作图）
? Restrictions and formalization
– Be expressed with OCL(object constraint language)
OO System Design
? Five levels of OO design
– Identify subjects
– Identify classes and objects
– Identify attributes
– Identify structures
– Identify services
Determine candidate classes
? Some questions can help us to group the
candidate classes and objects.
– What needs to be ―processed‖ in some way?
– What items have multiple attributes?
– When do you have more than one object in a class?
– What is based on the requirement themselves,not
derived from your understanding of the
requirements?
– What attributes and operations are always applicable
to a class or object?
Related Requirement Statements
A customer has the option to be billed automatically at the time of
purchase(of fuel,maintenance,or parking) or to be sent a monthly
paper bill,In either case,customers can pay using cash,credit card,
or personal check,Royal Service Station fuel is sold according to
price per gallon,depending on whether the fuel is diesel,regular,or
premium,Service is priced according to the cost of parts and labor,
Parking is sold according to daily,weekly,and monthly rates,The
prices for fuel,maintenance services,parts,and parking may vary;
only Manny,the station manager,can enter or change prices,At his
discretion,Manny may designate a discount on purchase for a
particular customer; this discount may vary from one customer to
another,A 5% local sales tax apples to all purchase.
Tentative classes of Royal Service Station
? Personal check
? Paper bill
? Credit card
? Customer
? Station manager
? Purchase
? Fuel
? Services
? Discounts
? Tax
? Parking
? Maintenance
? Cash
? Prices
First Grouping of Attributes and Classes, Step1
Classes Attributes
Customer
Maintenance
Services
Parking
Fuel
Paper bill
Purchase
Station manager
Personal check
Tax
Price
Cash
Credit card
Discounts
Related Requirement Statements
The system applies only to regular repeat
customers,A regular repeat customer means a
customers identified by name,address and birth-
date who uses the station’s service at least once
per month for at least six months,
The system will send periodic messages to
customers,reminding them when their vehicles
are due for maintenance,Normally,maintenance
is needed every six mouths,
First Grouping of Attributes and Classes, Step2
Classes Attributes
Customer
Maintenance
Services
Parking
Fuel
Paper bill
Purchase
Periodic message
Station manager
Personal check
Tax
Price
Cash
Credit card
Discounts
Birth_date
Name
Address
For the full set of requirements,we
might expand our table to include
all of the classes.
First Grouping of Attributes and Classes, Step3
Classes Attributes
Customer
Maintenance
Services
Parking
Fuel
Paper bill
Purchase
Periodic message
Station manager
Warning letter
Parts
Accounts
Inventory
Credit card system
Part-ordering system
Fuel-ordering system
Personal check
Tax
Price
Cash
Credit card
Discounts
Birth_date
Name
Address
Identify Behavior
? Look for particular items that suggest behaviors,
(Extract verbs from the requirements statement)
– Imperative verbs
– Passive verbs
– Actions
– Things or reminded events
– Roles
– Operating procedures
– Service provided by an organization
? The behaviors will become actions or
responsibilities.
Use UML to describe the relationship
among the object,classes,and behaviors
bill
Issue_date, Date
Payment_date, Date
Price( )
Taxes( )
Customers( )
Purchase( )
Add_to_bill( customer,amount,date)
Inheritance
Service
Discount_rate,number
Price( )
Parking
Price,number=5.00
Super-class
Sub-class
Inheritance( is a)
Four kinds of relationship
? Generalization
? Aggregation
? Association
? composition
association
composition
aggregation
dependency
navigation
UML notations
Association of classes
Salesperson
Customer
Order
Ordered item
receives
1 1..*
has
1
1..*
includes
Qualified association
Qualified association
qualifier
目录
文件名
文件
Periodic
Messages
text
Customer
name
Address
Birth_date
Warning letter
text
Credit Card system
Account
account_number Billissue_date
Payment_date
Vehicle Maintenance
issue_date
Payment_date
Inventory
Purchase
date
tax_rate
Fuel
price
discount_rate
min_quantity=100
Parking
location
price
Parking
Ordering
system
Fuel
Ordering
system
Station
Manager
Part
part_number
Price
discount_rate
First cut at Royal Service Station Design
Sway Back and Forth
? Abstract a Message Class from warning letter and
periodic message.
? The fuel class should be connected to inventory class
? Delete the account class(has only one attribute) and add
the account number to the customer class.
? Add three new class,refuel,parking space,service.
– For taking advantage of the polymorphism
? The price and discount can be different depending on what service is
required,
– Remove the discount rate from the fuel class and put it in the
part class.
– Remove the price from the fuel class and add it to the refuel
class.
– Put the price of a parking space,location in the parking class.
Periodic
Messages
text
Customer
name
Address
Birth_date
Warning letter
text
Credit Card system
Refuelgallons
price
Bill
issue_date
Payment_date
Vehicle Maintenance
issue_date
Payment_date
Inventory
Purchase
date
tax_rate
Fuel
min_quantity=100
Current_quantity
Parking
location
price
Parks
Ordering
system
Fuel
Ordering
system
Station
Manager
Part
part_number
Price
discount_rate
Second cut at Royal Service Station Design
Message
text
Parking Space
location
Services
price
discount_rate
Sway Back and Forth
? Delete Station Manager class
? Add service station to handle the tracking of
dormant accounts
Third cut at Royal Service Station Design
Periodic
Messages
Customer
name
Address
Birth_date
Warning letter
text
Credit Card system
Refuelgallons
price
Bill
issue_date
price( )
tax ( )
Vehicle Maintenance
issue_date
Payment_date
Inventory
order_fuel( )
order_part( )
Purchase
date
tax_rate
Fuel
min_quantity=100
Current_quantity
Parking
location
price
Parks
Ordering
system
Fuel
Ordering
system
Part
part_number
Price
discount_rate
Message
text
Parking
Space
location
Services
price
discount_rate
0..*
1
0..*
1
1..* 0..*
0..*
Service Station
dormant_account( )
0..*
1
0..*
0..* 1
1
1
1
1..*
Other UML Diagrams
? Class description template
? Package diagrams
? Sequence diagrams
? Collaboration diagrams
? State diagrams
? Activity diagrams
Class description template
? Template tell us
– the position of the class in the overall hierarchy
– export controls
– cardinality
– associations
? Template also specifies
– the operations in the class
– the public interface to the class
Template for the refuel class
Class name, refuel
Category,service
External documents:
Export control,Public
Cardinality,n
Hierarchy:
Super-classes,services
Associations,
Operation name,price
Public member of,refuel
Documentation:
Preconditions:
Gallons > 0
Object diagram,unspecified
Semantics:
final_price = gallons * price
Concurrency,sequential
Public interface:
Operation:
price
Private interface:
Attributes:
Gallons
price
Implementation:
Attributes:
Gallons
price
State machine,no
Concurrency,sequential
Persistence,transient
Package diagrams
Products ExternalSystem
Customer Services
Refuel
gallons
price
price( )
Vehicle
Maintenance
price
price( )Parkingprice
Parking Space
location
is_available( )
Services
discount_rate
price( )
0..*
1
Stand for
dependent
Interaction diagrams
? To describe how operations and behaviors
are handled by objects.
? To describe how the objects are connected
statically.
? Based on each use case
? Two kinds of interaction diagrams
– Sequence diagrams
– Collaboration diagrams
Sequence diagram for the refuel use case
Customer Service Station Credit Card
System
Purchase Refuel
refuel( )
Verify customer
(credit_card_sum,
amount )
new_purchase
(customer,refuel,
date,gallons) new_refuel
(customer,
date,gallons)
cancel
credit card
transaction transaction
okay
pay_by_cash( )
object’s lifeline
start or
end of a
messag
e
message
message
name
condition
object
Collaboration diagram for the parking use case
Customer
Parking Space
Purchase
Parking
Service Station
1,parking( )
2,next_available( )
3,parking_at(location)
4,new_purchase(customer,
parking,date,location)
5,new_parking(customer,
location)
State diagrams for fuel class
Normal stock Low stock
[delivery of new fuel]
[amount of fuel >= minimum ]
Fuel
min_quantity=100
Current_quantity
[amount of fuel < minimum ]
condition transition state
start
end
State diagrams for inventory class
Inventory
order_fuel( )
order_part( )
Low fuel
Order partsOrder fuel
Normal stock Low parts
[deliver parts][deliver fuel]
[parts low
in stock]
[fuel low
in stock]
Activity diagrams
Activity A
Output X
Activity B
Activity BActivity B
decision
broadcast
start
end
Activity diagrams for inventory class
Verify stock
Order partsOrder fuel
Verify
fuel stock
Verify
parts stock
okayokay
