Software Design 2e - DIM

1587.3 White box notationsSome design representationsA white box notation can be viewed as one that is largely concerned with describingsome aspect of the detailed realization of a design element. So, not surprisingly, suchnotations tend to be associated with the constructional and functional viewpoints.We should, however, be cautious of regarding these as being the equivalent of thedraughtsman’s ‘blueprint’. There is still a design process to be performed in translatinga white box description into the final system (essentially, the various detaileddesign activities of programming).In this section we review a smaller choice of forms than in the previous section,and most of these are also quite closely related to particular architectural styles (perhapswe should not be too surprised at that!). We begin with the Structure Chart,which provides a classical form of description for the call-and-return architecturalstyle. After that, we review two of the object-oriented notations that seek to describethe implementation details that relate to the concepts of class and object. SequenceDiagrams are also widely employed in object-oriented design, although strictly there isno reason to restrict their use to that particular architectural style. Finally, we examinethe role of pseudocode, a venerable form of description that is not strictly a diagrammaticalone, but which is often used to supplement diagrammatical forms in avery effective way.7.3.1 The Structure ChartThe Structure Chart provides a visual ‘index’ to the hierarchy of procedures within aprogram, using a treelike format. It is therefore very much a solution-oriented form ofdescription and, when allied with an algorithmic form such as pseudocode, can be usedto provide a fairly comprehensive implementation plan for the programmer.Its origins lie in the research performed at IBM to understand the problemsencountered with the design of the OS/360 operating system, which in many ways wasthe first real example of an attempt at programming in the large. A major problem thatthe researchers identified was that of complexity, and the Structure Chart was oneof the means suggested for helping to resolve and understand the structuring of aprogram (Stevens et al., 1974).The Structure Chart provides a means of recording the details of a program’sstructure in a form that is of great value to anyone who is trying to understand its operation.It is particularly useful to the maintainer, who needs to understand the generalarchitecture of someone else’s design, in order to make changes that are consistentwith its form.The form of the Structure ChartThe Structure Chart uses a treelike notation to describe the hierarchy of procedures(subprograms) in terms of the invocation relationship between them (sometimestermed a call graph). It therefore highlights the dependence of a procedure on thelower-level procedures that it invokes. Figure 7.27 shows an example of a StructureChart, in which the three main components are: