5 3.3.5 REFERENCING
5.4 ADVANCED CONCEPT MODELLING
Because of the number of concepts in a SDM, concept modelling is a very complicated and tedious job. The crystallisation of models into a common generic representation is also not a simple task. The new model must be concise and precise in its description. This section investigates a number of techniques that have been developed to solve various modelling problems or to reduce the complexity of the model. First of all, we shall investigate the possible relationships between entity concept and fragment concept.
5.4.1 AGGREGATION VS DECOMPOSITION VS REFERENCING
Software development vacillates between applications as well as within a single application. Each method allows a certain flexibility for the user to design within the ‘limited’ method concepts. In our meta model, there are three possible ways to denote the association between an entity and a fragment, namely aggregation, decomposition and referencing.
Aggregation is denoted as composition. There is an intrinsic asymmetry to the association: one concept is subordinate to the other. An aggregate (method fragment) consists of a number of constituents (method entities). For instance, a stateDiagram is an aggregation of its state, as shown in figure 5.18a.
Decomposition is depicted as grouping in our product model. A group is a concept, so a host concept (method fragment) may be expanded to an element concept (method entity). In figure 5.18b, a state can be decomposed to a stateDiagram through the nestedStateDiagram
concept. However, considering each state owns a stateDiagram, the relationship is shown by composition as illustrated by the shaded colour in figure 5.18a. A role or a label is required to denote the type of relationships (see figure 5.29c for the two types of decomposition between
state and stateDiagram in OMT). Nevertheless, the concept is hidden in the label of the composition and it is not identified as a concept of the method. This is a significant drawback of this representation. This relationship shall be considered as an optional host-element association rather than a whole-part ownership.
stateDiagram
T
X state stateDiagram ^ A objectDiagrarr nestedStateDiagram ) state )^~ A ^ r dataDictionary ^ f _ A object —-a. aggregation b. decomposition c. referencing
5. Product Model
IPSYS ToolBuilder adopts the composition approach for nesting diagrams. This is partly for navigational purposes and partly because of concept ownership management in the entity model. The main objective of the IPSYS ToolBuilder developer is to construct a method CASE tool rather than to formalise a method documentation.
The last type of association is known as referencing, which may also be called ‘defined-by’ relationship. An intrinsic entity concept is further described by another fragment. This is particularly useful when a concept is shared amongst two fragments, and one is a complement of the other. For instance, figure 5.18c shows the objects in objectDiagram are defined in the
dataDictionary.
These three associations are distinct in their usages. In summary, aggregation is a whole-part ownership, decomposition is a host-element association and referencing is a defined-by relationship.
5.4.2 COMPOSITION VS REFERENCING
In some cases the representations for composition and referencing have very close meaning. The decision will depend upon a judgment between restriction or flexibility. This can be illustrated by an example. Figure 5.19a shows that the dynamics of an object is defined by a
stateDiagram, the composition is optional. On the other hand, figure 5.19b depicts the relationship by referencing and the stateDiagram is owned by some other fragment concept, say a method.
object
object stateDiagram stateDiagram
a. composition b. referencing
Figure 5.19 Composition vs Referencing
Figure 5.19a describes a stateDiagram to be a constitutent of an object. Every stateDiagram
must be applied to an object. There is a strong dependence in composition. On the other hand, figure 5.19b denotes that an object can be further described by a stateDiagram. The description is more flexible. Each object may refer to a stateDiagram, and the stateDiagram
may describe a number of objects rather than just a single object. The dependence in referencing is weak.
Either method is permissible. The user has to decide on how specific they wish to be. In most cases, the referencing method is preferred as it provides flexibility in the design method.
5. Product Model
5.4.3 MERGING SOURCE AND TARGET LINKS
As mentioned earlier, many link concepts connect entity concepts of the same type. It is convenient to merge the source and target parts together and instead of labelling the parts ‘s’ and ‘t \ use the combined form ‘st\ This reduces the complexity of the concept diagram. Figure 5.20 illustrates a situation where the source part and the target part between transition
and interstate are merged.
y state
startStat e inter!S tate) s topState \ ---/ / s ,\ \ ---/ * \ ---' r --- “ —transition automaticTransition v J
Figure 5.20 Merged Link between interstate and transition
5.4.4 OVERRIDING
The default features of a superconcept can be overridden by its subconcepts. The overriding features can be shown diagramatically by reproducing the relationship at the subconcept level and denoting the changes explicitly. Figure 5.21 illustrates the instantiation concept overriding its superconcept relationship and only allowing instance to be the target concept of
instantiation. This technique prevents unnecessary duplication of linking relationships and allows generalisation from the superconcept level. The simplest way of resolving specialisation is to reproduce the common features of subconcepts.
s7~\7--- ;— — ' ' \ /relationship
( instantiation)
5. Product Model
5.4.5 INCLUSION AND EXCLUSION
The relationships between terminal concepts can be easily described, but the relationships between concepts involving subtyping are more complicated, especially those with abstract superconcepts. Overriding is one possible technique to avoid complex representation of non- trival relationship. In this section, we introduce two more notations to reduce the complexity as well as to resolve possible diagrammatic confusions. Figure 5.22 illustrates four complications that may occur. There is a composition relationship between concept B and a superconcept A, where B is the owner.
case 1 A2 B owns A1 or A2 case 2 case 3 A2 A2 B owns A or A1 or A2 inclusion:
B owns one of each A1 and A2
case 4 exclusion:B owns A but not A1 or A2 Figure 5.22 Four Cases of Possible Confusions
In case one, A is an abstract concept. B cannot directly own A, but it can own one of A’s subconcepts, that is either A1 or A2. If the cardinality is multiple, B can have any number of A1 or A2.
In case two, A is a concrete concept, so B can own one of A, A1 or A2. If it is a multiple cardinality, then B can have any number of A, A1 or A2.
In case three, the square box stands for inclusion. That is, B may own one of each A1 and A2. This technique eliminates all arrows from the whole concept to each subconcept components. If the cardinality is multiple, the effect will be the same as case one. The inclusion has no effect.
In case four, the bar is known as exclusion (or a cut), which stops inheritance going down to the subconcepts. In the example, B can own a superconcept A but neither subconcept A1 nor subconcept A2. If it is a multiple cardinality, the cut is still valid. That is B can have any numbers of A but not A1 or A2.
5. Product Model
Figure 5.23 gives an example for each inclusion and exclusion operation. In OMT, an
association may contain one sourceRole and one targetRole, both of these are inherited from the role concept. In contrast, in Ptech an eventTypePartition contains a number of eventTypes but they cannot be clockEventTypes or externalEventTypes. A cut on the target illustrates this effectively.
y role ^ asso c ia tio n ---&► sourceRole
targetRole V*... ...V
a. Inclusion applied on association to role Composition
clockEventType externalEventType
eventTypePartition eventType
b. Exclusion applied on eventTypePartition to eventType Composition Figure 5.23 Examples of Inclusion and Exclusion
The cut technique also applies to all the relationships described in section 5.3.3 apart from subtyping. This is one of the reasons that subtyping is denoted as a subconcept box inside superconcept box. Figure 5.24a illustrates the cut operation in a Ptech grouping relationship. The objectTypeExpansion group associates objectType as the host and objectSchema as an element, but derivedObjectType and externalObjectType cannot be expanded.
objectSchem a
externalObjectType derivedObjectType
objectTypeExpansion objectType
a. Cut Operation in a Grouping Relationship
event automaticTransition
transition
b. Cut Operation applies on the Source Concept Figure 5.24 Examples of Cut Operations