Other Block Relationships

Blocks are the key structural elements in the SysML and can participate in a variety of relationships, some of which have been discussed in earlier sections of the Guide while we were discussing Associations. There are a number of other relationships that can be used when defining Blocks.

Generalization a Relationship of Family

In an earlier section we spoke of the Part Association being the strongest type of Association relationship, but there is another relationship - the Generalization - which is also very strong and essentially is used to model the fact that Blocks (and other Classifiers) belong to the same family. The word 'classifier' comes from our natural languages, such as Chinese and Thai, that have an abstract way of classifying or grouping classes of nouns that have similar characteristics; for example, a belt and a road are long thin things, whereas a berry and a ball are round things. So too with the SysML, the Generalization relationship is used to classify things and the structure can be an arbitrary depth. In many ways it is more natural for engineers to read the relationship in reverse and say something is a specialized version of something.

Enterprise Architect allows an engineer to create these classification hierarchies for Blocks, Value Types, Signals, Interfaces, Activities and more. A diagram typically contains a single family.

The relationship can be drawn by first selecting the 'Generalization' icon in the Toolbox and then dragging-and-dropping from the more specialized element to the more generalized element. Alternatively this can be done using the Quick Linker.

When a Block participates in a generalization hierarchy and has a number of specializations, the connectors emanating from the Block can become untidy. Enterprise Architect provides a mechanism to change the line style to any one of a number of styles, but probably the most useful style is the Vertically-oriented Tree style, which groups the heads of the relationship together and allows their tails to be aligned in parallel.

One of the useful language mechanisms that results from Generalization is for the specialized elements to inherit the structural and behavioral features from the generalized element. So far in the example diagrams the engineer has chosen not to display these inherited features, but they can be set to be displayed using the compartments sections of the element's Property sheet.

The result will be that the specialized Blocks will display the attributes and operations that have been inherited from the parent Block. These will be shown grouped by the name of the parent Block. This mechanism is used extensively in software engineering but also is useful for the systems engineer where the specialized Block automatically inherits the features of its parent by virtue of being a 'member of the family'. Just as in a human family a specialized Block (child) can override the structural or behavioral features inherited from a parent.

Blocks belong to families base upon certain criteria, and this can be modeled using the Generalization Set, which is a mechanism used to define the basis for membership of a family.

Dependency

The Dependency is a useful but semantically weak relationship. It is the 'pawn' of the engineers' toolkit of relationships, often used early in the modeling process when the details of the relationships between system elements have not been analyzed or are simply not known. It models the fact that the element (Client) at the tail end of the relationship relies in some way on the element (Supplier) at the arrow-head end of the relationship. Novice modelers can be forgiven for drawing this relationship in the reverse direction, since anecdotally material is often thought to pass in the direction from the supplier to the client. Once the semantics of the relationship are understood and it is realized that the relationship does not say anything about the direction of flow, the mistake will not be made.

There are a number of types of dependency, all of which are supported by Enterprise Architect. The connector can be created by selecting the 'Dependency' icon in the 'SysML Block Relationships' page of the Toolbox and then clicking on the client (tail end) element and dragging the cursor across to the supplier (arrow-head end) element. The connector can also be created using the Quick Linker arrow at the top right corner of a selected diagram element. Once the relationship has been created, a stereotype can be chosen from the connector's Properties window to make the dependency more specific.  This screen capture shows all the available stereotypes, some of which are used between different types of element other than Blocks; for example, Packages and Requirements.

Allocating between Blocks and Activities

The Allocation relationship can be used in a variety of circumstances but it is particular useful for expressing a fundamental relationship between the two most canonical Behavioral and Structural elements, namely the Activity and the Block. This is similar to our natural languages, where a verb is meaningless without the presence of a noun that carries out the action described by the verb. This type of allocation is referred to as Functional Allocation, and the engineer bridges the divide between these two aspects of a system by finding a Block that can carry out the behavior described by an Activity.

In this diagram the engineer has created two functional allocation relationships that describe how the work specified in the Activity Verify Entrant will be carried out. One relationship targets the Camera System that is used to capture the vehicle's licence plate in order to determine if the particular vehicle has been authorized for entry. The other relationship targets the Card Reader Block that is used to determine that the card owner has a relationship with the Parking Station.