The specialization relationship is offered by the i* modeling language through the is-a construct that applies over actors (a subactor is-a superactor). Although the overall meaning of this construct is highly intuitive, its semantics when it comes to the fine-grained level of strategic rationale (SR) diagrams is not defined, hampering seriously its appropriate use. In this paper we provide a formal definition of the specialization relationship at the level of i* SR diagrams. We root our proposal over existing work in conceptual modeling in general, and object-orientation in particular. Also, we use the results of a survey conducted in the i* community that provides some hints about what i* modelers expect from specialization. As a consequence of this twofold analysis, we identify, define and specify two specialization operations, extension and refinement, that can be applied over SR diagrams. Correctness conditions for them are also clearly stated. The result of our work is a formal proposal of specialization for i* that allows its use in a well-defined manner.

1. Specialization in i* Strategic
Rationale Diagrams

2. Outline
• Motivation and research question
• Antecedents
• Proposal
 Notion of correctness
 Specialization operations
• Conclusions and related work
2

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

4. Motivation
Our focus: specialization in i* through is-a
Customer
Easily Bought
Travel
Agency
is-a
Family
The is-a association represents a generalization, with an actor being a specialized case of
another actor (ref. The i* Guide)
4

5. Motivation
The ultimate effect of is-a is not clear:
• The i* guide does not define it
• i* modelers use it intuitively (and sometimes
inconsistently)
5

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

7. Research Question
Given an actor specialization relationship
declared at the SD level, what modeling
operations can be defined at the SR level?
• What is the relevant background to make
this decision?
• What are the effects of these operations?
• What are the correctness conditions to be
fulfilled for their application?
7

8. Strategy
Formulate an answer that aligns with:
• the general concept of specialization in
the conceptual modeling community
• the reported uses made by i* researchers
• the preferences gathered empirically from
the community
8

9. Antecedents: conceptual modeling
Analysis using Meyer’s Taxomania rule: “Every heir
must introduce a feature, redeclare an inherited
feature, or add an invariant clause”.
Area
Knowledge
Representation
Approach
Strict
Defeasible
New feature
Add Invariant
Redeclare feature
New
Attributes
No
No
No
Attribute Cancellation
Simula 67
No
Smalltalk-80, Delphi, C++,
C#, Java
OO Languages
Visual Basic
New
Properties &
Methods
Conceptual
Modeling
UML
Borgida & Mylopoulos
Overrides for methods
Simulation for properties
accessing via methods
Overrides and Shadows for
properties and methods
Adding invariants
Eiffel
Semantic data models
Simulation accessing
properties via methods
New
Attributes &
Methods
Renaming and Redefinition for
routines and procedures using
contracts
No
No
No
No
Attributes
No
9

10. Reported uses
Regularly used but
RQ not answered
10

11. Community perception: a survey
21 valid responses (July-Sept. 2010; 4th i* wks.)
• 57% use sometimes, often or very often
is-a links in their i* models
• 84% have doubts about its usage
• 85%-90% allow for addition of elements
(dependencies / IEs)
• 14%-38% allow for modification of elements
• 5%-10% do not allow for removals of
elements
11

12. As a result…
From the three different possibilities:
• Extension: a new IE or dependency,
related somehow to inherited
elements, is added to the subactor.
• Redefinition: an IE or dependency
that exists in the superactor is
changed in the subactor.
• Refinement: the semantics of an
inherited IE or dependency is made
more specific.
12

13. Notion of correctness
• Algebraic formalization: see paper
 Some simplifications made
b
is-a
a
• Actor specialization correctness:
sat(a, M) sat(b, M)
• Actor correctness:
sat(ie, M) = ie mainIEs(a): sat(ie, M)
13

14. Notion of correctness
• IE correctness:
 ie not decomposed: given by user
 ie decomposed: see decomposition
task-decomposition: sat(ie, M) sat(iesub, M)
means-end: sat(iemeans, M) sat(ie, M)
 ie with contributions (softgoal): Horkoff&Yu’s rules
 ie with outgoing dependencies:
sat(ie, M) sat(iedep, M)
14

15. Definition of operations
• The paper introduces 5 different operations (2
for extension, 3 for refinement)
• For each operation:
 Definition:
 signature
 precondition
 postcondition (effects)
 Theorem: actor specialization correctness is kept
 always by induction
• I’m not going to do that here!!
15

16. Extension operations
• OP1: IE extension with decomposition link:
TA
is-a
UTA
Name a Price
Travels
Contracted
Increased
Customers
Attracted
is-a
Sell Travels
Assistence
Provided
Travels
Contracted
Increased
Book Travel
Help
Get Travels
Search Trip
by
Conference
Attractive
Products
OR
Search Trip
by
Destination
Name a Price
Good
Quality-Price
Rate
FTA
Good
Quality-Price
Rate
Help
OR
Many Kind
of Travels
Offered
Family
Facilities
Offered
Provide
Child
Discounts
Many Kind
of Travels
Offered
Help
Provide
Familiar
Destinations
Remark: please notice the graphical convention
16

17. Extension operations
• OP2: Addition of new main IEs
Services
Provider
is-a
Profit Increased
Travel
Services
Provider
Customer data
sold to 3rd
Many
Transactions
Processed
Costs
Reduced
Hurt
Help
Travel Services
Provided
Hurt
List Offerings
Privacy Kept
Encrypt Data
Contract
Travels
Encrypt Data
Help
17

18. Refinement operations
• OP3: IE refinement
 the implication given by correctness definition needs
to be preserved
18

19. Refinement operations
• OP4: contribution link refinement
 always keeping the “polarity” of the value
TA
Assistance
Provided
Travels
Contracted
Easily
Asynchronous
Support
is-a
Synchronous
Support
FTA
Customer
Help
Assistance
Obtained
is-a
Help
Travels Bought
Easily
Family
Assistance
Provided
Synchronous
Support
Make
Travels
Contracted
Easily
Provide
Hotline
[Telephone]
Assistance
Obtained
Make
Travels Bought
Easily
19

20. Refinement operations
• OP5: dependency refinement
 either dependum (IE) or strength (not in the paper!!)
TA
Customer
Name a Price
Book Travel
Travel Offerings
Travel
Offerings
Customer Info
is-a
Contract Travel
is-a
Research
er
UTA
Name a Price
Book Travel
Conference
[Travel Offerings]
Unversity&[Cust
omer Info]
X
Conference
[Travel
Offerings]
Contract Travel
20

21. Conclusions
Research questions answered:
What modeling operations can be defined at
the SR level? EXTENSION & REFINEMENT
• What is the relevant background to make
this decision? SOTA & SURVEY
• What are the effects? FORMAL DEFINITION
• What are the correctness conditions to be
fulfilled for their application? SATISFACTION
NOTION
21

22. Future work
• Consider also redefinition
• Ontological meaning for specialization
• Apply same strategy for other types of actor
links
22

23. Hope you
liked it!