Journée de travail du groupe RIMEL du GdR GPL. Nîmes, le 17 Décembre 2012

Transcription

1 Journée de travail du groupe RIMEL du GdR GPL Nîmes, le 17 Décembre 2012 crédit photo : François Richard Organisation!: Christelle Urtado, Sylvain Vauttier Salah Sadou, Chouki Tibermacine Journée organisée avec le soutien du GdR GPL, du LIRMM et de l'ecole des Mines d'alès.

2

3 Sommaire Session 1 : Architectures, DSL & Evolution Petr Spacek, Christophe Dony and Chouki Tibermacine A metamodel for a reflexive Component-oriented programming and modeling language Page 1 Thanh-Liem Phan, Anne-Lise Courbis et Thomas Lambolais Développement incrémental d architectures intégrant la substitution de composants Page 2 Minh Tu Ton That, Salah Sadou and Flavio Oquendo Supporting architectural pattern language using structural properties Page 13 Session 2 : Lignes de produits & Evolution Ra'fat Al-Msie deen, Abdelhak Djamel Seriai, Marianne Huchard, Christelle Urtado, Sylvain Vauttier and Hamzeh Eyal Salman Mining Feature From a Collection of Software Product Variants Page 17 Mireille Blay-Fornarino, Philippe Collet, Sébastien Mosser, Simon Urli et Philippe Renevier Using composite feature models to support agile SPL evolution Page 18 Hamzeh Eyal-Salman, Abdelhak-Djamel Seriai, Christophe Dony and Ra fat Al-msie deen Identifying Traceability between Feature Model and Source Code in a Collection of Product Variants Page 19 Session 3 : Services & Evolution Hervé Verjus et Frédéric Pourraz Ongoing Work and Perspectives on Evolvable Service-Based Applications Page 20 Guillaume Grondin, Matthieu Faure, Christelle Urtado and Sylvain Vauttier Mission-oriented autonomic configuration of pervasive systems Page 21 Session 4 : Analyse de code & Evolution Xavier Blanc, Jean-Rémy Falleri, Mathieu Foucault, Amine Ra ji et Cédric Teyton Harmony: The Ultimate Software Repository Mining Tool Page 25 Page i

4 Simon Allier, Nicolas Anquetil, André Hora and Stéphane Ducasse A Framework to Compare Alert Ranking Algorithms Page 28 Session 5 : Ingénierie et rétro-ingénierie dirigée par les modèles & Evolution Mahmoud El Hamlaoui, Sophie Ebersold, Adil Anwar, Bernard Coulette et Mahmoud Nassar Maintien de la cohérence de modèles hétérogènes par synchronisation des changements Page 33 Olivier Le Goaer Introduction à l'approche ADM - Modernisation du patrimoine logiciel par les modèles Page 37 Ha jer Saada, Xavier Dolques, Marianne Huchard, Clémentine Nebut and Houari Sahraoui Generation of Operational Transformation Rules from Examples of Model Transformations Page 38 Page ii

5 !"#$%&!"#$%&#'($)"*'+"&"+$*)$,-.$"/'#0'1$1%2'+-$1%$("0+'3+&##-13"&1("#'($)-13")&134&3$ ' ()#*+,-& 5$%+"60&7$8.'/*,"-#+0*%'1+23.'/*+)4"'!"5%,678"2% ' (99"$"7#"+2& EFE',)%'(G7' HIJKL'=+2#0%$$"%,'/%G%M'L'>'N,728% ' 6+G)$7,"#3'+,'%M#%2-"5"$"#3'7,%'5%8+6"2Q'-3-#%6'G%-"Q2'0,"28"0$%-P';60$%6%2#7#"+2-'6)-#'#74%'"2#+' 8+2-"G%,7#"+2'9)#),%'Q,+O#*'72G',%978#+,"2Q'+9'-+9#O7,%P'R"#*'O%$$'G%9"2%G'%M#%,27$'8+2#,78#-'72G'%M0$"8"#' +9'8+60$%M'-+9#O7,%'-3-#%6-'SDT30%,-4"U (2'7,8*"#%8#),%'+,Q72"T%-'7'-+9#O7,%'-3-#%6'7-'7'8+$$%8#"+2'+9'8+60+2%2#-.'8+22%8#"+2-'5%#O%%2'#*%' G%-"Q2-.'0,+Q,76-')2G%,-#72G"2Q.'72G'9+,67$'727$3-"-P %2*728"2Q'0,"67,3'6+G%$-'"2#+'9"27$'-+9#O7,%'0,+G)8#-P 1%-8,"5"2Q'7,8*"#%8#),%'"2'7'9+,67$'7,8*"#%8#),%'G%-8,"0#"+2'$72Q)7Q%'W(1:X'872'7"G'"2'#*%' =+,%.'O"#*'72'7,8*"#%8#),%'-%07,7#%G'9,+6'72'"60$%6%2#7#"+2.'#*%,%'"-'2+')2"9"%G'-"60$%'O73'*+O' #+'G%-"Q2'72G'%M%8)#%'6+G%$>#+>6+G%$'W=B=X'#,72-9+,67#"+2-P'!,72-9+,67#"+2-'*7-'#+'5%'G%-8,"5%G'"2' G"99%,%2#'$72Q)7Q%-P'!*"-'674%-'"#'G"99"8)$#'#+'700$3'7'#,72-9+,67#"+2'+2'7'6+G%$'"2'7'-#,7"Q*#9+,O7,G'O73P #+'2+#'+2$3'G%-"Q2'72G'"60$%6%2#'7'6+G%$.'5)#'7$-+'#+'-)00+,#'#,72-9+,67#"+2-'9,+6'7'0,"67,3'-+9#O7,%' 6+G%$'#+'7'9"27$'-+$)#"+2P )-%,-'#+',%7-+2'75+)#'7,8*"#%8#),%-.'#+'0%,9+,6'6+G%$'#,72-9+,67#"+2-.'#+'%M76"2%'72G'6+G"93'#*%' ' ] +9'+2%'$72Q)7Q%P ] Z,+0+-%G'6%#7>6+G%$.'57-%G'+2'_(9(%:&;'-<)'=)")5$/8$-(-&_'"G%7.'"-'72'"22+@7#"@%'700,+78*' O*"8*'*7-'2+#'5%%2'%M0$+,%G'3%#'"2'#*%'8+2#%M#'+9'8+60+2%2#>57-%G'$72Q)7Q%-P ' ' ' ' ' Page 1

6 Développement incrémental d architectures intégrant la substitution de composants Thanh-Liem Phan, Anne-Lise Courbis, Thomas Lambolais Centre LGI2P, Ecole des mines d Alès Site EERIE, Parc Scientifique Georges Besse, Nimes Cedex 1 France Résumé. Nous nous intéressons à la substituabilité de composants qui est une propriété essentielle utilisée en particulier pour le développement incrémental d architectures. Le problème de la substituabilité consiste à vérifier la possibilité de remplacer un composant par un autre en termes de comportements. Les systèmes à analyser sont modélisés en UML par des assemblages de composants dont les comportements sont définis par des machines d états. Nous examinons la substitution d un composant en étudiant sous quelles conditions il est possible de substituer un composant par un autre tout en garantissant le raffinement d une architecture. Keywords : substituabilité, UML, LTS, machine d états, structure composite. 1 Introduction Nous nous intéressons aux démarches développement par raffinements, qui sont vues comme le passage d une spécification à l implémentation tout en préservant la correction de propriétés validées par les spécifications intermédiaires. Dans un travail précédent [10], Luong et al ont traité le raffinement d un composant, qui consiste à réduire l indéterminisme et la partialité, et préserve des propriétés comportementales. De la même manière, le raffinement d une architecture consiste à ajouter de nouveaux composants ou à substituer un composant existant et assurer que l architecture obtenue est conforme à l architecture de référence. Dans ce travail, nous nous focalisons sur la substitution de composants. Nous nous intéressons à la substituabilité «sémantique», qui consiste à vérifier la possibilité de remplacer un composant par un autre en termes de comportements. Afin d assurer que la substitution d un composant ne cause pas de risques pour l architecture de systèmes, l analyse d informations statiques (les interfaces avec les contrats) du composant n est pas suffisante. Ceci ne prévient pas tous les risques de blocage et de refus. Nous devons considérer non seulement les interfaces du composant mais aussi son comportement. Les systèmes étudiés sont représentés par des structures composites UML qui définissent l assemblage de composants dont les comportements sont modélisés par des machines d états UML. Bien qu UML ait une syntaxe bien définie, sa sémantique n est pas formelle. Nous décidons d utiliser le langage LOTOS [7] comme une description formelle pour analyser les modèles. Grâce à la sémantique de LOTOS donnée Page 2

7 sur des LTS (Labelled Transition Systems), il est possible de générer un seul LTS pour une architecture UML. Le langage LOTOS repose sur une algèbre de processus munie d opérateurs de composition parallèle et de masquage, ce qui permet de décrire des architectures,... Parmi ces opérateurs, les deux contextes les plus importants pour la construction d'architectures sont l opérateur de masquage et l opérateur de composition parallèle [9]. L opérateur de masquage nous permet de réduire la complexité en ne regardant que les actions nécessaires (par exemple, les actions de l'interface publique). L opérateur de masquage est une source de live-locks (ou divergences) [15] (par exemple, un boucle infinie d actions internes), et il existe deux classes de pensée : i) tous les live-locks sont dangereux ; et ii) certains live-locks sont inoffensifs. Deux représentants de la première classe sont la sémantique de CSP [5, 17] et les pré-ordres de la théorie de test de De Nicola et Hennessy (! "#$%,&! "'(,&! %)$% ) [14]. Dans ces approches, tout comportement après un live-lock est ignoré. La deuxième approche incorpore l hypothèse d équité, dans laquelle les live-locks ne sont pas toujours considérés comme catastrophiques. Elle distingue les live-locks critiques dont on ne peut pas sortir et non-critiques dont on peut sortir. La congruence observationnelle (!) de Milner [12] et les relations de conformité (conf, red, ext, te) [9] appartiennent à cette classe. Regardons l exemple de la Fig. 1. L étiquette i représente l action interne, incontrôlable. P et Q ne sont pas comparables sous l équivalence de must qui identifie un live-lock dans l état 1. Cependant, sous l hypothèse d équité P et Q sont en congruence observationnelle (le live-lock dans l état 1 n est pas critique). Q * "#$% P mais Q! P Fig. 1. P et Q sont similaires sous l hypothèse d équité. Dans notre contexte, nous choisissons l interprétation des live-locks comme dans la congruence observationnelle, qui fait une hypothèse d équité forte disant que «quand une action est infiniment souvent offerte, elle sera finalement choisie». Les problèmes à résoudre pour pouvoir conduire des développements incrémentaux d architectures de composants UML sont alors les suivants : donner une sémantique opérationnelle aux machines d états UML, aux composants et aux architectures UML (section 2.2) ; assurer la substitution lorsqu on remplace un composant par un composant qui le raffine (section 2.3). Page 3

8 2 Méthode Avant résoudre les problèmes ci-dessus, nous rappelons les notations nécessaires des relations de comparaison. 2.1 Préliminaire Généralement, une bonne stratégie pour faire des vérifications est l utilisation de pré-ordres et équivalences. Les trois relations les plus fortes sont la bi-simulation branchée, la bi-simulation de retard, et la congruence observationnelle [4]. En pratique, la puissance des bi-simulations est indésirable dans quelques cas [16] (par exemple, cf. Fig. 2 : le changement de non-déterminisme). Avant de présenter les relations de comparaison, nous donnons la définition de LTS et les notations de traces et refus. Définition 1. Systèmes de transitions étiquetées (LTS) Soit!"# $ % & '() l ensemble de toutes les actions, où % est l ensemble des actions observables, et ( est l action interne. Soit * un ensemble de noms d états. Un LTS +,-!-.- /0 est un quadruplet formé : o d un ensemble non vide, 1 * d états ; o d un ensemble! 1!"# de nom d actions,! $ 2 & '(), où 2 1 % est l ensemble des actions visibles du LTS ; o d une relation de transition.1, 3! 3,4; o d un état initial / 5, Nous définissons : / :;;;< / = / A B / $ / :< / A / :;;;< >?/ = B/ :;;;< / = / D/ C = > / $ / = 4EF4/ G8G :< / = / 6 D/ = -/ H B/ C 6./H C D/ = / IJJJK / = / A B 4/ IK / A / D/ L = >?/ = B/ IJJJK / = / L D>?/ = B/ L D/ = Page 4

9 Fig. 2. Congruence observationnelle (!" ne supporte pas le changement de nondéterminisme. On a : #! $ La congruence observationnelle est trop forte comme indiqué dans Fig. 2. Nous cherchons des pré-ordres/équivalences qui sont moins. Nous commençons par les relations de conformité (conf, red, ext) qui ont été formalisées par Brinksma et Leduc [3, 9] sur des LTSs. Elles traduisent l idée du test de conformité dont la méthodologie a été définie par l ISO 9646 [6]. Elles vérifient si la version courante du modèle architectural est en accord avec la version précédente. Cette comparaison se fait par une relation de conformité. Plusieurs relations de conformité sont utilisables. Définition 2. Ensemble d acceptance [9] : %&&'() *" +, + -.+/+0( 1 2 '() *" '( 1 )8"9 Où : '() *" +, + -( 1 +/+( ;( : '() *" +, + < = > 2'=):" 567'( 1 " 567'(" +, + -? B9 A Définition 3. Conformité [9] : C+DEFG+(++HI++J* 2 KL'("M++%&&'C) *" NN %&&'() O"+ Où: % NN P++HI++JQ 2 %M 0Q 1 2 PM Q 1 RQ Définition 4. Réduction [9] : C+STU+(++HI++KL'C" R KL'(" +V +C+DEFG+( Définition 5. Extension [9] : C+TWX+(++HI++KL'C" Y KL'(" +V +C+DEFG+( Définition 6. Conformité restrictive [9] : C+DEFGSTZXS+(++HI+-L/L+DEFG+C9 R -L/L+DEFG+(9+ La relation de conformité (conf) n est pas transitive, alors elle n est pas appropriée pour le raffinement. Les trois relations red, ext, et confrestr sont transitives et réflexives, mais elles ne sont pas congruentes. Nous prenons un exemple pour montrer la limit du pré-ordre red. Dans Fig. 3 (a), nous avons bien que I red S, c est-à-dire I ne contient pas de blocages imprévus. Mais si nous masquons l action a dans les deux processus, nous n avons pas la même con- Page 5

10 clusion sur les deux processus dérivatifs I not red S où I = (I hide a) et S = (S hide a).! "!#$%&'#( "#$%&'#( # "! $ # "! & $ % (a)!"#$%"s (b) &!"'()*"+,"-./"#$%"(S hide a) Fig. 3. red n est pas congruence dans le contexte de masquage. Comme montré dans [9], #$%, $0/ ne sont pas pré-congruents et bien qu on utilise leur équivalence, les relations obtenues ne sont pas congruentes dans le contexte de masquage. Définition 7. Équivalence de test [9] : 1"/$"2" 3 "1"#$%"2" 4 ""2"#$%"1" 3 "1"$0/"2" 4 ""2"$0/"1 # "! # # "! & # % ( * " " # $ $ $ # )! %! $ & $ & ' % a) 5"/$"6 b) &5"'()*"+,"-./"/$"&6"'()*"+, Fig. 4. Équivalence de test n est pas congruente dans le contexte de masquage Dans Fig. 4, P et Q sont en équivalence de test, mais pas après le masquage de l action a. Alors, nous cherchons la plus grande relation plus forte que la conformité, qui soit une congruence pour les opérateurs de composition parallèle et de masquage et reste sur l hypothèse d équité. Ensuite, nous présentons l architecture UML et sa sémantique. 2.2 Sémantique opérationnelle des architectures UML Dans un travail précédent [9], nous avons défini la sémantique des composants par la transformation de machines d états UML en systèmes de transitions étiquetées. Dans le cas d une architecture, les compositions entre composants sont données sur l algèbre de processus LOTOS. En LOTOS, les communications correspondent à des rendez-vous synchrones. Pour des communications asynchrones, il est nécessaire de Page 6

11 définir explicitement des processus représentant des files d attente. Nous avons ainsi défini une transformation des structures composites UML en spécifications Exp.Open [8]. Grâce à la sémantique de LOTOS donnée sur des LTS, il est alors possible de générer un seul LTS pour l ensemble du comportement d une architecture UML (cf. Fig. 5). Ceci nous permet d analyser le comportement global de l architecture initiale, dans le but d y vérifier l absence de blocage. Fig. 5. Transformation d architectures UML en LTS Notons que ceci n est possible en pratique que sur des architectures de taille raisonnable. C est pourquoi nous pouvons, soit appliquer cette technique sur les premières étapes, soit comparer une version à la précédente en n analysant que les parties modifiées. 2.3 Substitution d un composant par un composant qui le raffine Supposons que l on souhaite remplacer un composant C2 dans une architecture A1 par un composant C2, de façon à obtenir une nouvelle architecture A2 (cf. Fig. 6). Si C2 est un raffinement de C1, alors A2 n est pas nécessairement un raffinement de A1. La relation de raffinement n est pas congruente ou en d autres termes elle n assure pas la substituabilité. Il en est de même pour l ensemble des relations de conformité présentées plus haut. Page 7

12 Fig. 6. La substitution de composant C2 par C2 Dans notre travail, les risques mis en évidence dans les architectures sont ceux de possibilité de refus. Un refus correspond au fait que le système ne répondra pas à certains des stimuli auxquels il devait répondre. À l extrême, si le modèle refuse tout stimulus, ceci conduit à l un des deux cas suivants : blocage ou live-lock critique. Un live-lock est critique s il est impossible d en sortir. Parce que nous sommes sous l hypothèse d équité, un live-lock non-critique n est pas dangereux. Trouver la plus grande relation plus forte que l équivalence de test (te), qui soit une congruence pour les opérateurs de composition parallèle et de masquage est resté un problème ouvert pendant de nombreuses années [2]. Le pré-ordre should a été proposé en même temps par Brinksma et al [2] et Natarajan et Cleaveland [13] pour répondre à ce problème. Cependant, [2] et [13] n ont pas identifié d algorithme. Il a fallu attendre la présence du article [16]. La décidabilité de should est basée sur la décidabilité du pré-ordre de futur impossible. Nous présentons premièrement la définition du pré-ordre de futur impossible et puis le pré-ordre de should ci-après : Définition 8. L ensemble d arbre d échecs d un LTS p (notée!" ) [16] #$%& '( )$*+,& -.$%& /0$1& $8& :, ( ;< =#$%& '( )$*+,& -.$%& /0$1 > & $8& :, ( ;< Où.$%& '( )* - 1? 2324$ &< Le futur impossible d un processus IF(p) est déterminé en ajoutant l information de comportement infini. En fait, l ensemble d actions de refus dans les échecs F est remplacé par l ensemble de mots de refus dans les arbres d échecs IF. Définition 9. Pré-ordre et Équivalence de futur impossible. AB 2528C2=#$%& D =#$5& %( AB AB AB 2%2 Page 8

13 Pour montrer l avantage d IF, nous revenons sur l exemple de la Fig. 3. On peut distinguer I de S avec IF mais pas avec red. On a bien que (a *, a * b)! IF(I) \ IF(S). C est-à-dire, I peut refuser {a * b} après la trace a * mais pas avec S. Alors IF(I)! IF(S)! " # $ %& #. Regardons le processus B dans la Fig. 7. On a l ensemble {(",{b,c,d}) ; (a,{a,c,d}) ;(ab,{a,b,d}) ;(ab,{a,b,c})} appartient à F(B), et IF(B) contient l ensemble {(",{abc,abd}) ; (a,{bc, bd}) ; (ab,{c,d})}. (a,{bc})! IF(B) mais (a,{bc}) # IF(C)! B $ %& C! B ( %& C (a,{bc})! IF(B) et on peut trouver (ab,{c})! IF(C): (a,{bc}) ) (ab,{c})! B * +, - C et C * +, - B Fig. 7. B et C sont en équivalence de should mais pas équivalence de futur impossible *. / distingue le moment du choix de processus, alors il est encore plus fort que * +, -. Il faut enlever l information du moment du choix par la fermeture vers le bas downward closure) de paires d échecs d IF. En conséquence, le pré-ordre de should est calculé à base de la fermeture vers le bas d ensemble de futur impossible, notée DCIF. Définition 10. La fermeture vers le bas d ensemble IF, noté DCIF 0 1" : ; 5 < =345 >?3@ A 5#B#C39 D : E 5 < "2345F G39: ; 5H 39: ; 5 ) 39 D : E 5I Où : 39: ; 5 ) 39 D : E 5 J GK < 8LI MN ; H 9 D 7 9K O K PQ ; 7 E La fermeture préfixe de V, notée N ; R #B#G9! < ; H 9# S # 9! I La relation préfixe, notée S #: T S T D #ssi le mot T D commence par le mot T. Définition 11. Pré-ordre/ Équivalence de Should (notée * UVW et 7 UVW ) [16] 4 * +, - X#YZ##0 1"2345 # [ 0 1"23X5 4# 7 +, - #X##YZ##4# * +, - #X# \ ]#X# * +, - #4# ^ 0 1" "23X5# Dans la Fig. 7, nous avons (a,{bc}) # IF(C), mais (a,{bc})! DCIF(B) et DCIF(C). En conséquence DCIF(B) = DCIF(C), c est-à-dire _ # 7 +, - #1. Revenons sur l exemple de la Fig. 4, nous avons ( UVW? car? * +, - # O # $ +, - 4. C est-à-dire, l équivalence de should peut distinguer les deux processus P et Q avant de les mettre dans l architecture. En fait, Q contient un live-lock critique tandis que P ne contient qu un live-lock non-critique, nous pouvons remplacer P par Q mais pas l inverse. Page 9

14 Pour montrer l avantage de pré-ordre de should, nous considérons l exemple suivant dû à Bergstra et al [1]. Dans la Fig. 8, nous ne pouvons pas distinguer les deux processus B1 et B2 avec te. Si nous masquons l action a dans B1 et B2, les deux processus dérivatifs B1! et B2! sont en équivalence de test. Cependant, B1 et B2 peuvent être classifiés grâce à l équivalence de should. En fait, (!, aa*b)"if(b2)! (!, aa*b)"dcif(b2) mais {(!,aa*b),(a,a*b), (aa*,b)}#if(b1)! (!,aa*b)#dcif(b1), alors B2! "#$ B1. Dans le contexte de masquage, (!,{b,c})"if(b2! )! (!,{b,c})" DCIF(B2! ) mais (!,{b,c})#if(b1!)! (!,{b,c})#dcif(b1!), donc B2!"! "#$ "B1!# Fig. 8. % &'( est congruent dans le contexte de masquage Nous avons analysé quatre relations : la congruence observationnelle ($), l équivalence de futur impossible (= IF ), l équivalence should (= shd ), et l équivalence de test (te). Dans la Fig. 9, $ % = IF % = shd % te. 3 2 te = shd )* (V, W) dans Fig. 2 : V = IF W mais V + W 2 (B, C) dans Fig. 7 : B = shd C mais B & IF C 1 = IF $ 3 (B1, B2) dans Fig. 8 : B1 = te B2 mais B1 & shd B2 Fig. 9. Représentation des relations de comparaison du point de vue ensembliste 2.4 Synthèse du pré-ordre de should Nous présentons les avantages de la relation de should : Page 10

15 Elle supporte le changement de non-déterministe (qui n existe pas dans la congruence observationnelle) et le changement de moment du choix (qui n existe pas dans le pré-ordre de futur impossible). Elle distingue la boucle critique de la boucle non-critique grâce à l hypothèse d équité. Ceci nous permet d éviter d avoir une mauvaise implémentation à partir d une bonne spécification (cf. l exemple dans Fig. 8). Elle est congruente pour l opérateur de masquage et de composition parallèles. Ceci nous permet construire le système de manière compositionnelle. 3 Conclusion Nous avons analysé plusieurs relations pour trouver le bon candidat (qui reste sur l hypothèse d équité et est approprié pour deux contextes au-dessus) pour la substituabilité de composants. Le pré-ordre de should est la réponse à notre problème. Nous avons implémenté le pré-ordre/équivalence de should et de futur impossible dans notre outil IDCM [11] à base de l algorithme abstrait de Rensink. Nous avons transformé l architecture UML en EXP.OPEN de façon à savoir générer des LTS à partir d architectures. Cette traduction vers une algèbre de processus présente aussi l avantage de permettre des vérifications incrémentales, à condition que les pré-ordres de vérification choisis soient monotones pour les opérateurs algébriques. C est le cas du pré-ordre should qui est congruent pour tous les opérateurs sauf le choix, donc pour les opérateurs architecturaux. Bibliographies 1. Bergstra, J.A. et al.: Failures without chaos: A new process semantics for fair abstraction. Formal description of programming concepts III. pp (1987). 2. Brinksma, E. et al.: Fair Testing. In: Smolka, S. (ed.) CONCUR 95: Concurrency Theory. pp Springer-Verlag, Philadelphia, PA (1995). 3. Brinksma, E., Scollo, G.: Formal Notions of Implementation and Conformance in LOTOS. Twente University of Technology, Department of Informatics, Enschede (1986). 4. Van Glabbeek, R.J., Glabbeek, R. van: The linear time Branching time spectrum II (1993). 5. Hoare, C.A.. R.: Communicating sequential processes. Communications of the ACM. 21, 8, (1985). 6. International Organization for Standardization: ISO 9646: Conformance Testing Methodology and Framework. (1991). Page 11

16 7. ISO: ISO 8807:1989 Information processing systems -- Open Systems Interconnection -- LOTOS -- A formal description technique based on the temporal ordering of observational behaviour, (1989). 8. Lang, F.: Exp.Open 2.0: A Flexible Tool Integrating Partial Order, Compositional, and On-the-fly Verification Methods. In: Judi, R. et al. (eds.) Proceedings of the 5th International Conference on Integrated Formal Methods IFM Springer, Eindhoven (2005). 9. Leduc, G.: A framework based on implementation relations for implementing LOTOS specifications. Computer Networks and ISDN Systems. 25, 1, (1992). 10. Luong, H.-V.: Construction Incrémentale de Spécifications de Systèmes Critiques intégrant des Procédures de Vérification. Université Paul Sabatier Toulouse III (2010). 11. Luong, H.-V. et al.: IDCM:un outil d analyse de composants et d'architectures dédié à la construction incrémentale. 11èmes Journées Francophones sur les Approches Formelles dans l Assistance au Développement de Logiciels. pp (2012). 12. Milner, R.: Communication and concurrency. Prentice-Hall, Inc., Upper Saddle River, NJ, USA (1989). 13. Natarajan, V., Cleaveland, R.: Divergence and Fair Testing. In: Fülöp, Z. and Gécseg, F. (eds.) Automata, Languages and Programming. pp Springer Berlin / Heidelberg (1995). 14. Nicola, R. De, Hennessy, M.: Testing Equivalence for Processes. Proceedings of the 10th Colloquium on Automata, Languages and Programming. pp (1983). 15. Ouaknine, J. et al.: Static livelock analysis in CSP (2011). 16. Rensink, A., Vogler, W.: Fair testing. Information and Computation. 205, 2, (2007). 17. Roscoe, A.W., Roscoe, A.W.: Seeing beyond divergence. Proceedings of Symposium on the occasion of 25 years of CSP. (2004). Page 12

17 Supporting architectural pattern language using structural properties Minh Tu Ton That, Salah Sadou, and Flavio Oquendo IRISA Université de Bretagne Sud Vannes, France Abstract. During the development of software architecture, patterns play an important role in documenting and maintaining quality attributes of the system. In our observation, architectural patterns often share common structural properties that characterize pattern s implied nonfunctional attributes. The fact that structural properties are implicitly integrated in architectural pattern structures can prevent the understandability and the reusability of these artifacts. Therefore, in this work we first present several architectural patterns structural properties and second propose to explicitly describe them in a pattern description language. 1 Introduction In software engineering, architectural patterns have been chosen as important artifacts in the architectural documentation. They not only provide common vocabulary and understanding of design principles but also support the construction of software with defined quality properties [2]. In our observation, architectural patterns often share common structural properties that characterize the quality attributes. The pattern definition languages in the literature [4,3] assume that these properties are implicitly integrated in the pattern structure. Since structural properties are scattered in many patterns, it s difficult to recognize the sharing property from different patterns and more over, the change of one structural property can lead to the change of many involved patterns. Thus, we find that implicit integration of structural properties in architectural pattern structures can prevent the understandability and the reusability of these artifacts. 2 Structural properties Structural properties in our perspective are properties that form the structure of a pattern or to some extent, add to a pattern certain characteristics. Along with the containing pattern, structural properties themselves help maintain nonfunctional properties of the applied architecture. Let s take an example of the Page 13

18 2 Minh Tu Ton That, Salah Sadou, and Flavio Oquendo vertical multiplicity property. This property specifies a pattern in which there exist a certain number of non-connected elements that are all connected to a stand-out element. We can find this characteristic in the pattern Client-Server or Master-Slave [2]. More specifically, all Clients are connected to a Server or all Slaves are connected to a Master. This property helps form the exchangeability of the architecture. Indeed, since the non-connected elements are treated equally and all connected to an element, it s easy to exchange these elements without changing the structure of the architecture. We present as follows the six discovered structural properties in [2]. 1. Mutual dependency Description: Two elements are mutually dependent if there s a relationship between them. The common form of this relationship is: The element X corresponds to at least (at most, exactly, ) one element Y. Applied patterns: Broker, MVC, Microkernel, Reflection, Whole-Part, Master-Slave, Proxy. 2. Interconnection Description: Specify that an element can always find a way to reach any same type element. Applied patterns: Broker, Peer-to-Peer. 3. Strict order Description: Specify that all same type elements must be strictly ordered. An element can only contact with the next higher ordered element. Applied patterns: Layer, Tier, Three Layer. 4. Graph Description: Specify that all same type elements create a cyclic graph or not. Applied patterns: Pipes and Filters. 5. Oriented multiplicity Description: Specify that all same type elements are horizontally multiplied (inter-related) or vertically multiplied (all connect to the same element). Applied patterns: Pipes and Filters, Client-Server. 6. Accessing shield Description: Specify that 2 elements must communicate indirectly through a shield element. Applied patterns: Blackboard, Broker, Microkernel, Whole-Part, Proxy. 3 Structural properties We add to our pattern language [6] the support to describe structural properties. They are described explicitly as independent artifacts and connected to patterns when necessary. The pattern language meta-model is illustrated in Figure 1. A property element is considered as a sub-pattern which is inherited from the pattern element. By this way, a property has the full power to be described as a Page 14

19 Supporting architectural pattern language using structural properties 3 Fig. 1. General pattern meta-model pattern. Our pattern language supports three types of composition: overlapping, stringing and internal replacement. Except for the internal replacement composition in which a pattern is replaced internally by another pattern, the other two types of composition are already addressed in the literature [5,1]. We leverage the overlapping composition as a means to integrate structural properties into the pattern model. The elements in the pattern model which play certain roles in the property are overlapped with the corresponding elements in the property model. Figure 2 illustrates the example of describing the shared vertical multiplicity property of two patterns: Client-Server and Master-Slave. To integrate this property into these patterns, the Node element is overlapped with the Client element and the Slave element respectively. Fig. 2. An example of structural property Page 15

20 4 Minh Tu Ton That, Salah Sadou, and Flavio Oquendo 4 Implementation To verify the feasibility of our approach, we developed a tool which provides the following functionalities: 1) Create architectural patterns 2) Create structural properties 3) Integrate structural properties into pattern models via the overlapping operator. The tool is built based on the following framework. EMF, GMF, Kermeta. References 1. Ian Bayley and Hong Zhu. On the composition of design patterns. In QSIC, pages 27 36, Buschmann, F., Meunier R., Rohnert, H., Sommerlad, P., and Stal, M. Pattern- Oriented Software Architecture - A System Of Patterns. John Wiley & Sons, New York, Maged Elaasar, Lionel C. Briand, and Yvan Labiche. A metamodeling approach to pattern specification. In Proceedings of the 9th international conference on Model Driven Engineering Languages and Systems, pages Springer-Verlag, R. B France, D. K Kim, Sudipto Ghosh, and E. Song. A UML-based pattern specification technique. IEEE Transactions on Software Engineering, pages , March Imed Hammouda and Kai Koskimies. An approach for structural pattern composition. In Software Composition, pages , Minh Tu Ton That, Salah Sadou, and Flávio Oquendo. Using architectural patterns to define architectural decisions. In WICSA/ECSA, pages , Page 16