Validation Rules

The following validation rules are separated into the domain they are checked on. Note that only validation rules clearly marked as done are available, the rest are used as assumptions for the different workflow steps.

Some validation rules may be deleted if they are no longer an issue. The reasoning for each deleted rule shall be added.

Additional notes in code style provide technical details for the rules.

UML

Components

1. Components cannot contain other components directly or transitively.

• Note that components may have parts with types that are components.

Class structure

1. An association can have maximum two AssociationEnds
2. Both association ends are contained by the association (see #56).

• Association.ownedEnd(assoc, end)

1. Non-default multiplicities are always stored as (1) integer for lower value and (2) unlimited natural for upper value (See #96).

• MultiplicityElement.lowerValue instanceOf LiteralInteger
• MultiplicityElement.upperValue instanceOf LiteralUnlimitedNatural
• Reason for deletion: use MultiplicityElement.lower() and upper() that handles incorrect ValueSpecifications and always returns values considered default in UML.

1. The generalization hierarchy has no cycles.
2. Attribute's type has to be data type.

• DataType and it's subtypes Enumeration and PrimitiveType

1. Constructor operations have the same name as their containing Class and have Create stereotype applied (from the UML Standard profile).
2. Destructor operation's name must be destroy, the operation has Destroy stereotype applied (from the UML Standard profile) and has no parameter.
3. Operations' name cannot be the same as their containing Class prefixed with ~.

Operations

1. Abstract operations does not have associated methods

Signals

1. Signal attributes are not static and always have public visibility.
2. Signal attributes cannot be redefined in sub Signals.
3. Signals have at most one other signal as super type.

Types

1. StructuredType cannot have class references as its attribute.

State machine

1. A transition triggering signal must have a Reception in the class that contains the state machine for the transition (see #85).

XTUML-Common

Component

1. Components cannot have dynamic behavior (state machines).

Transition

1. There is a single transition from the InitialPoint to the initial state and it has no triggers or guard
2. Transitions with the same source and target vertex have at least unique name
3. Transitions have at most one trigger
4. Transition with event trigger must have signal.

• XTEventTrigger.signal

1. Multiple transitions for the same source vertex with exactly the same triggering event are allowed

OOPLModel

CPPModel

Platform