Reflective Analysis of the Syntax and Semantics of the i * Framework

1. Reflective Analysis of the Syntax and Semantics of the i* Framework Jennifer Horkoff, GolnazElahi, SamerAbdulhadi, Eric Yu Department of Computer Science and Faculty of Information University of Toronto, Canada RIGiM’08

2. Modeling Languages: Intention vs. Use • Modeling languages are introduced to serve a variety of purposes, including: • Facilitating communication • Making tacit information explicit • Storing knowledge • Aiding analysis • (Sometimes the intention of a language is not explicitly expressed)

3. Modeling Languages: Intention vs. Use • As a language is adopted and used, it may be used in ways which the language creators did not anticipate • It is useful to reflect on the intentions of the language versus its use in practice • We focus on the intentions of the syntax and semantics of a language • Reflective Analysis of intention vs. use can help to answer: • What were the original intentions of the language syntax and semantics? • How are the syntax and semantics being commonly used? • Why are users prone to deviate from the original language description? • Do these variations matter? • Should the language be modified? • Or, should an effort be made to increase training?

4. Reflective Analysis of the i* Framework • We analyze the intention vs. use of the i* Framework • i* is a goal and agent-oriented framework which was intended to be used in the early requirements stage to capture agents, their inter-relationships, and their goals • Aimed at helping to discover and compare high-level system design alternatives

5. i* Evolving A good candidate for reflective analysis The i* Framework was left open to interpretation and modification i* has been applied to many areas for differing purposes • i* • Adapted Surveyed student i* assignments, research papers and presentations i* is used in system analysis courses We compare i* usage to current U of T Style

6. Survey Method • Survey subjects looking for variations from U of T style: • 15 student project assignments from a graduate level system analysis course • 15 academic papers and presentations using i* drawn from various sources. • All models in each document were surveyed • Variations were only counted once per document • The models covered diverse application domains, including health care, banking, and education systems. • An analysis of the motivations behind the variations was also performed • Was the modeler confused about the syntax? • Was the modeler using a syntactic shortcut? • Does the variation indicate issues within i*?

7. The i* Framework: U of T Flavour • Elements • Links between Elements • Actors and Actor Boundaries • Actor Association Links Soft Hard

8. The i* Framework: U of T Flavour • Syntax Restrictions Include: Goals decompose only with means-ends links to tasks Decomposition links are only used from tasks Contribution links only go to softgoals Dependums are needed Contribution links only inside actors Dependency links must go outside actors Actors are not nested Actor Associations are restricted between certain actors

9. Survey Results • Variations were grouped together in two ways: • By syntax category • By perceived motivation

10. Survey Results: Variation Instances by Syntax Category Number of Variations in Category 8 6 8 5 4 4

11. Decomposition Links Variations 6 9 Decomposition links are drawn directly from goals to tasks Decomposition links are used between goals 2 Softgoals are decomposed to tasks Goals are means-ends decomposed to softgoals 5 Decomposition links are used between Softgoals 3 Decomposition links extend outside actors' boundaries Goals are decomposed to resources 4 1 Decomposition links are used between resources 1

12. Survey Results • Variations Grouped by perceived motivations:

13. Example Variation: Nature of “Hard” Elements and SoftgoalsGoal (Means-Ends) Decomposed to Softgoal (7 Instances) • Syntax not permitted in the U of T style of i* • Semantics: The nature of soft and hard goals implies that a softgoal should not be sufficient to satisfy a hard goal • Something qualitative satisfies something concrete • However… • In i* a task can be decomposed to a softgoal • The softgoal represents a quality the task should encompass

14. Example Variation: Nature of “Hard” Elements and SoftgoalsGoal (Means-Ends) Decomposed to Softgoal • Possible Responses: • Discontinue decomposition of tasks to sofgoals • But how do we associate a quality with a task? • Create an alternative way to associate qualitative aspects to tasks, other than through decomposition • Could also be used for goals? Alternative Syntax

15. Survey Results • Variations Grouped by perceived motivations:

16. Example Variation: Means-Ends vs. DecompositionGoal Decomposition (16 instances) • Syntax: Goal decomposition is not permitted in the U of T i* style • Semantics: • Tasks versus goals • Goals can be accomplished in different ways • Task is a particular way of doing something • Syntax restriction promotes the discovery of alternatives

17. Example Variation: The Nature of Actor BoundariesContribution Links Outside Boundaries (6 Instances) • Syntax: Only dependency links should be used outside actor boundaries • Semantics: • Emphasize actors’ autonomy • Actors should not have knowledge of the internal motivations of other actors

18. Possible Responses • Strict and loose versions of i* syntax: • Strict syntax follows the U of T style restrictions • Loose syntax relaxes a select set of rules based on common variations: • Means-ends for tasks, decomposition for goals • Contribution links across actors • Omitting dependums • The notion of syntactical shortcuts Shortcut for

19. Survey Results: Students Vs Researchers • Students are more likely to: • Have more difficulties understanding the difference between soft and “hard” elements • Have incomplete models (models with un-decomposed goals) • Misuse association links • Researchers are more likely to adapt the Framework as they see fit: • More likely to use non-dependency links outside of actor boundaries

20. Conclusions and Future Work • Based on an analysis of several variations we were able to suggest: • Areas where the syntax of i* could be modified • We would like to explore the notion of “loose” and “strict” versions of i* syntax • Recognized syntactic shortcuts • Associating softgoals with hard elements • Areas where more training is needed • Soft vs. “hard” elements • Association links • Consistent interpretation of standard syntax shortcuts • Future work can: • Expand our survey pool and include analysis of further variations • Experiment with the utility of modified i* syntax

21. Thank You • Jennifer Horkoff • jenhork@cs.utoronto.ca • www.cs.utoronto.ca/~jenhork • Golnaz Elahi • elahi@cs.utoronto.ca • www.cs.utoronto.ca/~elahi • SamerAbdulhadi • Eric Yu • eric@cs.utoronto.ca • www.cs.utoronto.ca/~eric • i* Wiki • http://istar.rwth-aachen.de/tiki-view_articles.php

22. Threats to Validity • The selection of academic papers and presentations was not completely random • The surveyor was less interested in papers without variations • Student assignments were longer than academic works, and had more examples • But not all variations were higher for student assignments • The qualitative analysis of the variations was performed by the authors • Variation intentions could be misinterpreted • However, misinterpretation could indicate a general source of confusion

23. The Nature of “Hard” Elements and Softgoals • We select one category of perceived motivation to examine in detail Goal (means-ends) decomposed to softgoal

24. Survey Results: Decomposition Links Example Breakdown

25. Survey Results • Variations Grouped by perceived motivations: Number of Variations in Category Total Instances per Category