1 / 27

Consistency Check in Modelling Multi-Agent Systems

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.

faye
Download Presentation

Consistency Check in Modelling Multi-Agent Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 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

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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

  12. Caste model • Caste model • models the organizational structure • Caste diagram • Defines the castes in the system • Specifies their relations Notation Example COMPSAC'2004

  13. 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

  14. 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

  15. 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, nANode (G).DS. (nANode (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.(nEnv(MC) aInteraction(G).(n=Begin(a)C =End(a))) COMPSAC'2004

  16. 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

  17. 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

  18. 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, DCD.nNode(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,MBCM.(MB<MAR Aggr(C).(R(B,A)) COMPSAC'2004

  19. 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. BBM.nNode(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. BBM.aAgents(B).nNode(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

  20. 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. aVisibleActions(C).(rRules(BC) (MComponents(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. ScScenarios(BC).GRef(Sc).GCollaborators(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. ScScenarios(B).GRef(Sc).(GEnv(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). (aVisibleActions(C)). COMPSAC'2004

  21. Summary COMPSAC'2004

  22. 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

  23. 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

  24. 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

  25. 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

  26. 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

  27. 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

More Related