20 Design pattern:multi-panel interactive systems oufirstxampe e will devise adesign patte which,inaddition tolusanom typical properties of the object-oriented method,provides an excellent opportunity to contrast it with other approaches,in particular top-down functional decomposition. Because this example nicely captures on a small scale some of the principal properties of object-oriented software construction,I have often used it when requested to introduce an audience to the method in a few hours.By showing concretely (even to people who have had very little theoretical preparation)how one can proceed from a classical decomposition to an O-0 view of things,and the benefits gained in this transformation,it serves as a remarkable pedagogical device.This chapter has been written so that it could play the same role for readers who have been directed to it by the reference they found in the "spoiler"chapter at the beginning of this book. To facilitate their task,it has been made as self-contained as possible;this is why you will find a few repetitions with previous chapters,in particular a few short definitions of concepts which you already know inside out if you have been reading this book sequentially and carefully from the start. 20.1 MULTI-PANEL SYSTEMS The problem is to write a system covering a general type of interactive system,common in business data processing,in which users are guided at each step of a session by a full- screen panel,with predefined transitions between the available panels. The general pattern is simple and well defined.Each session goes through a certain number of states.In each state,a certain panel is displayed,showing questions to the user. The user will fill in the required answer;this answer will be checked for consistency (and questions asked again until an acceptable answer is found);then the answer will be processed in some fashion;for example the system will update a database.A part of the user's answer will be a choice for the next step to perform,which the system will interpret as a transition to another state,where the same process will be applied again A typical example would be an airline reservation system,where the states might represent such steps of the processing as User Identification,Enquiry on Flights(for a certain itinerary on a certain date),Enquiry on Seats(for a certain flight)and Reservation
20 Design pattern: multi-panel interactive systems In our first example we will devise a design pattern which, in addition to illustrating some typical properties of the object-oriented method, provides an excellent opportunity to contrast it with other approaches, in particular top-down functional decomposition. Because this example nicely captures on a small scale some of the principal properties of object-oriented software construction, I have often used it when requested to introduce an audience to the method in a few hours. By showing concretely (even to people who have had very little theoretical preparation) how one can proceed from a classical decomposition to an O-O view of things, and the benefits gained in this transformation, it serves as a remarkable pedagogical device. This chapter has been written so that it could play the same role for readers who have been directed to it by the reference they found in the “spoiler” chapter at the beginning of this book. To facilitate their task, it has been made as self-contained as possible; this is why you will find a few repetitions with previous chapters, in particular a few short definitions of concepts which you already know inside out if you have been reading this book sequentially and carefully from the start. 20.1 MULTI-PANEL SYSTEMS The problem is to write a system covering a general type of interactive system, common in business data processing, in which users are guided at each step of a session by a fullscreen panel, with predefined transitions between the available panels. The general pattern is simple and well defined. Each session goes through a certain number of states. In each state, a certain panel is displayed, showing questions to the user. The user will fill in the required answer; this answer will be checked for consistency (and questions asked again until an acceptable answer is found); then the answer will be processed in some fashion; for example the system will update a database. A part of the user’s answer will be a choice for the next step to perform, which the system will interpret as a transition to another state, where the same process will be applied again. A typical example would be an airline reservation system, where the states might represent such steps of the processing as User Identification, Enquiry on Flights (for a certain itinerary on a certain date), Enquiry on Seats (for a certain flight) and Reservation
676 DESIGN CASE STUDY:MULTI-PANEL INTERACTIVE SYSTEMS $20.1 A typical panel,for the Enquiry on Flights state,might look like the following (only intended,however,to illustrate the ideas,and making no claim of realism or good ergonomic design).The screen is shown towards the end of a step;items in color italics are the user's answers,and items in bold color show an answer displayed by the system. -Enquiry on Flights- A panel Flight sought from: Santa Barbara To: Paris Departure on or after: 21Nov On or before: 22 Nov Preferred airline(s): Special requirements: AVAILABLE FLIGHTS:1 FIt#AA 42 Dep 8:25 Arr 7:45 Thru:Chicago Choose next action: 0一Exit 1-Help 2-Further enquiry 3-Reserve a seat The session begins in an initial state,and ends whenever it reaches a final state.We The figure also can represent the overall structure by a transition graph showing the possible states and include state num- the transitions between them.The edges of the graph are labeled by integers bers,for use later in the discussion. corresponding to the possible user choices for the next step at the end of a state.At the top of the facing page is a graph for a simple airline reservation system. The problem is to come up with a design and implementation for such applications, achieving as much generality and flexibility as possible.In particular: GI.The graph may be large.It is not uncommon to see applications with several hundred states and correspondingly many transitions. G2.The structure is subject to change.The designers are unlikely to foresee all the possible states and transitions.As users start exercising the system,they will come up with requests for changes and additions. G3.Nothing in the given scheme is specific to the choice of application:the airline reservation mini-system is just a working example.If your company needs a number of such systems,either for its own purposes or (in a software house)for various customers,it will be a big benefit to define a general design or,better yet, a set of modules that you can reuse from application to application
676 DESIGN CASE STUDY: MULTI-PANEL INTERACTIVE SYSTEMS §20.1 A typical panel, for the Enquiry on Flights state, might look like the following (only intended, however, to illustrate the ideas, and making no claim of realism or good ergonomic design). The screen is shown towards the end of a step; items in color italics are the user’s answers, and items in bold color show an answer displayed by the system. The session begins in an initial state, and ends whenever it reaches a final state. We can represent the overall structure by a transition graph showing the possible states and the transitions between them. The edges of the graph are labeled by integers corresponding to the possible user choices for the next step at the end of a state. At the top of the facing page is a graph for a simple airline reservation system. The problem is to come up with a design and implementation for such applications, achieving as much generality and flexibility as possible. In particular: G1 • The graph may be large. It is not uncommon to see applications with several hundred states and correspondingly many transitions. G2 • The structure is subject to change. The designers are unlikely to foresee all the possible states and transitions. As users start exercising the system, they will come up with requests for changes and additions. G3 • Nothing in the given scheme is specific to the choice of application: the airline reservation mini-system is just a working example. If your company needs a number of such systems, either for its own purposes or (in a software house) for various customers, it will be a big benefit to define a general design or, better yet, a set of modules that you can reuse from application to application. A panel – Enquiry on Flights – Flight sought from: Departure on or after: To: On or before: Preferred airline (s): Special requirements: AVAILABLE FLIGHTS: 1 Flt# AA 42 Dep 8:25 Arr 7:45 Thru: Chicago Choose next action: 0 — Exit 1 — Help 2 — Further enquiry 3 — Reserve a seat Santa Barbara 21 Nov Paris 22 Nov The figure also include state numbers, for use later in the discussion
$20.2 A SIMPLE-MINDED ATTEMPT 677 A transition Initial diagram Help Help 1 Help Help 3 Confirmation Enquiry 5 on flights 2 3 Reservation Enquiry on seats 2 Help Help 20.2 A SIMPLE-MINDED ATTEMPT Let us begin with a straightforward,unsophisticated program scheme.This version is made of a number of blocks,one for each state of the system:BEnuin BReseo B etc.A typical block (expressed in an ad hoc notation,not the object-oriented notation of this book although it retains some of its syntactic conventions)looks like this: BEnquir “Display Enguiry on flights panel'” repeat "Read user's answers and choice C for the next step" if“Error in answer”then“Output appropriate message”end until not error in answer end Process answer” case Cin Co:goto Exit, C:goto BHelp C2:goto BReservation end and similarly for each state
§20.2 A SIMPLE-MINDED ATTEMPT 677 20.2 A SIMPLE-MINDED ATTEMPT Let us begin with a straightforward, unsophisticated program scheme. This version is made of a number of blocks, one for each state of the system: BEnquiry , BReservation, BCancellation etc. A typical block (expressed in an ad hoc notation, not the object-oriented notation of this book although it retains some of its syntactic conventions) looks like this: BEnquiry: “Display Enquiry on flights panel” repeat “Read user’s answers and choice C for the next step” if “Error in answer” then “Output appropriate message” end until not error in answer end “Process answer” case C in C0: goto Exit, C1: goto BHelp, C2: goto BReservation, … end and similarly for each state. Initial Confirmation Reservation Enquiry_ on_flights 2 2 2 2 2 3 3 3 3 3 1 1 1 1 1 1 1 1 Enquiry_ on_seats Help Help 1 1 Help Help Help Help 1 1 1 2 3 4 5 A transition diagram
678 DESIGN CASE STUDY:MULTI-PANEL INTERACTIVE SYSTEMS $20.3 This structure has something to speak for it:it is not hard to devise,and it will do the job.But from a software engineering viewpoint it leaves much to be desired. The most obvious criticism is the presence of goto instructions (implementing conditional jumps similar to the switch of C and the"Computed Goto"of Fortran),giving the control structure that unmistakable"spaghetti bowl"look. But the gotos are the symptom,not the real flaw.We have taken the superficial structure of the problem-the current form of the transition diagram-and hardwired it into the algorithm;the branching structure of the program is an exact reflection of the structure of the transition graph.This makes the software's design vulnerable to any of the simple and common changes cited above:any time someone asks us to add a state or change a transition,we will have to change the system's central control structure.And we can forget,of course,any hope of reusability across applications(goal G3 in the above list),as the control structure would have to cover all applications. This example is a sobering reminder that we should never get carried away when we hear about the benefits of"modeling the real world"or"deducing the system from the analysis of the reality".Depending on how you describe it,the real world can be simple or messy; a bad model will give bad software.What counts is not how close the software is to the real world,but how good the description is.More on this topic at the end of this chapter. To obtain not just a system but a good system we must think a little harder. 20.3 A FUNCTIONAL,TOP-DOWN SOLUTION Repeating on this particular example the evolution of the programming species as a whole, we will go from a low-level goto-based structure to a top-down,hierarchically organized solution,analyze its own limitations,and only then move on to an object-oriented version The hierarchical solution belongs to a general style also known as "structured",although this term should be used with care. For one thing,an O-O solution is certainly structured too,although more in the sense of "structured programming"as originally introduced in the seventies by Dijkstra and others than relative to the quite distinct notion of"structured design". The transition function The first step towards improving the solution is to get rid of the central role of the traversal algorithm in the software's structure.The transition diagram is just one property of the system and it has no reason to rule over everything else.Separating it from the rest of the algorithm will,if nothing else,rid us of the goto instructions.And we should also gain generality,since the transition diagram depends on the specific application,such as airline reservation,whereas its traversal may be described generically. What is the transition diagram?Abstractly,it is a function transition taking two arguments,a state and a user choice,such that transition (s,c)is the state obtained when the user chooses c when leaving state s.Here the word "function"is used in its
678 DESIGN CASE STUDY: MULTI-PANEL INTERACTIVE SYSTEMS §20.3 This structure has something to speak for it: it is not hard to devise, and it will do the job. But from a software engineering viewpoint it leaves much to be desired. The most obvious criticism is the presence of goto instructions (implementing conditional jumps similar to the switch of C and the “Computed Goto” of Fortran), giving the control structure that unmistakable “spaghetti bowl” look. But the gotos are the symptom, not the real flaw. We have taken the superficial structure of the problem — the current form of the transition diagram — and hardwired it into the algorithm; the branching structure of the program is an exact reflection of the structure of the transition graph. This makes the software’s design vulnerable to any of the simple and common changes cited above: any time someone asks us to add a state or change a transition, we will have to change the system’s central control structure. And we can forget, of course, any hope of reusability across applications (goal G3 in the above list), as the control structure would have to cover all applications. This example is a sobering reminder that we should never get carried away when we hear about the benefits of “modeling the real world” or “deducing the system from the analysis of the reality”. Depending on how you describe it, the real world can be simple or messy; a bad model will give bad software. What counts is not how close the software is to the real world, but how good the description is. More on this topic at the end of this chapter. To obtain not just a system but a good system we must think a little harder. 20.3 A FUNCTIONAL, TOP-DOWN SOLUTION Repeating on this particular example the evolution of the programming species as a whole, we will go from a low-level goto-based structure to a top-down, hierarchically organized solution, analyze its own limitations, and only then move on to an object-oriented version. The hierarchical solution belongs to a general style also known as “structured”, although this term should be used with care. For one thing, an O-O solution is certainly structured too, although more in the sense of “structured programming” as originally introduced in the seventies by Dijkstra and others than relative to the quite distinct notion of “structured design”. The transition function The first step towards improving the solution is to get rid of the central role of the traversal algorithm in the software’s structure. The transition diagram is just one property of the system and it has no reason to rule over everything else. Separating it from the rest of the algorithm will, if nothing else, rid us of the goto instructions. And we should also gain generality, since the transition diagram depends on the specific application, such as airline reservation, whereas its traversal may be described generically. What is the transition diagram? Abstractly, it is a function transition taking two arguments, a state and a user choice, such that transition (s, c) is the state obtained when the user chooses c when leaving state s. Here the word “function” is used in its
$20.3 A FUNCTIONAL,TOP-DOWN SOLUTION 679 mathematical sense;at the software level we can choose to implement transition either by a function in the software sense(a routine returning a value)or by a data structure such as an array.For the moment we can afford to postpone the choice between these solutions and just rely on transition as an abstract notion. In addition to the function transition we also need to designate one of the states,say state initial,as the place where all sessions start,and to designate one or more states as final through a boolean-valued function is final.Again this is a function in the mathematical sense,regardless of its eventual implementation. We can picture the transition function in tabular form,with rows representing states and columns representing choices,as shown below. Conventions used in this table:there is just one Help state,0,with a special transition Return which goes back to the state from which Help was reached,and just one final state, -1.These conventions will not be necessary for the rest of the discussion but help keep the table simple. A transition Choice→ 0 2 3 table ↓State 1(Initial) -1 0 5 2 2(Flights） 0 1 3 3(Seats) 0 2 4(Reserv.) 0 3 5(Confirm) 0 4 1 (Help) Return -1(Final） The routine architecture Following the traditional precepts of top-down decomposition,we choose a "top"(the main program)for our system.This should clearly be the routine execute session that describes how to execute a complete interactive session
§20.3 A FUNCTIONAL, TOP-DOWN SOLUTION 679 mathematical sense; at the software level we can choose to implement transition either by a function in the software sense (a routine returning a value) or by a data structure such as an array. For the moment we can afford to postpone the choice between these solutions and just rely on transition as an abstract notion. In addition to the function transition we also need to designate one of the states, say state initial, as the place where all sessions start, and to designate one or more states as final through a boolean-valued function is_ final. Again this is a function in the mathematical sense, regardless of its eventual implementation. We can picture the transition function in tabular form, with rows representing states and columns representing choices, as shown below. Conventions used in this table: there is just one Help state, 0, with a special transition Return which goes back to the state from which Help was reached, and just one final state, –1. These conventions will not be necessary for the rest of the discussion but help keep the table simple. The routine architecture Following the traditional precepts of top-down decomposition, we choose a “top” (the main program) for our system. This should clearly be the routine execute_session that describes how to execute a complete interactive session. Choice → ↓ State 0 1 2 3 1 (Initial) –1 0 5 2 2 (Flights) 0 1 3 3 (Seats) 0 2 4 4 (Reserv.) 0 3 5 5 (Confirm) 0 4 1 0 (Help) Return –1 (Final) A transition table