Transcript 1

1
Matakuliah
Tahun
: Konsep object-oriented
: 2009
IDENTIFYING FUNCTIONALITY
Pertemuan 15
A Student Guide to Object-Oriented
Development
Chapter 6 Identifying Functionality
3
Responsibilities
• Overall system functionality divided up
between classes
• Each class has certain responsibilities
to provide a service to a user (e.g.maintain a
customer record) or to another class (e.g. to
supply data)
5
CRC cards
• Responsibilities are allocated to the most appropriate
class
• Sometimes a class needs to collaborate with another
class to fulfil its responsibilities
6
CRC card for the Customer class
Customer
Responsibility
Collaborator
Provide customer
information
Keep track of hire
transactions
Hire
7
Identifying responsibilities from scenarios
 Stephanie arrives at the shop at 9.00am one Saturday and chooses a
mountain bike
 Annie sees that its number is 468
 Annie enters this number into the system
 The system confirms that this is a woman’s mountain bike and displays
the daily rate (£2) and the deposit (£60) (:Bike)
 Stephanie says she wants to hire the bike for a week
 Annie enters this and the system displays the total cost £14 + £60 =
£74 (:Bike)
 Stephanie agrees this
 Annie enters Stephanie’s name, address and telephone number into
the system (:Customer)
 Stephanie pays the £74
 Annie records this on the system and the system prints out a receipt
(:Payment collaborating with :Customer)
 Stephanie agrees to bring the bike back by 5.00pm on the following
Saturday
8
Collaboration of objects
A collaboration is the group of objects that interact to
execute a use case
: Customer
: Hire
: Payment
: Bike
9
CRC card for the Hire class
Hire
Responsibility
Collaborator
Provide details of a hire
transaction
Deal with the processing of a
bike return i.e. know if it is
late; calculate and store
lateness penalty. Store any
damage penalty
Bike
10
CRC card for the Bike class
Bike
Responsibility
Collaborator
Provide bike information
Calculate the hire cost for a
specified number of days
11
CRC card for the Payment class
Payment
Responsibility
Collaborator
Keep a record of all
customer payments
Calculate and store amount
of deposit returned
Issue receipt
Customer
12
Deriving operations from responsibilities
• We need to specify responsibilities in terms of
individual operations and attributes.
• Ensure that each class has data and operations to
fulfil responsibility
• Walk through use case description
13
Use case description: Issue bike
Use case :
Actors:
Goal:
Issue bike
Receptionist
To hire out a bike
Overview:
When a customer comes into the shop they choose a bike to hire. The receptionist looks up the
bike on the system and tells the customer how much it will cost to hire the bike for a specified
period. The customer pays, is issued with a receipt, then leaves with the bike.
Cross reference
R3, R4, R5, R6,R7, R8, R9, R10
Typical course of events
Actor action
1.
2.
The customer chooses a bike
The Receptionist keys in the bike number
4.
5.
7.
8.
10.
11.
Customer specifies length of hire
Receptionist keys this in
Customer agrees the price
Receptionist keys in the customer details
Customer pays the total cost
Receptionist records amount paid
System response
3. Displays the bike details including the daily
hire rate and deposit
6. Displays total hire cost
9. Displays customer details
12 Prints a receipt
Alternative courses
Steps 8 and 9. The customer details are already in the system, so the Receptionist need only key
in an identifier and the system will display the customer details.
Steps 7 – 12. The customer may not be happy with the estimated price and may terminate the
transaction at this stage.
14
Operations required for ‘issue bike’ use case
Bike
findBike(bike#)
getCharges(no.Days)
Bike()
Customer
recordDetails(custID, name, address, tel)
Customer()
Payment
calcTotalPayment()
issueReceipt()
Payment()
Hire
Hire(startDate, no.Days)
15
Class diagram for Wheels with attributes and
operations
Hire
Customer
startDate
numberDays
dateReturned
latenessDeduction
damageDeduction
custId
name
address
tel
recordDetails( )
returnHire( )
findCustomer(name)
editCust(name,addr,tel)
Customer( )
1
processReturn( )
1..* calcDaysOverDue( )
recordReturnDate( )
latenessDeduction(amt)
damageDeduction( )
Hire( )
1
0..*
1..*
Payment
date
totalAmountPaid
totalDeposit Paid
totalDepositReturned
calcTotalPayment( )
calcRemainingDeposit( )
issueReceipt( )
Payment( )
1
Bike
bike#
availabl e
type
size
make
model
dail yHireRate
deposit
getCharges( )
findBi ke(bike#)
regi sterBike( )
getBike#( )
Bike( )
SpecialistBike
epoch
insurance
findSpecialBike( )
SpecialistBike( )
16
Interaction Diagrams

Describe messaging between objects to
achieve use case goal

Revisit sequence of events in each
scenario

View in terms of messages spawned by
each event.

Two types of interaction diagram:
sequence and collaboration
17
Sequence diagrams











Stephanie arrives at the shop at 9.00am one Saturday and chooses a mountain bike
Annie sees that its number is 468
Annie enters this number into the system
The system confirms that this is a woman’s mountain bike and displays the daily rate
(£2) and the deposit (£60)
Stephanie says she wants to hire the bike for a week
Annie enters this and the system displays the total cost £14 + £60 = £74
Stephanie agrees this
Annie enters Stephanie’s name, address and telephone number into the system
Stephanie pays the £74
Annie records this on the system and the system prints out a receipt
Stephanie agrees to bring the bike back by 5.00pm on the following Saturday
18
Sequence diagrams
: Receptionist
: Bike
: Customer
: Hire
: Payment
19
Sequence diagrams
return arrow
activation
20
Sequence diagrams
21
Sequence diagrams - without returns
22
Collaboration Diagrams
23
Data dictionary - operations
findBike(bike#)
This operation finds the Bike object whose
number corresponds to the bike number input
(bike#) and returns details about the bike (bike#
+ available + type + make + model + size +
dailyHireRate + deposit)
24
Another example - calcDaysOverdue()
calcDaysOverdue()
This operation uses today's date from the
system clock and the attributes startDate and
numberDays to calculate whether the bike has
been returned late and if so by how many days.
It calculates the overdue amount
(Bike.dailyHireRate multipled by the number of
days late) and records it by executing
SetLatenessDeduction(amt).
25
specification by contract - describes operations in terms
of the services they deliver
the signature of the operation
(its name, any arguments, and
the type of values it returns)
calcDaysOverdue ( )
the purpose of the operation
this operation works out whether a bike has been returned
late and if so by how many days
what the client object must
provide in order to obtain the
required service
the bike must have been returned by the customer, the hire
details must have been found,
a description of the internal
logic of the operation
the number of days’ hired is added to the start date and
then compared with today’s date to calculate if the bike is
late and by how many days. The daily hire rate is multiplied
by the number of days late to give the charge for late return,
this is performed by the Bike.getCharges operation
any other operations that are
called by this operation
this operation calls Bike.getCharges(noDaysLate)
any attributes of objects
whose values are changed by
the operation
this operation sets the Hire attributes dateReturned and
26
latenessDeduction