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