iStar2.0 was delivered in 2016 with the intention of becoming a standard de facto for the i* community. It includes a lightweight definition of the language adorned with a metamodel (in the form of a UML class diagram) that is useful for most purposes. However, in some contexts, a more precise algebraic definition including a notion of satisfaction is needed. This paper presents such elements. First, an algebraic definition of iStar2.0. Then, some auxiliary operations. Last, the notion of satisfaction over i* models using first order logic. Satisfaction is still defined mainly in a syntactic form, relying upon the satisfaction of the individual intentional elements comprising the model.
Since its formulation in the mid-nineties [
While this diversity was considered overall positive because it facilitated the i*
community to grow lively, it has the other side of the coin in the lack of a well-established,
common core, acting as lingua franca for researchers, practitioners and tool developers.
With the purpose to solve this problem, the community launched in 2014 a task force
to define an agreed core of constructs to be used as the basis of any specialization of
the language. The most visible result was the formulation of the iStar2.0 language [
To cope with this problem, the present document has the goal of defining the
structure of the iStar2.0 language in an algebraic form, and then providing the notion of
satisfaction of iStar2.0 models on top of this definition. It can be considered as an
auxiliary document when a high degree of formalization is needed, e.g. for defining the
meaning of complex language constructs as specialization, as already done in the past
[
The rest of the paper introduces one section per topic: algebraic definition of the language, introduction of a collection of auxiliary operations that can be useful for working with this algebraic definition, and formulation of the satisfaction function using first order logic. 2
Algebraic definitions have a long tradition in theoretical computer science, to describe
complex structures as finite automata [
The algebraic definition for iStar2.0 language is shown in Table 1. The iStar2.0 constructs can be grouped into seven concepts: models (D1), actors (D2), intentional elements (D3), intentional element links (D4), dependencies (D5) and dependencies ends (D6), and actor links (D7). For every concept, we show the domains and the most significant properties that they need to fulfil. 3
• O1-O3 return the name of named iStar2.0 constructs, which is needed to establish identity of elements in definitions and proofs. • O4-O6: return descendants and parents of actors through actor links. We included operations for direct descendants of an actor a (O4), actors with an actor link to a, and the transitive clousure of descendants (O5), linked directly to a or to any of its descendants. • O7 returns the actor that acts as dependency end in a dependency. This operation is useful given that a dependency end can be the actor itself (in SD views mainly) and an intentional element (IE) inside an actor (in SR views mainly).
D1 M = (A, DL, DP, AL) A: set of actors; DL: set of dependencies DP: set of dependums; AL: set of actor links ─ a,bA: name(a) name(b) (all actors have different names) ─ x,yDL: name(x) name(y) (all dependums have different names) ─ aA: adescendants_trans(a, M) (avoid cycles in actor links)
D2 a = (n, IE, IEL) n: name; IE: set of IEs; IEL: set of IE links ─ x,y IE: name(x) name(y) (all IEs have different names) ─ m,n IEL: source(m) = source(n) type(m) = type(n) = refinement (refinementValue(m) = refinementValue(n)) , an IE cannot be ORand AND-refined simultaneously
D3 ie = (n, t) n: name; t: type of IE, t{goal, quality, task, resource}
D4 iel = (p, q, t, rv, cv) p, q: IEs (source and target) t: type of IE link, t{refinement, qualification, neededBy, contribution} ─ t = refinement type(p) {goal, task} type(q) {goal, task} ─ t = qualification type(p) = quality type(q) quality ─ t = neededBy type(p) = resource type(q) = task ─ t = contribution type(q) = quality
D5 d = (der, dee, dm)
D6 de = (a, ie)
D7 al = (a, b, t) rv: refinement value, rv {AND, OR, ⊥} ─ t = refinement rv ⊥ cv: contribution value, cv CT+ CT– {⊥} ─ CT+ = {make, help}, CT– = {break, hurt} ─ t = contribution cv ⊥ der, dee: dependency ends (depender and dependee respectively) dm: IE (dependum), dm = (n, t) (see D3) ─ actor(der) ≠ actor(dee) (an actor cannot depend on itself) a: actor (depender or dependee) ie: IE (from depender or dependee), ie IE(a) ∪ {⊥} a, b: actors (source and target), t {is-a, participates-in}
O1 Actor name a = (n, IE, IEL) M: name(a) = n O2 IE name x = (n, t)IE: name(x) = n O3 Dependum name d = (der, dee, dm) DL: name(d) = name(dm) -- dm is an IE; C2 applies O4 Descendants descendants(b, M) = {a | (a, b, t) AL} O5 Transitive clousure descendants_trans(b, M) = descendants(b, M)
of descendants (a: a descendants(b, M): descendants_trans(a, M) O6 Parent actor parent(a, M) = (b: (a, b, t) AL) O7 Dependency end d = ((a, ie1), (b, ie2), dm) DL: actor((a, ie1)) = a actor((b, ie2)) = b O8 Source and target iel = (p, q, t, rv, cv) IEL: source(iel) = p target(iel) = q
IEs of an IE link O9 Type of an IE link iel = (p, q, t, rv, cv) IEL: type(iel) = t O10 Actor outgoing de- outgoingDep(a, M) = {d: d = (der, dee, dm) DL: actor(der) = a} pendencies O11 Actor incoming de- incomingDep(a, M) = {d: d = (der, dee, dm) DL: actor(dee) = a} pendencies O12 Dependums of a set dependums(DL) = {dm: (der, dee, dm) DL}
of dependencies O13 Main IEs of an actor mainIEs((n, IE, IEL)) = {ie IE | ancestors(ie, IE, IEL) = }, where ancestors(IEL, ie) returns the set of IEs for which ie belongs to their decomposition, according to IEL (see below) O14 Ancestors of an IE Let be parents(ies, IE, IEL) = {iet: iet IE: (ies, iet, t, rv, cv) IEL) ancestors(ie, IE, IEL) = parents(ie, IE, IEL)
(ie2: ie2 parents(ie, IE, IEL): ancestors(ie2, IE, IEL) O15 Substituting an ac- substituteActor(M, a, a’) = (A\{a}{a’}, substituteActor(DL, a, a’), tor by another in a DP, substituteActor(AL, a, a’) model O16 Substituting an ac- substituteActor(DL, a, a’) = tor by another in a {d=((x, ie1), (y, ie2), dm): dDL x a y a: d} set of dependencies {d=((x, ie1), (y, ie2), dm): dDL x = a: ((a’, ie1), (y, ie2), dm)} {d=((x, ie1), (y, ie2), dm): dDL y = a: ((x, ie1), (a’, ie2), dm)} O17 Substituting an ac- substituteActor(AL, a, a’) = tor by another in a {(x, y, t): (x, y, t)AL x a y a: (x, y, t)} set of actor links {(x, y, t): (x, y, t)AL x = a: (a’, y, t)}
{(x, y, t): (x, y, t)AL y = a: (x, a’, t)} O18 Substituting an IE bysubstituteIE(M, a, ie, ie’) = (A, substituteIE(DL, ie, ie’), DP\{ie}{ie’), AL) another in a model O19 Substituting an IE substituteIE(DL, ie, ie’) = by another in a set {d=(der, dee, dm): dDL dm ie: d} of dependencies {d=(der, dee, dm): dDL dm = ie: (der, dee, ie’)} • O8-O9 gives a set of operations useful to handle with IE links. • O10-O12 gives a set of predicates useful to handle dependencies and dependums.
For the definition of the operation related to specialization (O12), we assumed that the subactor inherits all the superactor elements. • O13 provides an operation for getting the main IEs in an actor, i.e. IEs without ancestors. • O14 provides an operation for getting the ancestors of IEs in an actor through IE links. • O15-O19 provide a set of useful functions that substitute one element by another in a given context. We are using them in the definition of specialization, where refined elements need to be substituted by their redefinition. 4
Finally, this section presents the most restricted notion of satisfaction (e.g. full
satisfied/full denied satisfaction values in [
Fig 1. includes the elements used in the satisfaction definition predicates (see Table 3). This section includes the individual cases for the refinement, i.e. only one type of link arriving to the IE. In the case of combining different types of links, for example a goal refined using an OR-refinement with a qualification link (Fig.1, left), the satisfaction would be the result applying a logical AND of each link type result. In the example in Fig. 1 (left), it would be the result of applying a logical AND between the sat(ieq) and the result of the sat(ie) applying SD5. 5
This paper has provided an algebraic definition of the iStar2.0 language. We argue that
this work can help researchers when defining new constructs in a formal way, or even
making precise concepts already defined as inheritance or other related constructs as
metrics [
The main limitation is that this work is still at the syntactic level. Future work should go on this direction by considering ontologies in the notion of satisfaction.