280 likes | 406 Views
Consistency Check in Modelling Multi-Agent Systems. Lijun Shan H ong Zhu Dept of Computer Science Dept of Computing National Univ . of Defen s e Tech. Oxford Brookes Univ. Changsha, 410073, China Oxford OX33 1HX, England lijunshancn@yahoo.com hzhu@brookes.ac.uk. Outline.
E N D
Consistency Check in Modelling Multi-Agent Systems 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 lijunshancn@yahoo.com hzhu@brookes.ac.uk COMPSAC'2004
Outline • Motivation and related work • Agent-oriented software development (AOSD) • Model-driven software development (MDSD) • Roles and problems of consistency checking in MDSD • Definition of consistency constraints • Consistency checkers in a modelling environment • Case studies • Conclusion COMPSAC'2004
Motivation • Agent technology: • Widely recognized as a viable solution for applications in dynamic environments such as the Internet • Agent-oriented methodologies, such as Gaia, Tropos, AUML, etc. • CAMLE: Caste-centric Agent-oriented Modelling Language and Environment • as a method of requirements analysis and specification • as the base for the design and implementation of MAS • to generate formal specifications in SLABS • to write programs in AO programming languages COMPSAC'2004
Model-driven SW development • Models play the central role in SW development • modelling real world systems • as a means of requirements analysis • modelling software/information systems • as specifications of software systems • to analyse system’s properties, etc. • as high level designs • to derive or generate code • even as executable representation of software systems • as bases of software testing, etc. • Characteristics of modern modelling languages • Semiformal diagrammatic notation with defined semantics • Facilities to support separation of concerns • Multiple views • Hierarchically structured collection of diagrams COMPSAC'2004
Consistency as a basic quality attribute • Consistency: • Between different views • Between models at different levels of abstraction • Consistency is crucial in MDSD • A model must be consistent before it is transformed into other forms, e.g. • the generation of code, • the derivation of test cases, • the uses as software documentation, • A model must be consistent before the derivation and proof of the properties of the system • Ensuring consistency is very difficult • Related to the semantics of the model • Complexity due to multiple views and multiple levels COMPSAC'2004
Consistency check: a challenging problem • The aim of consistency check is to provide a partial but effective solution to model consistency problem. • Defining a set of consistent constraints that can detect a large number of common errors in models • Design algorithms that can automatically check if a model satisfies the consistency constraints • The idea of consistency check in modeling languages is similar to type check in programming languages: • defining a type system to prevent type errors • device a static type checking mechanism COMPSAC'2004
Consistencyconstraints • What are consistent constraints? Restrictions on the uses of diagrammatic notations, variables and names, types and symbols in a modeling language to reduce the possibility of inconsistency • Related to the semantics of the diagrams • Must be able to be syntactically checked • Typical examples • The same identifier that occurs at different places must refer to the same entity • An entity should be referred to by the same identifier if it occurs at different diagrams COMPSAC'2004
Intra-model consistency: Within one type of model Intra-diagram: Within one diagram Inter-diagram: Between different diagrams of the same model Inter-model consistency: Between different types of models, hence also different diagrams Horizontal consistency: Between models/diagrams of the same level of abstraction Vertical consistency: Between models/diagrams at different levels of abstraction Local: Between two levels Global: With respect to the overall structure Types of consistency constraints COMPSAC'2004
Related work • Defining consistency constraints for UML: • (Andr´e, P. 2000), (Pap, Z. S. 2001), (Nentwich, C. 2001), (Paige, R. F. 2002), (Astesiano, E. 2003) • Generic tools • Xlinkit: language for defining consistency + engine for automated checking, (Nentwich, C., Emmerich, W., & Finkelstein, 2003) • Formal methods (e.g. SPIN) • (Inverardi, P. 2001), (Schafer, T. 2001) • As a part of modelling environment • NDRASS (structured modelling) (Xu, J., Jin, L., & Zhu, H. 1996) COMPSAC'2004
Overviewof CAMLE • Conceptual model of multi-agent systems [2] • Agent: an active computational entity that encapsulates data, operations and behaviours and situates in its designated environment • state space • a set of operations/actions • designated operating environment • a set of behaviour rules • Caste: a set of agents that have the same structural and behavioural characteristics • agents are instances of, but have dynamic memberships of castes • inheritance relationship between caste COMPSAC'2004
Overall Structure ofCAMLE Models Collaboration Models and Behavior models • A CAMLE model consists of • a caste model • collaboration models • behaviour models Caste Model with Whole-Part Relations COMPSAC'2004
Caste model • Caste model • models the organizational structure • Caste diagram • Defines the castes in the system • Specifies their relations Notation Example COMPSAC'2004
Constraints on Caste Model 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. COMPSAC'2004
Collaborationmodels • Collaboration Diagram • Describes the dynamics of a system from communication perspective • The structure of collaboration models • A hierarchic of collaboration models as refinement of castes • A collaboration model for each compound caste: • a general collaboration diagram + a set of scenarios specific collaboration diagrams Notation Example COMPSAC'2004
Constraints on Collaboration Model • Well-formedness conditions 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. • Consistency between general and specific diagrams, e.g. 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)) • Consistency between models at different levels, e.g. 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))) COMPSAC'2004
Behaviour models • Scenario diagram • Describes a typical situation in the operation of a system from an agent’s view. • used in behaviour diagrams • behaviour diagram • define behaviour rules of an agent COMPSAC'2004
Constraints on Behaviour Model • Well-formedness conditions, e.g. Constraint 3a)The temporal order between events must be linear • Consistency between behaviour diagrams and scenario diagrams, e.g. 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) COMPSAC'2004
Inter-ModelConsistency • Between collaboration model and caste model Constraint 4a) Every caste in a collaboration model CD must be a caste in the caste model C. Formally, DCD.nNode(D).n’Node(C).(CName(n)=Name(n’)) Constraint 4b) The hierarchical structure of the collaboration models must be consistent with the whole-part relations between castes defined in caste diagram C. MA,MBCM.(MB<MAR Aggr(C).(R(B,A)) COMPSAC'2004
Between behaviour model and caste model 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. BBM.aAgents(B).nNode(C). (Caste-of(a)=Name(n)) 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. COMPSAC'2004
Between collaboration model and behaviour 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. ScScenarios(BC).GRef(Sc).GCollaborators(C) Constraint 4h) The agents/castes referred to in a scenario must be in the environment of the caste as described by the collaboration model. ScScenarios(B).GRef(Sc).(GEnv(C)) 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)). COMPSAC'2004
Summary COMPSAC'2004
Consistency check tools in CAMLE • Well-formedness conditions are checked during model construction in the process of interactive diagram editing • Other consistency constraints are checked by a set of tools; each for one specific constraint • Consistency checking tools are called in the following order to reduce the complexity of error handling: • Intra-model intra-diagram consistency checkers • Intra-model inter-diagram consistency checkers • Inter-model local consistency checkers • Inter-model global consistency checkers COMPSAC'2004
Graphic User Interface Users’Requirements Model Manager Check Result Graphic Models FormalSpecifications SpecificationGenerator Well- formedness Checker Diagram Editor Consistency Checker Controller Behaviour Model Checker Partial Diagram Generator Caste/ Behaviour Checker Collaboration Model Checker Caste/ Collaboration Checker Behaviour/ Collaboration Checker General/ Specific Checker Cross level Checker Architecture of CAMLE Environment COMPSAC'2004
Case studies • United Nations’ Security Council: • the organisational structure and the working procedure to pass resolutions • Amalthaea: • an evolutionary multi-agent system developed at MIT’s Media Lab for retrieving information from the Internet • University: • a partial model of the university organisation and working procedures • Web Services: • a model of the architecture of web services and an application of web services of online auctions COMPSAC'2004
Observations on case studies • In all cases, automated consistency check detected a large number of errors • Models that passed consistency checks are of good quality • Explicitly defined consistency constraints helped modeler to think more carefully in the construction of models, hence made fewer mistakes during modeling than without constraints • The design and implementation of the transformer for generating formal specifications become much simpler with the assumption that certain inconsistency can be ruled out COMPSAC'2004
Conclusion • Roles of consistency constraints in MDSD • Quality assurance in modelling process • Consistency constraints can be defined to effectively improve the quality of models and the productivity in model construction • Consistency checking can be implemented efficiently as a very useful tool in a modeling environment • Partial specification of the correctness of the transformation rules between models • The diagram generators in CAMLE can guarantee that a generated model (or partial model) is consistent with the original diagram(s). • Further work • Statistical analysis of the effectiveness of consistency constraints • Further development of CAMLE environment COMPSAC'2004
References • Shan, L. & Zhu, H. CAMLE: A Caste-Centric Agent Modelling Language and Environment. Proc. of SELMAS at ICSE’04, Edinburgh, Scotland (UK), May 2004. • Zhu, H. SLABS: A Formal Specification Language for Agent-Based Systems, Journal of Software Engineering and Knowledge Engineering 11(5), 529-558, 2001. • Pap, Z. S., Majzikl, I., Pataricza, A, & Szegi, A. Completeness and Consistency Analysis of UML Statechart Specifications. Proc. of IEEE Design and Diagnostics of Electronic Circuits and Systems Workshop, 83-90. 2001. • Nentwich, C., Emmerich, W., & Finkelstein, A. Flexible Consistency Check. ACM Transactions on Software Engineering and Methodology 12 (1), 28-63, 2003. • Inverardi, P., Muccini, H., Pelliccione, P. Automated check of architectural models consistency using SPIN. Proc. of 16th IEEE Int. Conf. on Automated Software Engineering, San Diego, California, p.346, 2001. COMPSAC'2004