8.2 The Architecture Notation

The architecture of a software system  is defined as its static structure, regarding packages, modules, and classes and the relationships among them. In the software development process, the architecture is the output of the design phase (Programming in the large), and is the specification for the implementation (Programming in the small).

The best way to specify the architecture of software system is to use a graphical notation which shows the relations between the numerous units of the system. There are various standardized notations, such as OMT  (Object Modeling Technique ) after Rumbaugh [RBP⁺91], the Booch Method  [Boo94], and the Jacobson method [Jac95], which have recently merged into UML  (Universal Modeling Language ) [Sof97].

Shortcomings of Existing Notations

When examining the applicability of these modeling languages to analysis and design of the spectral envelope library and the VIEWENV program, several shortcomings are apparent:

• Except for the now defunct OMT, these notations have no means of specifying data flow structures, but are specialized in describing object-oriented analysis and design. However, the spectral envelope library to be developed consists mainly of purely functional data transforming modules, where making the data flows explicit lends a very good insight into the structure of the system.

• It is advantageous to keep the distiction between abstract data types and functional module classes. In the above notations, principally all classes look the same. There are options to specify roles of classes, or to use adornments to express types of classes, but for the spectral envelope library, the distinction between data classes and functional modules is so important that it should be obvious on first sight. What's more, the diagrams can be kept simple and easier to understand.

• The object-oriented VIEWENV program would be amenable to one of the above standard notations while some other standard notation could be used for the mainly transformational spectral envelope library. However, this would undermine the consistency throughout this document.

• As the library is written in non-object-oriented C, it is unavoidable that the description of the architecture for the implementation will at some level of detail not match the structure of the implemented code anymore. That is, the notation for the architecture does not have to provide for means of adding more detailed information, it can be kept clean and simple.

The Adapted Notation

For these reasons, I decided to use an adapted notation which is very close to the standard notations mentioned above. It has two types of classes (data classes and functional module classes), two relations between classes of the same type (the inheritance relation and the ``uses'' relation), and data flows between functional modules which are typed by a data class.

  

Figure 7.4: Inheritance relation between functional module classes (left), and data flow between a reader and a writer functional module (right)

  

Figure 7.5: Inheritance relation between data classes (left), and data flow through a functional module (right)

  

Figure 7.6: Usage relation for functional module classes (left), and data classes (right)

Figure 7.4 shows the inheritance relation between functional classes and a data flow (always via an intermediate data class which specifies the type of the data flow). Figure 7.5 shows the inheritance relation between data classes and data flow which is transformed by a functional class. Figure 7.6, finally, demonstrates the usage relationship which expresses either a reference being held by the using class or an aggregation, i.e. the using class actually contains an object of the used class.^8.1

Note that the data flows in the diagrams are on class level, not on object level. That is, e.g. the diagram in figure 7.11, page , does not say that there are three Sound Data objects (Partials, Spectrum, Signal) that are eventually combined into one Sampled Spectral Env object, but it does simply show the possible data flows between the classes.