Practical Object-Oriented Design with UML 2e Slide 1/1 ©The McGraw-Hill Companies, 2004 PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 6: Restaurant System: Design

Practical Object-Oriented Design with UML 2e Slide 1/2 ©The McGraw-Hill Companies, 2004 Design Analysis shows how business functions can be implemented in the application layer Design extends this level of modelling to the other layers We assume the booking system will be implemented as a desktop application, ie: –single user –normal input and output devices

Practical Object-Oriented Design with UML 2e Slide 1/3 ©The McGraw-Hill Companies, 2004 Getting Input From The User System messages have been shown arriving at the controller in the application layer In fact these will have been ‘pre-processed’ in presentation layer A boundary object in the presentation layer models the system's user interface This has the responsibility for interacting with input devices

Practical Object-Oriented Design with UML 2e Slide 1/4 ©The McGraw-Hill Companies, 2004 Display Bookings Assume date is entered in a dialogue box –don't need to model standard dialogue box functionality in detail –‘submit’ message models pressing ‘OK’ button

Practical Object-Oriented Design with UML 2e Slide 1/5 ©The McGraw-Hill Companies, 2004 Selecting a Booking Mouse events are handled similarly –user interface object translates mouse events into system messages –‘time’ and ‘table’ derived from mouse coordinates

Practical Object-Oriented Design with UML 2e Slide 1/6 ©The McGraw-Hill Companies, 2004 Table Transfer Not every input event need give rise to a system message. The drag does not send a message.

Practical Object-Oriented Design with UML 2e Slide 1/7 ©The McGraw-Hill Companies, 2004 Producing Output Output also assigned as a responsibility of the user interface object The display should be updated whenever the application layer changes Problem: how to ensure that the display is: –always updated when it needs to be –only updated when it needs to be

Practical Object-Oriented Design with UML 2e Slide 1/8 ©The McGraw-Hill Companies, 2004 Polling The presentation layer would periodically check the application layer for updates –wasteful of processing time –expensive to tell if something has changed Better if the application layer triggered updates in the presentation layer –but how? In the layered architecture, the presentation layer is supposed to be independent of the application layer

Practical Object-Oriented Design with UML 2e Slide 1/9 ©The McGraw-Hill Companies, 2004 Observer Pattern Design patterns are standard solutions to problems like this In particular, the Observer pattern: –allows changes to one object (eg application) to be communicated to others (eg presentation) –without assuming what the other objects are This will allow the application layer to trigger events in the presentation layer

Practical Object-Oriented Design with UML 2e Slide 1/10 ©The McGraw-Hill Companies, 2004 Observer Pattern Structure

Practical Object-Oriented Design with UML 2e Slide 1/11 ©The McGraw-Hill Companies, 2004 Interfaces in UML Interfaces are represented as stereotyped classes –they have operations but no attributes Classes can realize interfaces –shown as a dashed arrow with an open arrowhead from the class to the interface –this means the class must implement all the operations defined in the interface

Practical Object-Oriented Design with UML 2e Slide 1/12 ©The McGraw-Hill Companies, 2004 Observer Pattern Rationale The user interface class implements the booking observer interface The booking system maintains a list of registered observers –but it doesn't know what class they belong to –so there is no 'upwards' dependency Each observer is notified whenever a change takes place

Practical Object-Oriented Design with UML 2e Slide 1/13 ©The McGraw-Hill Companies, 2004 Displaying bookings

Practical Object-Oriented Design with UML 2e Slide 1/14 ©The McGraw-Hill Companies, 2004 Explanation The interface implemented by the ‘StaffUI’ object is shown as a role When something changes, the ‘update’ messages is sent to the user interface It then gets updated information from the booking system –the simplest option is to redisplay everything –this can be optimized later if necessary

Practical Object-Oriented Design with UML 2e Slide 1/15 ©The McGraw-Hill Companies, 2004 Persistent Data Most systems need persistent data which is –not lost when the system closes down –stored in file system or database Object-oriented applications often use relational databases to provide persistence Designer needs to: –identify what data needs to be persistent –design a suitable database schema

Practical Object-Oriented Design with UML 2e Slide 1/16 ©The McGraw-Hill Companies, 2004 Designating Persistent Classes In UML classes are the unit of persistence –we must save all booking information –but not eg current date, or selected bookings Persistence is shown using a tagged value

Practical Object-Oriented Design with UML 2e Slide 1/17 ©The McGraw-Hill Companies, 2004 Creating a Database Schema Classes map to tables Associations are relationships between tables, so: –add explicit object IDs to each table –use these as foreign keys to implement links Generalization has no relational equivalent –as ‘Booking’ is an abstract class, simply map concrete subclasses as tables

Practical Object-Oriented Design with UML 2e Slide 1/18 ©The McGraw-Hill Companies, 2004 Database Schema From this we can derive a simple schema

Practical Object-Oriented Design with UML 2e Slide 1/19 ©The McGraw-Hill Companies, 2004 Saving and Loading Whose responsibility is it to save objects and load them from the database? –using existing classes risks low cohesion –make this the responsiblity of a new class –define a ‘mapper’ class for each persistent class Include object IDs in design model –keep persistency out of domain model classes –add ‘oids’ in a subclass

Practical Object-Oriented Design with UML 2e Slide 1/20 ©The McGraw-Hill Companies, 2004 Design for Persistency The mapper classes deal with the persistent subclasses

Practical Object-Oriented Design with UML 2e Slide 1/21 ©The McGraw-Hill Companies, 2004 Persistency Architecture Persistent subclasses and mapper classes depend on the class they are supporting –so they must be in the application layer But the ‘Restaurant’ class is dependent on mapper classes Split application layer into two subpackages –change to ‘Persistency’ subpackage has minimal effect on ‘Domain’ subpackage

Practical Object-Oriented Design with UML 2e Slide 1/22 ©The McGraw-Hill Companies, 2004 Persistency Architecture

Practical Object-Oriented Design with UML 2e Slide 1/23 ©The McGraw-Hill Companies, 2004 Detailed Class Design Create a detailed class specification that could be used as a basis for implementation Start with refined domain model Collect messages from all realizations –check redundancy, inconsistency etc –this defines the operation interface of class –specify detailed parameters and return types

Practical Object-Oriented Design with UML 2e Slide 1/24 ©The McGraw-Hill Companies, 2004 The Booking System Class

Practical Object-Oriented Design with UML 2e Slide 1/25 ©The McGraw-Hill Companies, 2004 Modelling Behaviour Class diagrams show structural design Sequence diagrams show behaviour But some questions are not answered, eg: –what should the system do if a ‘cancel’ message is received before a booking is selected? –what happens if the user tries to move a cancelled booking from one table to another? These depend on the interaction between separate messages

Practical Object-Oriented Design with UML 2e Slide 1/26 ©The McGraw-Hill Companies, 2004 Statecharts Summarize the behaviour of instances of a single class They answer two types of question: –what sequences of messages the objects are expected to receive and respond to –how an object's response to a message depends on its history, ie the messages that have already been received Not every class will require a statechart

Practical Object-Oriented Design with UML 2e Slide 1/27 ©The McGraw-Hill Companies, 2004 Statecharts In the UML, the term state machine refers to the technique used to model behavior in terms of states and transitions. A UML statechart diagram is a graphical representation of a state machine showing states, transitions and events. SC can represent the life history of objects of a given class, rounded rectangles represent a states with directed transition lines between them. SC can be used to model any situation where state change is considered important e.g. the state of a restaurant table.

Practical Object-Oriented Design with UML 2e Slide 1/28 ©The McGraw-Hill Companies, 2004 Statecharts ●The components of a statechart diagrams are: ● the states involved which are represented by the rectangles with rounded corners containing their names; and ●the transitions which are represented by arrows and identified by the events that give rise to them.

Practical Object-Oriented Design with UML 2e Slide 1/29 ©The McGraw-Hill Companies, 2004 Statecharts ●SC shows states, state transitions, and events. Transitions are said to be fired or triggered by events. The firing of a particular transition depends on the current state. In general a transition label can have three parts, all of which are optional: ●Event [Guard] / Action.

Practical Object-Oriented Design with UML 2e Slide 1/30 ©The McGraw-Hill Companies, 2004 Statecharts ●Events can be Signals, calls, time, or state change. There can be entry events and exit events, action that is marked as linked to the entry event is executed whenever the given state is entered via a transition. ●The action associated with the exit event is executed whenever the state is left via a transition. ●A guard or [condition] is a logical condition that will return only “true” or “false.” A guarded transition occurs only if the guard resolves to “true.”

Practical Object-Oriented Design with UML 2e Slide 1/31 ©The McGraw-Hill Companies, 2004 How can statecharts can used by the analyst? ●State diagrams are good at describing the behavior of a single object across several use cases. They are not very good at describing behavior that involves a number of objects collaborating together. So, it is useful to combine state diagrams with other techniques. For instance, interaction diagrams are good at describing the behavior of several objects in a single use case, and activity diagrams are good at showing the general sequence of actions for several objects and use cases.

Practical Object-Oriented Design with UML 2e Slide 1/32 ©The McGraw-Hill Companies, 2004 How can statecharts can used by the analyst? ●Not needed for every class in the system. Use state diagrams only for those classes that exhibit interesting behavior, where building the state diagram helps you understand what is going on. UI and control objects have the kind of behavior that is useful to depict with a state diagram.

Practical Object-Oriented Design with UML 2e Slide 1/33 ©The McGraw-Hill Companies, 2004 Recording Arrival (5.11) Selected booking must be on screen.

Practical Object-Oriented Design with UML 2e Slide 1/34 ©The McGraw-Hill Companies, 2004 Recording Arrival Selected booking must be on screen.

Practical Object-Oriented Design with UML 2e Slide 1/35 ©The McGraw-Hill Companies, 2004 Booking System Statechart The behaviour of the booking system is different if a booking is selected This suggests that it has (at least) two states

Practical Object-Oriented Design with UML 2e Slide 1/36 ©The McGraw-Hill Companies, 2004 Basic Statechart Properties At any given time, an object is in exactly one of a number of states When a message is received, a transition will fire if: –there is a transition leaving the current state –labelled with an event corresponding to the message The object may then end up in a different state.

Practical Object-Oriented Design with UML 2e Slide 1/37 ©The McGraw-Hill Companies, 2004 Operations on Bookings Further transitions can be added for all the events an object can detect

Practical Object-Oriented Design with UML 2e Slide 1/38 ©The McGraw-Hill Companies, 2004 Nondeterminism Sometimes an event can have more than one transition For example, the user may try to select a booking with the mouse over empty space –nothing will be selected and the state will not change

Practical Object-Oriented Design with UML 2e Slide 1/39 ©The McGraw-Hill Companies, 2004 Guard Conditions Nondeterminism can be removed using guard conditions –these are Boolean expressions stating when each transition will fire

Practical Object-Oriented Design with UML 2e Slide 1/40 ©The McGraw-Hill Companies, 2004 Actions Statecharts can show what an object does in response to a particular event These are shown as actions attached to the relevant transition (Event[Guard]/Action)

Practical Object-Oriented Design with UML 2e Slide 1/41 ©The McGraw-Hill Companies, 2004 Composite States Composite states can simplify diagrams –they define properties shared by all the ‘nested’ states Transitions can freely cross the boundary Transitions from a composite state apply to all the nested states History states ‘remember’ the most recent nested state –a transition to a history state goes to that state

Practical Object-Oriented Design with UML 2e Slide 1/42 ©The McGraw-Hill Companies, 2004 Booking System Statechart

Practical Object-Oriented Design with UML 2e Slide 1/43 ©The McGraw-Hill Companies, 2004 BookingSystem Statechart Is this Correct? No nested states No transfer Event[Guard]/Action

Practical Object-Oriented Design with UML 2e Slide 1/44 ©The McGraw-Hill Companies, 2004 Reservation Statechart Reservations have different behaviour after the diners have arrived –can't then cancel the reservation

Practical Object-Oriented Design with UML 2e Slide 1/45 ©The McGraw-Hill Companies, 2004 Initial and Final States Initial states model object creation –a transition from an initial state corresponds to a constructor –but: initial states inside composites indicate what state a transition ending at the composite will end up at Final states model object destruction –once an object reaches a final state it cannot detect events

Practical Object-Oriented Design with UML 2e Slide 1/46 ©The McGraw-Hill Companies, 2004 Error Handling An object may detect an event when there is no matching transition from its current state UML specifies that event is simply ignored In some cases, this indicates an error –to show this, add an explicit ‘Error’ state –add transitions to specify how the system recovers from the error

Practical Object-Oriented Design with UML 2e Slide 1/47 ©The McGraw-Hill Companies, 2004 Satecharts In the UML, the term state machine refers to the technique used to model behaviour in terms of states and transitions. A UML statechart diagram is a graphical representation of a state machine showing states, transitions and events. SC represents the life history of objects of a given class, rounded rectangles represent a states with directed transition lines between them. IT can be used to model anything where state change is considered important e.g. the state of a hotel room.

Practical Object-Oriented Design with UML 2e Slide 1/48 ©The McGraw-Hill Companies, 2004 Satecharts Components ●The states involved which are represented by the rectangles with rounded corners containing their names; and ●The transitions which are represented by arrows and identified by the events that give rise to them. ●SC shows states, state transitions, and events. Transitions are said to be fired or triggered by events. The firing of a particular transition depends on the current state. In general a transition label can have three parts, all of which are optional: Event [Guard] / Action. ●Events can be Signals, calls, time, or state change. There can be entry events and exit events, action that is marked as linked to the entry event is executed whenever the given state is entered via a transition. The action associated with the exit event is executed whenever the state is left via a transition. ●A guard or [condition] is a logical condition that will return only “true” or “false.” A guarded transition occurs only if the guard resolves to “true.”

Practical Object-Oriented Design with UML 2e Slide 1/49 ©The McGraw-Hill Companies, 2004 Satecharts Usage ●State diagrams are good at describing the behavior of a single object across several use cases. They are not very good at describing behavior that involves a number of objects collaborating together. As such, it is useful to combine state diagrams with other techniques. For instance, interaction diagrams are good at describing the behavior of several objects in a single use case, and activity diagrams are good at showing the general sequence of actions for several objects and use cases. ●Not needed for every class in the system. Use state diagrams only for those classes that exhibit interesting behavior, where building the state diagram helps you understand what is going on. UI and control objects have the kind of behavior that is useful to depict with a state diagram.

Practical Object-Oriented Design with UML 2e Slide 1/50 ©The McGraw-Hill Companies, 2004 Summary Input to a system can be handled by a boundary object in the presentation layer, which sends suitable system messages to the controller in the application layer. The Observer pattern can be used to define a means whereby the application layer can inform the presentation layer when changes to the system state may require changes to the display.

Practical Object-Oriented Design with UML 2e Slide 1/51 ©The McGraw-Hill Companies, 2004 Summary If persistent storage is being provided by a relational databases, a schema can be created by defining one database table for each persistent class, and adding explicit object identifiers to each. Mapper classes can be defined for each persistent class, with the responsibility for saving and loading persistent objects to and from the database.

Practical Object-Oriented Design with UML 2e Slide 1/52 ©The McGraw-Hill Companies, 2004 Summary Detailed class design carried out in the design workflow adds operations from all sequence diagrams to classes and makes properties like parameters, return types and visibility explicit. Statecharts can be used to specify the behaviour of classes that display state-dependent behaviour (order matters). They illustrate the sequence of messages that can be sent to an object and the response that the object might make to a message at the different times.

Practical Object-Oriented Design with UML 2e Slide 1/53 ©The McGraw-Hill Companies, 2004 Summary Statecharts show the different states that instances of a class can be in, the transitions they follow in changing state and the events that trigger state changes. Initial and final states represent the creation and the destruction of objects. Guard conditions specify when a transition is followed, and actions specify what an object does in response to a message received while in a particular state. Composite states can be to simplify the structure of a statechart, by factoring out common behaviour.