Advanced Constructs

These constructs enable the modeler to go further, but are less important for beginners. They require more time and practice to be mastered.

Class and Type advanced features

Note that most of these advanced features are also available for Properties, Associations, Echange Item Elements, etc.


When the type is declared discrete, it means that it defines non continuous or separable values. Examples of common discrete types are Boolean and Enumeration. This quality is required for a type used as a discriminant in a [ union] class.


Specifies whether the property or association is derived from other model elements such as other properties, associations or constraints. The default value is false.

For instance, a common derived property is the age of a Person, derived from the birthDate. The notation of a derived property is “/ derivedProperty”.

A good practice is to explain how the property is derived within the description field of the property or its summary.

Association roles can also be derived as in the following example. A person may own several cars. As each car contains 4 wheels, the person also owns all the wheels!


For multivalued elements (Max. Card > 1), this feature specifies whether the values in an instantiation of this element are sequentially ordered (Default is false).

For instance, when you play chess, a game consists in a sequence of moves:

If the element is specified as ordered (i.e., isOrdered is true), then the set of values in an instantiation of this element is ordered. This ordering implies that there is a mapping from positive or null integers to the elements of the set of values. If an element is not multivalued, then the value for isOrdered has no semantic effect.

If the element is specified as unordered (i.e., isOrdered is false), then no assumptions can be made about the order of the values in an instantiation of this element.

When one or more ends of the association are ordered, instances of association (links) carry ordering information in addition to their end values.


For multivalued elements (Max. Card > 1), this feature specifies whether the values in an instantiation of this element are unique (Default is false in Capella, although it should be true).

When isUnique is true, the collection of values may not contain duplicates. This is the most common case, as in the next figure (A person may own several cars, which are all different!).

When one or more ends of the association have isUnique=false, it is possible to have several links associating the same set of instances. In such a case, links carry an additional identifier apart from their end values. For instance if one wants to record a log of user connections, and count the number of times a specific user logged in during a specific duration, isUnique should be false. In this case, an additional attribute (such as connection time) may be needed.

Another simple example is shown on the next figure. In the game of chess, a game is a sequence of moves, involving one chess piece going from one square to another one. Several different moves may involve exactly the same piece and the same squares.

In combination with the feature [ isOrdered], the following table (from UML 2.4 specification) indicates pertinent collection types:

We can add that these two features are particularly important for code generation, but much less for pure system engineering modeling.

Is Final

If a type is marked as isFinal, then it cannot be any longer specialized by any sub-type.

Take care: if a type is marked as isFinal, and you still create a sub-type, there is no error or even warning produced by the model-checking tool.

Is Read Only

If a property is marked as readOnly, then it cannot be updated once it has been assigned an initial value (Default is false).

For instance, the birthdate of a Person is normally readOnly, unlike the age or weight.


Numeric, String and Enumeration types can be defined with a pattern which specifies the lexical space for their literal values. The syntax for expressing pattern is that of regular expressions in Java.

By default (when the pattern field is left empty in the type editor) a numeric type with kind:

When running the validation tool, if any literal does not conform to the pattern defined for its type an error is raised.


This feature comes from UML and object-oriented languages.

VisibilityKind is an enumeration type that defines literals to determine the visibility of elements in a model:


This field indicates the super-types (or generalized types) of the current type. It is empty by default.

As soon as a Generalization relationship is established, the “Super” field is automatically filled, as we saw in § [ Generalization]. Take care that this field can be edited. For instance, if you remove the Vehicle super-class from the Car Properties sheet, it deletes the generalization relationship and modifies the underlying model!

It is possible to allow multiple inheritance to define several super types.

Be careful: this action is not recommended. That is why it is not the default option, for it has different meanings depending on the targeted technology (e.g. with respect to late binding and overloading), it is not systematically supported, and it makes automatic processing of models a lot more complex.


An Expression is a formula that yields values when evaluated in a context.

Unary Expression

A Unary Expression is one specific kind of Expression consisting of one Operator (+, -, not, or, etc.) and exactly one Operand. The Operand can itself be an Expression.

We can for instance create a Factorial Unary Expression to calculate the factorial of any interesting value.

Binary expression

A Binary Expression is one specific kind of Expression consisting of one Operator (+, -, not, or, etc.) and exactly two Operands. Operands can themselves be Expressions.

Let us give a simple example with an expression calculating the total number of satellites in the constellation :

It is then possible to create a [ Reference] from the Expression, and to use this reference for association cardinalities:


A Collection is a data modeling construct allowing the definition of sets of elements.

To properly define a Collection, you have to choose the type of its elements. It can be a class, a complex type or a simple type. Min and max cardinalities should be indicated and they appear in diagrams.

Collections can be indexed. The type of an index should be discrete. Very often, collections are not indexed. The implicit index is then an Integer. If the collection has one or several indexes, the cardinalities should be consistent with the product of the index cardinalities.

For example, a chess board consists in exactly 64 squares, indexed by the couple (column, row).

Collections can be Sequences or Arrays (note that Capella does not offer yet set or bags, for instance). This distinction is closely related to the Interface Definition Language (IDL) constructs from OMG:

Note that Collections are more design concepts than analysis concepts. To model domain concepts collections, it is often sufficient to use the cardinality adornment on an association, possibly with the “ordered” keyword.

Cardinalities of Exchange Item Elements can also stbe used to prevent creating unnecessary Collections in the Data Model.

In the example above, the Exchange Item Element dci with a [0..24] cardinality prevents from creating an unnecessary Collection of Images ( CollectedImages) in the Data Model.

Union / Variant

Unions and Variants are advanced structures that can take different forms according to the values of a Discriminant.

The first thing we have to define on the Union is which UnionProperty will be the discriminant. We have to create an [ Enumeration], and type one UnionProperty by this Enumeration, and specify on the Union that we want to use it as a discriminant.

Let us give a simple example: according to a Security Policy, either normal or protected, employees will just need a name or an additional password to ask for a printing job.

We just have to specify two new UnionProperties, of types Login or ProtectedLogin, and we can for each of them define the pertinent Qualifier.

These constructs are mainly used in relation with software programming languages. For instance, in the Interface Definition Language (IDL) from OMG, a union is essentially a group of attributes, only one of which can be active at a time, according to the discriminant. A union saves memory space, because the amount of storage required for a union is the amount necessary to store its largest attribute. And Ada discriminated records are very similar to Capella variants.

Differences between Union and Variant are the following:

Differences between OMG/IDL and Capella /Union are the following:

Differences between ADA/discriminated record and Capella /Variant are the following:

Values and References

Values are instances of classes and data types and allow defining fixed data values. There are named values and anonymous values. Only named values can be reused to specify other model elements, such as [ cardinalities], [ default value], [ null value], [ min/max], [ length].

Simple Values

Simple values were explained in the Basic Constructs chapter:

Complex Values

Complex Value is the valuation of a structured element (for example, [ Class] or [ Union]). It contains one Value Part per Property owned by the structured element typing the Complex Value.

A Value Part is thus a valuation of one specific Property of the structured element. The type of the Value Part is the same as the type of the Property.

Collection Values

Collection Value is the valuation of a [ Collection]. It corresponds to a succession of Values for the type of the Collection.


Unlike Literals, References (Numeric, String, Expression, Enumeration, Boolean, Complex Value) allow defining Data Values related to other Data Values.

A Reference Data Value can target another Reference Data Value, A Literal Data Value or a Class Property.

Modeling Accelerators

Exchange Items Propagation to Function Ports

Effect: If an Exchange Item is conveyed by a Functional Exchange linking two Function Ports, this accelerator will also associate it to each Function Port.

This is interesting mainly when you want to get an autonomous specification of inputs/ outputs for each Function, via its owned ports.

Interface Generation from Allocated Functions

Effect: Analyze the Component Exchanges, the Functional Exchanges they carry and the Exchange Items associated to the Functional Exchanges to generate a set of [ Interfaces] between Components.

Example: Two components, three Component Exchanges, four Functional Exchanges associated to Exchange Items.

Result of the generation of Interfaces: One Interface is created per Component Exchange. All Exchange Items coming from different Functional Exchanges are aggregated in the same Interface.