Skip to content

Latest commit

 

History

History
317 lines (307 loc) · 12.3 KB

File metadata and controls

317 lines (307 loc) · 12.3 KB

Integrity


I_01 - Unnamed Association
This rule ensures that an association has a name.


I_02 - Naming conflicts check 2
NOTE: This constraint is replaced by "I_19 - Name conflict" and thus disabled by default. This rule checks that an element doesn't contain a naming conflict between different types of elements in the same package.


I_05 - Component Realization consistency
This rule ensures that Component Realization Realizations always have consistent Source and Target.


I_07 - Diagram Naming conflicts check
This rule checks that a diagram doesn't contain naming conflict with other diagrams of the same type.


I_08 - Naming conflicts check 1
NOTE: This constraint is replaced by "I_19 - Name conflict" and thus disabled by default. This rule checks that an element doesn't contain a naming conflict. Usually this means that two elements in the same container cannot have the same name, e.g. one cannot create two classes in a package and assign them identical names. Below we list the special cases: ExchangeItems Two exchange items that share a common container have conflicting names if both have the same name, and the order, number and type of their ExchangeItemElements is identical.


I_09 - Exchanges Naming conflicts check 1
This rule ensures that an element doesn't contain a naming conflict. This rule only applies to exchanges (Component Exchanges, Physical Links and Functional Exchanges) which have the same source (Component / function), the same target (Component / function) and the same name.


I_10 - Unnamed Element
This rule checks that an element has a name and does not contain a naming conflict. This rule does not check ExchangeItemAllocations and DataValues.


I_11 - Requirement ID check
This rule checks that all Requirements have a unique ID attribute.


I_12 - Function Realization
This test checks the realization consistency between functions.


I_14 - Functional Exchange Realization
This rule checks the realization consistency between functional exchanges.


I_15 - Component Exchange Functional Exchange Realization
This rule checks the realization consistency between Functional Exchanges and Component Exchange.


I_16 - Several Implementation/Use of the same interface by a component Check
This rule allows to ensure that a component cannot implement the same interface several times or use the same interface several times.


I_17 - Contexts minimal content check
This rule checks that context packages contain at least one component (the root component) of the correct level.


I_19 - Name conflict
This rule Finds name conflicts.
                    NOTE: This constraint include all Naming conflict detection and it is enabled by default.
This rule checks that an capella element doesn't contain any naming conflict. Usually this means that two elements in the same container cannot have the same name


I_20 - ComponentExchange port orientation
This rule cheks that source and target port orientations of a ComponentExchange are consistent, i.e. - A source port cannot have orientation'IN' - A target port cannot have orientation 'OUT' In Case the ComponentExchange is of kind DELEGATION - "source port/target Port" can only have orientation 'IN/IN' or 'OUT/OUT'


I_21 - Unique Model Element IDs
This rule checks that all capella elements have a unique ID.


I_22 - Hyperlink to Model Element or Diagram displayed text check
This rule ensures that displayed text of hyperlinks to Model Element or Diagram is up to date.


I_23 - Hyperlink to Model Element or Diagram existance check
This rule ensures that hyperlinks to Model Element or Diagram are still refering to existing elements.


I_24 - Operational Analysis Realization
This rule ensures that Operational Analysis Realization links targeting Operational Analysis instances have System Analysis instances as source.


I_25 - Description is well formed XML
This rule checks whether the description of a model element is well formed XML.


I_26 - Equivalent Trace Elements
Checks that there are no equivalent trace elements. Two trace elements are equivalent if they have identical types and identical source and target elements.


I_27 - Functional chain involvement check 3
This rule checks that a Functional Chain Involvement has a valid next and/or previous involvement (not empty)


I_29 - Physical path involvement check 1
This rule checks that a Physical Path Involvement has a valid next and/or previous involvement (not empty)


I_30 - Physical path involvement check 2
This rule checks that a Physical Path Involvement has a valid next and/or previous involvement (contained by the same physical path)


I_31 - check Null Part
This rule checks that a Component Exchange / Physical Link End doesn't have a part Null.


I_32 - Check Component Exchange / Physical Link Ends in SingletonComponents mode
This rule ensures that Component Exchange / Physical Link Ends are restricted to reusable mode defined in Key Value"projectApproach".


I_33 - Check Reused Parts in SingletonComponents mode
This rule checks that reused parts are not used when the project approach is in default mode (not in reusable mode).


I_34 - Inter-model inconsistency Detection
This rule detects inter-model inconsistencies (dependency violations and inter-model cycles).


I_35 - Related functional exchanges must have identical names
This rule checks that Functional Exchanges connected to the same source and/or target port have identical names.


I_36 - Check whether a Constraint is not used
This rule checks that Constraints are used in the model.


I_38 - Validate referential constraints
Verifies that an elements outgoing references are valid according to Capella business rules.


I_39 [Live] - Validate inter-model references
An element in model A can only reference an element in model B if A has declared a "Library Reference" to B.


I_40 - Equivalent Involvement Elements
Checks that there are no equivalent Involvement elements. Two Involvements elements are equivalent if they have identical types and identical source and target elements.


I_41 - Component generalizes other Components with HUMAN different by its own
This rule checks if a Component generalizes other Components with HUMAN different by its own.


I_42 - Component realizes other Components with HUMAN different by its own
Checks if a Component realizes other Components with HUMAN different by its own.


I_43 - Model Element shall not reference to aird element
This rule checks if a model Element references aird element (e.g. gmf)


I_44 - Check existence of unknown model features
This rule checks the existence of unkown model features. An unkown model feature is a feature that is persisted in your textual model representation, but is not recognised by the metamodel and therefore is not loaded during model opening. Its existence does not add any corruption risk to your model, but it does represent an anomaly so it should be removed.


I_45 - Typed Element has different name than its type
This rule checks the Typed Element (Part, Exchange Item Instance) has the same name as its Type (Component, Exchange Item).


I_46 - Check that the image used for diagram nodes is found
This rule applies on diagrams elements of diagram associated to the Capella element and will load the diagram. It is recommended to uncheck this rule by default. This rule ensures that images, used as background of diagram elements, can be found. Tip: If some cases are detected (validation markers), it is recommended to check the presence of the image and move it in the right folder according to the used expected image path location. Once done, you can restart the validation. If you have still validation markers, then, you can use the "Quick fix" tool to:
  • Select a new image
  • Remove broken image link from diagram element or restore default image of diagram element


I_47 - Check that images used in rich text is found (Capella and diagram descriptions etc)
This rule ensures that images, used in rich text editor, for attributes such as Capella elements description or diagram description, can be found. Tip: If some cases are detected (validation markers), it is recommended to check the existence of the image and move it in the right folder according to the used expected image path location. Once done, you can restart the validation.
If you still have validation markers, then use the "Quick fix" tool to select a new image or remove those images from the description. There are three "quick fixes"
  • Remove missing image from rich text description
  • Select a new image to replace the broken image
  • Replace all broken path by a new one. This "quick fix" will impact the whole model and not only the object associated to the marker