Modeler _modeler_interface_audit_view

Audit view

The Audit view

Key:

• 1. The “Audit” tab. The flag on the left of this tab changes color according to the most serious violation detected.

  • Green: No violations detected.

  • Blue: The most serious violation detected is an advice-level violation.

  • Yellow: The most serious violation detected is a warning-level violation.

  • Red: The most serious violation detected is an error-level violation.

• 2. Audit rule severity. There are three different severity levels:

  • Advice: Simple information message.

  • Warning: You can choose to take this information into account or not.

  • Error: The error must be corrected.

• 3. Main element concerned.

• 4. Audit rule number.

• 5. Description of the problem.

• 6. Audit rule sorting options.

• 7. Auto-select of the concerned element in the model explorer.

• 8. The Audit running mode button.

• 9. Current Audit summary. This indicates how many error, warning and advice violations currently are open for a session.

• 10. Audit status. A green light indicates that the audit is not currently running, while a red light indicates that the audit is currently running.

Main audit view commands

From the audit view toolbar:

• Group by severity [] : Presents audit rule violations by severity (error, warning, advice).

• Group by rule [] : Presents audit rule violations by rule, in other words, shows all violations of each individual rule.

• Group by concerned element [] : Presents audit rule violations by concerned element, in other words, shows all problems concerning each individual element.

• Flat view [] : Shows audit rule violations simply in the order in which they are detected.

• Clear audit view [] : Clear the contents of the audit view.

• Auto-select of the concerned element in the model explorer [] : When this button is active, the model explorer “follows” your selections in the audit view, automatically selecting the concerned element in the model browser.

• Audit running mode [] : When this button is pressed, the automatic audit running mode is selected. Otherwise, the manual mode is selected. In automatic mode, the audit will automatically check each modification carried out in the model. In manual mode, checks are only performed on demand, by running the “Check model” command on a model element (from the context menu opened by right-clicking on a model element). Note that in manual mode, the “Check model” command only checks the selected element and not the whole model.

From the audit view context menu:

• Select in explorer : This command is used to select the element concerned by the audit rule violation in the model explorer. This command is only useful when the “Auto-select of the concerned element in the model explorer” has been deactivated using the [] button in the audit view toolbar.

• Show details : This command opens a report dialog on the audit rule concerned. For more information, see the Audit report dialog paragraph below.

• Change severity : The three “Change severity” commands (“Change severity to advice”, “Change severity to warning” and “Change severity to error”) enable you to change the severity of the selected audit rule.

• Disable rule : This command is used to deactivate the selected rule. The rule in question will no longer be run. If you subsequently decide you want to reactivate the rule, this can be done in the “Audit configurator”.

The “Audit report” dialog

The Audit report dialog

Key:

• The Reported issue field provides a reminder of the audit rule violation.

• The Linked elements field provides information on any other elements which are involved in the audit rule violation. This is the case, for example, for dependency cycles, where the dialog will display all the elements involved in the cycle.

• The Information zone displays further information on the problem, and provides advice on how to fix it.

Audit rules list

• R1000: A Model Element cannot abstract itself.

• R1010: The top Partitions of an Activity must not have a Super-Partition.

• R1020: The source and the target of a Flow must be contained in the same Structured Activity Node.

• R1030: The source and the target of a Flow must be owned by the same Activity.

• R1040: An Activity Parameter Node must be represeneted by a Behavior Parameter owned by the same Activity.

• R1050: An Activity Parameter Node cannot have both incoming and outgoing edges.

• R1060: Activity Parameter Nodes with no incoming flow and one or more outgoing flow must have a Behavior Parameter with “In” or “In/Out” parameter passing mode.

• R1070: Activity Parameter Nodes with no outgoing flow and one or more incoming flow must have a Behavior Parameter with “Out” or “In/Out” parameter passing mode.

• R1080: All Partitions of the same nesting level must represent Parts of the same Classifier.

• R1090: If a Sub-Partition is non-external and represents a Classifier then the represented Classifier must be nested in the Classifier represented by its Super-Partition or be the extremity of a Composition with the latter.

• R1100: If a Sub-Partition represents a Part nested in a Classifier then its Super-Partition must represent the Classifier or an instance of the latter.

• R1110: There must be one to one correspondence between: (A) the Pins of a Call Behavior Action, and (B) the In, Out, InOut or Return Behavior Parameters of the called Behaviour.

• R1130: The type and the maximum cardinality of a Call Action'’s Pin must match the type and max multiplicity of the represented Parameter.

• R1140: There must be one to one correspondence between: (A) the Pins of a Call Operation Action, and (B) the In, Inout, Out and Return parameters of the called Operation.

• R1150: The Call Operation Action or Send Signal Action has more than one target Pin.

• R1160: A target Pin can only be owned by Call Operation Actions and Send Signal Actions

• R1170: The type of the target Pin must be the same as the type that owns the Operation.

• R1180: Control Flows may not have Object Nodes at either end, except for Object Nodes with control type.

• R1190: The Decision-Merge Node is used both as a Decision node and as a Merge node at the same time.

• R1200: The edges coming into and out of a Decision Merge Node must be either all Object Flows or all Control Flows.

• R1230: Only Control Flows can have Initial Nodes as their source.

• R1250: If a Fork/Join Node has an Object Flow in its incoming edges, it must have an Object Flow in its outgoing edges and vice versa. The same applies for Control Flows.

• R1280: Object Flows may not have Actions at both end.

• R1290: Object Nodes connected by an Object Flow, with optionally intervening control nodes, must have compatible types. In particular, the downstream Object Node type must be the same or a super type of the upstream Object Node type.

• R1300: Object Nodes connected by an Object Flow, with optionally intervening control nodes, must have the same upper bounds.

• R1310: An edge with constant weight may not target an Object Node, or lead to an Object Node downstream with no intervening actions and with an upper bound less than the weight.

• R1320: An Object Flow must not be simultaneusly multi-cast and multi-receive.

• R1350: If an Object Node has a ‘'Selection behavior’‘, then the ’‘Ordering’‘ of the Object Node is ordered and vice versa.

• R1360: Input Pins may have outgoing edges only when both the following conditions are met: (1) they are on Actions that are Structured Nodes, and (2) these edges must target a Node contained by the Structured Node.

• R1370: Output Pins may have incoming edges only when both the following conditions are met: (1) they are on Actions that are Structured Nodes, and (2) these edges must come from a node contained by the Structured Node.

• R1380: There must be one to one correspondence between: (A) the Pins of a Send Signal Action, and (B) the attributes of the sent Signal.

• R1390: The max cardinality of an argument Pin must be the same as for the represented Attribute.

• R1400: An Activity Parameter Node can only belong to an Activity.

• R1410: Only one Association End of an Association can be aggregate or composite.

• R1420: Actors and UseCases can only have binary Associations.

• R1430: Multiplicities of an AssociationEnd must be consistent: MultiplicityMin cannot be ‘*’ and MultiplicityMin must be inferior to MultiplicityMax.

• R1450: If an association is a composition, then the opposite maximum multiplicity must be 1.

• R1460: A public association oriented from a public Classifier cannot be linked to a private or protected Classifier.

• R1470: The name of an AssociationEnd’s qualifiers must be unique.

• R1480: An Attribute must be typed by a primitive type.

• R1490: In an instance, the type of an instantiated attribute must be in the instantiated class or in its parent classes.

• R1500: In an instance, the name of an instantiated attribute must be the same as the corresponding attribute.

• R1520: The name of a BindableInstance must be unique in it Classifier.

• R1530: An association or a port should have a name.

• R1540: A BindableInstance’s RepresentedFeature must not refer itself, directly or indirectly.

• R1550: If a BinbdableInstance has a type and has a represented feature, the type of the instance must be compatible with the type of this feature.

• R1560: Sub classes of an active class must be active.

• R1580: Attributes, Associations and Operations cannot simultaneously be abstract and class.

• R1590: Primitive GeneralClass cannot have associations.

• R1600: A primitive class cannot have collaborations.

• R1610: A primitive class cannot have state machines.

• R1620: A non-abstract Classifier cannot have abstract methods.

• R1640: A maximum of one ElementImport must exist between a NameSpace and another NameSpace or between an Operation and a NameSpace.

• R1650: An Enumeration cannot be abstract.

• R1660: An enumeration is always primitive.

• R1670: EnumlerationLitteral defined in an Enumeration must have an unique name.

• R1680: For a Call-type Event, the ‘Called operation’ field must be defined, whereas the ‘Instanciated signal’ must be empty.

• R1690: The ‘Expression’ field for a Change-type Event must be defined, whereas the ‘Called operation’ and ‘Instanciated signal’ fields must be empty.

• R1700: The ‘Instantiated signal’ field for a signal-type Event must be defined, whereas the ‘Called operation’ and ‘Expression’ fields must be empty.

• R1710: The ‘Expression’ field for a Time-type Event must be defined, whereas the ‘Called operation’ and ‘Instanciated signal’ fields must be empty.

• R1720: An abstract NameSpace should only inherit from an abstract NameSpace.

• R1730: A generalisation must be created between two model elements of the same type, except in the case of a signal, which can specialize a Signal or a Class.

• R1740: An InformationFlow should convey information.

• R1750: Repetition of names is forbidden for all AtrributeLinks.

• R1760: There cannot be inconsistency in the multiplicities of an Instance

• R1780: The name of an Instance must be unique in its NameSpace.

• R1790: An instance must have a name, or the instantiation association must be defined.

• R1800: If an Operator is of type opt, loop, break or neg, there cannot be more than one Operand.

• R1810: An actual Gate on an InteractionUse must reference a formal Gate contained by the referenced Interaction.

• R1820: A gate cannot cover a lifeline.

• R1830: A PartDecomposition cannot receive ‘create’ or ‘destroy’ messages.

• R1860: In an interface, the visibility of all Features must be public.

• R1870: An interface cannot be implemented twice by the same class or the same component.

• R1910: A Link that instantiates an association must be coherent with this association.

• R1950: Messages of type ‘reply’ cannot invoke an Operation.

• R1960: A message must have the same name as the invoked Operation.

• R1970: A TemplateParameterSubstitution must reference a TemplateParameter.

• R1980: The names of a Classifier’s Attributes and AssociationEnds must be unique.

• R1990: The name of a Classifier’s inherited Attributes and Roles must be unique.

• R2010: In a Dictionary, the name of each element must be unique.

• R2030: In a PropertyContainer, the name of each EnumerationPropertyType must be unique.

• R2050: Some elements must have a name.

• R2060: The name of a NameSpace must be unique in its NameSpace.

• R2080: In a PropertySet, the name of each Property must be unique.

• R2100: In a EnumerationPropertyType, the name of each PropertyEnumerationLiteral must be unique.

• R2120: In a PropertyContainer, the name of each PropertySet must be unique.

• R2140: In a PropertyContainer, the name of each PropertyType must be unique.

• R2160: In an Analyst Container, the name of each element must be unique.

• R2170: The name of a Behavior must be unique in its NameSpace.

• R2180: No cycles can exist in a NameSpace inheritance graph.

• R2190: A maximum of one generalization may exist between two namespaces.

• R2200: A NameSpace cannot both derive and import another NameSpace.

• R2210: A leaf NameSpace cannot be derived.

• R2220: A leaf NameSpace cannot be abstract.

• R2230: A root NameSpace cannot inherit from any other NameSpace.

• R2240: There can be no inter-package/inter-component dependency cycle.

• R2250: All operations in a Classifier must have a different signature from inherited public and protected operations. Except for constructor, destructor and redefined operations.

• R2260: Each Operation in a Classifer must have a different signature.

• R2270: All an Operation’s Collaborations must have a different name.

• R2330: All an Operation’s Parameters must have a different name.

• R2340: A redefined Operation must belong to a parent or an implemented Interface of the owner of the Operation.

• R2350: A private Operation cannot be redefined.

• R2360: The visibility of an Operation cannot be greater than that of the Operations it redefines.

• R2370: A class (static) Operation cannot be redefined.

• R2380: An abstract Operation must not redefine a concrete Operation.

• R2390: A constructor cannot have return parameters.

• R2400: A destructor cannot have any kind of parameters.

• R2410: An operation cannot own both ‘create’ and ‘destroy’ stereotypes.

• R2420: An Operation must have the same signature as the Operation it redefines.

• R2430: All an Operation’s StateMachines must have a different name.

• R2440: An Operation cannot belong to an Enumeration.

• R2450: A package cannot have inheritance links.

• R2470: A maximum of one PackageImport link may exist between a NameSpace and a Package.

• R2500: An ‘out’ Parameter cannot have a default value.

• R2510: There cannot be any direct link between two Class Ports.

• R2520: If a Port runs a delegation towards an internal part, it must provide at least one interface.

• R2530: If a Port receives a delegation from an internal part, it must provide at least one interface.

• R2540: The interfaces provided by a port must be implemented by the Class that types the Port.

• R2550: If a Port is a behavior port, its provided interfaces must be implemented by the Class it belongs to.

• R2560: A behavior Port must provide at least one interface.

• R2570: If a Port is a behavior port, the type of the port must be either the Class it belongs to or undefined.

• R2580: A region cannot contain more than one deep history state.

• R2590: A region cannot contains more than one initial state.

• R2600: A state machine or a state cannot have two states with the same name.

• R2610: Only submachine states can have connection point references.

• R2620: Submachine states should not have entry or exit pseudo states defined.

• R2630: A region cannot contain more than one shallow history state.

• R2640: The context of a state machine cannot be an interface.

• R2650: The context of a protocol state machine must be a Classifier.

• R2660: A state in a protocol state machine cannot have entry, exit, or do activity actions.

• R2670: A protocol state machine cannot have history vertexes.

• R2680: The number of parameter of a TaggedValue must be the same as the number of parameter defined in the TaggedValue declaration.

• R2690: An element cannot have a TemplateBinding towards itself.

• R2700: A TemplateBinding can only substitute each TemplateParameter of the instantiated element once.

• R2720: A TemplateBinding must be created between two elements of the same type or between a Class and a DataType.

• R2730: A TemplateBinding must substitute all the TemplateParameters of the instanciated template element, and the TemplateParameterSubstitution must be defines in the same order as the TemplateParameters.

• R2740: In a TemplateBinding, the TemplateParameterSubstitution must belong to the instantiated template element.

• R2750: A transition from a fork or join pseudo state should not have guards or triggers.

• R2760: A fork segment must always target a state.

• R2770: A join segment must always originate from a state.

• R2780: Transitions outgoing pseudostates may not have a trigger (except for those coming out of the initial pseudostate).

• R2790: A transition from one region to another in the same immediate enclosing composite state is not allowed.

• R2800: An initial vertex can have at most one outgoing transition.

• R2810: History vertices can have at most one outgoing transition.

• R2820: The target of a transition cannot be an initial vertex.

• R2830: The source of a transition cannot be a final vertex.

• R2840: A transition should have only one of Processed, Effects, or BehaviorEffet defined.

• R2850: An element cannot have a usage dependency towards itself.

• R2860: A maximum of one extension/inclusion relationship may exist between two Use Cases.

• R2870: There must be no cycle in Use Cases extension relationship graph.

• R2880: There must be no cycle in Use Cases inclusion relationship graph.

• R2890: A communication link cannot have the same Actor or Use Case as its source and target.

• R2900: An extension relationship must reference at least one Extension Point.

• R2910: An extension relationship can only reference the target’s Extension Points.

• R2920: Extension Points can only be referenced by an extension relationship.

• R2930: Message and Communication Message cannot have both Signal and Operation properties defined.

• R2940: All transitions incoming a join vertex must originate in different regions of an orthogonal state.

• R2950: All transitions outgoing a fork vertex must target states in different regions of an orthogonal state.

• R2960: Synonym, antonym, homonym, context, and kind-of dependencies can only link two terms.

• R2970: An Assigned dependency must be from an Actor, an Interface, a Package, or a Process, toward a Goal.

• R2980: A Measure dependency must be from a ModelElement toward a Goal.

• R2990: A Guarantee dependency must be from a Requirement toward a Goal.

• R3000: Positive influence and Negative influence dependencies must be between two Goals.

• R3010: A refers dependency must be between a Business Rule and a Term.

• R3020: A related dependency must be must be between two Business Rules or two Terms.

• R3030: A refine dependency must be between either: 1) from a Model Element or a Requirement towards a Requirement 2) from a Business Rule, an Activity or an Operation towards a Business Rule.

• R3040: An implement dependency must be from a Process or a Class towards a Business Rule.

• R3050: A part dependency must be between two Requirements or between two Goals.

• R3060: A satisfy or verify dependency must be from a ModelElement towards a Requirement.

• R3070: A derive dependency must be from a UseCase or a Requirement towards a Requirement.

• R3080: All FlowNodes should be part of a sequence starting with a StartEvent and finishing with an EndEvent.

• R3090: A SequenceFlow cannot have its source or target in different Process.

• R3100: A SequenceFlow in a SubProcess must have its origin and target in the same SubProcess.

• R3110: A SequenceFlow cannot target a StartEvent nor have an EndEvent as its source.

• R3120: A LinkThrowEvent must be linked to a LinkCatchEvent.

• R3130: A MessageFlow cannot target an EndEvent or an IntermediateThrowEvent, or have a StartEvent or an IntermediateCatchEvent as its source.

• R3140: All outgoing SequenceFlow from an EventBasedGateway or a ParallelGateway must have its guard empty.

• R3150: A MessageFlow cannot link two elements in the same Process.

• R3160: A MessageFlow cannot have a Gateway as its source or target.

• R3180: A FlowElement (and respectively a BaseElement) cannot have a SequenceFlow (respectively a MessageFlow) towards itself.

• R3190: A DataAssociation cannot target a DataInput nor have a DataOutput as its source.

• R3200: A LinkThrowEvent should have the same name as the targeted LinkCatchEvent .

• R3220: A SequenceFlow outgoing from an EventBasedGateway must target an IntermediaryCatchEvent.

• R3230: All SequenceFlows outgoing from an ExclusiveGateway must have a guard, except for the default SequenceFlow.

• R3250: Process and SubProcess should have at least one StartEvent and one EndEvent.

• R3260: The model should not contain missing elements.

• R3270: The State of a BpmnItemAwareElement must belong to its represented GeneralClass.

• R3280: A FlowElement must be part of a lane.

• R3290: A SequenceFlow must exist to support DataAssociations.

• R3300: Analyst elements must have a non-empty name.

• R3310: Dependency should follow recommended direction in Analyst models.

• R3320: A MessageFlow should start from a SendTask/ThrowEvent/Participant and end on a ReceiveTask/CatchEvent/Participant.

• R4000 : The relationships must comply with the ArchiMate standard.

• R4010 : The relationships to and from a Junction must be of the same kind.