Methodological Recommendations

Data Model and Arcadia Abstraction Levels

There are several different ways to organize data modelling in Capella.

In any case, you have to define precisely what your objectives for data modelling are.

For instance do you want to describe domain concepts only, or do you want to use the data model for code generation purposes? Also, do you need a complete functional analysis with Component Exchanges and Functional Exchanges, or can you live with just Interfaces on Components without any functions?

A common practice, but not a mandatory one, is to describe all external data at System Analysis level (starting possibly at Operational Analysis), and to describe further internal data at Logical Architecture and/or Physical Architecture levels.

With Capella, you are used to transition Actors, Functions, etc. from one Arcadia level to the next one down, and you cannot refer to a System function at Logical Architecture level, for instance. It is not the same with data: from a given level, you can refer to any Class, Basic Type, etc. defined in an upper level.

The main idea is to facilitate maintenance: if classes and types evolve at a given level, as we only reference them, there is nothing special to do. On the contrary, if we choose to transition manually the data, which is possible in Capella , we will need to update all lower levels as soon as there is a modification at a higher level. So the common recommendation is not to transition data, unless you really need to separate very strongly the different levels of a specific model.

Data Normalization


Attribute types are primitive classes. Value of each attribute is atomic, there is no embedded class.


The model shall be 1NF and every property (attribute or association) that does not belong to the key structure shall be dependent on the complete key: the key is the smallest key for the properties of this class.


The model shall be 2NF and there is no transitive dependence: X -> Y -> Z

A property (attribute or association role) �Y� is functionally dependent on a group of properties �X� = (X1, .., xn) if and only if its value is by nature determined as soon as the value �V� = (V1, .., Vn) from group �X� is known. We note X - >Y.

Contrary to preconceived ideas, in most cases, only one 3NF model exists.

More precisely, the greater the degree of normalization is required, the more the possible interpretations of the model are reduced.

Validating the interface and data model

A large number of rules checked by Capella apply to the Interface and Data Model. You should rely on them to maintain your model and ensure its consistency and completeness.

For instance, in the Design Well-Formedness category, there is a big Data group:

There is also an Interfaces group:

Some rules are nevertheless still missing and get progressively integrated on user suggestion.

Basic Best Practices

The model content and diagrams should be homogeneous between model contributors.

Hence define the rules to be applied by each contributor:

Before creating a new Type, check that it does not already exist!

Take care: model checking can detect duplicates only if they have the same name. And remember also that two elements created in different packages are considered different, even if they have the same name.

Naming Conventions

Capitalize the first letter of class names.

Begin property names with a lowercase letter. Multi-word names are often formed by concatenating the words and using lowercase for all letters except for upcasing the first letter of each word but the first.

A possible rule for Primitive Classes and Simple Types is to prefix their name with �T�, in order to easily distinguish them from a standard class.

Package Structuration

A package should never contain more than 20 elements. If it the case, break it down into sub-packages.

Diagram Layout

In the CDB, a good practice is to use only rectilinear line styles.

Put generalized classes above specialized ones.

Do not clutter your diagrams: not more than 12 classes or types in the same CDB.

Using color codes on diagrams

This guideline applies to any diagram and any type of model.

In case color codes are really needed to identifies specific concerns visually on a diagram, this should be managed in a formal way :

� Identifying formally a property or property value which holds the semantic concept under consideration,

� Developing a viewpoint that will ensure unicity and consistency of this attribute across all model elements,

� Using this same viewpoint to manage the color that is displayed on a diagram.

Using viewpoints will prevent from manual maintenance of the color codes which would be likely to generate inconsistencies and errors with critical impacts.

Document and annotate the model!

Do not forget to document extensively your modeling elements and diagrams.

You can use both rich text and links to diagrams, external files, etc.

This should be done via the Description tab: