=Paper=
{{Paper
|id=Vol-1260/paper10
|storemode=property
|title=GIMT: A Tool for Ontology and Goal Modeling in BDI Multi-Agent Design
|pdfUrl=https://ceur-ws.org/Vol-1260/paper10.pdf
|volume=Vol-1260
|dblpUrl=https://dblp.org/rec/conf/woa/CossentinoNGLLR14
}}
==GIMT: A Tool for Ontology and Goal Modeling in BDI Multi-Agent Design==
https://ceur-ws.org/Vol-1260/paper10.pdf
GIMT: A tool for ontology and goal modeling in
BDI Multi-Agent Design
Massimo Cossentino∗ , Daniele Dalle Nogare ‡ , Raffaele Giancarlo‡ , Carmelo Lodato∗ ,
Salvatore Lopes∗ Patrizia Ribino∗ , Luca Sabatucci∗ and Valeria Seidita†∗
∗ Istituto di Calcolo e Reti ad Alte Prestazioni - Consiglio Nazionale delle Ricerche
Email: {cossentino, c.lodato, lopes, ribino, sabatucci}@pa.icar.cnr.it
† Dipartimento di Ingegneria Chimica, Gestionale, Informatica, Meccanica
Email: valeria.seidita@unipa.it
‡ Dipartimento di Matematica e Informatica
Email: raffaele.giancarlo@unipa.it, daniele.dallen@gmail.com
Abstract—Designing and developing BDI multi-agent systems The objective of our work is to provide a CASE tool for
would be facilitated by rising up the level of abstraction to use supporting designers in the goal identification activity. We
and by a methodological approach for managing it. To this aim exploit the results presented in [17] where two activities of
it is common the integration of goal oriented analysis techniques the preliminary phase of a complete methodological approach
with the design and implementation phases. were developed.
In this fashion, our experience is that the use of an ontology
in the early stages of the process is a great support for subsequent Model Driven Engineering (MDE) is an approach promot-
phases: goal modeling, agent design and implementation. How- ing the use of models as first-class citizens of a software
ever, we are aware that building and maintaining an ontology development process [19]. These models are, in many usual
has to be supported by appropriate tools. cases, defined using general-purpose modeling languages like
This paper proposes GIMT (Goal Identification and Modeling
the UML: the standard modeling language in the field of
Tool) as a further step towards the creation of a complete object oriented software engineering. Conversely, for restricted
methodological approach for developing multi-agent systems to domains, it is widely spread the use of so-called Domain Spe-
be implemented in the JACAMO framework. GIMT is a CASE cific Modeling Languages (DSMLs) [14]. They are specifically
tool for supporting ontology building and goal modeling. designed to meet the needs of the target application domain by
using specific concepts of the domain. A common practice of
Besides the advantages offered by an automatic tool, the other
novelty of this research is in the mapping between metamodeling MDE is that DSMLs are defined using a metamodel expressed
based on Model Driven Engineering (MDE) and Domain Specific with a general-purpose metamodeling language like MOF [15],
Modeling Languages (DSMLs) with the Eclipse plug-in develop- to name the most widely used one. These metamodels describe
ment environment. elements of the language the designer can instantiate at the
immediate meta-level below in order to build its own DSML.
I. I NTRODUCTION
The results presented in this paper are founded on the use
The integration of a high-level programming paradigm, of MDE as a key element for the development of the proposed
such as the BDI multi-agent systems, into a systematic ap- tool. The main contribution is the development of a CASE tool
proach, requires a revision of traditional instruments and based on a DSML we have defined in order to support the
tools for conducting the requirement analysis, in order to activities of the requirement analyses proposed in our previous
better fit with the well-known concept of goal. Much research work [17].
exists in the literature to deal with the goal oriented require-
ment engineering. We aim at developing a complete software It is well known that the joint use of DSMLs and CASE
methodology that includes a goal-oriented analysis, the design tools allows to guide and automate the model construction and
of agent organizations, and the support to the implementation transformation, resulting in an increase of both software de-
phase. velopment productivity and quality. The tool imposes domain-
specific constraints and performs model checking for detecting
The fundamental common theme in all these activities is and preventing many errors in the early phases of the process
the presence of an ontology. It is necessary for the definition life cycle.
of the problem and of the solution domain, but also for the
structure of messages and for organizing agent knowledge in The tool we propose has been developed by using Graphiti
beliefs. [5], an Eclipse-based graphics framework that enables rapid
development of state-of-the-art diagram editors for domain
Ontologies are essential for our approach. However, we models. Graphiti can use EMF [3] based domain models very
have faced the problem that building and maintaining them is easily but can deal with any Java-based objects on the domain
not trivial. A totally manual approach would add a significant side as well.
burden to developer that may impact the personal productivity
in the project. The rest of the paper is organized as follows, in the next
section we present the motivation of our work, in section III
we illustrate the methodological approach for which the tool <> <> <>
isPart_of Association is_a
has been developed, in section IV we present the tool, its 1 1 1
2 {same 2 {same
functionality and some technological issues on its construction subtype} 2 subtype}
<>
and finally in Section V we draw some conclusions. <> Ontology
isPrecondition Element
0..*
II. M OTIVATION AND O BJECTIVES <> <> 0..*
<>
Describes
isPostcondition 0..* Predicate 1..*
Much research has highlighted advantages and strengths of
0..* <>
MDE and DSMLs [8][19][7][14] in managing the complexity 1..* 1..*
<>
hasTarget
Concept
0..*
of domain concepts and domain abstractions while designing <>
1..*
<>
complex systems. These are fundamentals in our research. We Action
1..* isInput
have been working for a couple of years on the construction 0..*
<> 1..* <> <>
of a complete design process for modeling complex MAS executes Position Object
systems, including organizations, hierarchical structures and <> <> 0..*
<>
1..*
Intentional Unintentional
norms [18][13][11][12]. Action Action
executes
In order to develop such kinds of systems, we need to
manage abstractions such as organizations, goals, communica- Fig. 1. The Problem Domain Description Metamodel.
tions, messages, beliefs and so on. Thus we need a domain-
specific modeling language that includes these specific terms
as keywords. In addition, the methodological approach we are <>
Position
2 1 <>
generalize
<>
extDep
developing may be facilitated by the creation of CASE tools 0..1
for supporting designers in each part of their work. However,
customization of existing tools for different application do- <> <> <>
aggregate depend intDep
mains is not always easy or even possible. 1
Nowadays, several environments exist for DSMLs, some 2 <>
<> OR_Dep
of them are commercial such as Metaedit+ [21] and Ac- Goal 0..* 1..n
tifsource [1], some are open source and some others are 2
1
<>
decompose
developed as plug-ins for popular IDEs such as Eclipse Mod-
<>
eling Project [2] and Microsoft’s DSL Tools [6]. In particular, AND_Dep
Eclipse is an open and flexible framework, providing the API <>
HardGoal 0..*
<>
contribute 0..*
<>
SoftGoal
for adding functionalities perfectly integrated in the whole
working environment. Indeed, the Eclipse framework does not
support any specific task but the composition of a set of plug- Fig. 2. The Goal Description Metamodel.
ins gives Eclipse a particular “configuration” for specific needs.
The Eclipse community is committed at providing plug-ins for
generating graphical modeling tool. Recently, the Graphical to be implemented in the JACAMO framework [9]. The result
Modeling Project reached good results by using two interesting of [17] is a couple of design activities for identifying goals
technologies: Graphiti [5] and Graphical Modeling Framework from the ontological representation of the problem domain.
(GMF) [4]. The distinctive feature in the Graphiti technology
is the employment of the Ecore metamodel for representing In this paper, we complement this portion of the method-
all the elements and relationships at the base of the graphical ology with a CASE tool. It has been developed as an Eclipse
view1 . plug-in, for supporting designers in these two activities (Prob-
lem Domain Description and Goal Description). The Goal
Ecore metamodel is the modeling language used for cre- Identification and Modeling Tool (GIMT) has been conceived
ating models in the diagram editor. In other words, the use for being a MDE tool that automatically aids designers in some
of a metamodel corresponds to the definition of a DSML. of their activities.
Since in our work [20] we use metamodels for representing
the abstractions to be managed during design processes and III. G OAL I DENTIFICATION A PPROACH
to be reported in the models, we have a grounded theory
for representing the domain abstractions for each kind of In the proposed methodology [17] ontologies are used
application and upon which to construct a DSML. very early in the process. Goal Description is the preliminary
activity in which the analysts observe (and model) the strategic
One of the objectives of our research is (i) to support objectives of the software system and of its environment.
designers in the early phase of goal oriented requirements This is done with a close iteration with another activity: the
analysis for BDI MASs and (ii) to provide a CASE tool in Problem Domain Description. This activity is responsible of
order to aid the design of the goal model. creating a significant and transferable understanding of the
This line of research exploits the results of [17]. This is portion of the world where to introduce the software. The
part of a broader activity towards the creation of a complete collaboration of the two activities produces the elements of
methodological approach for developing multi-agent systems the environment (together with their significant states) that
are collected and therefore used for formalizing user goals,
1 We discuss our point of view on developing CASE tool with Graphiti and thus avoiding ambiguities, discovering tacit knowledge and
Ecore in section IV, for more details see [5]. simplifying the comprehension among stakeholders.
a
<> output>> input>>
output>> input>> output>> input>> output>>
Problem Statement Element List Problem Ontology Problem Ontology Goal Information Goal diagram
<>
Description diagram Description diagram [initial]
input>>
System Analyst input>> [initial] [final]
Generate Initialize Problem Refine Problem Compose Goal Describe Goals Initialize Goal Design Goal
Highlight
Ontology Ontology Ontology Description List diagram Diagram
Keywords
Domain Expert Elements List
<>
output>>
a input>>
<>
<>
input>>
Problem Statement Goal Diagram
Goal Patterns Goal List
[highlighted]
Fig. 3. The flow of work from Problem Statement to Goal Model.
In particular, the aim of Problem Domain Description • Refine Problem Ontology Description - it is a refine-
(PDD) activity is to identify and to describe the problem ment of the POD, by analyzing the the underlined
domain elements and their relationships. This activity adopts Problem Statement. The final version includes rela-
the metamodel depicted in Fig. 1. Main elements are: concept tionships among ontology elements;
(anything about which something is said), action (the cause
of an event by an acting concept) and predicate (a property, a In the Goal Description Activity, tasks are:
state or more generally a clarification to specify a concept). In
particular we use to distinguish intentional actions (implying • Compose Goal List - this is the first activity for identi-
a kind of consciousness to act) from unintentional actions fying goals, starting from the POD diagram. The Goal
(purely reactive), and objects (concepts that can perform only Patterns document is used for searching patterns in the
unintentional actions) from positions (concepts with inten- POD diagram by following the guidelines illustrated
tions). in [17];
This activity enables the Goal Description (GD) activity • Describe Goals - here the description on each goal is
that grounds on the ontology and exploits some recurrent completed by describing the elements a goal is com-
structures (Goal Patterns) that lead to identify goals (in terms posed of: goal type, name, state, who is responsible
of actor, and state transitions) and dependencies among them. for the goal and dependencies;
The work product resulting from this activity is the Goal • Initialize Goal Diagram - a first draft of the goal
diagram whose system metamodel is shown in Fig. 2. This diagram is prepared by using the previous goal list
metamodel grounds on two main concepts: Hard Goal and and a specific notation for representing each element
Soft Goal. A HardGoal [10][16] represents a strategic interest of the diagram;
of an actor. It is satisfied absolutely when its subgoals are
satisfied, and that satisfaction can be automatically established. • Design Goal Diagram - it provides a structured de-
A SoftGoal [10][16] is a goal having no clear criteria for scription of the goals, their dependencies and the
deciding whether it is satisfied or not. positions responsible for goal achievement, by using
a specific notation.
Fig. 3 goes into details of the flow of work for identi-
fying goals, starting from the problem statement and passing The advantage of this methodological approach is cor-
through the use of ontology. System Analysts and Domain relating goals with the corresponding portion of textual re-
Experts collaborate in Problem Domain Description and in quirements, thus supporting an iterative approach and a future
Goal Description Activity. evolution of the system. In order to support the designer’s work
In the Problem Domain Description Activity, tasks are: during the goal identification phase, we developed a MDE tool,
as an Eclipse plug-in, for which a specific modeling language
• Highlight Keywords - starting from an informal tex- has been created. This tool is introduced in the next section.
tual document describing the problem domain, an
underlined text document where nouns have been
highlighted, according to their grammatical function IV. G OAL I DENTIFICATION AND M ODELING T OOL
in the sentence, is produced; The Goal Identification and Modeling Tool (GIMT) is a
• Generate Ontology Elements List - previously high- CASE tool for supporting designers in performing all the tasks
lighted nouns are listed with respect to their types (Po- of the Problem Domain Description and Goal Description ac-
sition, Object, Predicate, Intentional or Unintentional tivity (see Fig. 3) for the representation of system requirements
Action); and the domain formalization, as proposed in [17].
• Initialize Problem Ontology - a first draft of the GIMT has been realized as an Eclipse plug-in by using
problem ontology description diagram is prepared by the Eclipse Modeling Framework (EMF) and Graphiti. It im-
using the previous list and a specific notation for plements the Domain Specific Modeling Language we defined
representing each element of the diagram (the SMME in order to create the models for representing the problem
and SMMR in the metamodel); ontology and the goal identification.
The key element for the implementation of GIMT is the representing the concrete elements and the relationships of the
Model definition. The EMF provides a modeling and code Problem Ontology Description Metamodel (see Fig. 1).
generation framework for Eclipse applications based on a
layered structure for data models. The information type of the POD diagram elements - Each element of a POD diagram
sets of model instances is defined in a so-called core model, is represented by means of a graphical notation and a specific
corresponding to metamodel in the Essential MOF (EMOF). stereotype. In GIMT, each element is also colored differently
Ecore is the metamodel adopted for core models. It contains to easily distinguish it, especially in large diagrams. Elements
the following elements: EPackage, EClass, EDataType, EAt- in a POD diagram may be:
tribute and EReference.
- Intentional and Unintentional Action that are repre-
Usually, in our work we use a system metamodel for sented as a cut corners rectangle with an Action Name.
formalizing the definition of all the elements and relation- They are differentiated by means of the stereotype.
ships, and for representing constraints on the enactment of They may be also connected to other elements such
design processes or part of them. Examples of metamodels as Object, Position and Predicate.
are reported in Figures 1 and 2. They respectively describe the
- Object is represented as a round corner rectangle with
Problem Domain Description and Goal Description activities.
an Object Name. Object may be input or target of an
The metamodelling techniques [20] are based on a metamod-
action. It may be connected with predicates or other
elling layered architecture, that follows the principles of MOF
objects.
and OMG [15]. As anticipated before, constructing plug-in
in Eclipse implies the definition of models that are based on - Position is represented by a simple rectangle with a
Ecore. Therefore we map our metamodel elements (SMME Position Name. A position may be connected only to
and SMMR) on EClasses and the relations on ERelations, as actions and other positions.
specified in the Ecore notation. Moreover, starting from an
EMF model, a set of Java classes have been generated for the - Predicate is depicted as a little sheet with a Predicate
model. Name. It may be connected with Position, Action and
Object.
Summarizing, GIMT is based on two metamodels, one for
each supported diagram, (see Fig. 1 and Fig. 2) and on a graph- POD diagram relationships - The elements in a POD
ical notation to represent the specific design elements. GIMT diagram can be related to each other by different kinds of
has been conceived to give the user the possibility to create relationship, whose semantic is quite intuitive2 . Relationships
two different diagrams for representing the problem domain in a POD diagram may be:
ontology and the goal model according to the guidelines we
previously introduced. - Association that is represented as usual by an arrow.
Elements in the diagram can be logically related with
In the following subsections we present the adopted nota- each other by using Associations.
tion and its usage into the specific GIMT diagrams.
- Is A is represented by the traditional symbol for
generalization. Is-a is the relationship between an
A. Diagrams and Notation ontological element and one of its refinements.
GIMT supports the Problem Ontology Description and the - Part Of is represented by the traditional symbol for
Goal diagrams. The graphical notation defined for our DSML composition. This relationship represents the whole-
and implemented in these diagrams is shown in Fig. 4 and it part relationship among ontological elements.
refers to the abstractions we use in our metamodels (see Fig.
1 and Fig. 2). The Goal diagram adopts the notation (see the right side
As regard the Problem Ontology Description diagram, it of Fig. 4) defined for representing the concrete elements and
adopts the notation (see the left side of Fig. 4) defined for the relationships of the Goal Description Metamodel (see Fig.
2).
Goal diagram elements - The graphical notation of the
Goal diagram is derived from a well-known graphical notation
[10]. Elements in a Goal diagram may be:
- A Hard Goal is represented by an ellipse with a Name.
It is always connected with at least one Position. It can
be also related with other Hard Goals and Soft Goals.
- A SoftGoal is depicted as a cloud with a Name. It can
be related to Hard Goals.
- A Position is referred to the same element described
in the POD diagram, but in this diagram it is depicted
as a sticky man.
Fig. 4. The notation adopted in GIMT for Problem Ontology Description
and Goal diagram. 2 Detailed definitions can be found in [17].
Goal diagram relationships - The elements of a Goal Di-
agram can be logically related to each other by using the
following kinds of relationships:
- Aggregate is the only relationship that can exist be-
tween Positions and Goals. Its notation looks like the
UML “part-of” relationship: a line starting with an
empty diamond.
- Contribute that is the relationship that can relate
HardGoal with SoftGoal and vice-versa. There are
four different types of contribution: positive, strongly
positive, negative and strongly negative [10]. Each one Fig. 5. Problem Statement Editor
is depicted with its own dedicated notation, as shown
in Fig. 4.
- EAttribute represents an attribute which has a name
- Depend relates two different goals. It may be an Inter- and a type.
nal Dependency or an External Dependency. Notations
- EReference represents one end of an association be-
are respectively a simple arrow and an arrow with
tween two classes. It has a flag to specify if it
dashed line.
represents a containment and the cardinality.
- Generalize, very similar to the UML inheritance, it - EDataType represents the type of an attribute, e.g. int,
specifies a relationship between Positions, in which float or java.util.Date.
specialized positions inherit features from the general
position. For space reasons we do not provide further details about
how to create an EMF editor plug-in but it is worth to note that
- Decompose relates two Goals. There are two kinds
the mapping is one to one in most of the cases: any element of
of decomposition: AND and OR. Both of them are
the system metamodel has a direct counterpart with an element
depicted as an arrow and a specific symbol (see Fig.
of the Ecore metamodel. Therefore, it is pretty straight to
4).
obtain an Ecore metamodel starting from a system metamodel
(like those in Fig. 1 or Fig. 2).
B. Ecore Metamodel Mapping
C. Using GIMT
Adopting a design process for developing a system gen-
erally means managing a set of abstractions (concepts of GIMT provides three kinds of editor: a textual editor for
the domain) that may be instantiated in one ore more work manipulating the problem statement and two diagram editors
products. In this work we use system metamodelling as one for modeling respectively the Problem Ontology Description
of the fundamental elements for the construction of CASE (POD) diagram and the Goal diagram. Moreover, GIMT has
tools. In particular, our technique [20] prescribes that a system been endowed with some functionalities that allow to automat-
metamodel is composed of: ically perform transitions between the tasks of our process.
- Element (SMME) is a construct of the metamodel that This section aims at describing how to employ GIMT as a
can be instantiated into elements of the system model; CASE tool for the portions of design process described in Fig.
3. The Conference Management System (CMS) case study3
- Relationship (SMMR) is a construct used for repre- has been used for exemplifying the description.
senting the existence of a relationship between two
(or more) instances of elements. For instance, the At this stage it should be clear that the flow of work
aggregation relationship between two instances of described in Fig. 3 is logically divided into two main portion of
the element class is an instance of the “association” work: the Problem Domain Description activity and the Goal
SMMR. Description activity. The first devoted to deliver POD diagram
in its final version and the second resulting in the creation
- Attribute (SMMA) is a construct used for adding of the Goal diagram. The GIMT tool aims at supporting the
properties to SMMEs. designer in the creation of these two work products.
- Operation (SMMO) is a construct used for describing As it can be seen in Fig. 3, the first three tasks of the
additional proprieties of an SMMEs. Problem Domain Description Activity: Highlight Keywords,
Generate Ontology Element List and Initialize Problem On-
Eclipse EMF makes the domain concepts explicit. It tology. These have to be performed following the guidelines
distinguishes between model and metamodel and uses the briefly introduced in Section III. GIMT provides a text editor
metamodel for ruling the structure of a model. The Ecore for loading or creating textual documents (such as a Problem
metamodel is the part of the EMF metamodel dedicated to Statement), in order to make easy the use of our guidelines.
define the following elements: It also comes with particular editing functionalities that allow
the identification of ontology elements.
- EClass represents a class, with zero or more attributes
and zero or more references. 3 A complete description of the CMS case study may be found in [22].
Fig. 6. Transition from Problem Statement Highlighted to Problem Ontology Description Diagram Initial.
The Document is the key element of the Problem Statement ontological element named AcceptingRejecting (see lower side
Editor (PSE), shown in Fig. 5. In a Document the designer can of Fig. 6). Hence, it is worth to point out that the Initialize
highlight words thus identifying specific ontological elements Problem Ontology task can be performed automatically with
(such as Intentional Action, Position and so on) according GIMT by means of an exporting functionality implemented in
to our guidelines [17]. For instance in the CMS problem the Problem Statement Editor.
statement (see upper side of Fig.6) the words authors and
In order to complete the Problem Domain Description
manuscript have been identified respectively as a Position
Activity, the last task is the Refine POD (see Fig. 3). GIMT is
and an Object. Then, these ontological elements can be au-
also endowed with an appropriate diagram editor that allows to
tomatically exported into a POD diagram where they will be
handle the structural aspect of problem ontology elements by
represented according to their notation (see lower side of Fig.
organizing them and by adding relationships or other elements.
6).
The upper side of Fig. 7 shows the POD diagram for the CMS
Fig. 6 represents the portion of the work devoted to produce case study. This diagram has been obtained by refining its
the POD diagram in its initial version (see Fig. 3). In fact, in initial version (see the lower side of Fig. 6) derived from the
the upper part of Fig.6, the words highlighted with appropriate previous task. The POD editor allows to edit a POD diagram,
labels correspond to ontological elements that are added to a by managing elements imported from the previous phases, but
list (the Element List4 work product). Then, elements may be also adding new ontological elements and relationships. For
exported from the list to be added to the Problem Ontology instance, the Position author, the Intentional Action submit
Description diagram [initial] for its refinement. and the Object manuscript previously identified (lower side of
Fig. 6) have been opportunely related (top/right side of Fig.
Moreover, the GIMT Problem Statement Editor provides 7).
also functionality for grouping words to be identified as a
unique ontological element by means of a Connection. A The Refine POD task completes the Problem Domain De-
Connection is a link that allows to relate also two non- scription activity and the POD diagram [final] is the resulting
consecutive text portions. For instance, in the CMS case study artifact. So far, the second activity of our process can start
(see upper side of Fig. 6) we want to identify the words (Fig. 3): the Goal Description. As our guidelines prescribe, the
accepting and rejecting as the same Intentional Action. To do first task is Compose Goal List that identifies specific patterns
this, we firstly select the two words and then we relate them by from the POD diagram. Fig. 8 shows an example of a common
means of a Connection (represented as a dashed arrow). As a pattern5 that can be discovered in a POD diagram. It is worth
consequence, GIMT will automatically refers them as a unique to note that a pattern is characterized by compartments: i)
a generic schema of the ontological elements and ii) the
4 The Element List is not clearly visible to the designer. It maintains
information about ontological elements and it may be exported by the tool. 5 Further detail of patterns can be found in [17].
Fig. 7. Transition from Problem Ontology Description Diagram to Goal Model.
description of goal information that can be extracted if the information(see Fig. 9): Goal Type=Achieve, Name= To submit
pattern matches (goal type, goal name and so on). For instance, manuscript, State= submitted manuscript, Who= author.
the ontological elements triple, author, submit and manuscript
in the upper side of Fig. 7 corresponds to the pattern shown in Finally, GIMT supports the Design Goal Diagram task by
Fig. 8. The POD editor supports this task, by allowing multiple providing a Goal Diagram Editor. Previously created goals
selection of elements, thus generating the goal related to the may also be automatically exported in a goal diagram. The
specific pattern and adding it to the goal list. A thicker red functionality implemented in the Goal Diagram Editor allows
border is used to highlight the elements already selected by the designer to describe more in detail the dependencies
the designer. between the imported goals and the Positions that perform
them. For instance, by applying the pattern of Fig. 8, another
Pattern N°2 Pattern N°3 goal can be extracted from the POD diagram of the CMS case
executes target study: To maketarget
executes review (Fig. 7). The goal To make review and
Act Position1 Act Object1 Position1 Position2
the goal Act
To submit manuscript in the initial version of the Goal
Diagram were not related. By reasoning on the diagram with
Goal Information Goal Information
Goal type: Achieve the support of our guidelines, the designer is able to discover a
Goal type: Achieve
Name: To+ + Name: To+ +
Dependency among these two goals and to refine the diagram.
ng' () State: + 'ed' () State: + 'ed' ()
nsible for achieving the goal Who: Position1 is responsible for achieving the goal Who: Position1 is responsible for achieving the goal
Dependency: None Dependency: None
It is worth noting that our process is iterative. Thus, at
PreCondition: None PreCondition: None
Note: it may also be Position1=Position2
Fig. 8. Pattern extracted from [17].
The POD editor also provides a functionality in order to
automatically perform the second task of the Goal Description
activity, that is Describe Goals. This task consists in setting
the goal information according to the identified pattern. A
specific form (see Fig.9) allows to add all the information that
is not automatically settable, such as the information about
the Dependency. For instance, the triplet previously identified
corresponds to a goal with the following, automatically set, Fig. 9. The Goal Information frame.
each iteration it is important to trace (forward and backward) [10] P. Bresciani, A. Perini, P. Giorgini, F. Giunchiglia, and J. Mylopou-
the ontology model with the goal model. GIMT maintains los. Tropos: An agent-oriented software development methodology.
a traceability of the elements during model transformation. Autonomous Agents and Multi-Agent Systems, 8(3):203–236, 2004.
Each diagram of GIMT, in fact, uses a single persistence [11] M. Cossentino, A. Chella, C. Lodato, S. Lopes, P. Ribino, and V. Seidita.
A notation for modeling jason-like bdi agents. In Complex, Intelligent
file model. A typical scenario that can occur is, for example, and Software Intensive Systems (CISIS), 2012 Sixth International Con-
the deletion of a goal from the goal diagram. In this case, ference on, pages 12–19. IEEE, 2012.
the linked ontological elements will be affected. The tool [12] M. Cossentino, C. Lodato, S. Lopes, P. Ribino, V. Seidita, and A. Chella.
automatically removes the ticker border in the POD diagram. A uml-based notation for representing mas organizations. In WOA,
This functionality allows also to create a direct link between a pages 133–139, 2011.
goal and portion of problem statement from which it derives. [13] M. Cossentino, C. Lodato, S. Lopes, P. Ribino, V. Seidita, and A. Chella.
This is important when conflicting or inconsistent goals are Towards a design process for modeling MAS organizations. In Massimo
Cossentino, Michael Kaisers, Karl Tuyls, and Gerhard Weiss, editors,
discovered. Thus, the possibility to go back to the textual Multi-Agent Systems, volume 7541 of Lecture Notes in Computer
description that originated the problem may help to solve the Science, pages 63–79. Springer Berlin Heidelberg, 2012.
inconsistency. [14] S. Kelly and J.P. Tolvanen. Domain-specific modeling: enabling full
code generation. John Wiley & Sons, 2008.
V. C ONCLUSIONS [15] OMG meta object facility, version 2.4.2, april 2014.
doument formal/2014-04-03, available at http://www.omg.org.
GIMT has been designed and developed in order to over- http://www.omg.org/technology/documents/formal/mof.htm.
come the limitations of the manual approach proposed in [17] [16] J. Mylopoulos, L. Chung, and E. Yu. From object-oriented to goal-
especially when it has to be applied to large size problems. oriented requirements analysis. Communications of the ACM, 42(1):31–
37, 1999.
Such an approach grounds on two main models (an ontology
and a goal model) and on a set of guidelines allowing model to [17] P. Ribino, M. Cossentino, C. Lodato, S. Lopes, L. Sabatucci, and V. Sei-
dita. Ontology and goal model in designing bdi multi-agent systems.
model transformations. Hence, GIMT has been conceived as a In WOA@AI*IA, Proceedings of the 14th Workshop ”From Objects to
CASE tool based on a DSML opportunely defined to support Agents” co-located with the 13th Conference of the Italian Association
the goal oriented requirement analysis proposed in [17]. It has for Artificial Intelligence (AI*IA 2013), Torino, Italy, volume 1099,
also been endowed with some functionalities that support the pages 66–72, December 2-3 2013.
designer in applying the guidelines to perform the activities [18] P. Ribino, C. Lodato, S. Lopes, V. Seidita, V. Hilaire, and M. Cossentino.
A norm-governed holonic multi-agent system metamodel. In Agent
of the approach (i.e: the Problem Domain Description and the Oriented Software Engeneering (AOSE), 2013.
Goal Description activity). Moreover, in some cases GIMT
[19] D.C. Schmidt. Model-driven engineering. Computer, 39(2):25–31, Feb.
automatically executes some tasks of the process. 2006.
The work illustrated in [17] is a part of a broader work [20] V. Seidita and M. Cossentino. Metamodeling: Representing and
modeling system knowledge in design processes. In In Proceedings of
towards the creation of a complete methodological approach the 10th European Workshop on Multi-Agent Systems, EUMAS 2012,
for developing multi-agent systems to be implemented in the pages 103–117, 2012.
JACAMO framework. Thus, new models will be included in [21] J.P. Tolvanen and M. Rossi. Metaedit+: defining and using domain-
order to face other design issues. Hence, we decided to develop specific modeling languages and code generators. In OOPSLA ’03:
GIMT as an Eclipse plug-in by using the Graphity framework, Companion of the 18th annual ACM SIGPLAN conference on Object-
thus ensuring us a rapid development and integration of new oriented programming, systems, languages, and applications, pages 92–
93, New York, NY, USA, 2003. ACM Press.
diagram editors and a great flexibility to extend our DMSL.
[22] F. Zambonelli, N. Jennings, and M. Wooldridge. Organizational rules
We found in Ecore a very easy and fast way to produce as an abstraction for the analysis and design of multi-agent systems.
DSML due to its almost one to one mapping with our meta- Journal of Knowledge and Software Engineering, 2001.
modeling techniques.
R EFERENCES
[1] Actifsource, available at http://www.actifsource.com.
[2] Eclipse Modeling Project,
available at http://www.eclipse.org/modeling/.
[3] EMF - Eclipse Modeling Framework,
available at http://www.eclipse.org/modeling/emf/.
[4] GMF - Eclipse Graphical Modeling Framework,
available at http://www.eclipse.org/modeling/gmp/.
[5] Graphiti - Graphical Tooling Infrastructure,
available at http://www.eclipse.org/graphiti/.
[6] Microsoft visual studio sdk including domain-specific language tools,
available at http://msdn.microsoft.com/en-us/library/bb126259.aspx.
[7] U. Aßmann, S. Zschaler, and G. Wagner. Ontologies, meta-models, and
the model-driven paradigm. Ontologies for Software Engineering and
Software Technology, pages 249–273, 2006.
[8] C. Atkinson and T. Kuhne. Model-driven development: A metamodeling
foundation. IEEE Software, 20(5):36–41, September/October 2003.
[9] O. Boissier, R.H. Bordini, J.F. Hübner, A. Ricci, and A. Santi. Multi-
agent oriented programming with jacamo. Science of Computer Pro-
gramming, 2011.