Using Meta-Model-Driven Views to Address Scalability in i* Models

1. Using Meta-Model-Driven Views to Address Scalability in i* Models Jane You Department of Computer Science University of Toronto

2. Outline • Background • Architecture of the view extension • Features of the view extension • Reformulating i* using view • View types • View map • Representational constructs • Related and future work • Conclusions

3. An Example • 1 out of four models from the London Ambulance Service (LAS) case study • 4 out of 10 actors in that model • 82 out of some 400 domain objects (elements and links)

4. Scalability Issues in i* • Model a large-scale application into i* models • Present a large-scale i* model • Perform analysis using i* models

5. Research Objectives • A first step in address scalability—model representation • Seek a systematic method to break down a large and complex i* model into segments that are: • self-contained • comprehensible to human • Maintain inter-segment connections

6. Outline • Background • Architecture of the view extension • Features of the view extension • Reformulating i* using view • View types • View map • Representational constructs • Related and future work • Conclusions

7. Architecture of the View Extension Meta Level (Representational Constructs) Domain Level (Modeling Features) View Maps View management View Map Syntax and Semantics Views ViewClass Definition View Type View Name View layer (extension) Qualified objects in a specific view Selection Rule Model layer (i*) An i* baseline model Reformulated i* framework

8. Outline • Background • Architecture of the view extension • Features of the view extension • Reformulating i* using view • View types • View map • Representational constructs • Related and future work • Conclusions

9. The Original i* Framework • Strategic Dependency (SD) model: express the intentional relationship s among agents • Strategic Rationale (SR) model: show how processes are comprised of intentional elements of the agents Adapted from Eric Yu’s 1994 PhD Thesis

10. Reasons for Reformulation • The emergence of the Goal-oriented Requirements Language (GRL) framework • The separation of the actor diagram from the Strategic Dependency (SD) diagram • The release of the Organization Modelling Environment (OME) tool • Views in the proposed view extension are defined on i* meta-level concepts

11. Baseline Model and View • The baseline model: a domain i* model which consists of the collection of i* objects (elements and links) structured according to i* syntax and semantics • View: presents a partial of the baseline model

12. Four Basic View Types • Actor Class (AC) view: focusing on various forms of actors and the associations among the different forms of each actor • Strategic Dependency (SD) view: focusing on inter-actor dependencies • Strategic Rationale (SR) view: focusing on the internal rationales of the actors • Evaluation Results (EVLR) view: showing the results of the evaluation process

13. A baseline model Partial baseline model from the LAS case study

14. The Basic AC View Specifies Link Agent Instance Complete Composition Link

15. The Basic SD View External Link

16. The Basic SR View Decision Point

17. The Basic EVLR View Starting Label

18. Outline • Background • Architecture of the view extension • Features of the view extension • Reformulating i* using view • View types • View map • Representational constructs • Related and future work • Conclusions

19. View Type Properties • Category (AC | SD | SR ) • Unique name (e.g. Single Actor Focus SD view) • Selection rule • One for each view type • Formally defined in a Telos compatible First Order Logic formulae

20. AC View Types • One basic AC view type • Six partial AC view types: • Plain-Actors-Only view • Agents-Only view • Abstract-Actors-Only view • Single-Plain-Actor view • Single-Network view • Direct-Replaceable view

21. An Original AC View

22. Abstract-Actors-Only View

23. Direct-Replaceable View External relationship inheritance rule: automatically substitute one actor for another according to the associations among actors

24. SD View Types • Two basic view types: • Plain-Actor-Based view • Specified-Actor-Based view • Two partial view types (also work for SR views): • Single-Actor-Focused SD view • Pair-wise-Actors SD view

25. Plain- and Specified-Actor-Based SD views Refine abstract dependum and external link to instance ones Actor with no plain form

26. SR View Types • Share same view types of SD • A hierarchy of SR views based on the Single-Actor-Focus SR view: • Single-Actor-Internal view • Internal-Functional view • Internal-Non-functional view • Single-Softgoal view • Single-Actor-External view • Single-Affected-Dependum view • Single-Affected-Actor view

27. Single-Actor-Focus SR View

28. Single-Actor-Internal View

29. Single-Actor-External View

30. Internal-Functional View

31. Internal-Non-functional View This case is also a Single-Softgoal view

32. Single-Affected-Dependum View The affected dependum

33. Single-Affected-Actor View The affected actor This sample is taken from the Trusted Computing Group (TCG) case study—since we do not have such patterns in the LAS case study

34. Outline • Background • Architecture of the view extension • Features of the view extension • Reformulating i* using view • View types • View map • Representational constructs • Related and future work • Conclusions

35. Notations

36. View Map A generic view map (semantics) A domain instance of the generic one

37. An Domain View Map Sample

38. Outline • Background • Architecture of the view extension • Features of the view extension • Reformulating i* using view • View types • View map • Representational constructs • Related and future work • Conclusions

39. Embedded into Telos • To formally define the selection rules: the i* framework is embedded into Telos • To make the view extension extensible in a systematic manner: it is also embedded into Telos

40. Sample Formal Representation of an i* model % plain actor Ambulance Crew % TELL SimpleClass AmbulanceCrew_PlainActor IN ActorElementClass WITH name displayName : “Ambulance Crew” specifiedByLink : ACSpecifiesAC_Link END % agent Ambulance Crew % TELL SimpleClass AmbulanceCrew_Agent IN AgentElementClass WITH name displayName : “Ambulance Crew” specifiesLink : ACSpecifiesAC_Link children : AC_QualityService : AC_TimelinessService : AC_TimelinessArrivalLocation : AC_AccuracyAmbInfo … [outDepLinks : AC_TALtoOptimalLink] END

41. Partial Meta-Model of the AC view

42. Meta-Model of AC view classes

43. Sample Selection Rule The selection rule attached to the Internal-Non-functional (SR) view: internalNonfunctionalRule(v_a:InternalViewClass)::= §o:ObjectClass· ov_a  o{find_root_softgoals(a), {find_all_descendants(sg) | sg  find_root_softgoals(a) }} Informal Description: An Internal-Non-functional view presents the selected actor, its top-level softgoals, and all the descendants (reasoning structure) of these softgoals.

44. O-Telos Query Classes Individual find_root_softgoals in GenericQueryClass isA SoftgoalElementClass with attribute,retrieved_attribute name : String attribute,parameter a : ActorElementClass attribute,constraint c : $ (this parent ~a) and (not (exists l/LinkClass not (l in DependencyLinkClass) and (l from this)) )$ end

45. O-Telos Query Classes (2) Individual find_all_descendants in GenericQueryClass isA IntentionalElementClass with attribute,parameter ie : IntentionalElementClass attribute,constraint c : $ (this in find_direct_descendants[~ie/ie]) or (exists d/IntentionalElementClass a/ActorElementClass (d parent a) and (this parent a) and (d in find_all_descendants[~ie/ie]) and (this in find_direct_descendants[d/ie]) ) $ end

46. Outline • Background • Features of the view extension • Architecture of the view extension • Reformulating i* using view • View types • View map • Representational constructs • Related and future work • Conclusions

47. Related work • Scalability handling in KAOS and EKD • Multiple sub-models each grouping related meta-concepts • Using tool support to preserve elements consistency and to maintain hierarchies of modeled elements (e.g., diagrams, concepts, etc.) • Provide text-based search engines

48. Related Work (2) • Scalability Handling in OO and SADT: • IDEF0 (a SADT approach) use node tree to track relationships between diagrams • Higraph-based visual formalization introduces hierarchy to flat models • Representation first approach taken by most conceptual modeling researches

49. Future work • Defining new view types • Based on unused meta concepts (e.g. routine, dependency strength, ect.) • Based on domain knowledge-base (e.g. attacker, defender, etc.) • Seek heuristics for the modeling process • Broader applications

50. Outline • Background • Features of the view extension • Architecture of the view extension • Reformulating i* using view • View types • View map • Representational constructs • Related and future work • Conclusions