1. Object Oriented Analysis and Design COM327 week 7 COM252 week 1 Register! (Not petition!)

2. A summary so far. You should know about the following –Objects –Classes –Encapsulation –Abstraction –Message passing –Polymorphism. –Inheritance

3. Implementation You’ve tried all of those in C++ Time to try and do the “high end” of the lifecycle.

4. Topics to cover Notations –diagramming techniques Process –what to do and when Domain analysis –finding out about a problem area Requirements analysis –finding what a program is meant to do System design –working out how it will do it.

5. Process

6. Process =

7. Process - aims Produce a design which is implementable Need to know –classes in the problem –data members belonging to each class –function members belonging to each class –relationships between classes –data structures used –how the functions work

8. RequirementsAnalysis problem statement system charter requirements description use-case analysis DomainAnalysis object spotting candidate class list CRC analysis CRC cards class list SystemDesign implement C++ JSP diagramming Booch diagramming Booch class diagram complete design

9. Stage 1 - Domain Analysis Starting point - The client FAMILIARIZE! Produce –Problem Statement –System Charter –Requirements Description

10. Problem Statement What problem is the system trying to solve? If there is no problem, you don’t need a system. Plain language description NOT what the system is going to do. Description of the problem area

11. Problem Statement -example Lecturers often miss appointments to see students because they forget that their availability slots have been booked. Their slots can change on a day to day or week to week basis making them difficult to remember. Appointments are booked by reception but not always communicated to staff.

12. System Charter Description of how the system will solve the problem. What will it be responsible for? –Information –Operations What will the system DO? What will it NOT do?

13. System Charter - example The system will keep track of staff availability slots. The system will accept bookings of staff availability slots by students and automatically inform staff by sending an email message at the time of booking and 10 mins before the appointment as a reminder.

14. Requirements statement A list of individual things the system should be capable of. often presented as series of use-cases

15. Use-case analysis Imagine the system is finished. Imagine you are a user. Describe how you would do one single operation with the system: –What options would you select? –What data would you put in? –What info would you get out?

16. Use-case analysis No “repeats” - only a single operation. No “ifs” - describe what it will do in any given instance. Do the ordinary situations first, worry about special cases 2nd. a.k.a. “Critical Path Analysis” ? Now do that for ALL possible operations. The set of use cases is your requirements statement.

17. Use-case analysis - example Start appointment system enter lecturer name see weeks availability slots enter a booking –enter time –enter student name –enter subject of appointment exit system

18. Fergus on’s Laws You never get it right first time –Iteration You never get all the details first time –refinement When you do the use-case you’ll need to ask the client questions –change the problem/solution descriptions

19. Exercise - NOW! Produce the use-cases for the appointment booking system. Ask me for clarification GO!GO!

20. The End!