During the design of a model, ``we invent the abstractions and mechanisms that provide the behaviour that this model requires.'' [3]. Design typically represents the stage in the software process just before the implementation phase; the quality of the design quite often determines the extensibility, robustness and maintainability of the ensuing implementation. Because a bad design can seriously compromise the integrity of the subsequent implementation, it is important that the design phase not be treated lightly.
To aid in the discussion of the design of the simulator engine, several Booch diagrams [3] will be presented which highlight many of the important classes of the simulator architecture and the relationships among them. Booch diagrams illustrate the major aspects of a design through the use of several well-defined icons and adornments. In a class diagram, the most important icon is the ``dotted cloud'' which symbolizes a class; lines connecting two class icons together suggest an association between the two classes. By applying various adornments, such as arrows, circles and squares, to the end points of an association line, the designer may specify the type of association that exists between the two classes.
With respect to object-oriented design, there are two fundamental relationships which will be of particular interest to us, namely, the is a kind of relationship and the is a part of relationship. Two classes which exhibit the is a kind of association are potential candidates for inheritance. For example, a dog is a kind of mammal, therefore it would be natural for a Dog class to inherit from a Mammal class; thereby causing the Dog class to acquire all the attributes of the Mammal class. This type of relationship is also commonly called specialization/generalization. The is a part of relationship, however, suggests that an aggregation association exists between two classes, whereby one instance of a class can contain an instance of another class. For example, biologically, a spleen is a part of a dog; consequently, it is acceptable to encapsulate a Spleen class instance inside an instance of the Dog class so as to express this relationship. Aggregation associations are also referred to as whole/part relationships. The following subsections will make extensive use of these relationships, and others, when describing the various associations between classes in the domain of circuit representation and simulation.