Une approche orientée aspect allant du modèle d’exigences au modèle de conception

1. Une approche orientée aspect allant du
modèle d’exigences au modèle de conception
Journées du GDR GPL 2011, Session COSMAL
1 2 3 4
Sébastien Mosser, Gunter Mussbacher, Mireille Blay-Fornarino, Daniel
Amyot
1: INRIA Lille-Nord Europe, LIFL (UMR CNRS 8022), Université Lille 1, France
2: SCE, Carleton University, Canada
3: I3S (UMR CNRS 6070), Université Nice - Sophia Antipolis, France
4: SITE, University of Ottawa, Canada
1

2. Sébastien Mosser, Gunter Mussbacher, Mireille Blay
Fornarino, and Daniel Amyot. «From Aspect-oriented
Requirements Models to Aspect-oriented Business Process
Design Models»
2

3. AdoreModel transformMap(context:Component, am:AdoreModel, map:UCMmap, p
// determine context
if (context == null) { context = selectFirstComponentTaggedBusinessProcess
// establish Adore fragment or orchestration
if map.getConcern().isCrosscutting() { created = am.addFragment(map, conte
else { created = am.addOrchestration(map, p, context); }
// end recursion if the fragment/orchestration already exists
if (!created) { return am; }
// transform path element - also traverses the map to the next path element(s)
if (p == null) { p = map.getStartPoint(); }
am = transformElement(context, am, p, flag) // starts recursion
return am;
}
AdoreModel transformElement(context:Component, am:AdoreModel, p:PathNode[]
foreach element e in p {
// deal with a static stub – requires examination of its plug-in map
if e.isStub() {
if (!e.getPluginMap().contains(context) &&
e.getPluginMap().containsOtherComponentTaggedBusines
am.addServiceInvocation(e);
am = transformMap(null, am, e.pluginMap(), nu
3
}

4. Agenda
• Motivations : Vers une boucle de développement itérative
• Contexte : Exigences, Processus métiers SOA & Aspects
• Transformation «auto-magique»
• Avantages: Validation, Génération, Conflits, Abstraction
• Conclusions & Perspectives
4

5. Motivation :
Vers une boucle de développement interactive
5

6. Une dichotomie apparente
Modèle
de conception
Modèle
d’exigences
6

7. Et pourtant ...
7

8. Proposition : Une approche dirigée par les
modèles
• Supporter la réification continue des artefacts manipulés
• Transformation automatique d’une phase à une autre
• Profiter des avantages de chaque phase de développement
• e.g., représentation client, analyse de modèles
• Boucle de rétro-action pour un développement itératif
Analyse des Conception de
exigences l’architecture
8

9. Contexte :
Exigences, Processus Métiers & Aspects
9

10. Modèle d’exigences : AoURN
• URN : «User Requirements Notation»
• Standard international (Série ITU-T Z. 150), outillé dans jUCM-Nav
• Approche unifiée (goal-oriented, scenario-based, aspect-oriented)
• Supporte une modélisation multi-vues des exigences
• Structure et comportement réifiés par des scénarios
• Intentions/Trade-off réifiés par des buts
• Support d’analyse sur ces artefacts (e.g., non-régression)
10

11. Exemple : Récupération d’images
11

12. Processus Métiers (Arch. SOA)
• ADORE = «an Activity meta-moDel suppOrting oRchestration Evolution»
• Description de processus métiers (activités, relations)
• Basé sur le langage industriel BPEL (sous-ensemble du standard)
• Enrichissement du standard pour supporter l’évolution des processus
• Processus représentés par des «flots de contrôles»
• Evolutions représentées par des «fragments» de processus (incomplets)
• Support d’analyses sur les processus métiers (e.g., terminaison, R/W)
12

13. Exemple: Récupération d’images
13

14. Et les aspects dans tout ça ?
• Approche basée sur la séparation des préoccupations [Dijkstra, 74]
• Système final = Système ← Préoccupation #1 ← Préoccupation #2 ← ...
• Vocabulaire aspect (AO*: Aspect-oriented [Programming|Modeling|...])
• Les préoccupations sont des «aspects»
• Leur composition avec le système est appelée «tissage»
Get Pictures
14

15. Version AoURN
Lien avec le système initial
15

16. Version ADORE
Lien avec le système initial
16

17. Transformation «auto-magique»
17

18. Par l’exemple
18

19. Par l’exemple
18

20. Par l’exemple
18

21. Par l’exemple
18

22. Résultat immédiats
Processus
Processus
Scénario
Scénario Processus
Processus
Scénario
Scénario Processus
Métier
Métier
Scénario Métier
Métier
Métier
Aspect
Aspect Fragment
Fragment
Aspect Fragment
Réification continue des préoccupations 19

23. Avantages
Validation, Génération, Conflits, Abstraction
20

24. #1: Sur la validation
• Points clés & Avantages
• Le modèle d’exigence est validé en amont de la transformation
➡ On peut «oublier» de re-vérifier ce qui l’a déjà été
➡ Les vérifications sont exprimées en termes d’exigences
• Illustration
• Au niveau des exigences, on peut vérifier que les modèles définis
comportent tous au moins une une «responsabilité» d’affichage des
images récupérées sur le Web.
21

25. #2: Sur la génération
• Points clés & Avantages
• Génération automatique des artefacts du modèle de conception
➡ Ne pas refaire ce qui a déjà été fait
➡ Reposer sur des mécanismes automatique (et non plus humain)
• Illustration
• La transformation génère automatiquement les modèles
comportementaux ADORE à partir des modèles d’exigences exprimés
dans AoURN
22

26. #3: Sur les conflits
• Points clés & Avantages
• Le modèle de conception est plus «concret» que le modèle d’exigences
➡ les tissages d’aspects sont instanciés
➡ On peut détecter des conflits de tissage dans cet espace
• Illustration
• Une préoccupation de «Paiement» entre en conflit avec la
préoccupation d’ajout d’images «PICASA» car elles sont tissées au
même endroit sans qu’on en ait spécifié l’ordre.
23

27. #4: Sur l’abstraction
• Points clés & Avantages
• Le modèle de conception manipule des données (variables)
➡ Techniques d’analyse des processus au niveau «syntaxique»
➡ e.g., détection de flots de données inconsistent
• Illustration
• La préoccupation de «restriction» utilise un seuil (i.e., une variable)
pour définir la cardinalité finale de l’ensemble d’images. Qui définit ce
seuil ? Est-ce une constante ? Un paramètre ?
24

28. Conclusions & Perspectives
25

29. A retenir: Boucle de rétro-action & Itérativité
#1:Validation #3: Conflits
#2: Génération #4: Abstraction
Transformation automatique 26

30. Accomplissements
• Un algorithme de transformation automatique
• Transformation d’un modèle d’exigences en modèle de conception
• Outils et implémentations basées sur des standards
• Avantages
• Maintien de l’approche «aspects» des exigences à la conception
• Utilisation des avantages inhérents à chaque étape du cycle de vie
27

31. Travaux futurs
• Court terme
• Vérification du passage à l’échelle de l’approche
• Enrichissement du support outillé
• Formalisation du «feedback» retourné dans le modèle d’exigence
• Long terme
• Vers une chaine de transformation sur tout le cycle de vie
• Alignement avec des approches par lignes de production logicielles
28

32. Merci de votre attention !
29
graphics by C.line & sxc.hu