using meta-model-driven views to address scalability in i* models jane you department of computer...

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

Jane YouDepartment 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 (Modeling Features)Features)

Meta Level Meta Level (Representational (Representational

Constructs)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) casestudy—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

namedisplayName : “Ambulance Crew”

specifiedByLink: ACSpecifiesAC_Link

END% agent Ambulance Crew %TELL SimpleClass AmbulanceCrew_Agent IN AgentElementClass WITH

namedisplayName : “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· ov_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

selectedactor, its top-level softgoals, and all the

descendants(reasoning structure) of these softgoals.

44

O-Telos Query ClassesIndividual 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

http://www.cs.toronto.edu/~janeyou/avs/master-thesis-v4.3.pdf

53

Discussion