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 its678 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