Source-linked AI summary
iStar 2.0 Language Guide
Fabiano Dalpiaz, Xavier Franch, Jennifer Horkoff
TL;DR
The diversity of i* extensions and variations made the language difficult to learn and use consistently, motivating a shared core. This document presents iStar 2.0 through community standardization, defining core concepts and relationships while supporting future teaching materials and continued evaluation. The result is a standardized language intended for adoption in education and training, with several foundational and methodological issues still deferred.
Problem
Diverse i* extensions and variations made the framework difficult for newcomers, educators, practitioners, and technology providers to learn, teach, apply, and implement consistently.
Method
The i* research community standardized a widely agreed core through iterative discussions, concrete proposals, and community input.
Results
iStar 2.0 defines a consistent core language of concepts and relationships that preserves the ability to tailor the framework.
Takeaways & Limitations
The document promotes iStar 2.0 for educational and training purposes and identifies teaching materials as a next step.
Takeaways & Limitations
This first version excludes ontological, visual, wording, and methodological issues, and the standardization process remains open to further studies.
Abstract
from arXiv · showhide
The i* modeling language was introduced to fill the gap in the spectrum of conceptual modeling languages, focusing on the intentional (why?), social (who?), and strategic (how? how else?) dimensions. i* has been applied in many areas, e.g., healthcare, security analysis, eCommerce. Although i* has seen much academic application, the diversity of extensions and variations can make it difficult for novices to learn and use it in a consistent way. This document introduces the iStar 2.0 core language, evolving the basic concepts of i* into a consistent and clear set of core concepts, upon which to build future work and to base goal-oriented teaching materials. This document was built from a set of discussions and input from various members of the i* community. It is our intention to revisit, update and expand the document after collecting examples and concrete experiences with iStar 2.0.
1 Motivation and Overview
iStar’s flexible extensions supported varied applications but made the language difficult for newcomers, educators, practitioners, and technology providers to use consistently. The community therefore standardized iStar 2.0 around agreed core concepts while preserving room for tailoring, although several concerns remain outside this first version.
- Motivation and Overview: Multiple i* extensions and variations made the framework difficult for newcomers to learn and use consistently.The document identifies adoption difficulties for educators, practitioners, and technology providers as well.
- Motivation and Overview: The community initiative sought widely agreed core concepts that balance framework flexibility with agreement on fundamental constructs.The goal was to retain the ability to tailor the framework while establishing a common core.
- Motivation and Overview: iStar 2.0 is the name given to the first iteration’s standardized core language, developed through meetings, drafts, and community input.Discussions began before ER’14 and continued through later workshops and community meetings.
- Motivation and Overview: The document organizes iStar 2.0 concepts and relationships through definitions, comments, examples, graphical representations, views, and a metamodel.Its focus is concepts and relationships, while methodological possibilities receive only brief treatment.
- Motivation and Overview: This first version excludes ontological, visual, wording, and methodological issues planned for later versions.The document explicitly presents these as aspects still awaiting future inclusion.
2 Actors and actor types
Actors are autonomous entities that pursue goals through their knowhow and collaboration with other actors. iStar 2.0 distinguishes roles, agents, and optionally generic actors, and represents their intentional content within actor boundaries.
- Actors and actor types: Actors are active, autonomous entities that pursue goals by exercising knowhow and collaborating with other actors.They are central to iStar 2.0’s social modeling perspective.
- Actors and actor types: A role is an abstract characterization of social behavior within a specialized context or domain.Examples include Student and PhD Student.
- Actors and actor types: An agent is an actor with concrete physical manifestations, including a person, organization, or department.Examples include a travel agency, University of Wonderland, and Mike White.
- Actors and actor types: A generic actor can be used when the model does not need to distinguish whether an actor is a role or an agent.Travel agency may remain generic when its specialization is unknown or irrelevant at the current modeling stage.
- Actors and actor types: An actor boundary contains an actor’s intentional elements and their interrelationships.The boundary makes the actor’s intentionality explicit graphically.
3 Actors association links
iStar 2.0 uses binary actor links to represent generalization and other associations between actors. The is-a link is restricted by actor type, whereas participates-in supports broader associations such as plays and part-of.
- Actors association links: Actor links are binary relationships connecting one actor to one other actor, with two defined types: is-a and participates-in.They capture how actors are interrelated in iStar 2.0.
- Actors association links: The is-a link represents generalization or specialization and permits roles to specialize roles and generic actors to specialize generic actors.Agents cannot be specialized through is-a because they are concrete instantiations.
- Actors association links: The participates-in link represents associations other than generalization or specialization and imposes no restriction on the linked actor types.Its meaning depends on the connected actors.
- Actors association links: When an agent participates in a role, the association represents a plays relationship, such as Mike White playing PhD student.When same-type actors are connected, the association often represents part-of, such as a university system being part of a university.
- Actors association links: Actor association links use arrows whose arrowheads identify the target, and each link must include a type label.The notation applies to the actor-link examples shown in Fig. 4.
4 Intentional elements
Intentional elements represent what actors want, including goals, qualities, tasks, and resources. They can appear inside actor boundaries and are graphically distinguished by element type.
- Intentional elements model different kinds of requirements and denote what an actor desires or wants.They may appear inside actor boundaries or outside them as part of dependencies.
- Goals are desired states of affairs with clear-cut achievement criteria.
- Qualities are attributes for which an actor desires some level of achievement and can guide or evaluate alternative goal-achievement strategies.Their desired achievement level may be precise or vague.
- Tasks represent actions an actor wants executed, usually to achieve a goal.
- Resources are physical or informational entities an actor requires to perform a task.Goals, qualities, tasks, and resources have distinct graphical forms, including ovals, cloud-like shapes, hexagons, and rectangles.
5 Social dependencies
Social dependencies relate actors through a depender, dependum, and dependee, with optional intentional elements explaining why and how the dependency exists. Dependency type determines the dependee’s expected outcome and degree of freedom.
- Dependencies represent social relationships between actors and make iStar 2.0 a socio-technical modeling language.Actors may be humans, organizations, technical systems, or combinations thereof.
- A dependency comprises a depender, dependerElmt, dependum, dependee, and dependeeElmt.The depender requests something, the dependum is the dependency object, and the dependee should provide it.
- Dependencies link the depender’s intentional element through the dependum to the dependee’s intentional element, with a directed “D” symbol.
- The dependerElmt and dependeeElmt may be omitted to represent an initial dependency view or partial knowledge of why or how the dependency exists.Either element can be specified alone, or both can be omitted.
- Goals and qualities give the dependee the most freedom, tasks provide medium freedom, and resources provide the least.The dependum type specifies whether the dependee achieves, satisfies, executes, or provides the dependency object.
- Dependency elements with the same name remain distinct when they represent the viewpoints of the depender, relationship, and dependee.Dependency relationships should not share the same dependum, even when dependums have identical names.
6 Intentional element links
iStar 2.0 provides refinement, needed-by, contribution, and qualification links for connecting intentional elements. These links express hierarchy, resource requirements, effects on qualities, and desired qualities over goals, tasks, or resources.
- The four intentional-element link types are refinement, needed-by, contribution, and qualification.They are summarized in Table 1.
- 6.1 Refinement: Refinement hierarchically links one parent goal or task to one or more children through AND or inclusive OR logic.A parent can have at most one refinement relationship and cannot be both AND- and OR-refined.
- 6.1 Refinement: AND-refinement requires all children, whereas inclusive OR-refinement requires at least one child to fulfill the parent.Refinement may also contain a single child.
- 6.1 Refinement: Refinement meanings depend on whether the parent is a goal or task, with children representing sub-states, sub-tasks, alternative means, or goals uncovered through task analysis.
- 6.1 Refinement: Refinement relationships can be constructed bottom-up, top-down, or through a mixed approach.
- 6.2 NeededBy: The NeededBy relationship links a task with a resource required for executing that task without specifying the reason for the need.It is graphically shown as an arrow with a circular arrowhead directed toward the task.
- 6.3 Contribution: Contribution links express positive or negative effects of intentional elements on qualities using Make, Help, Hurt, and Break types.These links accumulate evidence about whether qualities are satisfied or denied and support decisions among alternatives.
- 6.4 Qualification: Qualification links relate a quality to a goal, task, or resource to express the desired quality of its achievement, execution, or provision.For example, “No errors” qualifies “Request prepared” by specifying the desired manner of preparation.
7 Model views
iStar 2.0 models can be visualized through Strategic Rationale, Strategic Dependency, and Hybrid SD/SR views. These perspectives expose different portions of actors, dependencies, and internal intentional detail.
- Strategic Rationale: The Strategic Rationale view shows actors, dependencies, actor links, and each actor’s internal details.It exposes the strategic rationale inside the actors in the model.
- Strategic Dependency: The Strategic Dependency view shows actors, actor association links, and dependency relationships from depender to dependum to dependee.
- Hybrid SD/SR: The Hybrid SD/SR view opens selected actors to show their strategic rationale while keeping other actors closed and hiding actor links.
- Other views: Additional views can be defined as needed, such as actor views or functional views that hide selected model elements.
8 Metamodel
The iStar 2.0 metamodel organizes the language concepts and relationships, with integrity constraints restricting valid model structures and interactions.
- The metamodel presents the iStar 2.0 concepts and relationships defined in the preceding sections.
- Is-a relationships apply only between roles or between actors, and is-a and participates-in relationships must not contain cycles.
- Actor pairs can have at most one actor link, preventing simultaneous is-a and participates-in links between the same actors.
- Dependencies require distinct depender and dependee actors, with dependency elements matching the actors that want them.
- Refinement relationships cannot form cycles, and intentional-element relationships apply only to elements wanted by the same actor.
- An intentional element and a quality may be linked by contributesTo or qualifies, but not both, and qualities cannot contribute to themselves.
- GoalTask Element, Intentional Element, and Refinement are abstract classes, whereas Actor is concrete despite being specialized.
9 Conclusion and Outlook
The document reports the standardization process that defined iStar 2.0 and promotes its adoption for education and training. Future work includes teaching materials, community studies, feedback, and further language improvement.
- The standardization process produced the iStar 2.0 language, whose adoption is promoted for educational and training purposes.
- Teaching materials that can be readily used to teach iStar 2.0 are identified as a next step.
- The standardization process remains open to studies of ease of use, teaching adequacy, expressiveness, graphical notation, and automated reasoning techniques.
- The authors acknowledge room for improvement and request feedback and examples of iStar 2.0 models to identify improvable aspects.
- Feedback can be submitted by email or through public comments on the iStar 2.0 website.