Using MetaModelDriven 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 scalabilitymodel
  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 Map Syntax and Semantics
View Maps
View management
Views
ViewClass Definition
View Type
View Name
View layer (extension)
Qualified objects in a specific view
Selection Rule
Model layer (i)
Reformulated i framework
An i baseline model
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 Yus 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 studysince 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 child
ren 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-fu
nctional (SR) view
internalNonfunctionalRule(v_aInternalViewClass)
oObjectClass 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_descendantsie/ie)
or (exists d/IntentionalElementClass
a/ActorElementClass (d parent a) and (this
parent a) and (d in find_all_descendantsie/ie
) and (this in find_direct_descendantsd
/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-thes
  is-v4.3.pdf

53
Discussion