using meta-model-driven views to address scalability in i* models jane you department of computer...
TRANSCRIPT
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