User Tools

Site Tools


This is an old revision of the document!


The Block-Port-Connector model is a specialization of the more abstract Hypergraph and Entity-Relation model.

The following generic relations have been introduced already: is-a, instance-of, conforms-to and constraints. There are two additional (i.e. more specific) relations that need to be introduced:

Relation Explanation Typical graphical representation Typical textual representation
contains # can be applied to entities and can be applied to relations
* this realizes hierarchical composition (nested composition) in a hierarchical composition (i.e. elements are enclosed by another element)
* the contained elements are not accessible (in contrast to elements in a collection)
* the contained elements cannot exist without the parent
* can be refined to composition association in UML
a nested box with solid border or a UML composition arrow contains(A,a,b,c)
has-a # can be applied to entities and can be applied to relations
* this realizes aggregation
* in aggregation, elements remain at the same level
* elements linked with has-a can exist independently
* can be refined to aggregation association in UML
a nested box with dashed border or a UML aggregation arrow has-a(A,a,b)

The generic entity is refined as follows:

Entity/Relation Model and Description Typical graphical
Typical textual
block Model:
* is-a entity
* possibly has-a property (or many)
* possibly has-a port (or many)
* possibly contains property (or many)
* possibly contains block (or many)
* possibly contains collection (or many)
* possibly contains connector (or many)
* possibly contains relation (or many)
the only interaction points of a block are ports
port Model:
* is-a entity
* has-a internal dock
* has-a external dock
it is the only interaction point over which a block can interact with other blocks;
when attached to a block, the internal dock becomes a private to the block (contains) and the external dock becomes public (has-a)
In textual representation, access to docks can be represented e.g. like internal-dock(Port-A), external-dock(Port-A)
dock Model:
* is-a entity
A dock is used to semantically differentiate between the “internal” and “external” sides of a port with respect to the port's parent block.
In a graphical representation, the internal dock and the external dock can be highlighted, for example by different colors (be careful, not to start an irrelevant activity in introducing such graphical notions into existing tools which cannot handle that).
connector Model:
* is-a entity
* connects ports (n-ary relation)
can connect ports as long as no block boundaries are crossed
In graphical representation, the connector itself is represented by a dot. With the connects-relation, star-shaped lines (connects-relations) originate from the dot in the center.
collection Model:
* is-a entity
* possibly has-a entity (or many)
* possibly has-a relation (or many)
A collection can group any combination of entities and / or relations. The enclosement formed by a collection is just a virtual one where the elements are openly accessible (in contrast to nesting).
A collection can pick any elements out of blocks ignoring block boundaries ⇒ this is particularly useful to specify modeling views
In the graphical representation, the dotted box can enclose entities and / or relations where you can cross the dotted line to “enter” the collection
connects Model:
is-a relation
links a dock of a port to a connector (binary relation)

There is a specific relation between the RobMoSys composition structures and the modeling views as is discussed on the next page. The important point at this level here is to provide a base-level that allows specification of both kinds. The specific part for specifying modeling views is the collection definition while all the other specifications are used to define the RobMoSys composition structures.

Please note that while blocks and ports are semantically different, depending on the current role-specific view with according level of abstraction, ports can contain additional structures and thus might appear as blocks on that detailed abstraction level (see service-definition metamodel).

See next

modeling:principles:block-port-connector · Last modified: 2017/07/27 14:31