A Student Guide to Object Oriented Development Chapter

A Student Guide to Object. Oriented Development Chapter 6 Identifying Functionality 1

Responsibilities l Overall system functionality divided up between classes l 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) 3

CRC cards l Responsibilities are allocated to the most appropriate class l Sometimes a class needs to collaborate with another class to fulfil its responsibilities 4

CRC card for the Customer class 5

Identifying responsibilities from scenarios · Stephanie arrives at the shop at 9. 00 am 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. 00 pm on the following Saturday 6

Collaboration of objects A collaboration is the group of objects that interact to execute a use case 7

. Sample Collaboration Diagram. 2: validate id 1: enter id 3: enter current semester registration form 4: create new schedule John : Student available classes 5: display schedule form 6: get courses

Sample Sequence Diagram registration form John : Student schedule form 1: enter id 2: validate id 3: enter current semester 4: create new schedule 5: display 6: get courses available courses

CRC card for the Hire class 10

CRC card for the Bike class 11

CRC card for the Payment class 12

Deriving operations from responsibilities l We need to specify responsibilities in terms of individual operations and attributes. l Ensure that each class has data and operations to fulfil responsibility l Walk through use case description 13

Use case description: Issue bike 14

Operations required for ‘issue bike’ use case 15

Class diagram for Wheels with attributes and operations 16

Interaction Diagrams l Describe messaging between objects to achieve use case goal l Revisit sequence of events in each scenario l View in terms of messages spawned by each event. l Two types of interaction diagram: sequence and collaboration 17

Sequence diagrams 18

Sequence diagrams 19

Sequence diagrams 20

Sequence diagrams 21

Sequence diagrams - without returns 22

Sequence Diagrams l Sequence diagrams present the flow of messages between instances in time. § One can immediately see in what order messages are sent because time is an explicit, vertical dimension on the sequence diagram l each instance is represented as a vertical line

Collaboration Diagrams l Collaboration diagrams show objects work with each other by sending messages and exchanging data. § Sequence diagrams and collaboration diagrams are two different views of object interactions

Collaboration Diagrams 25

Data dictionary - operations find. Bike(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 + daily. Hire. Rate + deposit) 26

Another example - calc. Days. Overdue() This operation uses today's date from the system clock and the attributes start. Date and number. Days to calculate whether the bike has been returned late and if so by how many days. It calculates the overdue amount (Bike. daily. Hire. Rate multipled by the number of days late) and records it by executing Set. Lateness. Deduction(amt). 27

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) calc. Days. Overdue ( ) 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. get. Charges operation any other operations that are called by this operation calls Bike. get. Charges(no. Days. Late) any attributes of objects whose values are changed by the operation this operation sets the Hire attributes date. Returned and lateness. Deduction 28