Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)
5. Modelling Rules for Data
5.1. Overall
ID | Rule |
---|---|
DMR-001 | In order to ensure consistency within the project, British English is to be used at all times. Refer to the Cambridge Dictionary for further information. |
DMR-002 | Images and/or diagrams that are to be used in the descriptions of Capella model elements shall be created and maintained on the following Confluence page: |
DMR-003 | Description Links for model elements shall be used in all model element descriptions. E.g. if a certain description refers to a defined model element, the name of the model element being referred to shall be copied (as a Description Link) and pasted (as a Link) in the corresponding description field. Exception: model elements defined as abstract concepts or terms, which serve solely as a form of documenting information external to the project, shall be excluded from this rule. |
5.2. Data Model Elements
5.2.1. Guidance
ARCH.M.050 Method for definition of data model
- Method for definition of data model
- Best practices to maintain a consistent data model
- Data modelling with capella (what is possible)
5.2.2. General Rules
DAT-003 | Units and physical quantities are always defined and edited on the operational level. Rationale: To ensure that they can be reused at all levels and that there is only one location for these standard definitions. |
DAT-004 |
|
DAT-005 | It is not allowed to have identical data model elements on multiple levels. EXCEPTION: when working together in a cooperation project in which there is no operational level model content. In the model where there is model content at the operational level it is allowed that there is identical data at the operational level and system level. But the realisation relationship must then be set correctly and the name of the operational level data model element must then end with _O. For example, the system of interest does not have an operational level, while another system of interest project does. In such a case, it is permissible for the system of interest to utilise operational-level data from the other system of interest on its system level, since in this case the data are not being duplicated. However, in the case that the two projects are merged in the future, realisation relationships will have to be created between the previously-created data on operational level and the newly-merged data on system level. It must also be ensured that the names of the data elements are provided postfixes corresponding to their levels. Note: identical refers to naming conflicts and identical content properties. |
DAT-009 | All data model elements at operational, system, and logical levels represent abstract application layer data only (that is, data connected with the functionality of the system). EXCEPTION: constraint system interface see ARCH.M.030 Method for definition of interfaces. |
5.2.3. Terms
ID | Rule |
---|---|
GT-010 | Terms are always created and edited on the Operational Analysis level and are modelled in Capella as Classes. |
GT-011 | Terms does not have relationships/associations to other terms. |
GT-020 | Naming convention for a class name in the terms::
|
5.2.4. Data Object
5.2.4.1. Data Object Class
DOC-010 | Where a class realises a higher level class, there shall exist a realisation relationship between realising class and realised class. Note: see DAT-004 and DAT-005 for additional rules. |
DOC-020 | Naming convention for a class name:
|
DOC-030 | Each class has an adequate description. |
DOC-040 | In the case of modelling a super-class the following two things are forbidden:
|
DOC-050 | A class property is either an attribute directly typed by one of the following, listed in order of preference:
OR is derived from a navigable role through an association link. |
DOC-060 | Naming conventions for Properties (Roles/Attributes) names:
|
DOC-070 | Each property has an adequate description. |
5.2.4.2. Simple Types
ID | Rules |
---|---|
DOS-020 | In case of defining Simple Types choose one of this Types:
Note: Simple Types can not have properties. If you need them please define Structured Types. |
DOS-050 | Naming conventions for Simple Types:
Guidance for the usage of units when defining physical quantities:
|
5.2.4.3. Structured Types
ID | Rule |
---|---|
DOT-040 | In case of defining a Structured Type the chosen Class must be specified as Primitive. Note: Concept of primitive class corresponds to that of DataType in UML, whose instances have no identity, unlike for classes. Guidance: the data object exchanged between an external actor and the system may vary:
|
Naming conventions for Structured Type:
| |
DOT-060 | Each Structured Type has at least one property. |
5.2.5. Exchange Item and Exchange Item Element
XGI-001 | Naming Convention for Exchange Item: lower_case - all letters lowercase, words separated by underscores. Guidance/recommendation: names of exchange items should end with one of the following nouns:
Note: where message sets are defined in standards, and not all messages are used, ONLY the used messages need to be modelled; there is no need to spend extra time capturing Exchange Items for messages that are never used. |
XGI-002 | Each Exchange Item is defined by a communication mechanism:
|
XGI-003 | Naming Convention for Exchange Item Element:
Guidance/recommendation: names of exchange item elements should begin with one of the following participles:
Note: An Exchange Item Element can be compared to a property/attribute of an exchange item so the name should take this into account. |
XGI-004 | Where the data object is NOT specific to that Exchange Item, the "Is Composite" box is UNCHECKED for an Exchange Item Element. |
XGI-005 | Each Exchange Item Element links Exchange Items to data object. Guidance: the data object exchanged between an external actor and the system may vary:
|
XGI-006 | The cardinality of each Exchange Item Element is defined correctly. Note: by default, the cardinality is set to 1; that is, a Exchange Item has one field of the specified type. Some Exchange Items need to be defined such that the cardinality is variable depending on the number of Types being transmitted. |
XGI-010 | Where an exchange item implements or realises a higher level exchange item, there shall exist a realisation relationship between realising exchange item and realised exchange item. Note: see DAT-004 and DAT-005 for additional rules. |
5.2.6. Data Rationale
ID | Rule |
---|---|
DRA-010 | Rationales should be created using the model element requirement (type rationale). |
DRA-020 | The description for the rationale is inserted in the field "text" in Capella. |
DRA-030 | Each rationale has at least one outgoing link to a target model element using the relation type "justifies". |
DRA-040 | Basically, all data model elements can be justified by a rationale. At least the following data model elements should be justified:
|
DRA-050 | If a rationale is expanded by an artefact, e.g. a trade study result or other type of supporting artefact, the rationale text shall include a reference to the expanding artefact, including (where possible) its document number and a hyperlink to the artefact's current version. |
Guidance:
ARCH.M.110 Method for definition of rationales
5.3. Diagram Types and Viewpoints
5.3.1. General Rules
ID | Rule |
---|---|
GRV-010 | Each diagram shall be named according to following convention: [<Capella diagram type abbreviation>][<Viewpoint number>] <Subject of view> [<Viewpoint name>] Capella diagram type abbreviation: abbreviation indicating the type of the diagram with the following possible values:
Viewpoint number: number given to the viewpoint based on ARCH process Subject of view: either a <model element> or <free text>
Examples:
|
GRV-030 | If a note is used on a diagram, it should include the name of the person responsible and the date of creation. Note: if after the design review there is still a need for the note, the name can be removed. |
5.3.2. AMOD-025 Abstract concepts
025-040 | Relationships between concept classes are logically consistent. Note: Permitted relationships are association, composition, aggregation, and generalisation. These relationships in Capella have their usual meanings as defined in UML/SysML. |
025-060 | The navigability of all associations is set to match the intended direction of the association (and therefore should be consistent when the tuple is read as a sentence in English, in the direction of the association). Note: this is a workaround that is not semantically correct, but is done because Capella does not provide the ability to set a direction of an association separately from its navigability. |
025-070 | The filters on the diagram are set to display the names of associations. |
025-071 | The filters on the diagram are set to hide the properties. |
025-072 | The filters on the diagram are set to hide the role names. |
025-080 | The multiplicity of associations is set appropriately at both ends. |
025-090 | When a class is modelled as part of more than one class, the aggregation type is always "aggregate". Guidance: This is achieved by editing the properties of the aggregation, and has the effect that the diamond end of the association is hollow. |
5.3.3. Data Object Definition Class Diagram
5.3.3.1. General Rules
COB-030 | Where a specific type is defined the types should be visible on the definition diagram to increase understanding. |
COB-040 | Relationships between class classes are logically consistent. |
COB-050 | The filters on the diagram are set to hide the names of associations. |
COB-060 | The filters on the diagram are set to show the properties. |
COB-070 | The filters on the diagram are set to show the role names. |
COB-080 | The multiplicity of associations is set appropriately at both ends. |
5.3.3.2. AMOD-105 Operational data objects [O.CDB]
105-010 | Instances should be structured in line with the structure used for the abstract concept viewpoint (so that there is generally one instance per instance of AMOD-025 - unless it is necessary to split the views up for readability). |
5.3.3.3. AMOD-112 System data objects [S.CDB]
112-010 | Instances should be structured in line with the structure used for the abstract concept viewpoint (so that there is generally one instance per instance of AMOD-025 - unless it is necessary to split the views up for readability). |
5.3.3.4. AMOD-091 Logical data objects [L.CDB]
091-010 | Instances should be structured in line with the structure used for abstract concept viewpoint (so that there is generally one instance per instance of AMOD-025 - unless it is necessary to split the views up for readability). |
5.3.3.5. AMOD-086 Interface layer data objects
ID | Rule |
---|---|
086-010 | All data objects are shown which are used in the exchange items of the considered interface layer. |
5.3.4. Exchange Item Definition Class Diagram
5.3.4.1. General Rules
MSG-010 | The <free text> for exchange item definition diagrams shall be the capability name. Note: For further details on diagram titles see General rules. |
5.3.4.2. AMOD-110 Operational exchange items [O.CDB]
ID | Rule |
---|---|
110-010 | There is at least one diagram per operational capability. |
110-020 | All exchange items (including all exchange item elements and their data objects) are shown which are allocated to an interaction which connects two activities of interest for for the capability. |
110-030 | Data objects that itself does not have a exchange item element link to an exchange item, but are the type for an attribute are shown as well on the diagram. |
5.3.4.3. AMOD-113 System exchange items [S.CDB]
ID | Rule |
---|---|
113-010 | There is at least one diagram per system capability. |
110-020 | All exchange items (including all exchange item elements and their data objects) are shown which are allocated to an functional exchange which connects two functions of interest for for the capability. |
113-030 | Data objects that itself does not have a exchange item element link to an exchange item, but are the type for an attribute are shown as well on the diagram. |
5.3.4.4. AMOD-092 Logical exchange items [L.CDB]
ID | Rule |
---|---|
092-010 | There is at least one diagram per realised capability. |
092-020 | All exchange items (including all exchange item elements and their data objects) are shown which are allocated to an functional exchanges which connects two function of interest for for the capability. |
092-030 | Data objects that itself does not have a exchange item element link to an exchange item, but are the type for an attribute are shown as well on the diagram. |
5.3.4.5. AMOD-094 Interface layer exchange items
ID | Rule |
---|---|
094-010 | All exchange items (including all exchange item elements and their data objects) are shown which are allocated to a functional exchange which connects two interface layer functions. |
094-020 | If the exchange items are related to a interface, there is at least one diagram per interface. |
Color legend :
Meaning | Color |
---|---|
Naming convention |