There are several tools currently available in the i * community. These tools have di erent features and purposes. Choosing the most adequate tool for a speci c modelling situation can be a challenge. To overcome this di culty, we present a systematic comparison of the i * tools listed in the i * wiki page, according to their features, syntax coverage and semantic analysis support. Our comparison highlights the di erent strengths of those tools, to help identifying situations for which each tool might be particularly useful. We contribute with an aggregated vision of current i * tool support to the body of knowledge of the i * community. In addition, this comparison also helps identifying opportunities for further evolution of the surveyed tools.
Introduction The i * framework is a modelling language that covers both agent-oriented and goal-oriented modelling. There are several variations of the i * framework, such as Yu'95, TROPOS, Secure Tropos, Iterative Tropos, and GRL. There are also several tools currently available to create i * models. Those tools have di erent features, purposes, and various levels of conformity with the i * syntax (usually alligned with one of the above-mentioned i * frameworks).
Choosing the best tool for a speci c purpose can be a challenge, not only
because one has to select the most suitable i * framework for the task, but also
because di erent tools targeted to the same i * framework provide di erent kinds
of support for the speci cation of an i * model, not only on the syntactic, but
also on the semantic level. This support includes di erent levels of correctness
checking of the created models. The i * wiki page [
In this paper we present a systematic comparison of syntactic and semantic features supported by the di erent i * tools. We use the language description available from the i * wiki to guide our comparison. This provides a languageoriented comparison of the i * tools, which bridges an important gap in the scope of the comparison currently available in the i * wiki.
This paper is organized as follows: in section 2, we summarize the objectives of this i * tools comparison; in section 3 we provide a detailed comparison of the i * tools, focusing on the syntactic coverage and semantics checking of the i * models; nally, in section 4, we present conclusions and further work. 2
Objectives of the Research Our goal is to analyze i * modelling tools, for the purpose of their comparison, with respect to their syntax coverage, and semantic checking support from the point of view of a requirements engineer, in the context of a survey of the existing tool support available to the i * community.
More speci cally, we aim to answer the following two research questions: { RQ1: Which of the syntactic constructs described in the i * wiki are supported by the i * tool? { RQ2: To what extent does each i * tool support semantic checking of the i * models built using it? 3
Scienti c Contributions
In order to answer our research questions, we tested available i * tools. The
criteria used for the inclusion of the tools in this analysis was their presence in
the i * wiki page [
OpenOME [2] is an Eclipse-based tool designed to support goal-oriented, agent-oriented and aspects-oriented modelling and analysis. It is an open source tool and researchers can propose further branches and extensions to the tool. TAOM4E [3] is an Eclipse plug-in that supports a model-driven, agent oriented software development. GR-Tool [4] is a graphical tool for forward and backward goal reasoning in Tropos. STS-Tool [5] is a socio-technical security modelling tool to draw Tropos and Secure Tropos models and to perform the e ective formal analysis of functional and security requirements. jUCMNav [6] is an Eclipse plug-in for modelling, analysis and transformation in both GRL and UCM (Use Case Map) notation. It is intended for the elicitation, analysis, speci cation and validation of requirements. DesCARTES [7] is an Eclipse plug-in that supports various models, such as i *, NFR, UML and AUML models in the context of Tropos and I-Tropos development. The tool allows the development of the methodology analysis and design models as well as forward engineering capabilities and an integrated software project management module.
All the tools were tested in Arch Linux x86 64 and Windows Vista 32 bits, both with Java Runtime Environment 1.6.0. For the tools that are an Eclipse plug-in, the version of the Eclipse was Indigo (3.7) for TAOM4E and Juno (4.2) for jUCMNav and DesCARTES, with Eclipse Modelling Tools.
The syntax coverage analysis aims to check if the tool has a) the basic i * syntax; and b) the graphical notation of the i * syntax (according to the i * wiki page). Table 2 shows this analysis. The cells with \Yes" denote that the tool complies with both criteria presented earlier. The cells with the symbol \*" after \Yes" mean that the tool complies with a) but not with b); i.e., it has a di erent notation for the given element. The cells with \No" show that the tool does not comply with any of the criteria.
The GR-Tool is the only not supporting any type of actor, as it is mostly targeted to goal reasoning. OpenOME is the only tool that supports all types of actors with the i * graphical notation. Actors links are often not provided and are only fully supported in OpenOME and jUCMNav. The STS-Tool also supports a type of actor association, namely the association \plays".
Concerning elements, all the tools support goals. Only jUCMNav has all kinds of elements of the i * graphical syntax. DesCARTES also supports all element types, but two of them use a non-standard notation.
With respect to the support for dependency links, the tools which support them only have commited elements, but not open or critical elements. The GRTool and STS-Tool do not support any kind of dependency links.
All the tools have at least two types of contribution links and all of them have the \and" link. It is in the contribution links that the variation of the notation according to the graphical notation of i * syntax is higher. OpenOME and jUCMNav are the only tools that have all types of contribution links.
As can be observed, OpenOME is the tool with the widest syntax coverage according to the two criteria described above and if it complies with the rst one, it always complies with the second. jUCMNav complies with the rst criteria except for dependency strengths but not always complies with the second one.
The semantic analysis aims to determine the level of corretness checking of the created models. Using the descriptions and guidelines available in the i * wiki, we analysed if the tool veri es when a modelling error is made. Table 3 shows a set of errors and if the tool veri es those errors or not. The N/A means that the tool does not have one or more elements needed to do the evaluation.
Yes Yes No No No No No No No No No Yes Yes Yes* Yes No Yes Yes Yes No No No No No No No Yes Yes No Yes No
No No No No No No No No No No No Yes No No No No No No No No No No Yes* Yes* Yes* Yes* Yes Yes No No No
No No Yes Yes No No No Yes No No No Yes No No No No No No No No No No No No Yes* Yes* Yes Yes No No No
Yes Yes Yes* Yes* Yes* Yes* Yes* Yes* Yes* Yes* Yes* Actors and relations Actors without links Actor inside another actor boundary Dependencies Dependency link without a dependum Dependency links with di erent directions Dependency link inside an actor boundary Other link rather than dependency link between an element and an actor Associations ISA between actors of di erent types Is-part-of between actors of di erent types Other association rather than Plays between Agent and Role Other association rather than Covers between Position and Role Other association rather than Occupies between Agent and Position INS between others than agents Associations between elements that are not actors Internal Elements SR elements outside actor boundary Softgoal decomposition in sub-softgoals or sub-tasks Goal decomposition in sub-goals or subtaks Goal decomposition without means-end Means-end where a goal is the mean Means-end di erent from \task{>goal" Decomposition beyond the actor boundary Means-end beyond the actor boundary Means-end decomposition to re ne a softgoal Softgoal decomposition without contribution links Any kind of direct relation between goals Link between an element inside the actor boundary and that actor Contribution Links Contribution links between any element to any element rather than softgoal Contribution link between actors Contribution link between goals and subgoals or sub-tasks Yes* Yes Yes* No Yes* Yes No No No No No No Yes No No No No No No No No No Yes* Yes* Yes No Yes No
No Yes Yes Yes Yes Yes N/A N/A N/A N/A N/A N/A N/A Yes No No No No No Yes Yes No No No Yes No Yes No
N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A No
No Yes N/A N/A N/A Yes N/A N/A Yes N/A N/A N/A Yes Yes N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Yes N/A Yes Yes
No No Yes No Yes No Yes Yes Yes Yes Yes Yes Yes No No No No Yes No No No No No No Yes Yes Yes Yes
No Yes Yes Yes N/A Yes N/A N/A N/A N/A N/A N/A N/A N/A Yes Yes Yes No No N/A N/A Yes No Yes N/A No Yes No
Some of the OpenOME categories are labeled with \Yes*". This means that the tool itself does not perform the corresponding analysis by default, but can do it with the add-on \Syntax check". However, syntax checking does not work for Linux and may not work for Mac as the executable version of prolog is not available for these platforms. In jUCMNav, it is necessary that the static semantics checking properties are selected.
i * tools support error prevention in two di erent ways. One is by not allowing the user to do what he intends, if it is not correct. The other one is by allowing the user to do so, but inform him that the resulting model is incorrect. In general, the level of correctness checking of the created models is not too deep. Note that the set of modelling errors that can be made depends on the available modelling elements, which vary from one tool to the next. On average, about 39% of the considered modelling errors are not applicable, due to the lack of support of the corresponding modelling elements by the tools.
There are some errors that all the tools (except those that do not support the used model elements) verify. This is the case of a dependency link without a dependum, associations between elements that are not actors, a link between an element inside the actor boundary and that actor, and a contribution link between actors. The opposite can also be noticed, i.e., there are some errors that none of the tools verify. This is the case of means-ends relations di erent from \task{>goal", softgoals decomposition without contribution links and contribution links between any element to any element rather than a softgoal.
jUCMNav is the tool with the highest number of veri ed errors, with a verication percentage of 50%, followed by OpenOME and TAOM4E. They are also the tools with the lowest number of errors that were not possible to analyse. 4
Conclusions and Future Work This paper provides a systematic comparison of some i * tools, listed in the i * wiki. The goal here is to complement existing comparison work by providing a comparison on syntatic and semantic properties of the i * modelling tools.
The contribution of this work is to provide relevant information to practitioners when selecting an i * tool, to tool developers when improving existing tools, and to researchers when studying the shortcomings of existing tools.
We plan to extend this analysis to other tools and include non-functional aspects in the evaluation.