The notion of Specialization in the i* Framework
Upcoming SlideShare
Loading in...5
×
 

The notion of Specialization in the i* Framework

on

  • 560 views

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 ...

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.

Statistics

Views

Total Views
560
Views on SlideShare
467
Embed Views
93

Actions

Likes
0
Downloads
0
Comments
0

4 Embeds 93

http://lidiaresearching.blogspot.com.es 75
https://lidiaresearching.blogspot.com 14
http://lidiaresearching.blogspot.com 3
https://twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

The notion of Specialization in the i* Framework The notion of Specialization in the i* Framework Presentation Transcript

  • The notion of Specialization in the i* Framework Lidia López Cuesta PhD Defense May, 16th 2013 Advisors:Dr. Xavier Franch Dr. Jordi Marco
  • 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
  • Outline Introduction • • • • Motivation Research Objective Research Questions Methodological Approach State of the Art Specialization Proposal Conclusions & Future Work May 2013 The notion of Specialization in the i* Framework 3 View slide
  • 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 View slide
  • 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
  • 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
  • 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
  • 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
  • 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
  • Methodological Approach Formal Analysis Proof of Concept Methodology Validation New Techniques Specialization Proposal Analytic Models Formalize Descriptive Models May 2013 Correctness Validation Understand the phenomenom The notion of Specialization in the i* Framework 10
  • 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
  • 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
  • State of the Art KR SD Related Areas CM i* i* Literature Survey May 2013 The notion of Specialization in the i* Framework 13
  • KR SD CM Knowledge Representation • Semantic Networks (Quillian 1966) Attribute Cancelation EXCEPTIONS May 2013 The notion of Specialization in the i* Framework 14
  • 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
  • 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
  • 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
  • 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
  • i* Literatur e Specialization in i* Literature Regurlarly used but no details May 2013 The notion of Specialization in the i* Framework 19
  • 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
  • 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
  • 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
  • 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
  • is-a Link • Transitive • Acyclic • No dependencies from subactor to superactor May 2013 The notion of Specialization in the i* Framework 24
  • 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
  • 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
  • Actor Satisfaction sat(a, M) = d outgoingDeps(a): sat(d) May 2013 The notion of Specialization in the i* Framework 27
  • 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
  • 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
  • from the State of the Art KR SD CM i* i* Literature Survey May 2013 The notion of Specialization in the i* Framework 30
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Refining Contribution Link Semantics: Restrict the Contribution Link Value Correctness condition: UnknownSome+, Some+Help, Help  Make UnknownSome-, Some-Break, BreakHurt May 2013 The notion of Specialization in the i* Framework 39
  • 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
  • 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
  • Redefinition Cancel Attributes Override Methods Redefine IE Remove Dependencies Modify Strengths Redefine IE Links Remove IE Redefine Dependencies i* flexibility May 2013 The notion of Specialization in the i* Framework 42
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Future Lines of Work • Real case (RISCOSS, OpenOME) Extension May 2013 The notion of Specialization in the i* Framework Refinement 51
  • 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
  • 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
  • Thank you Lidia López Cuesta llopez@essi.upc.edu http://www.essi.upc.edu/~llopez/