SysML Question: Why you should not connect ports with associations?

SysML Question: Why you should not connect ports with associations?

It is tempting to connect the small port boxes in the block definition diagram with solid lines (= associations) to express that the corresponding building blocks communicate with each other. That is forbidden! But why? This blog post gives you the answer.

The SysML forbids an association between ports and a good modeling tool should not allow that either. Therefore, I could create the following image only with the help of an image editor.

To understand why this is forbidden, I have to go further and explain the three levels of modeling of SysML.

Definition, Application, Objects
A SysML model distinguishes the three levels Definition, Application, and Objects. The SysML language provides model elements and diagrams for each level.

The block definition diagram, as the name implies, belongs to the definition level. Here things and structures are defined. These are, for example, blocks, associations, interface blocks. The definition of the elements is independent of its application. A block GPS sensor specifies characteristics of the sensor like a kind of data sheet in a catalog. This also includes the interfaces of the sensor, which are described in SysML with ports. This does not yet define where and how the sensor is used.

Associations are primarily used in system architecture modeling to define parts of a block (PartProperty). The association respectively the part property is modeled as a composition (black diamond). The association points to the definition of the part property (another block) and specifies the name and multiplicity at the end of the association. In the figure above, the left association defines the property a of type A by composition as part of the block Assembly. It is an application of block A.

At the application level, defined elements are used. In most cases, the elements of the application level can be recognized by the syntax name:Definition. For example, the parts of a block are named this way. Likewise the ports, which are an application of interface definitions (InterfaceBlock).

The parts or ports are connected in the internal block diagram with connectors. They look exactly like an association (solid line), but they are another model element and also mean something different. The association is defined as “An association assigns a semantic relationship that can occur between typed instances. “. And the connector as “A connector commits that between two or more instances.” That sounds initially very similar. The specification therefore explicitly provides a delimiting explanation: “In contrast to Associations, which specify links between any instance of the associated classifier Connectors specify links between instances playing the connected parts only.” The relationship specified by the connector applies only in the context of the block to which the connected parts belong.

The following figure shows the internal structure of the Assembly block from the above example in an internal block diagram. This time, the connection between the two ports is correct. It is a SysML connector and not an association.

In the area of behavior, a distinction is also made between definition and application. For example, the syntax name:Definition is found in the CallBehaviorAction, which is an application respectively call of another activity.

It is not relevant for answering the initial question, but for the sake of completeness a brief explanation of the third level: The object level represents objects (instance specifications) and object structures that describe a snapshot of a concrete system. This model level is used, for example, for the specification of test objects or objects for the simulation of a model.
The question “Why should ports not be associated with associations?” is already answered with these statements. In brief: Ports are elements of the application level and the association is a relationship between elements of the definition level. And that must not be mixed.

Unfortunately, the graphical representation tempts to associate ports in the block definition diagram with associations. A good practice is therefore to dispense with the graphical representation of ports in the block definition diagram and to list them only in the specially designed compartments:

In system architecture modeling, the association is primarily used to describe that a block contains parts (composition). The connector connects parts and ports to specify that they communicate with each other.

Has the initial question been clarified for you? If not, ask the remaining points as a comment to this post or send me an email:


3 Responses

  1. Chowa Choo says:

    I understand that connectors between ports are förbidden in Block Definition Diagrams, because ports are applictions of interfaces. My question is: Is it legal to define an association between two blocks. that are part properties?

    • Dear Chowa Choo,

      yes, this is legal (in a bdd). This Association can then be the type of the Connector between the parts in the ibd. However, if you want to connect two ports, no Association is needed, since the InterfaceBlock used as its type already implies an Association. Of course you could also make it explicit, by creating two associated InterfaceBlocks, but this is not common practice (unfortunately).

      best regards


  2. Avraham says:

    Seems to me to be like a good idea just never to show ports in a BDD diagram, and only to show them in an IBD diagram.

Leave a Reply

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