To better understand how the approach we have developed might be of practical value, we present the following stylized example involving a restaurant information system based loosely on the work of Salancik and Leblebici (1988). This example is chosen because of its relative simplicity, and because of the familiarity of the restaurant domain.
Imagine that you are a systems analyst charged with developing an information system to support the operational side of a large restaurant or chain of restaurants. You might include as part of your analysis a state diagram representing the flow of events involved in a ''meal transaction''in a restaurant. This would be the flow of events involved in the delivery of meals to customers and the collection of payment.
We will assume that based on interviews and observations, you have determined that any meal transaction will be composed of the following set of five activities: ordering a meal, cooking, serving, eating, and paying. Furthermore your interviews suggest that in the restaurants in question these steps always occur in a single sequence, leading to the simple state machine depicted in figure 5.3.[8]
Figure 5.3: State diagram for full service restaurant
Having successfully developed software to support the operations of this first group of restaurants, you are called upon to modify the software to work in three other food service environments: a fast food restaurant, a buffet, and a church supper. Based on further interviews and analysis you develop the state diagrams shown in figure 5.4 to describe each of these processes.
Figure 5.4: Additional restaurant state diagrams
Having observed that none of the four state diagrams developed so far is a specialization of any other, you apply the generalizing transformations to generate a generic restaurant process for which each of the above state diagrams is a specialization. As the diagrams differ only in the events they include, generalizing is simply a matter of adding each of the events from the other diagrams to the original diagram. The resulting diagram is shown in figure 5.5
Figure 5.5: Generalized restaurant transaction
You have thus generated the specialization hierarchy depicted in figure 5.6. Such hierarchies can contribute to software (and design) reuse by providing a taxonomy of previous designs that can be searched easily.
Figure 5.6: Initial specialization hierarchy for restaurant information system
Of special interest is the fact that design knowledge propagates up this hierarchy to the most generic diagram, which contains accumulated knowledge about all variants of the restaurant process. This generic diagram can then be used to generate additional diagrams.
For example, imagine that you are now called upon to develop a specification to support a restaurant with both table service and a buffet. You can obtain a state diagram for such a hybrid by applying a series of specializing transformations to the generic diagram (see figure 5.7).
Figure 5.7: Full service restaurant with buffet
To the extent that one is choosing among a set of preexisting functions resident in the most generic diagram, a story about the great artist Michaelangelo would seem to be relevant. Michaelangelo was asked how it was that he was able to produce the extraordinary sculpture of David for which he is famous. He replied that he began with a block of marble and simply removed all the pieces that were not David, until only David remained. So with the most generic state diagram in a hierarchy, many diagrams can be generated simply by removing states and events that do not apply.[9]
[8]While we have labeled the events in ?gure 5.3, in general, we will leave them unlabeled because the speci?c nature of the events is usually obvious, and in any case of limited relevance to the present analysis.
[9]One hesitates to draw such a presumptuous comparison, but we can all aspire to produce systems with the grace, beauty, and intrinsic value exempli?ed by Michaelangelo's work!