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 Domain Level Domain Level (Modeling Features) Meta Level (Representational Constructs) ViewsViewClass Definition View Map Syntax and Semantics Reformulated i* framework Selection Rule View Type View Maps An i* baseline model Qualified objects in a specific view View Name Model layer (i*) View layer (extension) View management

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 Agent Instance Specifies Link 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 Actor with no plain form Refine abstract dependum and external link to instance ones

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 This sample is taken from the Trusted Computing Group (TCG) case study—since we do not have such patterns in the LAS case study The affected actor

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 internalNonfunctionalRule(v_a:InternalViewClass)::= §o:ObjectClass· o  v_a  o  {find_root_softgoals(a), {find_all_descendants(sg) | sg  find_root_softgoals(a) }} The selection rule attached to the Internal-Non-functional (SR) view: 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

51 Conclusions This work offers a systematic approach to present large scale i* models The foundation lies in the notion of view Proposed a view extension As a by-product, streamlined the i* framework

52 References 38 references, please see my thesis for detail master-thesis-v4.3.pdf

53 Discussion