The Myth of the Association
The association is a strange model element. And many myths about the association are going around. For example, think of all the discussions about the meaning and difference of aggregation and composition. Did you know that the concepts of aggregation and composition have not much to do with associations?
I will not explain the association in detail in this blogpost. My primary intent is to get rid of the association. Ok, in some scenarios the association is necessary and useful. But it is not as important as it is presented in books and other publications about SysML (and UML).
But let us start in the beginning and I must nevertheless explain a little bit the concept of the association. It is a very complex element. Consider the following simple diagram:
Two blocks and an association from A to B. Most people interpret this diagram that block A has a property named “b” of type block “B”. That is more or less correct. In the model repository you will find 2 blocks, 1 association, and 2 properties. Regardless of whether the association has an arrow or not, there are two properties in the model.
Did you know that an association could own properties? The ownership of the property is shown by a small dot at the end of the association. Most modeling tools does not show the dot. The dot symbol means that the property is owned by the block on the other side of the notation. Without a dot the property is owned by the association. Interestingly the dot is very rarely used in practice, but in most cases the modeler wants to define properties for the related blocks with the association. There is a mismatch between the formalism of UML and the usage in practice.
Currently the dot notation is not allowed in SysML. The specification of the ownership is covered by the navigation arrow. That makes the specification vague in some scenarios. An open issue for SysML requests to allow the dot notation for SysML.
The following screenshot from a modeling tools depicts the data of the diagram above in the repository:
You can see that the property “b” is owned by block “A”. The other unnamed property without the dot-notation is owned by the association.
Some more strange things: at the beginning of this blogpost I have indicated that composition has nothing to do with association. The typical notation of a composition is depicted in the following diagram:
The property “b” is still owned by block A. The black diamond on the left side of the association defines the property “b” as a composite property – a so-called part property. In the previous diagram without the composition the property “b” is a so-called reference property. The composition feature is a property of the property “b” and is not defined at the association model element. A property has a property called ‘aggregationKind’ that could be none, shared (=also known as aggregation) and composite. In modeling tools you often find relationships called composition or aggregation relationships. These are shortcuts for properties with a special aggregation kind that are defined by an association model element.
Curiously enough the composite feature of a property is shown at the association and not at the association end where the property is defined, but at the other side.
Ok, back to the original idea: get rid of the association. The primary goal of modeling an association relationship in most cases, is the definition of the property. Indeed, if you model an association you define two properties and you are typically only interested in one of them. However, it is different the other way round. You can define a property without getting an association model element.
Independent of SysML a systems engineer thinks in block diagrams. She or he typically sketches the system of interest in a diagram of blocks with interfaces and links between the blocks. In SysML it is the internal block diagram with part properties, ports and connectors. The block definition diagram with the blocks and associations seems to be superfluous. At least for systems engineers which background is not software engineering. A software engineer is used to think in block definition diagrams more than internal block diagrams.
In any case you must define the blocks. But you do not need to model association relationships between them. Just define the part properties without a association. Your model has the same intended semantic with fewer model elements that must be managed.
You can directly model the internal block diagram and define – if not already done – the blocks in a simple block definition diagram or a table view. The following figure depicts a simple internal block diagram:
The blocks B and C, and A with the part properties are defined in a block definition diagram without any association:
In the model repository you only find the blocks, the properties, the connectors, and a port:
You do not need the association. It is an overhead. You should only spend the effort, if you need the block definition diagram view with the association relationship.
Unfortunately SysML has a constraint that all properties typed by a block must be defined by an association. As mentioned before I think that constraint is not necessary and leads to useless effort. I do not know any modeling tool that forces the constraint. So you can ignore it. Additionally there is an open issue against SysML to remove that constraint in a future version of SysML.
As mentioned before the association is useful in other contexts. For example, the use case diagram. The relationship between the actor and the use case is the association. Or to define domain blocks in a block definition diagram.