Legal information

Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)

Data modelling with capella (what is possible)

RCAMT-640 - 01_2022_3 Create a documentation on data modelling with capella (what is possible) Finished

Guidance what is possible in data modelling in capella


In order to describe un-ambiguously what is exchanged between functions, activities, components, and external actors, a specific formalization of data used in the system is usually performed.

To facilitate the understanding of the elements used in data modelling (for example, the picture on the side), this chapter summarises what is possible in Data modelling with capella.

Info

There are two kinds of classifiers: data types (simple type and structured type) and classes. Instances of a data type are identified only by their value, means that data type with the same value are considered to be equal instances.

Definition of data concepts thanks to a CDB (Class Diagram Blank)

Simple type

why create this?

To identify type with simple data (without properties) 


There exist different kind of simple types:

  • NumericType: represents numbers (float or integer)
  • PhysicalQuantity: represents a physical dimension and is associated to a unit (meter, gram, volt, etc.)
  • Enumeration: represents possible values which are enumerated (can be defined with EnumerationLiteral)
  • BooleanType: represents named values which hold the semantics of truth or falsehood (can be defined with BooleanLiteral)
  • StringType: represents a sequence of characters


Definition of simple types thanks to a CDB (Class Diagram Blank)

Defined with

CDB (Class Diagram Blank)


Warning

Simple types cannot have properties. If there is a need of structured data types we have to create structured type

Structured type

why create this?

To identify type with complex data because they can have properties and can be used as type of a property in another class or in another structured type.

Capella Info

To create a structured type we have to create a class, but then we have to specify that this class is “primitive”.

Definition of a structured type thanks to a CDB (Class Diagram Blank)

As data type, this classifier will have no identity in the context of the system and cannot be the source or target of association links. Two instances of this class with the same property values cannot be distinguished.

Example

A date does not have any intrinsic identity

Defined with

CDB (Class Diagram Blank)

Class

why create this?

To specify a classification of objects thanks to the features that characterize the structure and behavior of those objects. Classes have properties and objects of a class must contain values for each property of that class, in accordance with the characteristics of the property (type, multiplicity, etc.).

Property

A property can be held directly by a class (this is called an attribute) or can be derived from a navigable role through an association link (see section 3.3.2).

The principal characteristics of an attribute are:

  • Type: come from other classes or simple/structured types.
  • Key: It means that the values of this property enable to distinguish different instances of the class. It is noted with a "&" prefix.
  • Cardinality
  • Min/Max values



Relationship between diagrams and activity exporer

Characteristics of an attribute

Attributes of a class with different characteristics


Information about association between classes

Before identifying the different possibilities of interactions between classes, it is worth recalling some characteristics.

  • Role: define the relationship end (most of the time it is the name of the pointed class)


  • Navigability: means that the instance of the pointed class is accessible from the class of the pointing instance. Both sides of a link may be navigable, but most of the time there is only one side or no side at all. An open arrowhead on the end of an association indicates if the end is navigable.


  • Name: it is possible to add a name for the relationship.

Be careful, navigability (arrows on associations) and direction of the verb naming the association are completely distinct notions

  • Cardinality


Characteristics of a relationship


Association relationship between two classes thanks to a CDB (Class Diagram Blank)

Types of relationship between classes

  • Association: represents a relationship shared among the instances of two classes. (represented by a link between classes)


  • Aggregation: is a variant of the "has a" association relationship (represented by a white diamond)


  • Composition: is a form of aggregation that requires a part instance to be included in a composite. If a composition is deleted, all its parts are normally deleted with it. Be careful if there are multiple compositions in which the same class is involved as a part. (represented by a black diamond)


  • Generalization (also called realisation relationship): where a generalization relates a specific class to a general class, each instance of the specific class is also an instance of the general class. Therefore, properties specified for instances of the general class are implicitly specified for instances of the specific class. (represented by a hollow triangle).

Different kind of relationships between classes with a CDB (Class Diagram Blank)

Defined with

CDB (Class Diagram Blank)

Abstract class

why create this?

To have conceptual entity for understanding the foundations of the project

An abstract class is a class that cannot be instantiated; it is expected to be specialized by one or several concrete classes thanks to generalization links. Be careful, all properties of the generalized class must be meaningful for all the subclasses.

Capella Info

To create an abstract class we have to create a class, but then we have to specify that this class is “abstract”. Abstract class names are displayed in italics in diagrams.

Definition of an abstract class with a CDB (Class Diagram Blank)

Defined with

CDB (Class Diagram Blank)

Package


why create this?

To group elements, and provide a namespace for the grouped elements. A package may contain other packages (packages are shown as rectangles)

Defined with

PD (Package Dependencies)

Definition of the communication model


It is possible to link the elements defined in the previous chapter to the other elements of the model: thanks to "communication elements".
By defining the two new objects present in the figure below. We will be able to use classes and other data types in the exchanges between the functions and/or between the components.

Definition of exchange items with a CDB (Class Diagram Blank)

Use of data elements in an exchange between functions thanks to a SAB (System Architecture Blank)

Exchange items

why create this?

Help to structure ports/exchanges in order to organize exchanged data and carry a requested communication principle. It defines a communication mechanism.

Data are exchanged between functions or components according to standard communication patterns.

General information of exchange items

  • Exchange mechanism: specify how its content is actually exchanged. Different possibilities are possible like EVENT, FLOW, SHARED DATA and UNSET.


  • Exchange item elements: specify the reference to data model elements (classes, data types). The Exchange item only owns this exchange item element, and the structure of the exchange item is completely defined by the type of the exchange item element, and its features. More information about this object below.

Characteristics of an exchange item

Exchange item definition thanks to an IDB (Interface Diagram Blank)


Exchange mechanism

  • EVENT: asynchronous mechanism, structured data sent from one component or function and received by a unique receiver (unicast), a defined set of receivers (multicast) or an undefined set of receivers (broadcast).


  • FLOW: continuous or discrete flow of information or material (fluid, electric power, etc.) produced by a component or a function and consumed by one or several others.


  • SHARED DATA: Two cases of application, either shared and accessed by several components (writers or readers). Or either exchanged through a Publish/Subscribe mechanism.


  • UNSET: the communication mechanism applying to a given exchange item might not be known yet

Exchange items with different kind of mechanisms thanks to an IDB (Interface Diagram Blank)

Defined with

IDB (Interface Diagram Blank) or CDB (Class Diagram Blank)

Exchange item elements

why create this?

Allow to reference a data model element (classes, data types) to an exchange item.

Exchange items are structured through exchange items elements in the same way as classes are structured in properties. These elements are in turn defined by classes, structured types and simple types.

General characteristics of exchange item elements

  • Composite: specify that the exchange item is a container for the object contained in the element. In other words, where the data object is NOT specific to that exchange item, the "Is Composite" box is UNCHECKED. (represented by a black diamond)


  • Type: specify which data model element (classes, data types) is involved in the exchange item


  • Cardinality


  • Referenced properties: in case of structured type or class we can select specific properties for the exchange item element. (represented with brackets)

Remark

Do not forget the inherited properties! For example the train has the currentSpeed property because it is an inheritance of vehicle class.

Exchange item element characteristics thanks to a CDB (Class Diagram Blank)

Defined with

CDB (Class Diagram Blank)