680 DESIGN CASE STUDY:MULTI-PANEL INTERACTIVE SYSTEMS $20.3 Level3 Top-down execute session functional decomposition execute initial transition state is_final Level2 Level1 display read correct message process Immediately below (level 2)we will find the operations relative to states:definition of the initial and final states,transition structure,and execute state which prescribes the actions to be executed in each state.Then at the lowest level (1)we will find the constituent operations of execute state:display a screen and so on.Note how such a solution may be described,as well as anything object-oriented that we may later see,to "reflect the real world":the structure of the software perfectly mirrors the structure of an application,which involves states,which involve elementary operations.Real- worldliness is not,in this example and many others,a significant difference between O-O and other approaches;what counts is how we model the world. In writing execute session let us try to make it as application-independent as possible.(The routine is again expressed in an ad hoc notation imitated from the O-O notation of the rest of this book.The repeat...until...loop is borrowed from Pascal.) execute session is --Execute a complete session of the interactive system local state,choice:INTEGER do state initial repeat execute state (state,next) --Routine execute state updates the value of next. state :transition (state,next) until is final (state)end end
680 DESIGN CASE STUDY: MULTI-PANEL INTERACTIVE SYSTEMS §20.3 Immediately below (level 2) we will find the operations relative to states: definition of the initial and final states, transition structure, and execute_state which prescribes the actions to be executed in each state. Then at the lowest level (1) we will find the constituent operations of execute_state: display a screen and so on. Note how such a solution may be described, as well as anything object-oriented that we may later see, to “reflect the real world”: the structure of the software perfectly mirrors the structure of an application, which involves states, which involve elementary operations. Realworldliness is not, in this example and many others, a significant difference between O-O and other approaches; what counts is how we model the world. In writing execute_session let us try to make it as application-independent as possible. (The routine is again expressed in an ad hoc notation imitated from the O-O notation of the rest of this book. The repeat … until … loop is borrowed from Pascal.) execute_session is -- Execute a complete session of the interactive system local state, choice: INTEGER do state := initial repeat execute_state (state, →next) -- Routine execute_state updates the value of next. state := transition (state, next) until is_final (state) end end execute_session initial transition execute_ state is_final display read correct message process Level 1 Level 3 Level 2 Top-down functional decomposition
$20.3 A FUNCTIONAL,TOP-DOWN SOLUTION 681 This is a typical transition diagram traversal algorithm.(The reader who has written a lexical analyzer will recognize the pattern.)At each stage we are in a state state, originally set to initial;the process terminates when state satisfies is final.For a non-final state we executeexecute state,which takes the current state and returns the user's transition choice through its second argument next,which the function transition uses, together with state,to determine the next state. The→notation is a The technique using a procedure execute state that changes the value of one of its temporary comven- arguments would never be appropriate in good O-O design,but here it is the most tion,used only for this expedient.To signal it clearly,the notation flags an "out"argument such as next with an particular procedure and forread below. arrow-.Instead of a procedure which modifies an argument,C developers would make execute state a side-effect-producing function called as next :execute state (state )we will see that this practice is subject to criticism too. Since execute state does not show any information about any particular interactive application,you must fill in the application-specific properties appearing on level 2 in the figure:transition function;initial state;is final predicate. To complete the design,we must refine the execute state routine describing the actions to be performed in each state.Its body is essentially an abstracted form of the contents of the successive blocks in the initial goto-based version: execute state (in s:INTEGER;out c:INTEGER)is --Execute the actions associated with state s. --returning into c the user's choice for the next state. local a:ANSWER;ok:BOOLEAN do repeat display (s) read(s,→a) ok:correct (s,a) if not ok then message (s,a)end until ok end process (s,a) c :next choice (a) end This assumes level 1 routines with the following roles: display (s)outputs the panel associated with state s. read (s,-a)reads into a the user's answer to the display panel of state s. correct (s,a)returns true if and only if a is an acceptable answer to the question displayed in state s;if so,process(s,a)processes answer a,for example by updating a database or displaying more information;if not,message (s,a)outputs the relevant error message
§20.3 A FUNCTIONAL, TOP-DOWN SOLUTION 681 This is a typical transition diagram traversal algorithm. (The reader who has written a lexical analyzer will recognize the pattern.) At each stage we are in a state state, originally set to initial; the process terminates when state satisfies is_final. For a non-final state we execute execute_state, which takes the current state and returns the user’s transition choice through its second argument next, which the function transition uses, together with state, to determine the next state. The technique using a procedure execute_state that changes the value of one of its arguments would never be appropriate in good O-O design, but here it is the most expedient. To signal it clearly, the notation flags an “out” argument such as next with an arrow →. Instead of a procedure which modifies an argument, C developers would make execute_state a side-effect-producing function called as next := execute_state (state); we will see that this practice is subject to criticism too. Since execute_state does not show any information about any particular interactive application, you must fill in the application-specific properties appearing on level 2 in the figure: transition function; initial state; is_final predicate. To complete the design, we must refine the execute_state routine describing the actions to be performed in each state. Its body is essentially an abstracted form of the contents of the successive blocks in the initial goto-based version: execute_state (in s: INTEGER; out c: INTEGER) is -- Execute the actions associated with state s, -- returning into c the user’s choice for the next state. local a: ANSWER; ok: BOOLEAN do repeat display (s) read (s, →a) ok := correct (s, a) if not ok then message (s, a) end until ok end process (s, a) c := next_choice (a) end This assumes level 1 routines with the following roles: • display (s) outputs the panel associated with state s. • read (s, →a) reads into a the user’s answer to the display panel of state s. • correct (s, a) returns true if and only if a is an acceptable answer to the question displayed in state s; if so, process (s, a) processes answer a, for example by updating a database or displaying more information; if not, message (s, a) outputs the relevant error message. The → notation is a temporary convention, used only for this particular procedure and for read below