C.1 Intervening class and Association class
32.1563GPPFixed Mobile Convergence (FMC) model repertoireRelease 17Telecommunication managementTS
C.1.1 Concept and definition
Classes may be related via simple direct associations or via associations with related association classes.
However, in situations where the relationships between a number of classes is complex and especially where the relationships between instances of those classes are themselves interrelated there may be a need to encapsulate the complexity of the relationships within a class that sits between the classes that are to be related. The term “intervening class” is used here to name the pattern that describes this approach. The name “intervening class” is used as the additional class “intervenes” in the relationships between other classes.
The “intervening class” differs from the association class as the intervening class does break the association between the classes where as the association class does not but instead sits to one side. This can be seen in the following figure. A direct association between class A and C appears the same at A and C regardless of the presence or absence of an association class where as in the case of the “intervening class” there are associations between A and the “intervening class” B and C and the “intervening class” B.
Figure C.1.1-1: Various association forms
The “intervening class” is essentially no different to any other class in that it may encapsulate attributes, complex behaviour etc.
The following figure shows an instance view of both an association class form and an “intervening class” form for a complex interrelationship
Figure C.1.1-2: Instance view of "intervening class"
The case depicted above does not show interrelationships between the relationships. A practical case from modeling of the relationships between Termination Points in a fixed network does show this relationship interrelationship challenge. In this case the complexity of relationship is between instances of the same class, the Termination Point (TP). The complexity is encapsulated in a SubNetworkConnection (SNC) class.
Figure C.1.1-3: SNC intervening in TP-TP relationship
The SNC also encapsulates the complex behaviour of switching and path selection as depicted below.
Figure C.1.1-4: Complex relationship interrelationships
C.1.2 Usage in the non-transport domain
The choice of association class pattern or intervening class pattern is on a case-by-case basis.
The transport domain boundary is highlighted in the following figure.
Figure C.1.2-1: Highlighting the boundary between transport and non-transport domains
C.1.3 Usage in the transport domain
The following guidelines must be applied to the models of the “transport domain”.
When considering interrelationships between classes the following guidelines should be applied:
• If considering all current and recognised potential future cases it is expected that the relationship between two specific classes will be 0..1:0..1 then a simple association should be used
– This may benefit from an association class to convey rules and parameters about the association behaviour in complex cases.
• If there is recognised potential for cases currently or in future where there is a 0..*:0..* between two specific classes then intervening classes should be used to encapsulate the groupings etc. so as to convert it to 0..1:n..*.
– Note that the 0..1:n..* association may benefit from an association class to convey rules and parameters about the association behaviour in complex cases but in the instance form this can probably be ignored or folded into the intervening class
• In general it seems appropriate to use an association class when the properties on the relationship instance cannot be obviously or reasonably folded into one of the classes at either end of the association and when there is no interdependency between association instances between a set of instances of the classes.
An example of usage of intervening class is the case of the TP-TP (TerminationPoint) relationship (0..*:0..*) where the SNC (SubNetworkConnection) is added as the intervening class between multiple TPs, i.e. TP-SNC. Note that TP-SNC actually becomes 0..2:n..* due to directionality encapsulation.
Considering the case of the adjacency relationship between PTPs it is known that although the current common cases are 1:1 there are some current and many potential future case of 0..*:0..* and hence a model that has an intervening class, i.e. the TopologicalLink, should be used.
For a degenerate instance cases of 0..*:0..* that happens to be 0..1:0..1 the intervening class pattern should still be used:
– • Using the 0..1:0..1 direct association in this degenerate case brings unnecessary variety to the model and hence to the behaviour of the application (the 0..1:n..* model covers the 0..1:0..1 case with one single code form clearly)
– • An instance of the 0..1:0..1 model may need to be migrated to 0..1:n..* as a result of some change in the network forcing an unnecessary administrative action to transition the model form where as in the 0..1:n..* form requires no essential change.