The notion of Specialization in the i* Framework

The notion of Specialization in the

i* Framework

Lidia López Cuesta

May, 16th 2013

Advisors:Dr. Xavier Franch

Dr. Jordi MarcoPhD Defense

What will I talk … in the next 45 minutes?

Introduction

•Motivation•Research Objective•Research Questions•Methodological Approach

State of the Art

•In Related Areas•In the i* Literature•According to the i* Community

Specialization Proposal

•is-a link•i* Model Correctness•Specialization Proposal•Extension•Refinement•Redefinition•Methodology

Conclusions & Future Work

•Contributions•Future Lines of Work•Publications

May 2013 The notion of Specialization in the i* Framework 2

Introduction State of the ArtSpecialization

ProposalConclusions & Future Work

Outline

Introduction

• Motivation• Research Objective• Research Questions• Methodological Approach

State of the Art




MotivationTwo types of i* diagrams

SD Diagrams

SR Diagrams

They need to be synchronized

Customer

Name a Price

Buy Travel

Travel Agency

Travels Bought Easily

Easily Bought

CustomerTravel

AgencyEasily Bought


My focus: specialization in i* through is-a

Motivation

• How are the IEs belonging to Customer inherited in Family?

• What manipulations are valid over them?– E.g., may Buy Travel have additional subtasks?

• Do Customer dependencies apply to Family?May 2013 The notion of Specialization in the i* Framework 5

Motivation

The ultimate effect of is-a is not clear• The i* guide does not define it• i* modellers use it intuitively


Research Objective

Presenting a set of specialization operations applicable in the process of building models with the i* language.


Presenting a set of specialization operations applicable in the process of building models with the i* language.

Research Questionsi*

Specialization proposed

Define i* Specialization

Operations

RQ2: Define i* Language

Core

RQ1:Specialization Applied Correctly

RQ3: Validate i* model

Correcteness


RQ1: How can actor specialization be applied when building models with the i* language?

RQ2: What constructs configure the i* language core?

RQ3: How can the model correctness be validated when specialization is used in i* models?

Research Questionsi*

Specialization proposed

V2: Formalize operations

V3: Formal validation for operations

V4: provide Tool Support

Define i* Specialization

Operations

RQ2: Define i* Language

Core

RQ1:Specialization Applied Correctly

RQ1-1: Identify the i* current use

AND

RQ1-2.1: specialization in other areas

RQ1-2.2: define

operations semantics

RQ1-2.3: define

operationssyntax

RQ1-2: define admisible

modifications

ANDAND

RQ1-3: define

methodology V1: Run Academic Exemplar

AND RQ3: Validate i* model

Correcteness

Define i* Model

Correctness


Methodological Approach

Formal Analysis

Correctness Validation

Proof of Concept

Methodology Validation

New Techniques


Analytic Models

Formalize

Descriptive Models

Understand the

phenomenom


Formal Analysis


Proof of Concept


New Techniques


Analytic Models

Formalize

Descriptive Models

Understand the

phenomenom

Methodological Approach


Formal Analysis


V3•Formal Validation

Proof of Concept


V1•Academic Exemplar

V4•Tool Support: HiME

New Techniques


RQ1-2.2•Operation Semantics

RQ1-2.3•Operation Syntax

RQ1-3•Methodology

Analytic Models

Formalize

RQ2• i* Language

RQ3• i* Models Correctness

V2•Operations

Descriptive Models

Understand the

phenomenom

RQ1-1• i* models• i* survey

RQ1-2.1•Related Areas

RQ2• i* models• i* dialects

RQ3• i* Models Correctness

Stage1: Initial ProposalStage 2:

Proposal Consolidtion

Stage 3: Proposal Validation

V4•Tool Support: REDEPEND

Outline

Introduction

State of the Art

• In Related Areas• In the i* Literature• According to the i* Community




State of the Art

i* Survey

i* Literature

Related Areas

SD

CM

KR


Knowledge Representation

• Semantic Networks (Quillian 1966)

KR SD

CM

Attribute Cancelation


EXCEPTIONS

Software Development• Inheritance - main characteristics in OOP• Simula 67(1968)

– Order class Single Order• Nowadays

– Java, C# - overrides for methods– Visual Basic – shadows

• More than programing languages…– Eiffel – Contracts (restricting methods)– Taxomania rule (taxo + mania)

KR SD

CM

Taxomania RuleEvery heir must introduce a feature,

redeclare an inherited feature, or add an invariant clause


Conceptual Modelling• 1975: “Conceptual Model”• 1976: ER (Chen) EER (inheritance)• Nowadays: UML

– 1997 v1.0: only new features– 2005 v2.0: includes redefinition

• IS-A hierarchies: Template vs. Prototype

KR SD

CM


Specialization in Related Areas

Area ApproachIntroduce

featureAdd Invariant Redeclare feature

Knowledge Representation

Strict NewAttributes

Does not Apply No

Defeasible Does not Apply Attribute Cancellation

OO Languages

Simula 67

New Properties & Methods

Simulation accessing properties via methods

No

Smalltalk-80, Delphi, C++, C#, Java

Overrides for methodsSimulation for properties accessing via methods

Visual BasicOverrides and Shadows for

properties and methods

Eiffel Adding invariantsRenaming and Redefinition for routines and procedures

using contracts

Conceptual Modeling

Semantic data models

New Attributes &

Methods

No No

UMLFeatures Restriction (cardinality, visibility,…)

Attributes and Roles Renaming

Borgida & Mylopoulos Attributes No

KR SD

CM


Taxomania RuleEvery heir must introduce a feature,

redeclare an inherited feature, or add an invariant clause

Specialization in i* Literaturei*

Literature

1995

Introduce a feature

Add invariant


SR?

Subactor

Superactor

Specialization in i* Literaturei*

Literature


Regurlarly used but no

details

i* Surveyi*

Survey

Q1 How often do you use is-a links in the i* models that you develop?

Q2 If you use is-a links, do you have any doubt about their usage?

Q3 If A is-a B, what is the consequence regarding dependencies at the SD model level?

Q4 If A is-a B, what is the consequence regarding the SR model level?

B

A

is-a

3; 14%

6; 29%9; 43%

2; 9%

1; 5%

Q1: Using is-a Link

Never

Rarely

Sometimes

Often

Very Often

57%

3; 16%

13; 68%

3; 16%

Q2: Doubts about construct?

No

Yes, no fundamental

Yes

84%

21 valid responses, 10-15% of the population (2010; 4th i* workshop)

Q1 Q2


i* Surveyi*

Survey

Q1 How often do you use is-a links in the i* models that you develop?

Q2 If you use is-a links, do you have any doubt about their usage?

Q3 If A is-a B, what is the consequence regarding dependencies at the SD model level?

Q4 If A is-a B, what is the consequence regarding the SR model level?

B

A

is-a8

18

1

8

00

5

10

15

20

No Changes Add Remove Modify Other

Q3: Dependencies...

3

19

23

00

5

10

15

20

No Changes Add Remove Modify Other

Q4: SR Elements...

Q3 Q4

85% 90%

14% 38%5% 10%


21 valid responses, 10-15% of the population (2010; 4th i* workshop)

…as a Resulti* Survey

i* models

KR SD

CM

Introduce Feature

AddInvariant

RedeclareFeature

Knowledge Representation All N/A Defeasible

OO Languages All All All – Simula

Conceptual Modelling All All – ER None

i* Literature All Yu None

i* Survey 85-90% 14-38% 5-10%

i* Specialization Operations Extension Refinement RedefinitionModels reuse (Open-Closed principle) & Exceptions modeling


+

Outline

Introduction

State of the Art


• is-a link• i* Model Correctness• Specialization Proposal

• Extension• Refinement• Redefinition

• Methodology



is-a Link• Transitive• Acyclic• No dependencies from subactor to

superactor

24May 2013 The notion of Specialization in the i* Framework

Subactor / Superactor• Subactor inherits from superactor:

– All inside the boundary– All dependencies– All actor links


i* Models Correctness• LSP (Software Development)• LSP (SD) The subtype instances are also

the supertype’• LSP (i*) subactor can substitute its

superactor– Superactor’s incoming dependencies kept– Subactor satisfaction must imply superactor’s

• sat(a, M) sat(b, M) b

a

is-a

Liskov Substitution PrincipleIf for each object o1 of type S there is an

object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2,

then S is a subtype of T.


Actor Satisfaction


sat(a, M) = doutgoingDeps(a): sat(d)

Actor Satisfaction


sat(a, M) = iemainIEs(a): sat(ie, M)

main1

a

main2

g sgt

main1

b


• 3 kinds of specialization: Extension, Refinement and Redefinition.

• 9 specific operations (3 for each kind)– Intentional Elements– Intentional Element Links– Dependencies

• 1 operation per element


from the State of the Art

i* Survey

i* Literature

SD

CM

KR


Specialization Syntax

• Subactor only includes relevant elements• New Elements: regular lines• Inherited modified Elements: regular lines• Inherited non-modified Elements: dotted

lines• Specialized Elements: [] for the inherited

element name• Deleted Elements (redefinition): cross out


Extension

New Dependencies

New Dependencies

New Int. Elements

New IE LinksNew Dependencies

New Int. Elements

New IE Links

New Properties

New Methods

New Attributes

New Methods

New Attributes


New Intentional Element

Correctness condition: actors with internal Intentional Elements

Semantics: Add a new Main IE


New IE LinkSemantics: Add new decomposition to an inherited IE

Correctness condition: Only decomposition Links, no Contributions Links


New Dependency

Correctness condition: actors without internal Intentional Elements

Semantics: Add a new outgoing Dependency


Refinement

Modify Strengths

Modify Dependencies

Modify Int. Elements

Modify IE LinksNew Dependencies

Refine Int. Elements

Refine IE Links

Add Invariants

Restrict Features

Rename Attributes

Rename Roles


Refining IE

Correctness condition: satisfaction(refined IE) implies satisfaction(inherited IE)

Semantics: Restrict the IE


Refining IE

Correctness condition: softgoal goal, goal task, goal Resource

Semantics: Restrict the IE


Refining Contribution Link

Correctness condition: UnknownSome+, Some+Help, Help MakeUnknownSome-, Some-Break, BreakHurt

Semantics: Restrict the Contribution Link Value


Refining Dependency

Correctness condition: same condition as IE for dependum

Semantics: Restrict the dependum and/or strengths


Refining Dependency

Correctness condition: Open (O) Committed, Committed Critical (X)



Redefinition

Remove Dependencies

Remove IE

i* flexibility

Redefine Dependencies

Redefine IE

Redefine IE Links

Override Methods

Cancel Attributes

Modify Strengths


Redefining Intentional Element

Correctness condition: at least remove one decomposition link, no incoming dependencies arriving to removed elements

Semantics: Redefine the way to satisfy the IE (its decomposition)


Redefining Contribution Link

Correctness condition: not respecting the order for contribution link values

Semantics: Change Contribution Link value


Redefining Dependency

Correctness condition: not respecting the order for strength values



Operations Formalization

For each operation:• Formal Definition: signature, precondition

& postcondition (effects)• Theorem: actor specialization kept the

model correctness– First-order Logic– Induction


Specialization ProcessStep 1

is-a link


Extension

Redefinition

Refinement

Activity 2.1Step 2

Activity 2.2

Actor Link

Dependency

Decomposition subtree

Qualitative Contribution

PreventiveIncoming

Reallocation?

Outgoing/Incoming

Reallocation?

Outgoing/Incoming

Reallocation?

Outline

Introduction

State of the Art


• Contributions• Future Lines of Work• Publications



Contributions

• RQ1. Specialization Operations– Extension– Refinement– Redefinition

• RQ1. Methodology• RQ2. Formal definition for i* models• RQ3. Formal definition for i* Correctness


Validation

• Operations & Methodology– V1: Academic Exemplar– V4: Tool Support (HiME & REDEPEND)

• Formal– V2: i* Models & Operations Formalization

• Set theory

– V3: Fomal Validation• sat(subactor) implies sat(superactor)• First Order Logic (induction)


Future Lines of Work

• Real case (RISCOSS, OpenOME)

RefinementExtension


Future Lines of Work

• Multiple Inheritance• Refinement + Redefinition• How affect to properties & treatments for i*

framework• Including strengths to the dependency

satisfaction• Apply operations to other links (plays,

occupies, …)


Publications1 Clotet, R.; Franch, X.; Lopez, L.; Marco, J.; Seyff, N. and Grünbacher, P.: On the Meaning of

Inheritance in i*. In Proceedings of the 17th International Workshop on Agent-Oriented Information Systems (AOIS 2007).

2 Lopez, L.; Franch, X. and Marco, J.: Defining Inheritance in i* at the Level of SR Intentional Elements. In Proceedings of the 3rd International i* Workshop (iStar 2008).

3 Lopez, L.: A complete definition of the inheritance construct in i*. In Proceedings of the ER 2009 PhD Colloquium.

4 Lopez, L.; Franch, X. and Marco, J.: HiME: Hierarchical i* Modeling Editor.Tool Demo session for the ER 2009.

5 Cares, C.; Franch, X.; Lopez, L. and Marco, J.: Definition and uses of the i* metamodel. In Proceedings of the 4th International i* Workshop (iStar 2010).

6 Lopez, L.; Franch, X. and Marco, J.: Making Explicit some Implicit i* Language Decisions. In Proceedings of the 30th International Conference on Conceptual Modeling (ER 2011).

7 Lopez, L.; Franch, X. and Marco, J.: Specialization in i* Strategic Rationale Diagrams. In Proceeding of the 31th International Conference on Conceptual Modeling (ER 2012). Best Student Paper Award. An extended version as a Research Report.


Lidia López Cuesta

[email protected]

http://www.essi.upc.edu/~llopez/

Thank you

mailto:[email protected]

http://www.essi.upc.edu/~llopez/

Date post:	15-Dec-2014
Category:	Technology
Upload:	gessi-upc
View:	373 times
Download:	2 times

The notion of Specialization in the i* Framework

Technology