Software Design 2e - DIM

170Some design representationsFigure 7.37An STT describing an aircraft in an air traffic control zone.Simple though this example is, it does demonstrate the way in which a tabularform can aid with checking a model and identifying any questions about its completenessor correctness. For example, the table in Figure 7.36 might rightly lead thedesigner to question whether there should be any way of moving between (say) linecommand mode and text insertion mode (probably not), and also whether there areactions that might usefully need to be defined, such as the effect of pressing the ‘esc’key when in text insertion mode. Finally, we can also note that, in this particular example,the STT’s tabular form can more readily accommodate the structure of vi than theSTD can, since it is more easily extended to include the many other command options.A slightly fuller (or, at least, more balanced) STT describing the behaviour of anaircraft in an air traffic control zone, is shown in Figure 7.37. The corresponding STDwas shown earlier in Figure 7.11. Again, this provides a form that might be used forchecking the analysis model with users, since each combination of state and event canbe considered in turn (and decisions about each recorded).While the STT is by no means the only form that can be readily transformed intoa table, it does provide a particularly clear illustration of the concept, as well as of thetrade-offs between the two formats. On the one hand we have ready visualization ofthe model itself, while on the other we have easier visualization of any omissions orinconsistencies. We can also see that a tabular form is likely to be convenient onlywhere a particular notation combines two major elements in some way. So while anERD might be easily transformed into a table (if not so usefully as an STD), it is slightlyless convenient, although not impossible, to transform a DFD, where auxiliary elementssuch as datastores need to be included.7.4.2 Developing a diagram from a tabular representationOne software design method that does provide particularly comprehensive proceduresfor diagram development is SSADM (Longworth, 1992). To illustrate this process, webriefly consider the development of an Entity Life-History Diagram (ELHD) (a particularinterpretation of the Jackson Structure Diagram). All we should really note about theSSADM model at this point is that it is strongly data driven, makes use of a variationupon the DFD, and hence is based upon the use of processes rather than objects.