A Student Guide to Object-Oriented Development

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

2. 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)

3. CRC cards • Responsibilities are allocated to the most appropriate class • 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.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

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 . 3: enter current semester 1: enter id registration form 4: create new schedule 5: display John : Student available classes schedule form 6: get courses

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

9. 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 • 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

14. Operations required for ‘issue bike’ use case

15. Class diagram for Wheels with attributes and operations

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

18. Sequence diagrams

19. Sequence diagrams

20. Sequence diagrams

21. Sequence diagrams - without returns

22. Sequence Diagrams • 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 • each instance is represented as a verticalline

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

24. Collaboration Diagrams

25. 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)

26. 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).

27. specification by contract - describes operations in terms of the services they deliver