The Myth of the Association

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:

Association

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:

Association 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:

Composition relationship (association)

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:

SysML Internal Block Diagram

The blocks B and C, and A with the part properties are defined in a block definition diagram without any association:

SysML Block Definition Diagram

In the model repository you only find the blocks, the properties, the connectors, and a port:

SysML blocks repository

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.

 

7 Responses

  1. Hi Tim,

    Interesting post (as usual), but it seems (i) to go by to some modifications that the SysML spec requires (in order to simplify the use of associations) and (ii) at least that Magicdraw has not implemented some SysML specificities (simplifications) about associations, right? For instance, the ‘dot notation’ you mention in your diagrams is explicitly forbidden by the SysML 1.4 Spec

    8.3.1.3 UML Diagram Elements not Included in SysML Block Definition Diagrams
    […]
    An “X” on a single end of an association to indicate that an end is not navigable has similarly been dropped, a\
    s has the use of a small filled dot at the end of an association to indicate that the end is owned by the assoc\
    iated classifier.

    Next to that, I assume that you are aware that your suggestion to omit assocations violates the SysML 1.4 spec. See constraint [4] on page 53 of the spec:

    In the UML metamodel on which SysML is built, a Property that is typed by a block must be defined as an end of an association. (An inverse end of this association, whether owned by another block or the association itself, must always be present so there is always a metamodel element to record the inverse multiplicity of the reference.)

    Similarly, page 51 of the spec mentions some nice simplifications to the UML associations…

    Personally, I find that SysML has done a reasonable job in making associations simpler to use, and even in BDDs, in some cases (for instance when you want to model a concept as an association in one view, and a block with properties in another logical view), you cannot do without them…

    • Hi Klass,

      Thanks for your comment that reminds me that I have forgotten to mention that in my blogpost. I am not very pleased with the constraints and other “simplifications” of the association in the SysML. I do not think that it makes something simpler when adding exceptions.

      Regarding the dot notation I have already files an issue to clarify that better in the SysML specification.

      I cannot remember why we have added the constraint that a block typed property needs an association. I think it makes things unnecessary complex. I will check for that, too.

      In MagicDraw you can directly add a PartProperty to a block and it does not create an association. It makes modeling very smooth. I assume that other modeling tools have the same behavior.

  2. I think the rationale for this constraint is that a link would be underspecified without the Assocation. And for physical systems that is not acceptable.

    A Property owned by a Block and without Association also defines a link between an instance of the owning Block and an instance of the type of the Property. There is one important information missing: What is the allowed cardinality range for the other end?

    Keep in mind that a link between physical objects is *always* bidirectional. We can always navigate in both directions. When a cup is linked to a table, we can find the cup standing on the table and the table supporting the cup. At the same time neither the cup nor the table have a reference to the other, so both of them don’t own the property typed by the other Block. Therefore the correct model of this situation would be Association-owned navigable Properties on both sides.

    To make my point more clear: What would a Block-owned Property mean? Let’s look what it means in UML: Within the memory space allocated to one instance there is the memory address of another instance. Well, in physical Systems the memory would be the world. And no Block needs to know the geographical location of another Block in order to interact with it.

    Conclusion: Using Block-owned properties is not the natural way to deal with the real situation, but explaining the difference is also not easy. Therefore I think the SysML chose not to bother and exclude one possiblity. Non software engineers would not even understand what we are talking about.

    PS: Composite properties are a different kind. My argument doesn’t apply there.

    • Hi Axel,

      Without an association there is no link that could be underspecified. A part property without an association has exactly one owner and specifies itself its own multiplicity.

      • Hi Tim,

        I think what we mean by a link between two objects is, that they could interact. While a Link cannot get defined in a SysML object diagram without an Association, this doesn’t mean, that there is no link in the real world. This link can be specified by a Connector or by Properties, with or without an Association, or it could be not specified.
        Since a link in the real world is always bidirectional I would call a Model of it, that only specifies one end, underspecified.
        Maybe my assumption, that a real world link is always bidirectional is wrong. I didn’t find a non software example for an unidirectional link though.

  3. Rodney McDonell says:

    Interesting article, but i disagree that associations are superfluous on Block diagrams. Sysml does not dictate that you need an association (on a block diagram) for every connection (you have on a inner block diagram). SysML use heavily based around the idea of Definition and Use. I.e Define once, use many times. Associations such as refrence assocations and the related Refrence Assocation blocks, allow the SysML practitioner to define Assocations that have properties and/or structures that are applicable to many possibly very different connectors.

    There are many examples of this reuse in text books. One common example is modeling a connector that has many different pins. This may be modeled by use of a Refrence Assocation block which defines all the pins (ports) on both sides of a connection, and then in an inner block diagram may reuse the Type created by that Refrence Assocation and apply it to the connector where that type is required in any number of inner block diagrams. In this way, you do not need to specify the pins and individual connectors each time.

    • Tim Weilkiens says:

      Hi Rodney,

      I agree that it is useful to define association blocks to reuse the defined structure in several places. Although a simple association constrains connectors in internal block diagrams, I think, typically, the effort is not justified in relation to the advantage.

      Another point is the difference between model and diagram. If it is justified to model associations, you should think if it is sufficient to have this information in the model, or if you really need to spend the effort to layout the block definition diagrams. Alternatively, you can use tables and matrices to manage the model.

Leave a Reply

Your email address will not be published. Required fields are marked *