682 DESIGN CASE STUDY:MULTI-PANEL INTERACTIVE SYSTEMS $20.4 The type ANSWER of the object representing the user's answer has not been refined further.A value a of that type globally represents the input entered by the user in a given state;it is assumed to include the user's choice for the next step,written next choice (a). (ANSWER is in fact already very much like a class,even though the rest of the architecture is not object-oriented at all.) To obtain a working application,you will need to fill in the various level 1 features: display,read,correct,message and process. 20.4 A CRITIQUE OF THE SOLUTION Have we now a satisfactory solution?Not quite.It is better than the first version,but still falls short of our goals of extendibility and reusability. Statism Although on the surface it seems we have been able to separate the generic from the application-specific,in reality the various modules are still tightly coupled with each other and with the choice of application.The main problem is the data transmission structure of the system.Consider the signatures (argument and result types)of the routines: execute state n s:STATE:out c:CHOICE) display in s:STATE read in s:STATE out a:ANSWER) State intervention correct in s:STATE:a:ANSWER):BOOLEAN message in s:STATE:a:ANSWER) process in s:STATE:a:ANSWER) The observation (which sounds like an economist's lament)is that the role of the The architectural state is too pervasive.The current state appears under the names as an argument in all thefgre isonpage 680. routines,coming from the top module execute session,where it is known as state.So the hierarchical structure shown in the last figure,seemingly simple and manageable,is a lie, or more precisely a facade.Behind the formal elegance of the functional decomposition lies a jumble of data transmission.The true picture,shown at the top of the facing page, must involve the data. The background for object technology,as presented at the beginning of this book,is the battle between the finction and data(object)aspects of software systems for control of the architecture.In non-O-O approaches,the functions rule unopposed over the data; but then the data take their revenge. The revenge comes in the form of sabotage.By attacking the very foundations of the architecture,the data make the system impervious to change-until,like a government unable to handle its perestroika,it will crumble under its own weight.682 DESIGN CASE STUDY: MULTI-PANEL INTERACTIVE SYSTEMS §20.4 The type ANSWER of the object representing the user’s answer has not been refined further. A value a of that type globally represents the input entered by the user in a given state; it is assumed to include the user’s choice for the next step, written next_choice (a). (ANSWER is in fact already very much like a class, even though the rest of the architecture is not object-oriented at all.) To obtain a working application, you will need to fill in the various level 1 features: display, read, correct, message and process. 20.4 A CRITIQUE OF THE SOLUTION Have we now a satisfactory solution? Not quite. It is better than the first version, but still falls short of our goals of extendibility and reusability. Statism Although on the surface it seems we have been able to separate the generic from the application-specific, in reality the various modules are still tightly coupled with each other and with the choice of application. The main problem is the data transmission structure of the system. Consider the signatures (argument and result types) of the routines: execute_state ( in s: STATE ; out c: CHOICE) display ( in s: STATE ) read ( in s: STATE ; out a: ANSWER) correct ( in s: STATE ; a: ANSWER): BOOLEAN message ( in s: STATE ; a: ANSWER) process ( in s: STATE ; a: ANSWER) The observation (which sounds like an economist’s lament) is that the role of the state is too pervasive. The current state appears under the name s as an argument in all the routines, coming from the top module execute_session, where it is known as state. So the hierarchical structure shown in the last figure, seemingly simple and manageable, is a lie, or more precisely a façade. Behind the formal elegance of the functional decomposition lies a jumble of data transmission. The true picture, shown at the top of the facing page, must involve the data. The background for object technology, as presented at the beginning of this book, is the battle between the function and data (object) aspects of software systems for control of the architecture. In non-O-O approaches, the functions rule unopposed over the data; but then the data take their revenge. The revenge comes in the form of sabotage. By attacking the very foundations of the architecture, the data make the system impervious to change — until, like a government unable to handle its perestroika, it will crumble under its own weight. State intervention The architectural figure is on page 680