iStarML is an XML-based format for enabling interoperability among i* tools. Its main design focus was to support data interchange even when involved tools implement different i* variants. In this paper we analyse required changes to the format from two main sources (i) the evolution of i* into a consistent and clear set of core concepts expressed in the new iStar 2.0 specification and (ii) recurrent necessities due to a wide use of i* modelling. In order to address these requirements, we propose new XML elements to be considered in a new version of iStarML: iStarML2.0
As an effect of the past and even current proliferation of different i* variants,
interoperability has become a non-functional requirement hard to accomplish by i* tools.
iStarML [
iStarML 1.0 was defined according to an extensible i* metamodel [
Copyright © 2016 for this paper by its authors. Copying permitted for private and academic purposes. of core concepts, not losing the open the ability of i* to tailor the framework. In this sense, iStar 2.0 is aligned to the iStarML goal of making the language as much extensible as possible. Referent to the concentric ring structure of iStarML (Fig 1), the iStar 2.0 is defining the concepts included in the two inner rings.
The iStar 2.0, presented in [
As any other modelling language, its wide use has resulted in a set of new requirements
which has been discussed by i* research community. First, scalability as the problem of
dealing with large i* models [
iStar2.0’s intentional element link types
Moreover, we aim to keep expressiveness of first iStarML proposal and to add backward
compatibility that is a common criterion for format evolution [
In Table 1 we have summarized a set of addition or change proposals to iStarML1.0 in order to consider above requirements. Additionally to the requirements coming from the iStar 2.0, we also include an initial solution addressing traceability, scalability and analysis. Although traceability is a relevant requirement, it seems necessary to analyse if existing version control tools (like Mercurial, Apache subversion and so on) may give enough support. Including the notion of view defined by iStarML 2.0, the boundary can be open or closed, and extending this property to the other elements in the model, we are addressing in an initial way the scalability requirement. Finally, for analysis support, we include new properties in some elements in order to define metrics associated to them.
interoperability of unfinished models (traceability)
To enable analysis {is_part_of, instance_of, covers, <string> } is_a, plays, occupies, <dependency> Definition: dependerTag {dependerTag} {dependeeTag} <boundary> <ielement> <actor> <actor> and <ielement> 4
The formulation of a new standard is a collective task of several stakeholders in order to solve a common problem under a shared perspective. This have addressed the formulation of iStarML 2.0 at an early stage. Firstly, we have reviewed the design principles of iStarML 1.0 and gathered from the i* research community their main evolving requirements at modelling time. A key milestone was the generation of a consensuated iStar2.0 metamodel which has motivated four of the nine extensions to iStarML 2.0. The other extensions are participates-in, <string> } {dependerTag | dependeeTag}
<metric> Metric attributes: name=<name> value=<value> [type=<metricType>] previous links can be processed as an instance of <string>
intentional elements from wants association must be hidden when style is closed
elements from refines association must be hidden when style is “closed”.
Acknowledgments. (TIN2013-44641-P).
This work has been supported by the Spanish project EOSSAC related to modularity, one to enable i* model assessment and propagation analysis and one to deal with a particular element of traceability.
The future work includes promoting a shared standard proposal and to provide basic tools to deal with generation, reading, parsing, analysis and evolution of i* models represented in iStarML 2.0