1. Designing applications Software Engineering from a Code Perspective

2. Main concepts to be covered • Discovering classes • CRC cards • Designing interfaces • Patterns Lecture 11: Designing Applications

3. Analysis and design • A large and complex area. • The verb/noun method is suitable for relatively small problems. • CRC cards support the design process. Lecture 11: Designing Applications

4. The verb/noun method • The nouns in a description refer to ‘things’. • A source of classes and objects. • The verbs refer to actions. • A source of interactions between objects. • Actions are behavior, and hence methods. Lecture 11: Designing Applications

5. A problem description The cinema booking system should store seat bookings for multiple theatres. Each theatre has seats arranged in rows. Customers can reserve seats and are given a row number and seat number. They may request bookings of several adjoining seats. Each booking is for a particular show (i.e., the screening of a given movie at a certain time). Shows are at an assigned date and time, and scheduled in a theatre where they are screened. The system stores the customers’ telephone number. Lecture 11: Designing Applications

6. Nouns and verbs Cinema booking system Stores (seat bookings) Stores (telephone number) Theatre Has (seats) Movie Customer Reserves (seats) Is given (row number, seat number) Requests (seat booking) Time Date Seat booking Show Is scheduled (in theatre) Seat Seat number Telephone number Row Row number Lecture 11: Designing Applications

7. Using CRC cards • First described by Kent Beck and Ward Cunningham. • Each index cards records: • A class name. • The class’s responsibilities. • The class’s collaborators. Lecture 11: Designing Applications

8. A CRC card Class name CollaboratorsResponsibilities Lecture 11: Designing Applications

9. A partial example CinemaBookingSystem CollaboratorsCan find shows by Showtitle and day.Stores collection of Collection shows. Retrieves and displaysshow details.... Lecture 11: Designing Applications

10. Scenarios • An activity that the system has to carry out or support. • Sometimes known as use cases. • Used to discover and record object interactions (collaborations). • Can be performed as a group activity. Lecture 11: Designing Applications

11. Scenarios as analysis • Scenarios serve to check the problem description is clear and complete. • Sufficient time should be taken over the analysis. • The analysis will lead into design. • Spotting errors or omissions here will save considerable wasted effort later. Lecture 11: Designing Applications

12. Class design • Scenario analysis helps to clarify application structure. • Each card maps to a class. • Collaborations reveal class cooperation/object interaction. • Responsibilities reveal public methods. • And sometimes fields; e.g. “Stores collection ...” Lecture 11: Designing Applications

13. Designing class interfaces • Replay the scenarios in terms of method calls, parameters and return values. • Note down the resulting signatures. • Create outline classes with public-method stubs. • Careful design is a key to successful implementation. Lecture 11: Designing Applications

14. Documentation • Write class comments. • Write method comments. • Describe the overall purpose of each. • Documenting now ensures that: • The focus is on what rather than how. • That it doesn’t get forgotten! Lecture 11: Designing Applications

15. Cooperation • Team-working is likely to be the norm not the exception. • Documentation is essential for team working. • Clean O-O design, with loosely-coupled components, also supports cooperation. Lecture 11: Designing Applications

16. Prototyping • Supports early investigation of a system. • Early problem identification. • Incomplete components can be simulated. • E.g. always returning a fixed result. • Avoid random behavior which is difficult to reproduce. Lecture 11: Designing Applications

17. Software growth • Waterfall model. • Analysis • Design • Implementation • Unit testing • Integration testing • Delivery • No provision for iteration. Lecture 11: Designing Applications

18. Iterative development • Use early prototyping. • Frequent client interaction. • Iteration over: • Analysis • Design • Prototype • Client feedback • A growth model is the most realistic. Lecture 11: Designing Applications

19. Using design patterns • Inter-class relationships are important, and can be complex. • Some relationship recur in different applications. • Design patterns help clarify relationships, and promote reuse. Lecture 11: Designing Applications

20. Pattern structure • A pattern name. • The problem addressed by it. • How it provides a solution: • Structures, participants, collaborations. • Its consequences. • Results, trade-offs. Lecture 11: Designing Applications

21. Decorator • Augments the functionality of an object. • Decorator object wraps another object. • The Decorator has a similar interface. • Calls are relayed to the wrapped object ... • ... but the Decorator can interpolate additional actions. • Example: java.io.BufferedReader • Wraps and augments an unbuffered Reader object. Lecture 11: Designing Applications

22. Singleton • Ensures only a single instance of a class exists. • All clients use the same object. • Constructor is private to prevent external instantiation. • Single instance obtained via a static getInstance method. • Example: Canvas in shapes project. Lecture 11: Designing Applications

23. Factory method • A creational pattern. • Clients require an object of a particular interface type or superclass type. • A factory method is free to return an implementing-class object or subclass object. • Exact type returned depends on context. • Example: iterator methods of the Collection classes. Lecture 11: Designing Applications

24. Observer • Supports separation of internal model from a view of that model. • Observer defines a one-to-many relationship between objects. • The object-observed notifies all Observers of any state change. • Example SimulatorView in the foxes-and-rabbits project. Lecture 11: Designing Applications

25. Observers Lecture 11: Designing Applications

26. Review • Class collaborations and object interactions must be identified. • CRC analysis supports this. • An iterative approach to design, analysis and implementation can be beneficial. • Regard software systems as entities that will grow and evolve over time. Lecture 11: Designing Applications

27. Review • Work in a way that facilitates collaboration with others. • Design flexible, extendible class structures. • Being aware of existing design patterns will help you to do this. • Continue to learn from your own and others’ experiences. Lecture 11: Designing Applications

28. A case study Whole-application development 1.0

29. The case study • A taxi company is considering expansion. • It operates taxis and shuttles. • Will expansion be profitable? • How many vehicles will they need? Lecture 11: Designing Applications

30. The problem description The company operates both individual taxis and shuttles. The taxis are used to transport an individual (or small group) from one location to another. The shuttles are used to pick up individuals from different locations and transport them to their several destinations. When the company receives a call from an individual, hotel, entertainment venue, or tourist organization, it tries to schedule a vehicle to pick up the fare. If it has no free vehicles, it does not operate any form of queuing system. When a vehicle arrives at a pick-up location, the driver notifies the company. Similarly, when a passenger is dropped off at their destination, the driver notifies the company. Lecture 11: Designing Applications

31. Amendments • Purpose of the modeling suggests additions: • Record details of lost fares. • Record details of how each vehicle passes its time. • These issues will help assess potential profitability. Lecture 11: Designing Applications

32. Discovering classes • Singular nouns: company, taxi, shuttle, individual, location, destination, hotel, entertainment venue, tourist organization, vehicle, fare, pickup location, driver, passenger. • Identify synonyms. • Eliminate superfluous detail. Lecture 11: Designing Applications

33. Simplified nouns and verbs Company Operates taxis. Receives calls. Schedules a vehicle. Taxi Transports a passenger. Location Passenger Vehicle Pick up individual. Arrives at pickup location. Notifies company of arrival. Notifies company of drop-off. Passenger source Calls the company. Shuttle Transports one or more passengers. Lecture 11: Designing Applications

34. Scenarios • Follow a pickup through from request to drop off with CRC cards. PassengerSource CollaboratorsCreate a passenger. PassengerRequest a taxi. TaxiCompanyGenerate pickup and Locationdestination. Lecture 11: Designing Applications

35. Designing class interfaces public class PassengerSource { /** * Have the source generate a new passenger and * request a pickup from the company. * @return true If the request succeeds, * false otherwise. */ public boolean requestPickup(); /** * Create a new passenger. * @return The created passenger. */ private Passenger createPassenger(); } Lecture 11: Designing Applications

36. Collaborators • Received through a constructor: new PassengerSource(taxiCompany) • Received through a method: taxiCompany.requestPickup(passenger) • Constructed within the object. • Taxi company’s vehicle collection. • Some such objects may be passed as collaborators to other objects, as above. Lecture 11: Designing Applications

37. Outline implementation • Once the interfaces are complete, the outline implementation can start. • The outline implementation tests the adequacy of the interfaces. • Expect to have to correct the design. • Lay down some basic tests that will be repeated as development continues. Lecture 11: Designing Applications

38. Iterative development • Take relatively small steps towards the completion of the overall application. • Mark the end of each step with a period of testing. • Regression test. • Fix errors early. • Revisit earlier design decisions, if necessary. • Treat errors-found as successes. Lecture 11: Designing Applications

39. Review • Robust software requires thoughtful processes to be followed with integrity. • Analyze carefully. • Specify clearly. • Design thoroughly. • Implement and test incrementally. • Review, revise and learn. Nobody’s perfect! Lecture 11: Designing Applications