Since it was first released, the i* framework has been adapted to the needs of specific research groups that wanted to represent concepts specific of their software engineering problem, like security, law compliance, trust modelling, architectural design, model-driven development and agent-orientation, among others. Even, the i* framework itself has experienced a natural evolution that has led to a slightly modified version available in the i* wiki. This set of main i* variations have been object of our study which we have described and genealogically analysed in [1]. This diversity, although not necessarily pernicious, has some consequences. When reading a work around the i* framework, it is necessary first to understand what concrete version of i* is being used. If the contribution is based on the original framework, sometimes the authors declare which version are using (lately, it is happening to be the wiki version), but sometimes there is no explicit mention, which often makes the reader a bit hesitant about details of the proposal being presented. On the other hand, if the work is proposing some new variation, the semantics is sometimes given informally or by using a formalism which is not easy to align with the available descriptions of i*. In order to deal with this problem we proposed at 2005 a reference metamodel for i* [2] where particular metamodels of i* variations can be obtained by applying UML refactoring operations. Since then, we have revised this metamodel upon which we have based our research work on: i* inheritance, requirements interoperability, and metrics frameworks among others.
In this report-of-progress paper, we review our proposal of metamodel for the i* framework, we show our updated version and outline several contexts in which it has been used to formalize our i*-related proposals. In particular, our main objective has been to define a metamodel able to express most of the current variations and extensions of the i* framework and to use this metamodel as a reference model for our lines of research. More precisely, we have worked with four specific objectives in mind: (i) To define a metamodel for the i* framework not bound to any particular technology, (ii) To use this metamodel as the underlying baseline for defining a i* diagram interchange format, iStarML, (iii) To use this metamodel as a reference framework over which formulating our own extensions and variations of i*, namely a full definition of inheritance and the concept of module, and (iv) To use this metamodel as the syntactic baseline over which formulating a framework for the definition of metrics on i*.
As a first tangible contribution, we are proposing an i* metamodel compliant with the objectives stated in Section 2 (generality, flexibility, technological independence; see Figure 1). It has been built by consolidating several main versions of the framework, as thoroughly described in [1]. It presents some superclasses of interest (Node as the most general one, and also DependableNode and IntentionalElement) and then the most relevant i* concepts: Actor, SR-Element and SD-Dependum as classes, and Relationship and Link as association classes, all of them with the appropriate subclasses.
The iStarML interchange format [3,4] has being designed starting from the metamodel. The format implements the metamodel as an XML grammar and also supports the possibility of extension with new constructs. The ccistarml v0.6 Java package (http://www.essi.upc.edu/~ccares/ccsoftware/ccistarml_v0.6.1.zip) allows creating, importing and handling iStarML-compliant files. Several tools have been and are being customized to support importing and exporting iStarML. Remarkably, the HiME tool (http://www.lsi.upc.edu/~llopez/hime/) supports both export and import, whilst we have developed an online translator from OME .tel files into iStarML (http://www.essi.upc.edu/~ccares/index.php?section=ometranslator). It is planned for adoption in a next release of TAOM4E (http://sra.itc.it/tools/taom4e/).
The inheritance proposal presented in [5,6] and the module construct as defined in [7] have been related to the metamodel. This makes the definition of both concepts easy to integrate into the i* framework. In the case of inheritance, the integration is very tight since inheritance appears in the metamodel itself, therefore we are just providing a more detailed definition of a core concept. The concept of inheritance has been implemented in the HiME tool presented above, supporting the three operations identified in [5]: extension, refinement and redefinition. As for modules, the option has been to integrate in a loosely coupled way, meaning that modules are linked to the metamodel but the metamodel is not modified. Figure 2 provides an excerpt of both modifications. We may observe that in addition to actor inheritance, we are allowing the refinement of dependencies and intentional elements in general, and extension and redefinition only for SR-elements. Concerning modules, in addition to the general concept of module, we identify SD-modules and SR-modules. SR-modules may be of different types too, e.g. for storing means-end decompositions. New classes are introduced for these concepts, coupled to their counterpart elements in the metamodel. As a last remarkable use of the i* metamodel, we have used it as the baseline for formulating an i* metrics definition framework. In [8], we have provided a catalogue of metric definition patterns in which their form is expressed as an OCL template involving metamodel elements (see Figure 3 for an example). In [9], we have illustrated a particular case of application, the definition of a metric suite for business process modeling. In this exemplar we may observe the general procedure in which an extension of the i* metamodel for capturing the essential concepts of the domain of interest (business processes in this case) is needed. Then, the metric suites that exist in this domain are mapped into their counterparts using a metamodel mapping.
Some metrics have sense when applied to dependency links
The metrics will depend not just on the characteristics of the dependency link itself, but also on the two actors that act as depender and dependee
Identify three different factors that influence the metrics: one bound to the dependency link itself (probably related with the type of its dependum), and the others to the two actors, depender and dependee
The effect of the depender, the dependee and the dependum in the metric, represented by three functions: filter: Dependum Float correctionFactorDepender: Actor Float, correctionFactorDependee: Actor Float
This main purpose of this paper has been twofold. On the one hand, illustrating the form that the i* reference metamodel takes by including a particular proposal. On the second hand, providing an overview of the different uses of such a metamodel in different contexts that may be of general interest for the i* community: for model interchange, for definition of new concepts and for definition of metrics.
Several authors agree on our belief that the existence of an i* metamodel could bring some benefits (shared understanding, tool interoperability, etc.) to the i* community [10,11], although the statement could in fact be a matter of discussion, and in fact some other researchers advocate for more focused metamodels like the Tropos metamodel [12] and the GRL metamodel [13]. Our view is that the differences among the several existing approaches concerning the core concepts of i* are not so severe as to prevent the proposed agreement, whilst the potential benefits seem attractive enough.
We think that the most important future work is a community work: agreeing on a metamodel as the "official" i* framework metamodel the one presented here or other), making it available in the i* wiki for reference. Its existence shall provide a shared context to i* researchers and practitioners, and shall serve as reference for: new extensions and variations, semantic and pragmatic agreements, tool support, etc.
Concerning our particular future work, we plan to advance in the following research lines: (1) using iStarML as the technological infrastructure to connect as many available tools as possible. This also means coping with the mapping problem where a construct that is used in some source tool is not supported in some destination tool. An example of how to deal with this case has been presented in [4]; (2) completing the definition of inheritance, providing the necessary restrictions on the use of the identified operations (extension, refinement and redefinition [5]) in the form of OCL constraints over the metamodel elements; (3) creating a comprehensive catalogue of metrics suite based on the use of the patterns identified in our previous work; (4) implementing the concepts presented here (inheritance, modularity and metrics) using our HiME tool, and (5) providing semantics to the metamodel (i.e., how the different concepts proposed in the metamodel should be interpreted).