Designing applications Software Engineering from a Code Perspective

13/01/2004Lecture 11: Designing Applications2 Main concepts to be covered Discovering classes CRC cards Designing interfaces Patterns

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

13/01/2004Lecture 11: Designing Applications4 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.

13/01/2004Lecture 11: Designing Applications5 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.

13/01/2004Lecture 11: Designing Applications6 Nouns and verbs Cinema booking system Stores (seat bookings) Stores (telephone number) Seat booking Theatre Has (seats) Seat Row Customer Reserves (seats) Is given (row number, seat number) Requests (seat booking) Row number Seat numberShow Is scheduled (in theatre) Movie DateTime Telephone number

13/01/2004Lecture 11: Designing Applications7 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.

13/01/2004Lecture 11: Designing Applications8 A CRC card Class name Collaborators Responsibilities

13/01/2004Lecture 11: Designing Applications9 A partial example CinemaBookingSystem Collaborators Can find shows by Show title and day. Stores collection of Collection shows. Retrieves and displays show details....

13/01/2004Lecture 11: Designing Applications10 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.

13/01/2004Lecture 11: Designing Applications11 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.

13/01/2004Lecture 11: Designing Applications12 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...”

13/01/2004Lecture 11: Designing Applications13 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.

13/01/2004Lecture 11: Designing Applications14 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!

13/01/2004Lecture 11: Designing Applications15 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.

13/01/2004Lecture 11: Designing Applications16 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.

13/01/2004Lecture 11: Designing Applications17 Software growth Waterfall model. –Analysis –Design –Implementation –Unit testing –Integration testing –Delivery No provision for iteration.

13/01/2004Lecture 11: Designing Applications18 Iterative development Use early prototyping. Frequent client interaction. Iteration over: –Analysis –Design –Prototype –Client feedback A growth model is the most realistic.

13/01/2004Lecture 11: Designing Applications19 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.

13/01/2004Lecture 11: Designing Applications20 Pattern structure A pattern name. The problem addressed by it. How it provides a solution: –Structures, participants, collaborations. Its consequences. –Results, trade-offs.

13/01/2004Lecture 11: Designing Applications21 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.

13/01/2004Lecture 11: Designing Applications22 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.

13/01/2004Lecture 11: Designing Applications23 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.

13/01/2004Lecture 11: Designing Applications24 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.

13/01/2004Lecture 11: Designing Applications25 Observers

13/01/2004Lecture 11: Designing Applications26 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.

13/01/2004Lecture 11: Designing Applications27 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.

A case study Whole-application development 1.0

13/01/2004Lecture 11: Designing Applications29 The case study A taxi company is considering expansion. –It operates taxis and shuttles. Will expansion be profitable? How many vehicles will they need?

13/01/2004Lecture 11: Designing Applications30 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.

13/01/2004Lecture 11: Designing Applications31 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.

13/01/2004Lecture 11: Designing Applications32 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.

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

13/01/2004Lecture 11: Designing Applications34 Scenarios Follow a pickup through from request to drop off with CRC cards. PassengerSource Collaborators Create a passenger. Passenger Request a taxi. TaxiCompany Generate pickup and Location destination.

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

13/01/2004Lecture 11: Designing Applications36 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.

13/01/2004Lecture 11: Designing Applications37 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.

13/01/2004Lecture 11: Designing Applications38 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.

13/01/2004Lecture 11: Designing Applications39 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!