The clear definition of a metamodel can be considered helpful for any conceptual modeling approach, and the i* framework is not an exception. Agreeing on a metamodel for i* can be considered even more convenient than ever when we are aware of the different dialects and variations that the community proposed, and keep proposing, over the seminal i* definition. In this paper we present the revised version of the i* metamodel proposed by the GESSI research group at 2005 and we report some current contexts of use: 1) definition of a data interchange format; 2) definition of the inheritance construct; 3) definition of a modularity construct; and 4) definition of a metrics framework.
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 [
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* [
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*. 3
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 [
The iStarML interchange format [
The inheritance proposal presented in [
As a last remarkable use of the i* metamodel, we have used it as the baseline for
formulating an i* metrics definition framework. In [
Name Context Problem Solution Required knowledge Form
Dependency-Based (Metrics Definition -> Quantitative -> Structural) 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 context Dependency::metric(): Type let ownerActor(x: DependableNode): Actor =
if x.oclIsTypeOf(Actor) then x else x.owner in: post: result = self. dependum.filter() * ownerActor(self. depender).correctionFactorDepender() * ownerActor(self.dependee).correctionFactorDependee()
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 [
We think that the most important future work is a community work: agreeing on a metamodel as the “official” i* framework metamodel (being 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 [