This thesis provides a formal proposal for the specialization relationship in the i* framework that allows its use in a well-defined manner. I root my proposal over existing works in different areas that are interested in representing knowledge: knowledge representation from Artificial Intelligence and conceptual modeling and object-oriented programming languages from Software Development. Also, I use the results of a survey conducted in the i* community that provides some insights about what i* modelers expect from specialization. As a consequence of this twofold analysis, I identify three specialization operations: extension, refinement and redefinition. For each of them, I:
• motivate its need and provide some rationale;
• distinguish the several cases that can occur in each operation;
• define the elements involved in each of these cases and the correctness conditions that must be fulfilled;
• demonstrate by induction the fulfilment of the conditions identified for preserving satisfaction;
• provide some illustrative examples in the context of an exemplar about travel agencies and travelers.
The specialization relationship is offered by the i* framework through the is-a construct defined over actors (a subactor is-a superactor) since it was first released. Although the overall meaning of this construct is highly intuitive, its effects at the level of intentional elements and dependencies are not always clear, hampering seriously its appropriate use.
In order to be able to reason about correctness and satisfaction, I define previously the conditions that must be preserved when a specialization takes place. In addition, I provide a methodology with well-defined steps that contextualize the formal aspects of this thesis in a development process.
As a conclusion, this thesis is making possible the use of the specialization relationship in i* in a precise, non-ambiguous manner.
Repurposing LNG terminals for Hydrogen Ammonia: Feasibility and Cost Saving
The notion of Specialization in the i* Framework
1. The notion of
Specialization in the
i* Framework
Lidia López Cuesta
PhD Defense
May, 16th 2013
Advisors:Dr. Xavier Franch
Dr. Jordi Marco
2. What will I talk …
in the next 45 minutes?
Introduction
• Motivation
• Research
Objective
• Research
Questions
• Methodological
Approach
May 2013
State of the Art
• In Related
Areas
• In the i*
Literature
• According to
the i*
Community
Specialization
Proposal
Conclusions &
Future Work
• is-a link
• i* Model
Correctness
• Specialization
Proposal
• Extension
• Refinement
• Redefinition
• Methodology
• Contributions
• Future Lines of
Work
• Publications
The notion of Specialization in the i* Framework
2
4. Motivation
Two types of i* diagrams
Customer
Travel
Agency
Easily Bought
SD Diagrams
Travel
Agency
Customer
Buy Travel
SR
Diagrams
Easily Bought
Name a Price
Travels Bought
Easily
They need to be synchronized
May 2013
The notion of Specialization in the i* Framework
4
5. Motivation
My focus: specialization in i* through is-a
• 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
6. Motivation
The ultimate effect of is-a is not clear
• The i* guide does not define it
• i* modellers use it intuitively
May 2013
The notion of Specialization in the i* Framework
6
7. Research Objective
Presenting a set of specialization
operations applicable in the process of
building models with the i* language.
May 2013
The notion of Specialization in the i* Framework
7
8. Research Questions
i*
Specialization
proposed
Define i*
Specialization
Operations
Presenting a set of specialization
operations applicable in the process of
RQ1: buildingactor specialization be applied when
How can models with the i* language.
RQ1:Specializati
on Applied
Correctly
RQ2: Define i*
Language
Core
RQ3: Validate i*
model
Correcteness
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?
May 2013
The notion of Specialization in the i* Framework
8
9. Research Questions
i*
Specialization
proposed
Define i*
Specialization
Operations
AND
RQ1:Specializati
on Applied
Correctly
AND
AND
RQ2: Define i*
Language
Core
RQ3: Validate i*
model
Correcteness
AND
RQ1-1:
Identify the i*
current use
RQ1-2.1:
specialization
in other areas
May 2013
RQ1-3:
define
methodology
RQ1-2: define
admisible
modifications
RQ1-2.2:
define
operations
semantics
RQ1-2.3:
define
operations
syntax
V1: Run
Academic
Exemplar
Define i*
Model
Correctness
V4: provide
Tool Support
The notion of Specialization in the i* Framework
V3: Formal
validation for
operations
V2: Formalize
operations
9
11. Methodological Approach
Formal
Analysis
Correctness
Validation
V3
Formal
• Formal
Validation
Analysis
Proof of
Concept
Methodology
Validation
Proof of
• Academic
Exemplar
Concept
New
Techniques
Specialization
Proposal
New
Techniques
Analytic
Models
Formalize
Analytic
• i* Language
Models
Descriptive
Models
Understand
the
phenomenom
Descriptive
• i* models
• i* survey
Models
May 2013
Correctness
Validation
Stage1: Initial
Proposal 2:
Stage
Proposal3:
Stage
Consolidtion
Proposal
Validation
V1
V4
V4
RQ1-2.2
RQ1-2.3
RQ1-3
• Operation
Semantics
Specialization
• Operation
Syntax
Proposal
• Methodology
RQ2
RQ3
V2
• i* Models
Formalize
Correctness
• Operations
RQ1-2.1
RQ2
RQ3
• i* models
• i* dialects
• i* Models
Correctness
RQ1-1
Methodology
• • ToolSupport:
Tool Support:
Validation
HiME
REDEPEND
Understand
• Related Areas
the
phenomenom
The notion of Specialization in the i* Framework
11
12. Outline
Introduction
State of the Art
• In Related Areas
• In the i* Literature
• According to the i* Community
Specialization Proposal
Conclusions & Future Work
May 2013
The notion of Specialization in the i* Framework
12
13. State of the Art
KR SD
Related
Areas
CM
i*
i*
Literature Survey
May 2013
The notion of Specialization in the i* Framework
13
15. KR
SD
CM
Software Development
• Inheritance - main characteristics in OOP
• Simula 67(1968)
– Order class Single Order
Taxomania Rule
• Nowadays
Every heir must introduce a feature,
– Java, C# - overrides for methods
redeclare an inherited feature, or add an
– Visual Basic – shadows
invariant clause
• More than programing languages…
– Eiffel – Contracts (restricting methods)
– Taxomania rule (taxo + mania)
May 2013
The notion of Specialization in the i* Framework
15
16. KR
SD
CM
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
May 2013
The notion of Specialization in the i* Framework
16
17. KR
SD
CM
Specialization in Related Areas
Area
Knowledge
Representation
Approach
Strict
Defeasible
Introduce
feature
New
Attributes
Add Invariant
Redeclare feature
Does not Apply
No
Does not Apply
Attribute Cancellation
Simula 67
No
Taxomania Rule
Every heir must introduce a feature,
redeclare an inherited feature, or add an
invariant clause
Smalltalk-80, Delphi,
C++, C#, Java
OO Languages
Visual Basic
New
Properties
& Methods
Borgida & Mylopoulos
May 2013
Overrides and Shadows for
properties and methods
New
Attributes &
Methods
Renaming and Redefinition
for routines and procedures
using contracts
No
Semantic data models
UML
Simulation accessing
properties via methods
Adding invariants
Eiffel
Conceptual
Modeling
Overrides for methods
Simulation for properties
accessing via methods
No
Features Restriction
(cardinality, visibility,…)
Attributes and Roles
Renaming
Attributes
The notion of Specialization in the i* Framework
No
17
18. i*
Literatur
e
Specialization in i* Literature
1995
Supe
ractor
Add invariant
Suba
ctor
Introduce a feature
May 2013
SR?
The notion of Specialization in the i* Framework
18
20. i*
Survey
i* Survey
Q1
Q2
B
is-a
A
57%
84%
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?
21 valid responses, 10-15% of the population (2010; 4th i* workshop)
May 2013
The notion of Specialization in the i* Framework
20
21. i*
Survey
i* Survey
Q3: Dependencies...
20
B
10
Q3
85%
8
8
is-a
5%
5
19
90%
Q4
10
14%
1
A
20
15
18
15
Q4: SR Elements...
5
10% 38%
3
3
2
0
0
0
0
No Changes
Add
Remove
Modify
Other
No Changes
Add
Remove
Modify
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
Other
If A is-a B, what is the consequence regarding the SR model level?
21 valid responses, 10-15% of the population (2010; 4th i* workshop)
May 2013
The notion of Specialization in the i* Framework
21
22. KR
SD
…as a Result
CM
i*
i*
models Survey
Introduce
Feature
Add
Invariant
Redeclare
Feature
Knowledge Representation
All
N/A
Defeasible
OO Languages
All
All
All – Simula
Conceptual Modelling
All
All – ER
None
i* Literature
All
Yu
None
85-90%
14-38%
5-10%
i* Survey
i* Specialization
Extension
Refinement
Redefinition
Models reuse (Open-Closed principle) & Exceptions modeling
Operations
+
May 2013
The notion of Specialization in the i* Framework
22
23. Outline
Introduction
State of the Art
Specialization Proposal
• is-a link
• i* Model Correctness
• Specialization Proposal
• Extension
• Refinement
• Redefinition
• Methodology
Conclusions & Future Work
May 2013
The notion of Specialization in the i* Framework
23
24. is-a Link
• Transitive
• Acyclic
• No dependencies from subactor to superactor
May 2013
The notion of Specialization in the i* Framework
24
25. Subactor / Superactor
• Subactor inherits from superactor:
– All inside the boundary
– All dependencies
– All actor links
May 2013
The notion of Specialization in the i* Framework
25
26. i* Models Correctness
• LSP (Software subtype instances are also
(SD) The Development)
the supertype’
Liskov Substitution Principle
• LSPfor each object can substitute its an
If (i*) subactor o1 of type S there is
object o2 of
superactor type T such that for all programs
–P defined in terms of T, the behavior ofkept
Superactor’s incoming dependencies P is
unchanged when o1 is substituted for o2,
– Subactor satisfaction must imply superactor’s
then S is a subtype of T.
• sat(a, M)
sat(b, M)
b
is-a
a
May 2013
The notion of Specialization in the i* Framework
26
27. Actor Satisfaction
sat(a, M) = d outgoingDeps(a): sat(d)
May 2013
The notion of Specialization in the i* Framework
27
28. Actor Satisfaction
b
main 1
a
main 1
g
main 2
t
sg
sat(a, M) = ie mainIEs(a): sat(ie, M)
May 2013
The notion of Specialization in the i* Framework
28
29. Specialization Proposal
• 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
May 2013
The notion of Specialization in the i* Framework
29
30. from the State of the Art
KR SD
CM
i*
i*
Literature Survey
May 2013
The notion of Specialization in the i* Framework
30
31. 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
May 2013
The notion of Specialization in the i* Framework
31
32. Extension
New Properties
New Attributes
New Methods
New Attributes
New Methods
New Int. Elements
New Int. Elements
New Dependencies New IE Links New IE Links
New Dependencies Dependencies
New
May 2013
The notion of Specialization in the i* Framework
32
33. New Intentional Element
Semantics: Add a new Main IE
Correctness condition: actors with internal Intentional Elements
May 2013
The notion of Specialization in the i* Framework
33
34. New IE Link
Semantics: Add new decomposition to an inherited IE
Correctness condition: Only decomposition Links, no Contributions Links
May 2013
The notion of Specialization in the i* Framework
34
35. New Dependency
Semantics: Add a new outgoing Dependency
Correctness condition: actors without internal Intentional Elements
May 2013
The notion of Specialization in the i* Framework
35
36. Refinement
Add Invariants
Restrict Features
Rename Attributes
Refine Int. Elements
Rename Roles
Modify Strengths Refine IE LinksModify Int. Elements
New DependenciesModify IE Links
Modify Dependencies
May 2013
The notion of Specialization in the i* Framework
36
37. Refining IE
Semantics: Restrict the IE
Correctness condition: satisfaction(refined IE) implies satisfaction(inherited IE)
May 2013
The notion of Specialization in the i* Framework
37
38. Refining IE
Semantics: Restrict the IE
Correctness condition: softgoal goal, goal task, goal Resource
May 2013
The notion of Specialization in the i* Framework
38
39. Refining Contribution Link
Semantics: Restrict the Contribution Link Value
Correctness condition: UnknownSome+, Some+Help, Help Make
UnknownSome-, Some-Break, BreakHurt
May 2013
The notion of Specialization in the i* Framework
39
40. Refining Dependency
Semantics: Restrict the dependum and/or strengths
Correctness condition: same condition as IE for dependum
May 2013
The notion of Specialization in the i* Framework
40
41. Refining Dependency
Semantics: Restrict the dependum and/or strengths
Correctness condition: Open (O) Committed, Committed Critical (X)
May 2013
The notion of Specialization in the i* Framework
41
43. Redefining Intentional Element
Semantics: Redefine the way to satisfy the IE (its decomposition)
Correctness condition: at least remove one decomposition link, no incoming
dependencies arriving to removed elements
May 2013
The notion of Specialization in the i* Framework
43
44. Redefining Contribution Link
Semantics: Change Contribution Link value
Correctness condition: not respecting the order for contribution link values
May 2013
The notion of Specialization in the i* Framework
44
45. Redefining Dependency
Semantics: Restrict the dependum and/or strengths
Correctness condition: not respecting the order for strength values
May 2013
The notion of Specialization in the i* Framework
45
46. Operations Formalization
For each operation:
• Formal Definition: signature, precondition
& postcondition (effects)
• Theorem: actor specialization kept the
model correctness
– First-order Logic
– Induction
May 2013
The notion of Specialization in the i* Framework
46
47. Specialization Process
Step 1
is-a
link
Step 2
Activity 2.1
Extension
Preventive
Incoming
Reallocation?
Redefinition
Outgoing/
Incoming
Reallocation?
Refinement
Activity 2.2
Outgoing/
Incoming
Reallocation?
Actor Link
Dependency
Qualitative Contribution
Decomposition subtree
May 2013
The notion of Specialization in the i* Framework
47
48. Outline
Introduction
State of the Art
Specialization Proposal
Conclusions & Future Work
• Contributions
• Future Lines of Work
• Publications
May 2013
The notion of Specialization in the i* Framework
48
49. Contributions
• RQ1. Specialization Operations
– Extension
– Refinement
– Redefinition
• RQ1. Methodology
• RQ2. Formal definition for i* models
• RQ3. Formal definition for i* Correctness
May 2013
The notion of Specialization in the i* Framework
49
50. 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)
May 2013
The notion of Specialization in the i* Framework
50
51. Future Lines of Work
• Real case (RISCOSS, OpenOME)
Extension
May 2013
The notion of Specialization in the i* Framework
Refinement
51
52. 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, …)
May 2013
The notion of Specialization in the i* Framework
52
53. Publications
1 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.
May 2013
The notion of Specialization in the i* Framework
53