User Tools

Site Tools


modeling:principles:block-port-connector

Block-Port-Connector

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 elements are enclosed by another element
* contains is topology
* the contained elements are not accessible/visible (in contrast to elements in a collection)
* the contained elements can or cannot exist without the parent (depending on the context)
an arrow with a diamond (filled with black color for ownership or white color for no ownership) contains(A,a,b,c)
contains(B,m,n)
has-a # can be applied to entities and can be applied to relations
* this realizes aggregation
* has-a is mereology
* in aggregation, elements remain at the same level
* elements linked with has-a remain aceesible/visible
* the contained elements can or cannot exist without the parent (depending on the context)
an arrow with a diamond (filled with black color for ownership or white color for no ownership) has-a(A,a,b)

The generic entity is refined as follows:

Entity/Relation Model and Description Typical graphical
representation
Typical textual
representation
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)
block(block-A)
Description:
the only interaction points of a block are ports
port Model:
* is-a entity
* has-a internal dock
* has-a external dock
port(Port-A)
Description:
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)
Comment:
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
dock(Dock-A)
Description:
A dock is used to semantically differentiate between the “internal” and “external” sides of a port with respect to the port's parent block.
Comment:
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)
connector(connector-A)
Description:
can connect ports as long as no block boundaries are crossed
Comment:
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)
collection(collection-C,k,l,m,n)
Description:
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
Comment:
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
connects(connector-A,external-dock(Port-A))
Description:
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: 2019/05/20 10:49
http://www.robmosys.eu/wiki/modeling:principles:block-port-connector