iStar has been extended since its initial proposal in the 90's. In a previous work we have identified that 96 extensions had been proposed until 2016. It is worth noting that since 2016 the language notation is under standardisation. However, new extensions continue to be proposed. So, it is essential to discuss extension mechanisms to be included in the new standard. Hence, in this paper, we present some preliminary results related to this topic. We performed an exploratory study to analyse previous extensions and identified patterns of lightweight representations. The results of this study point out to 8 objectives and their representations. Furthermore, we used a survey to identify the opinion of 12 experts about this theme. Most of the participants considered important to include extension mechanisms in iStar, and indicated the light-weight representations of extensions that should be considered in this proposal. Finally, we discuss possible ways to propose the extension mechanisms in iStar 2.0 and present a preliminary proposal of these mechanisms.
Several iStar extensions have been proposed since the proposal of Yu [
This paper presents results of three studies, two of them analyses the existing iStar extensions and the last one proposes a preliminary version of extension mechanisms. The first study (Section 4.1) identifies the light-weight representations used in existing iStar extensions and we counted the occurrence of each one to show a ranking of these representations.
The second study (Section 4.2) is a survey which the main goal was to evaluate
which light-weight representations of the first study (presented in Table 1) should be
included as standard extension mechanism in iStar 2.0 and if the language should
have extension mechanisms. We followed the principles of Survey Research proposed
in [
The third study (Section 4.3) is a preliminary proposal of extension mechanism based on a benchmark of other modelling languages and the results of studies 1 and 2 of this paper. The selected light-weight representations were considered to define the default properties in our proposal. 3
Extension mechanisms have been proposed similarly to the User Requirements
Notation (URN) [2 and 8] and Unified Modelling Language (UML) [
URN is a modelling language that joined Use Case Maps (UCM) and GRL. URN
is specified as an international standard [
For a long time, UML had three extension mechanisms: stereotypes, tagged values and constraints. These mechanisms are textually represented, as stereotypes are represented between << >> and tagged values and constraints are represented between {}. The profile diagram was included recently in UML, and it is used to define profiles based on the extension mechanisms which are applied to the models during modelling time. The UML specification cites that in theory the profiles capability can be used to define extensions for metamodels other than UML. 4 4.1
We analysed the existing iStar extensions in [
The purpose of Node Identifier is to identify a goal/quality/task/resource with a short label that is used in some situations: i) it is used together with a reasoning technique; ii) also to make it easier to establish a reference to a goal/quality/task/ resource in a diagram that is part of a requirements document; or iii) to help to define priority of entities.
Node Status adds the status of a goal/quality such as denied, achieved and maintained. Label with syntax is used to add an additional representation using a kind of logic syntax in a textual label in diagrams. Cardinality is used to represent the number of elements in an iStar model. E.g., a cardinality <1..1> is used in means-end links to represent or exclusive or the cardinality [0..1] is used in Resource to represent an optional resource and [1..1] to represent a mandatory task. Reference to external representation is used to link an iStar diagram to external information. Reference to another part of the diagram is used to improve the modularity and scalability of iStar models. It links parts of iStar diagrams. Link Qualifier is used to qualify a relationship; the relationships help, break and hurt specialise it.
In general, there is no unique kind of representation for each light-weight
representation informed. So, Node identifier, e.g., is represented by five different ways:
Textual label without a special marker, Textual label between “[]”, Textual label before
”:”, Textual label before “-“ and Using a coupled graphical representation. Further
details about the representations used can be found at [
This section presents the results of the survey with experts to evaluate which lightweight representations of the first study (presented in Table 1) should be included as standard extension mechanism in iStar 2.0 and if the language should have extension mechanisms. The means of the responses are presented in the Fig. 1.
Note that Specialised Link, Cardinality and Link Qualifier means are below or equal to 3. However, we believe that some mistakes may have influenced their opinions about Specialised Link. Four participants who evaluated Specialised Link as neutral, weak or strong reject commented that it is interesting to consider Specialised Link in the extension mechanism, but they did not agree with the representation used by us to illustrate this concept in the survey - for example we illustrated the specialised link by the usage of a label, we did not use “<<>>” such as stereotypes, and according to these participants, this representation is better. So, if we consider that this is the reason for the low evaluation, perhaps we can accept the Specialised Link as a possible part of the extension mechanisms definition.
Specialised Node, Node Identifier, Node Status, Label with Syntax, Reference to External Representation and Reference to another Part of the Diagram had the mean above 3. Remember that the value 3 represents neutral in the Likert scale used in this survey, so mean above 3 means that the related representation is important in the extension mechanism proposal.
Finally, the last question analyses if the iStar extensions should have extension
mechanisms had value above 3. In another study [
Node status is the fourth light-weight representation more used in extensions with fourteen constructs in nine previous extensions. So, it should be considered as a kind of representation frequently used in iStar extensions. Cardinality and link qualifier will not be considered here due to the value of its mean in the results of the survey and its low use in previous extensions (4 and 1 extensions, respectively).
We identified two ways to represent the extension mechanisms in iStar. The first one is to select one of the existing representations for each light-weight representation identified. So, we can have 8 different representations, one for each light-weight representation. For example, we can define that Node Identifier is represented by a “:” in the label of entities, Label with syntax represented by “{{}}” and so on. Another way is to consider the abstractions of UML and URN extension mechanisms as the base and adapt these ideas in the definition of iStar extension mechanisms. So, we think this second manner is better than the first one, since it is more generic and allows customisations.
So, the idea of UML stereotypes can be used to represent the specialisation of nodes and links in iStar. The UML tagged values have no similar representation in URN models, but we believe it is suitable in iStar context to represent the light-weight representations which we presented in Section 4.1 of this paper.
Additionally, default properties associated with tagged values could be defined. In UML there is a set of 33 default stereotypes such as <<Utility>>, applied to a Class to inform that it has no instances, but rather denotes a named collection of attributes and operations. So, we can define some default properties to tagged values to represent part of the light-weight representations selected in Section 4.2. Hence, Node identifier could be referred as Id, reference to external representation and reference to another part of the diagram can be adopted. They can be joined in a representation labelled as Reference to. Node status can be labelled as Status. Finally, Label with syntax can be labelled as Logic. Thus, a goal can be labelled, as for example as <<Business>> {Id = G1} Accommodation booked. The additional information can be used in a reasoning approach which can consider only business goals and take the value of Id (i.e., G1) of all business goals. The user could use the predefined iStar tagged-values and define their own. Fig. 2 presents an illustration of part of the existing representations and the representation with our proposal to Node Identifier and Specialised Node.
The profiling is a characteristic present in UML and URN. The UML uses a specific model to allow the definition of UML profiles. It uses the class representations as basis. In URN the profiling is defined with the usage of metadata, URN links, URN concerns and OCL constraints (see Section 3). These elements are defined as properties of the elements of the models in the tool jUCMNav Tool. We believe URN concerns and OCL constraints could be adapted to become part of iStar extension mechanism regarding group concepts and define constraints between them.
In summary, we conclude that iStar could have the iStar stereotypes and iStar tagged-values visual light-weight mechanisms as a specialisation of iStar extension mechanisms. Additionally, it would have two new elements named iStar groupers and iStar OCL constraints, which could be hidden as properties in a modelling tool. The iStar groupers are useful to group metaclasses and make easy define constraints for a set of metaclasses in group.
These concepts should be part of the iStar syntax, so we represented them in the iStar metamodel. The metaclasses Stereotype and TaggedValue were associated with Element propagating these properties to all iStar nodes and links. We created an enumeration related to default tagged values (Id, Reference to, Status and Logic). The iStar groupers and iStar OCL constraints are represented as properties. The iStar metamodel with the representation of extension mechanism is available at http://www.cin.ufpe.br/~ejtg/istar_metamodel_extension_mechanisms/.
The gain with the iStar extension mechanisms is not only about simplification of
the scenario presented in Fig. 2. Tools are relevant for the usage of an extension, but
51 extensions (53.6%) do not have any modelling tool [
Many extensions have been proposed since the initial iStar version, in the 90's. At this moment iStar is under standardisation. Consequently, it is relevant to discuss iStar extensibility mechanisms. In this paper, we presented some preliminary considerations for extension mechanisms. It was based on analysis of existing extensions and considered the opinion of the experts about the selection of existing light-weight representations. We recognise the importance of the iStar community to be engaged in the definition of iStar extensions mechanisms. So, this our preliminary proposal can be a starting point for discussions about the theme and future inclusion of extension mechanism in iStar 2.0.
As future work, it is important to include a new version of the extension mechanisms and to propose a tool able to use them in a practical way. Another required important contribution is to formalise the iStar metamodel with extension mechanisms with a formal/semi-formal language such as Alloy. Last but not least, the proposal of a process to guide the proposal of future iStar extensions is an ongoing work.
The authors thank to CNPQ / Brazil (Conselho Nacional de Desenvolvimento Científico e Tecnológico) by the financial support to the execution of this work, Universidade Federal do Ceará, LER-UFPE and NOVA LINCS Research Laboratory (Ref. UID/CEC/04516/2013).