Methodology of D SML 4M AS

One of the main problems that prevent AOSE from a broad application in main stream software development is the lack of adequate methodologies and suitable tool support. Both are necessary to support the unexperienced user to design the system in accordance to the vocabulary and semantics given by the language. In the software engineering domain, a methodology defines in general a guided procedure for using the (modeling) language to build software systems in a systematic manner. The methodology’s procedure guides all involved roles (e.g. business analysts, system architects, engineers, developers, etc.) in using the given technologies and modeling techniques, and allows them to obtain the maximal benefits for the engineering process that are inherently supported by tools. The guided procedures ideally cover the complete system engineering process from initial design to system development and maintenance along with detailed methods for the modeling and development of specific aspects. The procedures are normally obtained from experiences gained from already completed system engineering projects.

The purpose of this chapter is to present the DSML4MASmethodology aiming at providing guided procedures for supporting the system engineering process of DSML4MASby using its modeling techniques, tools and code generators. The DSML4MASmethodology includes proper support for all phases of the overall MAS engineering process, i.e. from the analysis stage to the final implementation of the system.

Structure of this Chapter Section 5.1 summarizes the basic components of any methodology.

Afterwards, Section 5.2 reports on the tool support provided by DSML4MAS. Section 5.3 then introduces the concrete syntax of DSML4MAS followed by Section 5.4 illustrating the (semi-) automatic model-driven methodology process. Finally, Section 5.5 concludes this chapter.

5.1 Basic Concepts of Methodologies

A methodology is, in accordance to (Ghezzi et al.; 2002), a collection of methods covering and connecting different stages in a process. The purpose of a methodology is to prescribe a certain coherent approach to solving a problem in the context of a software process by preselecting and putting in relation a number of methods. At this, the methodology should be understood as collection of methods covering and connecting different stages or phases in a process. A methodology has two important components, (i) one component that describes the process elements of the approach, and (ii) one component that focuses on the work products and their documentation. AOSE methodologies mainly try to suggest a clean and disciplined approach to analyze, design and develop MASs, using specific methods and techniques that are presented in more detail in Chapter 10, when discussing the state of the art on AOSE modeling approaches.

In this dissertation, the term methodology denotes a set or collection of methods and re-lated artifacts needed to support the model driven engineering of MASs. Our view on the term

methodology as a collection of methods is aligned with e.g. (Blum; 1994): "Methodology: A body of methods, meant to support all software development phases." and with (Estefan; 2007) who defines a methodology in the area of Model Based Systems Engineering (MBSE) as: "A MBSE methodology can be characterized as the collection of related processes, methods, and tools used to support the discipline of systems engineering in a model-based or model-driven context".

The main difference between an agent modeling language and an agent-oriented methodology is that a methodology builds upon the modeling language, but provides in addition mechanisms that support the design, analysis, and development of MASs. This means in accordance to (Bordini et al.; 2007a) that a methodology includes the following aspects:

Concepts define the vocabulary used by the methodology. As already mentioned earlier, for describing and modeling agent systems, a single set of basic concepts is not yet univer-sally accepted or known. So each methodology focuses on concepts considered as most important. The concepts used in DSML4MASare clearly defined by the abstract syntax given by the PIM4AGENTSmetamodel (cf. Chapter 4). The vocabulary along with the viewpoint information is the foundation for creating models and notations.

Models and Notation are the artifacts generated during the analysis and design. These models are depicted using some notation, often graphical. To define the notation and the different kinds of diagrams used to determine the models, the concrete syntax of DSML4MASis given in Section 5.3, which is based on the concepts and viewpoints given by the PIM4AGENTS

metamodel.

Techniques usually formulated as heuristics guide the use through the existing phases in order to refine the developed design. The techniques used in DSML4MASare given by the model transformations of the DSML4MASmodel transformation architecture. As heuristics are not part of this architecture, parts of the design have still to be done manually, even if the model transformation architecture supports the automatic code generation.

Tool support is an essential feature of a methodology in order to support the user during the various design phases. Tools can range from simple drawing packages, to more sophisti-cated design environments that provide various forms of consistency checking. To provide adequate tool support for DSML4MAS, we developed the DSML4MASDevelopment Environ-ment (DDE) that includes the concrete syntax defining the graphical visualization, the static semantics to check the conformance of the design, as well as the code generators, which are given in Chapter 7. Section 5.2 is devoted to present DDE.

Process defines the order in which the different software development phases are applied. Any process comprises several phases like the analysis phase, design phase, or the implementa-tion phase. The process of designing in accordance to DSML4MASis mainly defined through the model transformation architecture. A detailed discussion on the DSML4MASprocess model is given in Section 5.4.

For a successful development of any visual modeling language, three facets are needed in accor-dance to Quatrani (2000): A notation, a process, and a tool. Quatrani claimed that "You can learn a notation, but if you don’t know how to use it (process), you will probably fail. You may have a great process, but if you can’t communicate the process (notation), you will probably fail. And lastly, if you cannot document the artifacts of your work (tool), you will probably fail". In order to develop a powerful modeling language for MASs, DSML4MASprovides all of these facets (i.e. a notation, process and tool) that are examined in detail in the forthcoming sections of this chapter.

5.2. Tool Support: The DSML4MAS’SDevelopment Environment 115

5.2 Tool Support: The D

SML

4M

AS

’

S

Development Environment

Only little research has been done with respect to the development of adequate tools to support the design of agent-based systems, which certainly hampers the breakthrough of MASs in industry.

In particular, integrated development environment support for developing MASs is rather weak, and existing agent tools do not offer the same level of usability as state-of-the art object-oriented IDEs (Luck et al.; 2006). Beside a graphical visualization, adequate tool support should also provide facilities to support the domain experts with respect to testing, evaluation, and execution of the generated artifacts. In the present section, related work in the area of agent-based modeling tools is capitulated before presenting the core features of the DSML4MASDevelopment Environment (DDE).

5.2.1 Related Work

Several tool-supported methodologies for developing MASs exist. Examples are PASSI with the PASSI Tool Kit (PTK) (Cossentino and Potts; 2002) and ROADMAP with REBEL (Juan et al.; 2002).

These methodologies differ in their scope, tool support, and maturity. In this section, we want to further discuss three tool supported agent-based methodologies that we consider the closest to the DSML4MASapproach¹.

In accordance to (Bresciani et al.; 2004), Tropos is a software development methodology founded on the key concepts of agent-oriented software development by focusing on the re-quirements analysis, design, and on model checking. The Tropos methodology bases on the Tropos metamodel (see Section 10.2.7 for a detailed discussion) and covers the development phases of requirements analysis, design, and implementation. Tools for goal analysis (GR-Tool, see (Giorgini et al.; 2005)) and model checking (T-Tool, see (Fuxman et al.; 2001)) have been separately implemented. The eCAT tool is used for automated testing. The modeling tool of the Tropos methodology is called TAOM4e²and provides code generation for JADE and Jadex. TAOM4e is based on the Eclipse Modeling Framework (EMF³) and the Graphical Editing Framework (GEF⁴).

One important benefit of Eclipse’s Graphical Modeling Framework (GMF) (that is used for creating DDE) over the combination of GEF and EMF is that its tooling component allows the model-driven creation of a graphical editor based on the underlying metamodel.

In accordance to (Padgham and Winikoff; 2002a), Prometheus is an agent-oriented software engineering methodology. Prometheus supports the whole agent-oriented software development process from analysis to implementation. The Prometheus Design Tool (PDT⁵) (Thangarajah et al.; 2005) offers diagrams for the high-level analysis of a system, the refinement with interaction diagrams with Agent UML (AUML, (Odell et al.; 2000)), and the specification of processes. PDT contains a cross checking tool that covers problems like inconsistency checking, identification of dangling model elements, type checking, etc. Moreover, PDT provides code generation for JACK. It seems that PDT was implemented as a usual Java Swing application. There also exists a plug-in for the Eclipse platform but the integration seems to be very weak.

1In Chapter10, these three methodologies are further evaluated in terms of their metamodel and interoperability support.

2http://sra.itc.it/tools/taom4e/

3http://www.eclipse.org/modeling/emf/

4http://www.eclipse.org/gef/

5http://www.cs.rmit.edu.au/agents/pdt/

According to (Pavón and Jorge; 2003), INGENIAS is a methodology for specifying MASs on a platform independent level. The INGENIAS metamodel covers aspects such as organizations of agents, agent interactions, and environments of MASs. The INGENIAS methodology is supported by the graphical modeling tool INGENIAS Development Kit (IDK) (Gomez-Sanz et al.; 2008a) providing code generation for JADE, where the INGENIAS Code Uploader extension supports refactoring of the generated code. INGENIAS belongs to the few approaches that also focus on code generation and implementation.

Instead of focusing purely on the analysis and design phases as most of existing related ap-proaches do, the aim of the DSML4MASmethodology is to cover the whole design process from analysis to executable code. At this, PIM4AGENTSpresents an expressive language that can be used to generate most parts of a MAS implementation. In our point of view, the automatic code generation and suitable tool support are critical for the practical application of agent-oriented software engineering. Our contribution consists of an expressive platform independent modeling language and adequate tool support that guides the user in designing and implementing MAS.

The core features of DDE are as follows.

5.2.2 Features of the D

SML

4M

AS

Development Environment

DDE has been implemented using GMF and is based on a plug-in architecture. Hence, DDE inherits many useful features from GMF, such as unlimited undo and redo, auto-arrange, snap-to-grid, modeling assistance, a graphical outline, picture export to save the design in jpeg or png formats, and many more. The following section summarizes the core features of DDE that were not inherited by GMF, but base on the work presented in the upcoming chapters.

Model-driven approach DDE integrates a model-driven development process to close the gap between design and code. Hence, models in accordance to PIM4AGENTSare transformed to platform-specific agent models of JACK and JADE. Details of the DSML4MASto JACK transformation are given in Section 7.3. In a second step, source code for JACK and JADE is generated using the model-to-text transformation engine of MOFScript. Finally, the generated source code can be edited, executed and tested.

Reduction of Complexity To reduce the complexity of the MAS design is one of the main objec-tives of the AOSE research area. For this purpose, DDE offers several views on a MAS. Each view (e.g. agent view, protocol view, deployment view, etc.) focuses on a certain aspect and abstracts from others. Changes that affect several views at the same time are automatically propagated to the others. Details on the DSML4MAS’s specific views are given in Section 5.3.

Model validation Most of the design errors made when building MASs can already be captured at the model level. DDE integrates the static semantics of DSML4MAS(cf. Chapter 4) utilized to check the syntactic correctness of the created models. For this purpose, constraints based on OCL have been manually derived from the formal Object-Z specification of DSML4MAS

to check the static semantics of the created models. These constraints are automatically evaluated during design time and support the developer to produce well-formed models.

Details on the OCL specification are given in Section 5.3.2.

Integration of Service-Oriented Architectures MASs do not exist in pure isolation. Instead, they need to be integrated and combined with other related technologies like for instance Service-Oriented Architectures (SOAs). Therefore, in (Hahn et al.; 2008b), we demonstrated how to

5.3. Models and Notation: The Concrete Syntax of DSML4MAS’S 117

integrate Semantic Web services into DDE. The service description can be defined at design-time and invoked by the run-design-time agents. Beside Semantic Web technologies, moreover, we provide a model-driven integration of SOAs into MAS defined in accordance to DSML4MAS. Chapter 8 is devoted to this integration.

Reusable Components DDE allows the user to reuse components (like plans, protocols, organi-zational structures, etc.) across several projects. This reduces development time and cost, and increases the quality of the components.

Refinement To support developers in specifying behaviors that conform to a certain protocol, we provide refinement functionalities that transform protocols into behaviors. This kind of refinement is part of the overall process guiding the design with DSML4MASand is presented in Chapter 6.

Extensibility DDE is seamlessly integrated into the Eclipse workbench. This implies that the community can easily develop own extensions for DDE (e.g. transformations, views, model validation, etc.) and plug them into the Eclipse workbench. Furthermore, the DDE directly benefits from new developments around the very active Eclipse modeling project⁶and other Eclipse tools.

Open source DDE is launched as open source project. The source code is published under LGPL and can be downloaded⁷for free.

5.3 Models and Notation: The Concrete Syntax of D

SML

4M

AS

’

S The previous chapter dealt with the abstract syntax defined by the PIM4AGENTSmetamodel and the semantics of DSML4MAS. The next step toward a graphical editor for DSML4MASis the specification of the concrete syntax. This section explains how the concrete syntax of DSML4MAS

is specified. After choosing the graphical notation for the concepts and relations, GMF by Eclipse is utilized to tie the domain concepts and their notation together.

5.3.1 Role of Notation

A common misunderstanding in the modeling world is the equality between a diagram and a model. Important to note is that a diagram is not a model. Instead a diagram is considered as a representation of some aspect or view of the model, using visual representation like lines, boxes, etc. According to the OMG way of thinking, the model is the whole machine-readable description of the system. Following this way of thinking, a modeling tool should not be only about the manipulation of a diagram, but generate a model that conforms to its metamodel. Apart from the model and metamodel, a diagram is from a user perspective the most important artifact (Booch;

1995).

Definition 5.3.1 (Notation, according to Booch (1995)

A notation serves as the language for communicating decisions that are not obvious or cannot be inferred from the code itself, provides rich enough semantics sufficient to capture all important strategic and tactical decisions and offers a concrete form for humans to reason about decisions.

6http://www.eclipse.org/modeling/

7https://sourceforge.net/projects/dsml4mas/

In order to determine a reasonable notation for MASs, we decided to adopt existing notations domain experts already use wherever possible, instead of re-inventing the wheel. However, as DSML4MASemphasizes on the complete development process from requirement specification to implementation, none of the existing proposals of suitable agent-based notations fits to 100 %.

Hence, we extended existing notations from the agent world and mixed it with basic notations from UML aiming at the development of a descriptive and distinguishable representation of the DSML4MASelements.

5.3.2 Nine Diagrams to Design Multiagent Systems

GMF provides the possibility of creating multiple diagrams for one graphical editor. In order to reduce complexity when modeling with DSML4MAS, we split the design into various diagrams, i.e. for each viewpoint of PIM4AGENTSat least one diagram is created. At this, the main intention is to make the design the most intuitive for the user by reducing the complexity of the designing process itself and thus allowing for separation of concerns. Even if the design is split into various diagrams, all different diagrams within one project share the same model, which is an instance of the PIM4AGENTSmetamodel. This feature has two main advantages as it allows (i) cross-checking among the diagrams and (ii) applying model transformations on one model. To illustrate how to model with DSML4MASin a graphical manner, we studied a very intuitive example, i.e. the conference management system.

5.3.2.1 Illustrative Example: Conference Management System using DSML4MAS

In order to demonstrate the notation of DSML4MAS, throughout this thesis, we want to use the development of an agent-based conference management system (CMS, (Padgham and Luck; 2007;

Zambonelli et al.; 2001)) as example that has already been used at the AOSE workshop in 2007 to provide a comparison between different AOSE tools and methodologies like O-MaSE (DeLoach;

2007), Tropos (Morandini et al.; 2007) and Prometheus (Padgham et al.; 2007b). Beside the good foundation we could base on, this case study is sufficiently familiar to most scientists, who already submitted a scientific paper to a conference or workshop.

For our purposes, the committee of a conference consists of the program committee chair, the program committee members, the reviewers, and the authors. These entities are now engaged in the following activities of the conference management:

• Submission phase: The program chair sends a call for papers to researchers that might be interested to contribute to the conference. If a researcher is interested in writing a paper, he/she has to submit his/her contributions before the submission deadline elapses.

The author then receives an acknowledgment of his/her submission together with a paper identification number.

• Reviewing phase: Once the submission deadline has passed, the program chair partitions the set of papers received and assigns them to the program committee members in accordance to their particular interests (possibly expressed through a bidding on papers the PC have a particular interest on). The members of the program committee review the papers by either contacting referees and asking them to review a number of the papers, or by reviewing the papers themselves.

• Paper selection and author notification: The result of the reviews is collected by the pro-gram committee members and is sent back to the propro-gram committee chair. Based on the reviewers’ recommendations, the chair is then responsible for making a decision, which

5.3. Models and Notation: The Concrete Syntax of DSML4MAS’S 119

Fig. 5.1: The notation of the agent diagram. From left to right, the notations of agent, plan, capability, and domain role are depicted.

paper to accept or reject. Once the decision has been made, the corresponding authors of

paper to accept or reject. Once the decision has been made, the corresponding authors of

In document A platform-independent domain-specific modeling language for multiagent systems (Page 143-169)