In the following class diagram, we see the elements of a legal contract, identifying that the contract is between
two or more parties. In identifying the common elements we see that the core elements are the structure of the contract
itself and the different relations to the parties.
Figure 1. Initial structural model of a legal contract
However, a legal contract can be between different people, organizations or government agencies, and so we
note that Party is a variable element by type. In documenting this we define a type hierarchy for
Party and also denote Party as an abstract class so that concrete types must be used in an actual design. This is shown
in Figure 2.
Figure 2. Identifying variability in the Party component of the contract
The type hierarchy in the example above is referred to as an inheritance hierarchy. The
following are examples of kinds of type hierarchies.
Figure 3. Inheritance hierarchy -- classes organized using generalization-specialization
concepts
Figure 4 illustrates an aggregation hierarchy. An aggregate is a class that contains one or more other
classes, related using aggregation/composition relationships
Figure 4. Aggregation hierarchy
Figure 5 represents a cluster hierachy. This is a community of collaborating classes that typically have a
facade, at least one mediator, and a composite which would typically have an abstract factory to produce objects within
the cluster.
Figure 5. Cluster hierarchy
As the final example, Figure 6 illustrates a Framework. This is a set of classes related by a combination of
inheritance and aggregation which have an interface -- abstract classes with default implementations -- that can be
customized for a given context.
Figure 6. Framework
|