Designing applications Software Engineering from a Code Perspective

Designing applicationsDesigning applications

Software Engineering from a Code Perspective

13/01/2004 Lecture 11: Designing Applications

2

Main concepts to be coveredMain concepts to be covered

Discovering classesCRC cardsDesigning interfacesPatterns


3

Analysis and designAnalysis and design

A large and complex area.The verb/noun method is suitable for

relatively small problems.CRC cards support the design process.


4

The verb/noun methodThe 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.


5

A problem descriptionA problem description

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


6

Nouns and verbsNouns and verbsCinema booking systemStores (seat bookings)Stores (telephone number)

Seat booking

TheatreHas (seats)

Seat

Row

CustomerReserves (seats)Is given (row number, seat number)Requests (seat booking)

Row number

Seat numberShowIs scheduled (in theatre)

Movie

DateTime

Telephone number


7

Using CRC cardsUsing 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.


8

A CRC cardA CRC cardClass name Collaborators

Responsibilities


9

A partial exampleA partial example

CinemaBookingSystem Collaborators Can find shows by Showtitle and day.Stores collection of Collectionshows.Retrieves and displaysshow details....


10

ScenariosScenarios

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.


11

Scenarios as analysisScenarios as analysisScenarios 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.


12

Class designClass 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

Designing class interfacesDesigning 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.


14

DocumentationDocumentation

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!


15

CooperationCooperation

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.


16

PrototypingPrototyping

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.


17

Software growthSoftware growth

Waterfall model.– Analysis– Design– Implementation– Unit testing– Integration testing– Delivery

No provision for iteration.


18

Iterative developmentIterative development

Use early prototyping.Frequent client interaction.Iteration over:

– Analysis– Design– Prototype– Client feedback

A growth model is the most realistic.


19

Using design patternsUsing 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.


20

Pattern structurePattern structure

A pattern name.The problem addressed by it.How it provides a solution:

– Structures, participants, collaborations.

Its consequences.– Results, trade-offs.


21

DecoratorDecorator

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.


22

SingletonSingleton

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.


23

Factory methodFactory methodA 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.


24

ObserverObserver

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.


25

ObserversObservers


26

ReviewReview

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.


27

ReviewReview

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 studyA case study

Whole-application development

1.0


29

The case studyThe case study

A taxi company is considering expansion.– It operates taxis and shuttles.

Will expansion be profitable?How many vehicles will they need?


30

The problem descriptionThe problem descriptionThe 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.


31

AmendmentsAmendments

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.


32

Discovering classesDiscovering 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.


33

Simplified nouns and verbsSimplified nouns and verbsCompanyOperates taxis.Receives calls.Schedules a vehicle.

TaxiTransports a passenger.

ShuttleTransports one or more passengers.

PassengerLocation

VehiclePick up individual.Arrives at pickup location.Notifies company of arrival.Notifies company of drop-off.

Passenger sourceCalls the company.


34

ScenariosScenarios

Follow a pickup through from request to drop off with CRC cards.

PassengerSource Collaborators Create a passenger. PassengerRequest a taxi. TaxiCompanyGenerate pickup and Locationdestination.


35

Designing class interfacesDesigning class interfacespublic 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();}


36

CollaboratorsCollaborators

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.


37

Outline implementationOutline 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.


38

Iterative developmentIterative 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.


39

ReviewReview

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!

Documents

Designing applications Software Engineering from a Code Perspective