Lijun Shan Hong Zhu
Dept of Computer ScienceDept of Computing
National Univ.of Defense Tech.Oxford Brookes Univ.
Changsha, 410073, China Oxford OX33 1HX, England
Restrictions on the uses of diagrammatic notations, variables and names, types and symbols in a modeling language to reduce the possibility of inconsistency
Within one type of model
Within one diagram
Between different diagrams of the same model
Between different types of models, hence also different diagrams
Between models/diagrams of the same level of abstraction
Between models/diagrams at different levels of abstraction
Between two levels
With respect to the overall structureTypes of consistency constraints
an active computational entity that encapsulates data, operations and behaviours and situates in its designated environment
a set of agents that have the same structural and behavioural characteristics
Collaboration Models and Behavior models
Caste Model with Whole-Part Relations
Constraint 1a) A caste diagram defines a naming space in which each node defines a caste with a unique name.
Constraint 1b) Each link defines a binary relation on castes by linking two nodes in the diagram.
Constraint 1c) An inheritance relation and a migration relation must be associated to two different caste nodes.
Constraint 1d) Inheritance relations must not form any loops.
Constraint 2a) Each caste / agent node must have a unique name.
Constraint 2b) The number assigned to an action indicating its temporal order must be unique, if any.
Constraint 2c)Every agent node in the general collaboration diagram G must appear in at least one scenario-specific collaboration diagram. Formally,
nANode (G).DS. (nANode (D))
Constraint 2j) For all castes C in a collaboration model M,C’s environment described in M must be equal to C’s environment described in C’s collaboration model MC.
n.(nEnv(MC) aInteraction(G).(n=Begin(a)C =End(a)))
Constraint 3a)The temporal order between events must be linear
Constraint 3d) In a behaviour diagram, every scenario reference node must refer to a scenario defined by a scenario diagram.
n ScenarioNode(DC). S SC.(Name(n)=Name(S)
Constraint 4a) Every caste in a collaboration model CD must be a caste in the caste model C. Formally,
Constraint 4b) The hierarchical structure of the collaboration models must be consistent with the whole-part relations between castes defined in caste diagram C.
Constraint 4c) For each behaviour model BM, the caste that BM defines its behaviour must be in declared in the caste model C.
BBM.nNode(C).(Caste(B)= n ).
Constraint 4d) Every agent occurs in a scenario in a behaviour model BM must have its caste defined in the caste model C.
Constraint 4e)The ‘join’, ‘quit’ and ‘move’ actions occur in the behaviour model of a caste c must be consistent with the migration relation described in the caste model.
Constraint 4f) Every visible action of caste C defined in the collaboration model CM must occur in C’s behaviour model BMCor at least one of C’s components as a result action.
aVisibleActions(C).(rRules(BC) (MComponents(C). r Rules(BM)). (a=Action(r))
Constraint 4g) For each scenario used in the definition of caste C’s behaviour, the agents and/or castes that the scenario referred to must occur in the collaboration model CM as C’s collaborators.
Constraint 4h) The agents/castes referred to in a scenario must be in the environment of the caste as described by the collaboration model.
Constraint 4i) Every action that a scenario refers to in a behaviour diagram must be a visible action of the caste of the scenario.
Sc Scenarios(BC).a ReferredActions(C, Sc). (aVisibleActions(C)).
Consistency Checker Controller
Partial Diagram Generator
CheckerArchitecture of CAMLE Environment