• Aucun résultat trouvé

Complete proceedings as a single PDF-file

N/A
N/A
Protected

Academic year: 2022

Partager "Complete proceedings as a single PDF-file"

Copied!
188
0
0

Texte intégral

(1)

iStar 2011 – Proceedings of the 5 th International i * Workshop

29-30

th

August, 2011 Trento, Italy

http://www.cin.ufpe.br/~istar11/

Jaelson Castro

Xavier Franch

John Mylopoulos

Eric Yu (eds.)

(2)

a CEUR Workshop Proceedings, ISSN 1613-0073

© 2011 for the individual papers by the papers' authors. Copying permitted for private and academic purposes. This volume is published and copyrighted by its editors.

(3)

Keynote talk. Governing Sociotechnical Systems. Munindar P. Singh, p. 1

Scientific Papers

Session 1. Framework Evaluation

1. Eight Deadly Sins of GRL. Gunter Mussbacher, Daniel Amyot, Patrick Heymans, p. 2-7 2. iStarML: Principles and Implications. Carlos Cares, Xavier Franch, p. 8-13

3. Empirical Evaluation of Tropos4AS Modelling. Mirko Morandini, Anna Perini, Alessandro Marchetto, p. 14-19

Session 2. Model Analysis and Evaluation

4. Detecting Judgment Inconsistencies to Encourage Model Iteration in Interactive i*

Analysis. Jennifer Horkoff, Eric Yu, p. 20-25

5. Towards a Declarative, Constraint-Oriented Semantics with a Generic Evaluation Algorithm for GRL. Hao Luo, Daniel Amyot, p. 26-31

6. A Flexible Approach for Validating i* Models. Ralf Laue, Arian Storch, p. 32-36 Session 3a. Ontologies and Foundations

7. Ontological Analysis of Means-End Links. Xavier Franch, Renata Guizzardi, Giancarlo Guizzardi, Lidia López, p. 37-42

8. Supporting i* Model Integration through an Ontology-based Approach. Karen Najera, Anna Perini, Alicia Martínez, Hugo Estrada, p. 43-48

9. The Mysteries of Goal Decomposition. Scott Munro, Sotirios Liaskos, Jorge Aranda, p.

49-54

Session 3b. Enterprise and Software Architectures

10. Development of Agent-Driven Systems: from i* Architectural Models to Intentional Agents Code. Maurício Serrano, Julio Cesar Sampaio do Prado Leite, p. 55-60

11. Towards Adoption and Use of i* to Support Enterprise Architecture in Organizational Settings: a Position Paper. Daniel Gross, Uwe Zdun, Eric Yu, p. 61-65

12. Towards an i*-based Architecture Derivation Approach. Diego Dermeval, Monique Soares, Fernanda Alencar, Emanuel Santos, João Pimentel, Jaelson Castro, Márcia Lucena, Carla Silva, Cleice Souza, p. 66-71

Session 4a. Application to Domains

13. Nòmos: from Strategic Dependencies to Obligations. Silvia Ingolfo, John Mylopoulos, Anna Perini, Alberto Siena, Angelo Susi, p. 72-77

14. Technology Representation in i* Modules. Eliel Morales, Xavier Franch, Alicia Martínez, Hugo Estrada, Oscar Pastor, p. 78-83

15. An extension of i* to Model CSCW Requirements Applied to a Collaborative Conference

Review System. Miguel A. Teruel, Elena Navarro, Víctor López-Jaquero, Francisco

Montero, Pascual González, p. 84-89

(4)

96-101

18. Security Requirements Engineering for Service-Oriented Applications. Fabiano Dalpiaz, Elda Paja, Paolo Giorgini, p. 102-107

19. Goals and Scenarios for Requirements Engineering of Software Product Lines. Gabriela Guedes, Carla Silva, Jaelson Castro, p. 108-113

Session 5a. User-Centered Design and Simulation

20. Bridging User-Centered Design and Requirements Engineering with GRL and Persona Cases. Shamal Faily, p. 114-119

21. Issues and Challenges in Coupling Tropos with User-Centred Design. Luca Sabatucci, Chiara Leonardi, Angelo Susi, Massimo Zancanaro, p. 120-125

22. Causal vs. Effectual Behavior - Support for Entrepreneurs. Jan Schlüter, Dominik Schmitz, Malte Brettel, Matthias Jarke, Ralf Klamma, p. 126-131

Session 5b. Sociality and Measurement

23. A Social Interaction Based Pre-Traceability for i* Models. Maurício Serrano, Julio Cesar Sampaio do Prado Leite, p. 132-137

24. Requirements Engineering for Social Applications. Amit K. Chopra, Paolo Giorgini, p.

138-143

25. Intentional Models based on Measurement Theory. Andre Rifaut, p. 144-149

Tool Fair Demos

Preface, p. 150

26. I*-Prefer: A Tool for Preference Model-Driven Decision Making. Tianying Li, Tong Li, Haihua Xie, Lin Liu, p. 151-153

27. OpenOME: An Open-source Goal and Agent-Oriented Model Drawing and Analysis Tool. Jennifer Horkoff, Yijun Yu, Eric Yu, p. 154-156

28. Implementing Structural Measures over i* Diagrams. Daniel Colomer, Xavier Franch, p.

157-159

29. GRL Modeling and Analysis with jUCMNav. Daniel Amyot, Gunter Mussbacher, Sepideh Ghanavati, Jason Kealey, p. 160-162

30. iStarTool: Modeling Requirements using the i* Framework. Átlia Malta, Monique Soares, Emanuel Santos, Josias Paes, Fernanda Alencar, Jaelson Castro, p. 163-165

31. Tool Interoperability using iStarML. Carlos Cares, Xavier Franch, Daniel Colomer, Lidia López, p. 166-168

32. Adding Functionality to openOME for Everyone. Ralf Laue, Arian Storch, p. 169-171 33. Tropos Modeling, Code Generation and Testing with the Taom4E Tool. Mirko

Morandini, Cu Duy Nguyen, Loris Penserini, Anna Perini, Angelo Susi, p. 172-174 34. Analysing a Repository of Design Knowledge with the GO-DKL Browser. Andrew Hilts,

Eric Yu, p. 175-177

35. i* Modules: a jUCMNav Implementation. Daniel Colomer, Xavier Franch, p. 178-180

(5)

Preface

The iStar workshop series is dedicated to the discussion of concepts, methods, techniques, tools, and applications associated with i* and related frameworks and approaches. Following successful workshops in Trento, Italy (2001), London, England (2005), Recife, Brazil (2008), and Hammamet, Tunisia (2010), the 5

th

International i* Workshop is being held back again in Trento. As with previous editions, the objective of the workshop is to provide a unique opportunity for exchanging ideas, comparing notes, and forging new collaborations.

This year, the workshop is co-located with the 19

th

IEEE International Requirements Engineering Conference (RE 2011), benefiting from the common interests shared by the workshop and the conference. As with past editions, we have tried to keep the format small and informal so as to maximizing interaction. However, the increasing number of submissions and presented papers have forced for the first time in the workshop to organize some parallel sessions. We preferred to adopt this option, rather than to reduce the time allocated to papers or be more restrictive in the acceptance process. We have included in the wrap-up session a 5- minute summary of each parallel session given by the session chairs. Also in terms of format, the 30 minutes allocated to each paper have been split equally into presentation and discussion.

Concerning the review process, each of the 29 submitted papers went through a thorough review process with three reviews from a programme committee, providing useful feedback for authors. Revised versions of the 25 accepted papers are included in these proceedings. We thank authors and reviewers for their valuable contributions.

The program was completed with a keynote given by Prof. Munindar P. Singh entitled

“Governing Sociotechnical Systems” and a tools fair in which 10 tools were presented in a plenary session - the first such event in the workshop series.

Last but not least, we want to deeply thank the organizers of the RE conference for their great support.

We look forward to lively conversations and debates with old and new friends at the workshop, in the wonderful surroundings of Trento, Italy!

Jaelson Castro, Universidade Federal de Pernambuco, Brazil

Xavier Franch, Universitat Politècnica de Catalunya, Spain

John Mylopoulos, University of Trento, Italy

Eric Yu, University of Toronto, Canada

(6)

Fernanda Alencar, Universidade Federal de Pernambuco, Brazil.

Daniel Amyot, University of Ottawa, Canada.

Carlos Cares, Universidad de la Frontera, Chile.

Luiz Marcio Cysneiros, York University, Canada.

Fabiano Dalpiaz, University of Trento, Italy.

Hugo Estrada, CENIDET, Mexico.

Paolo Giorgini, University of Trento, Italy.

Daniel Gross, University of Toronto, Canada.

Renata S.S. Guizzardi, Universidade Federal do Espírito Santo, Brazil.

Jennifer Horkoff, University of Toronto, Canada.

Dimitris Karagiannis, Universitaet Wien, Austria.

Alexei Lapouchnian, University of Toronto, Canada.

Julio Cesar Sampaio do Prado Leite, Pontificia Univ. Catolica do Rio de Janeiro, Brazil.

Sotirios Liaskos, York University, Canada.

Lin Liu, Tsinghua University, China.

James Lockerbie, City University London. UK.

Lidia López, Universitat Politècnica de Catalunya, Spain.

Oscar Pastor, Universidad Politécnica de Valencia, Spain.

Michael Petit, University of Namur, Belgium.

André Rifaut, Centre de Recherche Public Henri Tudor, Luexembourg.

Pete Sawyer, Lancaster University, UK.

Dominik Schmitz, RWTH Aachen University, Germany.

Juan Carlos Trujillo, Universidad de Alicante, Spain.

Yves Wautelet, Hogeschool-Universiteit Brussel, Belgium.

Jelena Zdravkovic, Stockholm University, Sweden.

Submissions Management

Carla Silva, Universidade Federal da Paraiba, Brazil.

Tools Fair Organizer

Jennifer Horkoff, University of Toronto, Canada.

Tools Fair Committee

Jennifer Horkoff, University of Toronto, Canada.

Xavier Franch, Universitat Politècnica de Catalunya, Spain.

Webmaster

Diego Dermeval Medeiros da Cunha Matos, Universidade Federal de Pernambuco, Brazil.

(7)

*RYHUQLQJ6RFLRWHFKQLFDO6\VWHPV

0XQLQGDU36LQJK

1RUWK&DUROLQD6WDWH8QLYHUVLW\

http://www.csc.ncsu.edu/faculty/mpsingh/

$EVWUDFW)URPVRFLDOQHWZRUNVWREXVLQHVVSURFHVVHVWRFROODERUDWLYHVFLHQFH D KDOOPDUN RI PRGHUQ DSSOLFDWLRQV RI LQIRUPDWLRQ WHFKQRORJ\ LV WKDW WKH\

LQYROYH LQWHUDFWLRQV EHWZHHQ ODUJHO\ DXWRQRPRXV DQG KHWHURJHQHRXV SDUWLFLSDQWV , GHILQH VRFLRWHFKQLFDO V\VWHPV DV WKRVH WKDW LQYROYH ERWK UHDO ZRUOG VRFLDO UHODWLRQVKLSV EHWZHHQ WKH SDUWLFLSDQWV DQG WHFKQRORJLFDO HOHPHQWV 7UDGLWLRQDO FRPSXWHU VFLHQFH FRQFHQWUDWHV RQ WKH WHFKQRORJLFDO HOHPHQWV DQG KDV OLWWOH WR RIIHU LQ WKH ZD\ RI DEVWUDFWLRQV DQG WHFKQLTXHV IRU VRFLRWHFKQLFDOV\VWHPVOHDYLQJSUDFWLWLRQHUVZLWKQRRSWLRQEXWWRUHVRUWWRDG KRFDSSURDFKHV

, PRWLYDWH JRYHUQDQFH DV WKH SURSHU QRWLRQ RI DGPLQLVWUDWLRQ LQ VXFK VHWWLQJV

*RYHUQDQFH UHFRJQL]HV WKH LQKHUHQW SHHUWRSHHU QDWXUH RI VRFLRWHFKQLFDO V\VWHPV DQG WKHLUQHHG WR VXSSRUW IOH[LEOH LQWHUDFWLRQV DPRQJ WKH SDUWLFLSDQWV ,QWKLVPDQQHULWFRQWUDVWV ZLWKWKH7ZHQWLHWK&HQWXU\QRWLRQRIPDQDJHPHQW RIVXERUGLQDWHVE\VXSHULRUV

*RYHUQDQFH RIIHUV D JUHDW RSSRUWXQLW\ IRU PXOWLDJHQW V\VWHPV SUDFWLFH DQG UHVHDUFK , VKRZ KRZ ORQJVWDQGLQJ PXOWLDJHQW WKHPHV RI RUJDQL]DWLRQV LQVWLWXWLRQVDQGQRUPVFRPHWRJHWKHULQJRYHUQDQFHDQGDOVRKRZZHQHHGWR JR EH\RQG H[LVWLQJ PXOWLDJHQW DSSURDFKHV LQ PRGHOLQJ DQG DSSO\LQJ WKHVH WKHPHV

,GUDZP\H[DPSOHVIURPWKH2FHDQ2EVHUYDWRULHV,QLWLDWLYHZKHUHWKLVQRWLRQ RIJRYHUQDQFHLVEHLQJDSSOLHG

(8)

$"#. '3 $)-*!

HAG8E$HFF546;8E4A<8?@LBG 4A7 '4GE<6>8L@4AF

8CG B9*LFG8@F4A7B@CHG8EA:<A88E<A:4E?8GBA,A<I8EF<GL4A474

*6;BB?B9?86GE<64?A:<A88E<A:4A7B@CHG8E*6<8A68,A<I8EF<GLB9&GG4J44A474

')8 *)8F84E6;8AGE8,A<I8EF<GLB9%4@HE8?:<H@

-.,.B4? @B78?<A: ?4A:H4:8F 4E8 ABJ 4A <AG8:E4? C4EG B9 E8DH<E8@8AGF 8A:<A88E<A: +;8L4??BJ9BE G;8FLFG8@4G<664CGHE8B9E4G<BA4?8F9BEFG4>8;B?78E A887F 4A7 8A45?8 G;8 E84FBA<A: 45BHG CBG8AG<4? FLFG8@ FB?HG<BAF +;8 :B4?

BE<8AG87 )8DH<E8@8AG #4A:H4:8 )# <F 5BG; 4 GLC<64? :B4? @B78?<A: ?4A :H4:8 4A7 4A <AG8EA4G<BA4? FG4A74E7 L8G <G FH998EF 9EB@ @4AL F;BEG6B@<A:F 4><A GB 7847?L F<AF G;4G E8?4G8 GB <GF 6BA6E8G8 FLAG4K F8@4AG<6F 4CCEB46; GB

@B7H?4E<GL 4A4?LF<F4A7 8KG8AF<5<?<GL 4F87 BA L84EF B9 8KC8E<8A68 HF<A:

)#J8 7<F6HFF F8I8E4? F;BEG6B@<A:F 4A7CB<AGGBE8?8I4AG9HGHE8JBE>4E84F 31*,-B4?$B78?<A:)# *LAG4K*8@4AG<6F $B7H?4E<GLA4?LF<F

).,*/.$*)

B4? @B78?<A: 9BE@F 4A <@CBEG4AG C4EG B9 E8DH<E8@8AGF 8A:<A88E<A: &I8E G;8 ?4FG 786478 G;EBH:; 8KC8E<8A68 78I8?BC<A: FG4A74E7<M<A: 4A7 HF<A: G;8 B4?BE<8AG87 )8DH<E8@8AG#4A:H4:8)# 23J8;4I8B5F8EI87F8I8E4? <@CBEG4AG <FFH8F G;4G J8 6BAF<78EGB58 4><AGB T7847?LF<AFU .84?FBFHFC86GG;4G@4ALB9G;8F8F<AF 6BH?7 58 :8A8E4?<M87 GB BG;8E :B4? @B78?<A: ?4A:H4:8F FH6; 4F < "&* 4A7 +EBCBF ;8A68 G;8<E :8A8E4? <AG8E8FG GB G;8 :B4? @B78?<A: 6B@@HA<GL A G;8 9B??BJ<A: F86G<BA J8 5E<89?L F8G BHG BHE E8F84E6; B5=86G<I8F 4A7 <A *86G<BA J8 7<F6HFF G;8 <78AG<9<87

<FFH8F *86G<BA CEBI<78FBHE6BA6?HF<BA4A7 E8CBEGF <A498JJBE7F BA9HGHE8JBE>

- ,# % .$0 -

.84<@GB<@CEBI8G;8FG4G8B9G;84EGB9:B4?@B78?<A:5L9<EFG<78AG<9L<A:F;BEG6B@

<A:F<A BA8 B9G;8@4<AFGE84@ :B4?@B78?<A:?4A:H4:8F )#G;8A4A4?LM<A:G;8F8 F;BEG6B@<A:FFLFG8@4G<64??L<AI8FG<:4G<A: <784FBA;BJGB477E8FFG;8@ 4A79<A4??L CEBI<7<A: FB?HG<BAF 9BE G;8F8 F;BEG6B@<A:F G;4G 64A 58 <A6BECBE4G87 <AGB G;8 )#

FG4A74E7 4A7C8E;4CF<AGBBG;8E:B4?@B78?<A:?4A:H4:8F 8E8J8 E8CBEG BA G;8 6HE E8AG?L <78AG<9<87 8<:;G @4=BE F;BEG6B@<A:F4A4?B:BHFGB7847?LF<AFG;8F8I8A6B@

@BABA8FC?HF 8FC4<E B9 )# ?4A:H4:878F<:A8EF 4A7GBB?5H<?78EF <A6?H7<A:HF

(9)

$ ).$!$*).,$/.$*)-

+;8?<FGB9 8<:;G F<AFB9:B4?@B78?<A: ?4A:H4:8F<AG;<FF86G<BAFG4EGF J<G;<FFH8FE8

?4G87 GB G;8 FLAG4K B9 :B4? @B78?<A: ?4A:H4:8F *86G<BA G;8A 6BAG<AH8F J<G;

F8@4AG<6 <FFH8F *86G<BA 4A7 6BA6?H78F J<G; <FFH8F E8:4E7<A: @B7H?4E<GL *86 G<BAF 4A7 4A4?LF<F *86G<BAF 4A7 4A78KG8AF<5<?<GL*86G<BA .;8A8I8E 4CC?<645?8 78C8A78A6<8F58GJ88A<FFH8F4E8FG4G87

,$ &*!/++*,.!*, /'.$+' *), . 3).2 -

B4?@B78?<A:?4A:H4:8F4E8 HFH4??L I8ELCEBH7B9G;8<EI<FH4?E8CE8F8AG4G<BAF B4?

@B78?F;BJ8I8E G8A7GB586B@C?8KJ<G;@4ALE8?4G<BAF;<CF4@BA: @4AL<AG8AG<BA 4? 8?8@8AGF 4A7 46GBEF A 477<G<BA <G <F 7<99<6H?G 9BE BA8 F<A:?8 6BA6E8G8 FLAG4K GB FHCCBEGG;8@4ALGLC8FB9:B4??4A:H4:8HF8EF<AG;8<EI4E<BHF@B78?<A:4A74A4?LF<F G4F>F BE 8K4@C?8 J;<?8 )#SF :E4C;<64? FLAG4K ;8?CF J<G; G;8 HA78EFG4A7<A: 4A7 4A4?LF<FB9:B4?@B78?F 4F4ABHGCHGE8CE8F8AG4G<BA <G<FB9G8A <A899<6<8AG4F4A<ACHG E8CE8F8AG4G<BA 4F <G G8A7F GB F?BJ 7BJA G;8 6E84G<BA 4A7 @4<AG8A4A68 B9 6B@C?8K

@B78?F 8<A:?4E:8?L 54F87 BA <)#SF ABG4G<BA 4?FB ?<>8?L FH998EF9EB@ @4AL B9 G;8789<6<8A6<8F<78AG<9<879BE<<AG8E@FB96B:A<G<I889986G<I8A8FF23 +;86HEE8AG FLAG4K 6BH?7 58 E8I<F87 GB 9<K G;8F8 789<6<8A6<8F 4A7 A8J :E4C;<64? FLAG4K8F 6BH?7 8I8A5847787 9BEFC86<9<6GLC8FB9HF8EF $BE8BI8E 4 @BE8CE46G<64? G8KGH4?6BA6E8G8 FLAG4K ?<>8 4 CEB:E4@@<A: ?4A:H4:8 J<G; 4 FH<G45?8 AG8:E4G87 8I8?BC@8AG AI<

EBA@8AG6BH?758@4784I4<?45?8G;<FG<@8@4<A?L4F4A4?G8EA4G<I8<ACHGE8CE8 F8AG4G<BA CEBCBF4? J4F @478 5L #<H 4A7 0H <A G;8<E BE<:<A4? )# CEBCBF4? 23 5HG J4F A8I8E 9B??BJ87HC 4A7 <G A8I8E @478 <G GB G;8 FG4A74E7 *<@<?4E?L 9BE HF8EF HA94@<?<4E J<G; :B4? @B78?<A: 4 G45H?4E54F87 E8CE8F8AG4G<BA N ?4 BHF8 B9 (H4?<

GL 23 @4L58HF87 <: F;BJF4A8K4@C?8B9J;4G <: 6BH?7?BB>?<>8<A4G45H

?4E 9BE@ 8 : <AG8AG<BA4? 8?8@8AGF 4E8 F;BJA J<G; G;8<E GLC8F ?<A>F 9EB@ EBJF GB 6B?H@AF4A75<A7<A:FGB46GBEFF;BJA 4F <@CBEG4A68?8I8?F58GJ88A4A7

$"##"$ """$!% #!#! #!"$!% !!$!""$!% "#!"#' #!%""""# &!##"""""# !%!$!!!#"# $!$!#'# "$!% "$!!%' $'# ###!#! # $#

$"##"$

"""$!%

#!#!

#!"$!%

!!$ !""$!%

"#! "#'

#!%""""#

&!##"""""#

!%!$!! !#"#

$!$!#'#

"$!%

"$! !%'

$" K4@C?8 B9'BG8AG<4?+45H?4E )8CE8F8AG4G<BA B94B4?$B78?

(10)

!**

*,)-!$$&

& , /*+%

+') '&+)'$

++

+') '&+)'$

!!$ ((,$!

!&')%,)+$/

&+!%$/

,*'!+$

+*'& ,

+')

*,)-!$$&

)'-!) ,$) )(')+*+'++

+')'&+)'$

!!$

)')%& , ()%!*

*,)-!$$&

*+') (*+!!

!/

!$

&+

'%

,(&+

&*,) ()!-/

' ''

*,)-!$$&"'

'%'.&) +&&+*$

****%&+

!$

&+)!-&

****%&+

!**

*,)-!$$&

!**

*,)-!$$&

& , /*+%

+') '&+)'$

+') '&+)'$

++

+') '&+)'$

!!$ ((,$!

!&')%,)+$/

&+!%$/

((,$!

!&')%,)+$/

&+!%$/

,*'!+$

+*'& , ,*'!+$

+*'& ,

+')

*,)-!$$&

+')

*,)-!$$&

)'-!) ,$) )(')+*+'++

+')'&+)'$

!!$

)'-!) ,$) )(')+*+'++

+')'&+)'$

!!$

)')%& , ()%!*

*,)-!$$&

)')%& , ()%!*

*,)-!$$&

*+') (*+!!

!/

*+') (*+!!

!/

!$

&+

'%

,(&+

&*,) ()!-/

&*,) ()!-/

' ''

*,)-!$$&"' ' ''

*,)-!$$&"'

'%'.&) +&&+*$

****%&+

'%'.&) +&&+*$

****%&+

!$

&+)!-&

****%&+

!$

&+)!-&

****%&+

$" K4@C?89BE$B7H?4E<GL FFH8F

+;8I4E<BHF/$#9BE@4GFCEBCBF87BI8EG;8L84EF23 4E8:BB74F<AG8E6;4A:89BE

@4GF 5HG ABG 9BE ;H@4A <ACHG +;<F 6BA6E8G8 FLAG4K <FFH8 <F BEG;B:BA4? GB 4?? BG;8E

<FFH8F78F6E<587<A*86G<BA

)03 &*!*, *,(' ().$-

B4? ?4A:H4:8F 4E8 B9G8A 8AI<BHF B9 G;8 @4GHE<GL B9 BG;8E @B78?<A: ?4A:H4:8F <A G8E@FB9FG4A74E7<M87F8@4AG<6F )#CBFF8FF8F49BE@4?45FGE46GFLAG4K<AG;89BE@

B94 FG4A74E7 @8G4@B78? BJ8I8E G;8 @84A<A: B94 )# @B78?<F?4E:8?L 789<A87 5LG;88I4?H4G<BA@86;4A<F@6;BF8A9BE G;4G @B78? 8 : I4E<BHF64G8:BE<8FB9@86;

4A<F@F4E8CE8F8AG87<A23J<G;BG;8E4A4?LF<FG86;A<DH8F<A 23 +;89BE@4?HA78E C<AA<A:9BE8I4?H4G<BA4A4?LF<F @86;4A<F@F<FE4G;8E47 ;B6 BAF8DH8AG?L<G<F7<99<

6H?GGBHA78EFG4A7J;LBA8@86;4A<F@F;BH?7586;BF8ABI8E4ABG;8E &A8BCG<BAGB

<@CEBI89BE@4?<GL <FG;8 789<A<G<BA 4A7I4?<74G<BA B94 E898E8A68 9BE@4? F8@4AG<6F9BE )# EBBG87 <A @4G;8@4G<6F <AFG847 B9 GLC<64? BC8E4G<BA4? F8@4AG<6F <A G;8 9BE@ B9 4?:BE<G;@F 9BE <AFG4A68 5L 9B??BJ<A: G;8 :H<78?<A8F CEBCBF87 <A 23 +;<F 6BH?7 58 9B??BJ87 5L G;8 78I8?BC@8AG B9 6B@C?<4AG <AG8ECE8G4G<BAF <A G;8 9BE@ B9 6BAFGE4<AG F4G<F946G<BACEB5?8@F 9BE J;<6; CBJ8E9H?4A4?LF<FG86;A<DH8F4A7GBB?F 4?E847L 8K<FG

/-. &*!/++*,.!*,). ,! !$)$.$*)-

.;<?8 <G <F FB@8J;4G CBFF<5?8 GB 6BAF<78E 4A 46GBE 4F 4A 8A64CFH?4G87 HA<G G;<F <F DH<G87<99<6H?G9BE4G4F>BE4AL BG;8E<AG8AG<BA4?8?8@8AGG;4G<F 58<A: 786B@CBF87

<AGB?BJ8E?8I8?8?8@8AGF I8AJ<G;46GBEF46?84E<AG8E9468789<A<G<BA<F45F8AG?847

<A: GB ?HFG9H? F<GH4G<BAF 58GJ88A @B78?<A: 8?8@8AGF 8C8A78A6<8F ;8?C GB 4 68EG4<A 8KG8AG GB F8C4E4G8 :B4? GE88F B9 I4E<BHF 46GBEF 5HG E8?4G<BAF;<CF 4@BA: 8?8@8AGF B9 7<998E8AG 46GBEF @4L B66HE 4G 4AL ?8I8? B9 45FGE46G<BA F88 ;BJ G;8 E8?4G<BAF;<CF 58 GJ88AG;89BHE46GBEF<A <: @4A<98FGG;8@F8?I8F4G7<998E8AG786B@CBF<G<BA ?8I8?F

'*.# & *!/++*,.!*, '.$*)-#$+ -.,.$*)-

A)#G;8E8<FAB FHCCBEG5BG;9EB@4 ?4A:H4:878F<:A CB<AG B9 I<8J4A79EB@4 GBB?FHCCBEG CB<AG B9 I<8J9BE 78F6E<5<A: G;8E8?4G<BAF;<CFB94A<AG8AG<BA4?8?8@8AG

(11)

54F87 BAG;8E8?4G<BAF;<CF B9 <GF6BAFG<GH8AG8?8@8AGF F4A8K4@C?86BAF<78EJ;4G G;8E8?4G<BAF;<CFB9G;8;<:;?<:;G87 G4F> <A <: F;BH?758 &A?LBA8 6BAGE<5HG<BA<F F;BJA 9BE G;<F G4F> 5HG F8I8E4? BG;8EF 8K<FG J;8A <GF ?BJ8E?8I8? 8?8@8AGF 4E8 G4>8A

<AGB466BHAG &96BHEF8 ABG8I8ELG;<A:A887FGB58F;BJA<A 4C4EG<4?I<8JFH6;4F 4 :B4?:E4C;5HGG;8E8F;BH?758FB@8J4LGBI<8JE8?4G<BAF;<CFB94AL:<I8A 46GBE BE <AG8AG<BA4? 8?8@8AG +BB? 5H<?78EF 4E8 F?BG;9H? <A G;8<E FHCCBEG 9BE 7LA4@<64??L 78E<I<A: 9EB@G;86B@C?8G8:B4?@B78? 4I<8J9BE4C4EG<6H?4E8?8@8AG G;4G G4>8F G;8 E8?4G<BAF;<CFB9<GF6;<?7E8A<AGB466BHAG HEG;8E@BE8<GF;BH?758CBFF<5?8GB8KC?BE8 4 :B4? @B78? J<G; <AG8E46G<I8 DH8E<8F FH6; 4F TF;BJ @8 4?? <AG8AG<BA4? 8?8@8AGF 9BE G;<F46GBEU4A7T8KC4A7G;<F<AG8AG<BA4?8?8@8AGSF E8?4G<BAF;<CF 5L GJB ?8I8?FU E4G;8E G;4A=HFG;4I<A:FG4G<6I<8JF DH8E<8F4E8 46B@@BA984GHE8B9,$#@B78?<A:GBB?F

.;<?8 7LA4@<6 I<8JF 4E8 @BFG?L 4 GBB? FHCCBEG CEB5?8@ 9BE 4A 4?E847L 9<A4?<M87 :B4?@B78? 4A 4E:H45?L 8I8AJBEF8 F<GH4G<BA B66HEFJ;8AG;8:B4?@B78?<F5H<?G<A G;8 9<EFG C?468 #8G HF 4FFH@8 G;4G 4 6BAGE<5HG<BA ;4F 588A 789<A87 9BE 4 ;<:;?8I8?

<AG8AG<BA4?8?8@8AGGB <A7<64G8G;<F <@CBEG4AG E8?4G<BAF;<C 4GG;<F ?8I8?B945FGE46G<BA .;8A786B@CBF<A: G;8 8?8@8AG<AGB ?BJ8E?8I8?8?8@8AGFBA8@4L J4AGGB4?FBE8 9<A8G;8 6BAGE<5HG<BA F;BJA 9BE G;88?8@8AG +;<F ;BJ8I8E<FGLC<64??L ABG CBFF<5?8 J<G;BHG ;4I<A: GB E8@BI8 G;8 ;<:;8E?8I8? 6BAGE<5HG<BA 4A7 6BAF8DH8AG?L ?BF<A: G;8

;<:;?8I8? BI8EI<8J %BG8 G;4G G;<F <FFH8 78C8A7F F<:A<9<64AG?L BA G;8 AIL .E4G;

4A7 #HFG F<AF 9BE@4? F8@4AG<6F J<G; CEBC8E FHCCBEG 9BE 45FGE46G<BAF JBH?7 4??BJ

<AG8E9468FGB58789<A87@BE884F<?L4GI4E<BHF?8I8?FB945FGE46G<BA 4A7I<68I8EF4

'/..*)3 &*!/++*,.!*, +,.$*)*!*) ,)-

)# FH998EF 9EB@ :?HGGBAL <A G;4G 4?? 6BA68EAF B9G8A A887 GB 58 6BAFH@87 4G BA68 .<G;4FC86GBE<8AG87 @B78?<A: 586B@<A: @BE84A7@BE8C4EGB9 @4<AFGE84@ @B78?

<A: G86;A<DH8F :B4? @B78?F F;BH?7 FHCCBEG G;8 <78AG<9<64G<BA 4A7 8A64CFH?4G<BA B9 6BA68EAFE8:4E7?8FFB9J;8G;8EG;8L4E86EBFF6HGG<A:BEABG +;<F@4L<AIB?I8F<@C?8 FHCCBEG9BEG4::<A:4A8?8@8AG4F58<A:C4EGB946BA68EAGB9H??9?87:87FHCCBEG9BE 4FC86GBE<8AG87 @4G6;<A: 4A7 6B@CBF<G<BA 23 $B78? GE4AF9BE@4G<BAF 23 4A7 FH:

:8FG<BAF @478 9BE < 23 @4L 4?FB ;8?C 477E8FF G;<F @B7H?4E<GL <FFH8 ?HGGBAL <F

?4E:8?L4ABEG;B:BA4?<FFH8GB4??BG;8E<FFH8F<A*86G<BA

,.# )'3-$- )*('$ -

+;8E8<F4 9EHFGE4G<A:4A78I8A <A9HE<4G<A: <AG8E46G<BA58GJ88AG;878F<E8GBI<8JE8?4 G<BAF;<CF 4G 7<998E8AG ?8I8?F B9 45FGE46G<BA 4A7 G;8 78C?BL87 8I4?H4G<BA @86;4A<F@F GG;8;84EGB9G;<F<FFH8<FG;4G 4E8?4G<BAF;<CF;BJA4G@BE8G;4ABA8?8I8?B945FGE46 G<BA@HFG58G4>8A<AGB466BHAG BA?LBA687HE<A:4A4?LF<F .;<?8G;8 ?89G4A7 @<77?8 )# :E4C;F <A <: 4E88DH<I4?8AGG;8 E<:;G :B4? :E4C; ?847FGB47<998E8AG8I4?H4 G<BAE8FH?G 5864HF8E8?4G<BAF;<CFJ<G;G;8FB9G:B4?4E8F;BJA @4ALG<@8F 4G7<998E8AG

?8I8?F B945FGE46G<BA HEG;8E@BE8G;8 6BAGE<5HG<BA I4?H89BEG;8;<:;8E?8I8?G4F> <A G;8 @<77?8 :B4? :E4C; A887F GB 58 F8G GB GB E89?86G G;4G G;8 6BAGE<5HG<BAF B9 5BG;

FH5G4F>F <AG;8 ?89G :B4?:E4C; 4E86B??4CF87<AGBBA8;<:;8E?8I8?6BAGE<5HG<BA

(12)

*#

'+ '$

*#

*#

*#

'+ '$

*#

*#

*#

'+ '$

*#

*#

*#

'+ '$

*#

*#

*#

*#

'+ '$

'+ '$

*#

*#

*#

*#

*#

'+ '$

*#

*#

*#

*#

'+ '$

'+ '$

*#

*#

*#

*#

*#

'+ '$

*#

*#

*#

*#

'+ '$

'+ '$

*#

*#

*#

*#

$" K4@C?89BEA4?LF<F AB@4?L

.;<?8)#4??BJF946GBEFGB58789<A879BE<AG8AG<BA4?8?8@8AGFGB7<998E8AG<4G8G;8<E

<@CBEG4A68 GB 4 FG4>8;B?78E G;8 <@CBEG4A68 B9 FG4>8;B?78EF G;8@F8?I8F <F GLC<64??L ABG 64CGHE87 8I8A G;BH:; 4?? FG4>8;B?78EF 7B ABG ;4I8 G;8 F4@8 <A9?H8A68 BI8E G;8 FLFG8@ HA78E 6BAFGEH6G<BA *<@<?4E?L FB@8 <AG8AG<BA4? 8?8@8AG @4L 58 ABA A8:BG<45?89EB@G;8CB<AGB9I<8JB9BA8 FG4>8;B?78E 5HGABG9EB@G;8CB<AGB9I<8JB9 4ABG;8E FG4>8;B?78E5HGG;<F<F4?FBABG64CGHE87

-+$, )$)"' --/( ,-,*' (

$B78?8EFDH<6>?L?BF8;BC8<A8KC?B<G<A::B4?@B78?F <A4HF89H?J4L J;8AG;8 @B7 8?F 7B ABG CEBC8E?L E89?86G E84?<GL &A8 B9 G;8 @4<A 7<99<6H?G<8F J;8A 6E84G<A: :B4?

@B78?F <F GB FC86<9L 4CCEBCE<4G86BAGE<5HG<BA?8I8?F BA6BAGE<5HG<BA?<A>F )# F;BH?7 8A45?8@B78?8EFGB CEBI<78 6BAGE<5HG<BA E4A:8FGB8A45?8 F8AF<G<I<GL 4A4?LF<F BE4?

G8EA4G<I8?8I8?F4FC4EGB9G;8:B4?@B78? E8?4G87<FFH8<FG;4G<G<FB9G8AABGCBFF<5?8 GB9<A746BEE8FCBA78A6858GJ88AG;8E8FH?GB9 4A 8I4?H4G<BA 4A7E84??<984F<G<F7<99<

6H?G GB GE4AF?4G8 E84? ?<98 <AGB G;8F8 F88@<A:?L 4E5<GE4EL DH4AG<G4G<I8 AH@58EF 4A7 DH4?<G4G<I8 FL@5B?F 4A7 I<68 I8EF4 E84G8E E8?<4A68 BA >8L C8E9BE@4A68 <A7<64GBEF

"' F78E<I879EB@@84FHE8@8AGFB9G;8E84? JBE?7 @4L 477E8FFG;8?4GG8E<FFH8 4F FH::8FG87<A23 +;8F8 <FFH8F4E86BAA86G87GB .E4G; 4FG;845<?<GLGB789<A8F8AF<

5?86BAGE<5HG<BA?8I8?F<F4CE8E8DH<F<G89BE4HF89H? 4A7FBHA7 8I4?H4G<BAB9@B78?F

, &*! 2. )-$$'$.3

&9G8A :B4? @B78?<A:?4A:H4:8F7BABG 4??BJ?4A:H4:88?8@8AGFGB588KG8A787 <A4 FLFG8@4G<6J4L +;<F?847FGB 7<998E8AG HF8E6B@@HA<G<8FG;4G 4CC?L 4C4EG<6H?4E :B4?

@B78?<A: ?4A:H4:8 <A I8EL :E887L J4LF 4A7 HA9BEGHA4G8?L J<G; <A6B@C4G<5?8 7<4

?86GF A4CCEB46;GB477E8FFG;<F<FFH8<FGBCEBI<78G;845<?<GLGB4789<A8G4:FFG8 E8BGLC8F BE @8G474G4 9BE @B78?<A: 8?8@8AGF 5 8FG45?<F; ?<A>F 58GJ88A 4E5<GE4EL

@B78?<A: 8?8@8AGF 6 :EBHC @B78?<A: 8?8@8AGF 4A7 7 789<A8 FG4G<6 6BAFGE4<AGF BA G;8:B4?@B78? 8 : J<G; &# +;<F<FC4EG<4??LFHCCBEG87<A)#235HGG;8E8<F

@H6;EBB@9BE <@CEBI<A:G;8C46>4:<A:4A7@B7H?4E<M4G<BAB9FH6;8KG8AF<BAF +;<F

<FFH8;4F478C8A78A6LJ<G; AIL 4FG;845<?<GLGB789<A8?4A:H4:88KG8AF<BAF9BE@4?

?L <@CEBI8F G;8 F8@4AG<6 6B@C4G<5<?<GL 58GJ88A I4E<4AGF B9 G;8 @B78?<A: ?4A:H4:8 8GG8E 8KG8AF<5<?<GL 6BH?7 4?FB ;8?C G46>?8 G;8 ?46> B9 6B:A<G<I8 9<GA8FF 7<F6HFF87 <A AIL5HGG;<F@4LABG4?J4LF58G;858FGJ4LB9CEB7H6<A:4FH<G45?87<4?86G

(13)

*)'/-$*)- )/./, *,&

.8;4I8CE8F8AG874?<FGB9F;BEG6B@<A:FB9 )# J<G;4A4?B:<8FGB7847?LF<AF +;8

@BFGF8E<BHF<FFH8FE8?4G8GBI4:H8789<A<G<BAFB9:B4?@B78?F8@4AG<6F J;<6;8FF8A G<4??L49986GF@BFGF<AFG;8?46>B9CEBC8E@B7H?4E<M4G<BA4A7G;8 E8?4G87 7<99<6H?G<8F J;8A 4A4?LM<A: :B4? @B78?F 4G 7<998E8AG ?8I8?F B9 45FGE46G<BA +;8 ?46> B9 @B7H?4E

<M87 8KG8AF<5<?<GL @86;4A<F@F <F 4?FB 4 6BA68EA .8 FHFC86G G;4G BG;8E CBCH?4E :B4?

@B78?<A:?4A:H4:8F ;4I86B@@<GG87 @4ALB9G;8F8F<AF 4FJ8??GBI4E<BHF8KG8AGF A BHE 9HGHE8JBE> BA)#J8C?4AGB 9<A745FB?HG<BA5L 4 FB?<7<9L<A: G;8 9BE@4?

F8@4AG<6FJ<G;G;8 ;8?C B9 @4G;8@4G<64?4A7 6BAFGE4<AG54F87 G86;A<DH8F 5 <AI8FG<

:4G<A: @B7H?8F 9BE FG4>8;B?78EF 4A7 <AG8AG<BA4? 8?8@8AGF G;4G CEBI<78 CE86<F8 <AG8E 9468789<A<G<BAF 6 CEBI<7<A: G8KGH4?4A7G45H?4EFLAG4K8F9BE:B4?@B78?FGB<@CEBI8

@B78? 6E84G<BA 89986G<I8A8FF 7 CEBI<7<A: FHCCBEG 9BE 78F6E<5<A: E8?4G<BAF;<CF B9 FG4>8;B?78EF 4A7 <AG8AG<BA4? 8?8@8AGF 54F87 BA G;8<E ?BJ8E?8I8? 8?8@8AGF 4A7 8 CEBI<7<A: 7LA4@<6@B78?8KC?BE4G<BA946<?<G<8F8 : DH8E<8F<A =,$%4I23

! , ) -

?8A64E #H68A4$ *<?I4 *4AGBF 4FGEB! @CEBI<A:G;8$B7H?4E<GLB9<

$B78?F G; AG8EA4G<BA4?<.BE>F;BC,) IB?

@LBG BE>B99 ! EBFF $HFF546;8E #<:;GJ8<:;G )# 'EB9<?8 9BE <

$B78?<A: ) <$ ).BE>F;BCF *CE<A:8E #%* IB?

@LBG ;4A4I4G< * BE>B99 ! $HFF546;8E '8LGBA # 0H I4?H4G<A:

B4?$B78?FJ<G;<AG;8B4?BE<8AG87)8DH<E8@8AG#4A:H4:8 AG8EA4G<BA4?!BHEA4?B9 A G8??<:8AG*LFG8@F ! * IB? H:HFG

4E8F E4A6; / '8E<A< *HF< +BJ4E7F <AG8EBC8E45<?<GL B9 < @B78?F HF<A:

<*G4E$# B@CHG *G4A7 AG8E9468F!4AH4EL

E4A6;/ A6BECBE4G<A:$B7H?8F<AGBG;8<E4@8JBE> 7I4A687 A9BE@4G<BA*LFG8@F A:<A88E<A:A7 AG BA9 <* *CE<A:8E#%* IB?

4E8? )H@C8 $84A<A:9H? @B78?<A: J;4GF G;8 F8@4AG<6F B9 F8@4AG<6F B@CHG8E

4HF8E! ) ?4HF<A: +;8;BHF8B9DH4?<GL 4EI4E7HF<A8FF)8I<8J$4L!HA8

BE>B99 ! 0H A4?LM<A: :B4? @B78?F 7<998E8AG 4CCEB46;8F 4A7 ;BJ GB 6;BBF8 4@BA:G;8@ $*L@C BACC?<87B@CHG<A:* $ +,+,F8E)8DH<E8@8AGF%BG4G<BA,)% R #4A:H4:8789<A<G<BA +,+)86B@@8A74

G<BA1 8A8I4*J<GM8E?4A7 ;GGCJJJ <GH <AGE86+)1 8A =,$%4I ;GGCFB9GJ4E88A:<A88E<A: 64=H6@A4I

#<H# 4A70H )# B4?BE<8AG87)8DH<E8@8AG#4A:H4:8

;GGCJJJ 6F GBEBAGB 87H>@)#

$BB7L 8L@4AF' $4GH?8I<P<HF) -<FH4?FLAG4K 7B8F @4GG8E<@CEBI<A:G;86B:

A<G<I889986G<I8A8FFB9G;8<I<FH4?ABG4G<BA )8DH<E8@8AGF A: ! $HFF546;8E FC86GBE<8AG87,F8E)8DH<E8@8AGF%BG4G<BA '; G;8F<F* +,A<I8E

F<GLB9&GG4J44A474 %BI8@58E

'BHEF;4;<7 ;8A' @LBG BEFG8E ! ;4A4I4G<* '8LGBA# .8<FF$

HF<A8FF 'EB68FF $4A4:8@8AG J<G; G;8 ,F8E )8DH<E8@8AGF %BG4G<BA ?86GEBA<6 B@

@8E68)8F84E6; 868@58E

(14)

iStarML: Principles and Implications

Carlos Cares1,2, Xavier Franch2

1 Universidad de La Frontera, Av. Francisco Salazar 01145, 4811230, Temuco, Chile,

2 Universitat Politècnica de Catalunya, c/ Jordi Girona 1-3, 08034, Barcelona, Spain, {ccares,franch}@essi.upc.edu

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

Abstract. iStarML is an XML-based format for enabling i* interoperability. A relevant difference with any other interoperability proposal is that iStarML is founded under the assumption that there is not a common ontology guiding this communication proposal. The different i* variants and even particular applications proposing new language constructors forced to confront a theoretical approach for supporting an interoperability approach in an evolving and variable semantic scenario. In this paper we focused on the theories behind the iStarML proposal, which include sociological, cybernetics and linguistics approaches. Finally, we apply what these theories predict to the case of the i*

framework and its research community.

Keywords: i* Framework, iStar, variants, interoperability.

1 Introduction

The i* (iStar) framework has become a recognized and widespread framework in the Information Systems Engineering community. Given that the i* framework incorporates goal- and agent-oriented modelling and reasoning tools, it has been a milestone for providing the basis, developing and spreading goal-orientation as a relevant paradigm in Requirements Engineering and agent orientation in Software Engineering. As a result of different interpretations and adoptions, several i* variants have emerged, which have evolved at different maturity levels. Some of them have reached the category of industrial standard (e.g., GRL in ITU-T) whilst others are in some initial stages of development or were conceived for supporting a localized (in scope and time) problem. Besides, there is a set of proposals that cannot be considered i* variants because they simply include new or modified language constructions. In [1] we have summarized a literature review reporting this fact.

As an effect of the past and even current proliferation of different i* variants, a derived set of software tools and prototypes have been generated. However, interoperability has been an elusive target. Although there is a clear core common to virtually all i* variants, tool interoperability is founded on an agreement that implies the existence of a shared ontology, which it has not been the case of i* variants.

This work has been partially supported by the Spanish project TIN2010-19130-C02-01.

(15)

We have tackled the problem of proposing an interoperability framework for i*

variants. The aim is model interchange to “work together”, which is the deep meaning of interoperability. We have called iStarML to the proposal of a XML-based format language [2]. It incorporates structures which allows the representation of a wide set of i* variants. As part of the theoretical approach that supports iStarML we have presented the proposal from [3] as a key theory because it introduces the concept of supermetamodel, which has been a key concept for demonstrating the reduction of complexity of the translation among n i* variants. Besides, this framework introduce degrees of semantic preservation which we have used to qualify the translation from an i* variant to another [1]. The iStarML applications and usages that we have promoted [4] illustrate the feasibility not only of interaction between different i*

variants but also the feasibility of using iStarML as a valid textual representation over which other applications can be built.

2 Objectives of the Research

However, we have not explained the theoretical principles which have supported the idea of enabling interoperability without having a shared and common ontology, i.e. why and how interoperability can be sustained in a human poly-semantic scenario.

The goal of tackling this social perspective was to consider the Requirements Engineering’s (and also Scientifics’) principle of proposing a better approach if there a model (or theory) for understanding why.

In this paper we briefly present different theories that support the idea of having communication without a shared ontology, some of them from linguistics, others from cybernetics, and also from sociology of science. The social nature of these theories gives us some information of what could be expected as research community and the feasible social and technical scenarios that we could expect.

3 Scientific Contributions

Basic foundations in Computer Science affirm that interoperability requires a stable semantic scenario to reach high levels of interoperability. However, this is not the situation in the i* community because different tools have been inspired on different i* variants. They do not only have different metamodels (syntax) but also they have a different mapping to objects of reality (semantic) of their language constructs. We present principles from Sociology of Science, Cybernetics and Linguistics which sup- port the idea of enabling interoperability in spite of the absence of a shared ontology.

3.1 Sociology of Science Approaches

Sociology of Science embraces those studies that explain the foundations of science (i.e., Philosophy of Science) from a sociological perspective. One of the relevant contemporary philosophers has been Thomas Kuhn, who has modelled science

(16)

evolution through discontinuous jumps [5]. Kuhn called these jumps “scientific revolutions”, which are leaded by a reduced set of pioneers who change the basic conceptualizations and build a new way of doing science. This new way of perceiving and researching is called “scientific paradigm”. Each paradigm has an initial and underlying ontology, which is “known” (in the beginning) only by the pioneers, who try to communicate it and teach the new way of doing research using this ontology.

The impossibility of explaining the new ontology based on the previous ontology is called by Kuhn “the incommensurability problem”. In spite of that, along time, the ontology is spread, and used, not always as it was proposed but according to the particular interpretations of the followers. This phase is called “the revolutionary stage”. However, at some moment, the conceptualization converges to a stable and shared ontology (the key concepts of the paradigms) and epistemology (what the community accept as valid methods for knowledge production). When it happens, the following phase, the normal-science stage, starts. The cycle continues when theoretical anomalies appear (unsatisfactory explanations) and a new pre- revolutionary stage germinates. Although the original Kuhn’s idea was to explain big scientific movements, lately he recognizes that there are a lot of small and even micro-revolutions which present the same behaviour. Figure 1 illustrates the stages.

Fig. 1. Kuhn’s model of a paradigmatic shift

Bourdieu’s theory of scientific fields [6] is the second approach from sociology of science that we reviewed. In this theory the key concept is the symbolic capital.

Scientific behaviour is associated to fields that have, in its centre, the highest concentration of symbolic capital; normally the leaders/pioneers of the fields occupy these positions. They dominate the concepts and try to spread their ideas. Scientifics try to maximize their symbolic capital by two ways: moving to the centre of the field, which means to exactly follow the pioneers’ ideas and collaborate with them, or generating new scientific fields by the intersection with other fields that allow them occupying the centre of a new scientific field. Either in the zones of lower symbolic capital or in the new fields, the concepts are not used as in the centre of the reference scientific field. In Fig. 2, left, the idea of scientific field is illustrated.

In both theories it is recognized the fact that research activity without a fully shared ontology, as it happens in the i* community, is feasible. Also, from these two theories, we cannot expect the paradigms (i.e., the i* framework) be extended over time or the i* field be kept the same way is in the centre and in the very far periphery.

A point of difference among these two approaches is the position about community agreement on a shared ontology. From Kuhn it is predicted that having a shared ontology stops the revolutionary stage and from Bourdieu it is predicted that we will

(17)

always have uncontrolled interpretations and uses. However, this apparent contraction is not real if we suppose that having static scientific fields is part of “normal science”.

3.2 Cybernetics Approaches

Cybernetics has been conceptualized as the General Theory of Control [7]. We can rescue from Cybernetics both, classical and new conceptual frameworks. A classic contributor has been Ross Ashby, who proposed a definition of intelligence from the control perspective. Thus, intelligence is understood as a repertoire of behaviours;

therefore having more intelligence or variability means having a broader repertoire of behaviours. In this theory it is said that humans are able to create intelligence amplifiers in order to enlarge their control capabilities, which means to increase variability. One of Ashby’s examples is the difference between the ships being loaded quickly and easily by movements of a control handle, or slowly and laboriously by hand [8]. Other intelligence amplifiers can be a dictionary, a sunglasses, a calculator and of course, a modelling tool, because they improve the repertoire of behaviours.

In addition, contemporary cybernetics takes concepts as autopoiesis [9] to explain that biological-based systems continuously regenerate the processes that produce them (autopoiesis). This should be understood from both, as an internal point of view (transformations) and as an external one (interactions). It is said that biological systems are operationally closed systems which are self-produced and self-referred. It means their actions are the effect of their interpretations (meaning-making process). It also implies that operational distinctions (ontology) that use a system in order to guide its interactions and transformations are not observable ones since they are internal to the system. Therefore a biologically-based communication process emerges without an explicit (non-external and non-shared) ontology. As an extension of that, and due to intelligence amplifiers (e.g. modelling tools) are part of the interactions of the system with its environment, then interoperability will take place if the meaning- making process produces some interpretation (e.g. for an arriving model) which improve variability.

3.3 Semiotics Approaches

Semiotics is about the interpretation of signs, syntax, semantics and pragmatics as well. The main focuses are models that explain human communication from both individual and collective perspectives. A relevant semiotic concept is language expressions and their meanings, which changes depending on the community. What is interesting for us are collective perspectives because they may model communication in scientific communities. Semiotics considers that some language expressions can reach stable meanings in the natural dynamic of meaning systems which implies that these expressions can be used as intepretants, i.e. using in sentences that explain other meanings. This is why an explanation might be completely understood by some people meanwhile some others will have a different conception about it or partially get what it means.

(18)

Yuri Lotman [10] introduced the concept of semiosphere to explain commu- nication inside medieval human cultures. Firstly he expresses that mono-semantic systems do not exist in isolation. These related systems are part of a continuous sphere of meaning called semiosphere. Lotman explains that the boundary is the area of accelerated semiotic process (interpretations). This theoretical approach affirms that in peripherical areas, where structures are “slippery”, less organized and more flexible, the dynamic process meets with less opposition and, consequently, develops more quickly. Then, one may say that the new semiosphere grows leaving in the centre the dominant semiotic system constituted by a wide set of stable concepts. This theory seems be very applicable for i* community as part of a more general software engineering community and also for a particular i* variant community. From this perspective the sentence from Lotman saying that the creation of meta-structural self- descriptors (grammar) appears to be a factor which dramatically increases the rigidity of the semiosphere’s structure and slows down its development, it can be easily understood, e.g. by producing some social-based standard. In Fig. 2, right, the general idea of semiosphere is illustrated.

Fig. 2. Concepts on Bourdieu’s Scientific Fields and Lotman’s Semiospheres

3.4 Implications for iStarML and the i* Research Community

After the theoretical analysis which only in part we have summarized here, some conclusions emerge. Firstly, a complete shared ontology is neither a human requisite for interaction nor for action, even when this communication is intermediated by intelligence amplifiers as software tools. Therefore, an interoperability proposal appears theoretically feasible. Moreover, we conclude that the structure of the interoperability language should correspond to the way of a Bourdieu’s scientific field or, similarly, to a Lotman’s semiosphere, i.e. core or stable concepts at the centre, and the increasing of semantic variability and additional constructs towards the periphery.

If the inteoperability language may reproduce the semiosphere structure, then intermediate structures should be in terms of core structures. Therefore, we proposed iStarML using a concentric ring structure: (1) the core set of stable and common abstract concepts (actor, intentional element, intentional link, dependency), (2) a core set of common concepts established by a predefined set of main tag attributes (e.g., type=”softgoal”), (3) a space for specifying variations on existing but not so common

(19)

attributes (e.g., value=”xor”) and (4) new elements (e.g. type=”norm” prior=”low”.

Therefore an iStarML message should be part of a meaning-making process, thus, it, could be interpreted depending of the target i* variant community.

In addition, the application of these theoretical frameworks allows to derive some conjectures about i* community: (1) If i* represents a materialization of a scientific revolution then is not expected that the i* ontology keeps being an underlying ontology. It will be explicitly expressed at some moment. (2) The externalization of an i* ontology will not stop the scientific activity; it only will change its state.

Proliferation of interpretations will be stopped but “normal” (in the sense of Kuhn) applications will be massively reported afterwards. (3) Following Lotman’s and Bordieu’s theories, externalizing an ontology may be a very difficult job if central scholars of the field are not involved. (4) Expressing an ontology will not avoid intersections to other scientific fields, therefore, proliferation of applications with and without i* modifications will take place.

4 Conclusions

The theoretical foundation for proposing iStarML, an interoperability proposal for i*

variants, has been reviewed. It included sociology of science, cybernetics and semiotics. Following these theories about human communication and scientific behaviour we have explained some reasons behind central features of iStarML.

However, the social nature of this theoretical framework allowed obtaining conjectures (i.e. theory predictions) about the future of the i* community. Mainly they point out to the expression and formalization of the i* ontology which stops the revolutionary stage, fixes the grammar and establishes a new research period about applications under a stable semantic scenario. In this hypothetical scenario iStarML should be revised according to the inclusion of a set of language constructs from this explicit formalization.

References

1. Cares, C., Franch, X.: A Metamodelling Approach for i* Model Translations. CAiSE 2011.

2. Cares, C., Franch, X., Perini, A., Susi, A.: Towards Interoperability of i* Models Using iStarML. Computer Standards & Interfaces, 33(1) (2011).

3. Wachsmuth, G.: Metamodel Adaptation and Model Co-adaptation. ECOOP 2007.

4. Colomer, D., López, L., Cares, C., Franch, X.: Model Interchange and Tool Interoperability in the i* Framework: A Proof of Concept. WER 2011.

5. Kuhn, T.: The Structure of Scientific Revolutions. The University of Chicago Press (1996).

6. Bourdieu, P.: The Specificity of the Scientific Field and the Social Conditions of the Progress of Reason. Social Science Information 14(6), 1975.

7. Beer, S.: Cybernetics and Management. The English Universities Press (1967).

8. Ashby, W.R.: An Introduction to Cybernetics. Chapman & Hall (1957).

9. Maturana, H.R., Varela, F.J.: De Máquinas y Seres Vivos: Autopoiesis la Organización de lo Vivo. Santiago de Chile, Editorial Universitaria (1998).

10.Lotman, J.: On the Semiosphere. Sign Systems Studies, 33(1) (2003).

(20)

Empirical Evaluation of Tropos4AS Modelling

Mirko Morandini, Anna Perini, and Alessandro Marchetto FBK-CIT, Trento, Italy,

{morandini,perini,marchetto}@fbk.eu,

Abstract. Our work addresses the challenges arising in the development of self-adaptive software, which has to work autonomously in an unpre- dictable environment, fulfilling the objectives of its stakeholders, while avoiding failure. In this context we developed the Tropos4AS framework, which extends the AOSE methodology Tropos to capture and detail at design time the specific decision criteria needed for a system to guide self- adaptation at run-time, and to preserve the concepts of agent and goal model explicitly along the whole development process until run-time.

In this paper, we present the design of an empirical study for the evalua- tion of Tropos4AS, with the aim of assessing the modeling effort, expres- siveness and comprehensibility of Tropos4AS models. This experiment design can be reused for the evaluation of other modeling languages ex- tensions.

Key words: Agent-oriented software engineering, Empirical studies, Self- adaptive systems.

1 Introduction

Today’s software is expected to be able to work autonomously in an open, dy- namic and distributed environment. Self-adaptive software systems were pro- posed as a solution to cope with the uncertainty and partial knowledge in such environments. The development of such software, which should automatically take the correct actions based on knowledge of what is happening, guided by theobjectives assigned by the stakeholders, gives rise to various challenges: the software needs multiple ways of accomplishing its purpose, enough knowledge of its construction and the capability to make effective changes at runtime, to be able to autonomously adapt its behaviour to satisfy the requirements, shifting decisions which traditionally have been made at design-time, to run-time.

In our recent work we try to address these challenges, proposing the Tro- pos4AS (Tropos for Adaptive Systems) methodology [1]. Tropos4AS aids the software engineer in capturing and detailing at design time the specific knowl- edge and decision criteria that will guide self-adaptation at run-time. Moreover, it brings the high-level requirements, in form of goal-models, to run-time, to en- able the system to monitor their satisfaction, to reflect upon them and to guide its behaviour according to them.

(21)

Like Tropos4AS, various extensions of the Tropos modelling language and methodology were proposed in the last years, specific for different purposes and various domains. However, only few attempts were made to assess such exten- sions by means of empirical studies. We present the design of two experiments with subjects, which have the scope to assess the novel extensions of Tropos4AS by comparison with the general methodology Tropos. Applying proper statistical tests, we are able to collect evidence on the effectiveness (modelling effort, model correctness and model comprehensibility) of Tropos4AS models, evaluating the results of modelling tasks, comprehension tasks and supporting questionnaires.

The design is general and thus reusable for the evaluation of other specific ex- tensions to general modeling languages.

2 Background

The Tropos4AS methodology extends Tropos to provide a process and modelling language that captures at design time the knowledge necessary for a system to deliberate on its goals in a dynamic environment, thus enabling a basic feature of self-adaptation. It integrates the goals of the system with the environment, and gives a development process for the engineering of such systems, that takes into account the modelling of the environment and an explicit modelling of failures.

Tropos goal modelling is extended along different lines:

i) Capturing the influence of artifacts in the surroundings of an actor in the system to the actor’s goals and their achievement process. This is achieved by modelling an actor’s environment and definingconditions on the environment artifacts, to guide or guard state transitions in the goal satisfaction process, e.g.

achievement conditions, goal creation conditions or failure conditions.

ii) The definition of goal types (maintain, achieve,. . . ) and additional inter- goal relationships (inhibition, sequence), to detail the goal achievement and al- ternatives selection dynamics.

iii) Modelling possible failures, errors and proper recovery activities, to elicit missing functionalities to make the system more robust, to separate the excep- tional from the nominal behaviour of the system, and to create an interface for domain-specific diagnosis techniques.

For the aim of providing an explicit representation of high-level requirements at run-time and lowering the conceptual gaps between the software development phases, we perserve the concepts of agent and goal model explicitly along the whole development process. The detailed Tropos4AS goal models represent the

“knowledge level”, that is, the rationale behind the execution of specific tasks (i.e.

plans). Adopting an implementation architecture which supports goal models, the software can navigate and reason on them and exploit available alternatives satisfy its requirements. A complete translation of requirements concepts to tra- ditional software level notions, such as classes and methods of object-oriented programming, is avoided. This contributes to a smoother transition between the development phases, reducing loss and conceptual mismatch and simplifying the

(22)

tracing of decisions made in requirements analysis and design to the implemen- tation and vice-versa.

A direct mapping from goal models to implementation concepts is defined, relying on agents with a BDI (Belief-Desire-Intention) architecture and a native support for the concepts of agent and goal. With a supporting middleware, an explicit, navigable and monitorable representation of goal models at run- time is realised. Tropos4AS (with the graphical modelling language presented in Figure 1) is detailed in [1], and [2]. Details for the operational semantics attributed to condition evaluation and to the satisfaction of goals in goal models, can be found in [3]. Note that the optimisation of a system’s behaviour, by the use of run-time goal model reasoning, learning or knowledge acquisition strategies, is not part of, but would be complementary to Tropos4AS.

Tool support. TheTaom4ETropos modelling tool (selab.fbk.eu/taom) supports modelling of extended Tropos4AS models and includes a plug-in for an auto- mated code generation (t2x tool), base on the Taom4E Tropos modelling tool which uses theJadex agent framework as implementation platform.

Fig. 1.Fragment of the Tropos4AS model for a patient monitoring system, one of the objects used in the the comprehension experiment.

3 Empirical Evaluation

The evaluation of novel extensions to a development methodology poses various challenges, since they are usually not yet extensively used in practice. Moreover, it is challenging to set up a fair and meaningful comparison for the evaluation of the introduced extensions: An empirical study which consists of a compari- son of Tropos4AS with a methodology with a similar scope but with different roots, would inevitably also assess the performance of the whole Tropos lan- guage. Therefore, an evaluation limited to the novel extensions, which is our

(23)

scope, would be impossible. Conversely, an empirical study which involves im- plementation, would require participants that are experienced in the use of the implementation language, and demand a very high time effort. Also, a com- parison of the whole modelling process would not be feasible within the given time constraints. Thus, to assess the novelties introduced with Tropos4AS, we propose to perform a controlled experiment with subjects, comparing the Tro- pos4AS modelling language to the underlying Tropos modelling language1, which showed its effectiveness in various studies, e.g. [5].

The evaluation of a modelling language can be characterised by three main aspects: (1) the effort for modelling, (2) the effectiveness for capturing the re- quirements and (3) the comprehensibility of the obtained models. The study we propose consists of modelling and comprehension tasks performed by a group of subjects, and is divided into two experiments:

Modelling: we evaluate if Tropos4AS is effective in modelling self-adaptive systems, with an acceptable modelling effort, in comparison to Tropos.

Comprehension: we evaluate if the Tropos4AS modelling extensions increase the comprehensibility of the requirements of a system.

The design of the experiments follows the guidelines by Wohlin et al. [6] and allows to have a high degree of control over the study, to achieve results with statistical significance. Tropos and Tropos4AS represent the control treatment and the treatment to evaluate. The quality focus of the experiment concerns the capability of the treatments in supporting the analysts in requirements modelling and comprehension. The target subjects are researchers and Ph.D. students, while theobjectsof study are requirements specifications (textual and graphical) of two software systems with adaptivity features. It is however important that these systems can be modelled in a satisfactory way with both the general and the domain-specific methodology. We define three research questions (together with the relative null- and alternative hypotheses):

RQ1: Is the effort of modelling requirements with Tropos4AS significantly higher than the effort of modelling them with Tropos?

RQ2: Is the effectiveness of Tropos4AS models significantly higher than the effectiveness of Tropos models, for representing requirements of an adaptive system?

RQ3: Do Tropos4AS models significantly improve the comprehension of the requirements of a self-adaptive system, in comparison to Tropos models?

To investigate on these questions (with the aim of showing if the relative null-hypothesis can be rejected or not), we run a modelling and a comprehen- sion experiment, which both adopt a paired, counterbalanced experiment design based on two laboratory sessions, such that the subject perform the experi- mental task twice, once with each object and treatment, exploiting all possible combinations. This lets us evaluate the performance of the subjects with both treatments, avoiding learning effects.

1 We refer to the Tropos modelling language, as defined in [4]. In particular, we focus on Troposgoal diagrams, which are mainly affected by the novel extensions.

(24)

Design of the modelling experiment. The modelling experiment covers the re- search questionsRQ1 andRQ2 and consists of:

1. a presentation and training session for the subjects, to introduce or refresh notions related to both treatments, and to explain the experiment tasks;

2. a pre-questionnaire to capture information about the experience of the sub- jects and about the clearness of the notations and of the experimental task;

3. two supervised laboratory sessions concerning a modelling task to be per- formed in an open time frame, asking the subjects tomodel with as much details as possible the textual requirements specifications handed out, with the assigned modelling language;

4. post-questionnaires asking about the perceived effort for each treatment and about personal opinions, comparing both treatments.

The research questions include the abstract terms effectiveness and effort, which have to be detailed in order to characterise these two terms for the scope of the study and to associate them to variables which can be evaluated. RQ1 is decomposed to aspects considering time, perceived effort, and the difficulties encountered while modelling, while the aspects forRQ2 consider the expressive- ness of the modelling language as perceived by the subjects and the correctness of the models built. These aspects are evaluated collecting the questionnaire re- sults (on an ordinal 1. . . 5Likert scale, fromstrongly agreetostrongly disagree) and measuring the time spent. Moreover, model correctness is evaluated against an expert-madegold standardmodel, evaluating the coverage of three predefined software execution scenarios.

Design of the comprehension experiment. The comprehension experiment, cov- eringRQ3 and conducted with the same subjects, consists of:

1. two laboratory sessions concerning a comprehension task to be performed in a fixed time, asking the subjects to answer to five comprehension questions on the object assigned, by looking at the Tropos or Tro- pos4AS models handed out(built by modelling experts) and the respec- tive textual requirements specifications;

2. a final questionnaire with questions on the subjective perception of subjects with respect to the experiment and the treatments.

The main dependent variable is the correctness of the subjects’ answers to the comprehension questions, measured by comparing the answers given to gold standard answers, in terms of precision and recall.

Statistical evaluation. To determine if the null-hypotheses can be rejected and thus an affirmative answer can be given to the research questions, considering the nature of the variables and the experiment design, we apply a non-parametric, pairedWilcoxon test, adopting a 5% significance level for the obtainedp-values (refer to [6] for details). Medians, averages andCohen.d effect size are applied to analyze trends and to estimate the magnitude of the obtained results. Similar tests are used to evaluate the adequateness of the experimental settings by an analysis of the pre-questionnaires.

Références

Documents relatifs

models [2]. In this research work [7], we aim to show that the use of ontologies.. can provide a practical approach towards tackling the i* variants interoperabil- ity problem. As

Semantic data annotation and event processing (SeDIEP). 1) System overview: Semantic data annotation and event processing (SeDIEP) subsystem manages various data sources and

A personal learning environment (PLE) is a recent and evolving concept yearly discussed in the framework of the PLE conference 1 and in workshops related to

O presente artigo está estruturado nas seguintes seções: na seção 2 discorre-se sobre o uso de ferramentas de PLN para extração de informação e construção

This approach could be used to further enhance our extraction systems, and there are available tools in GATE to support this: OwlExporter is a GATE plugin for populating OWL

The extracted dataset has several unique characteristics: (1) it has a wide temporal coverage from 300 BC to today, (2) it is available for a lot of

More and more data is opened and interlinked using Linked Data principles, and it is worth modeling ge- ographic data efficiently by reusing as much as possible from existing

The use of provenance information for computing trust assessments has also been investigated in a previous work of ours [5] where we determined the trustworthiness of event