Une approche orientée aspect allant dumodèle d’exigences au modèle de conceptionJournées du GDR GPL 2011, Session COSMAL  ...
Sébastien Mosser, Gunter Mussbacher, Mireille BlayFornarino, and Daniel Amyot. «From Aspect-orientedRequirements Models to...
AdoreModel transformMap(context:Component, am:AdoreModel, map:UCMmap, p      // determine context      if (context == null...
Agenda• Motivations : Vers une boucle de développement itérative• Contexte : Exigences, Processus métiers SOA & Aspects• T...
Motivation : Vers une boucle de développement interactive                                                 5
Une dichotomie apparente                              Modèle                           de conception  Modèled’exigences   ...
Et pourtant ...                  7
Proposition : Une approche dirigée par lesmodèles• Supporter la réification continue des artefacts manipulés  • Transforma...
Contexte :  Exigences, Processus Métiers & Aspects                                           9
Modèle d’exigences : AoURN• URN : «User Requirements Notation»  • Standard international (Série ITU-T Z. 150), outillé dan...
Exemple : Récupération d’images                                  11
Processus Métiers (Arch. SOA)• ADORE = «an Activity meta-moDel suppOrting oRchestration Evolution»  • Description de proce...
Exemple: Récupération d’images                                 13
Et les aspects dans tout ça ?• Approche basée sur la séparation des préoccupations [Dijkstra, 74]  • Système final = Systè...
Version AoURNLien avec le système initial                               15
Version ADORE                Lien avec le système initial                                               16
Transformation «auto-magique»                                17
Par l’exemple                18
Par l’exemple                18
Par l’exemple                18
Par l’exemple                18
Résultat immédiats                              Processus                              Processus   Scénario   Scénario    ...
Avantages  Validation, Génération, Conflits, Abstraction                                                 20
#1: Sur la validation• Points clés & Avantages   • Le modèle d’exigence est validé en amont de la transformation      ➡ On...
#2: Sur la génération• Points clés & Avantages   • Génération automatique des artefacts du modèle de conception      ➡ Ne ...
#3: Sur les conflits• Points clés & Avantages   • Le modèle de conception est plus «concret» que le modèle d’exigences    ...
#4: Sur l’abstraction• Points clés & Avantages      • Le modèle de conception manipule des données (variables)          ➡ ...
Conclusions & Perspectives                             25
A retenir: Boucle de rétro-action & Itérativité  #1:Validation                    #3: Conflits  #2: Génération            ...
Accomplissements• Un algorithme de transformation automatique  • Transformation d’un modèle d’exigences en modèle de conce...
Travaux futurs• Court terme  • Vérification du passage à l’échelle de l’approche  • Enrichissement du support outillé  • F...
Merci de votre attention !                                 29graphics by C.line & sxc.hu
Prochain SlideShare
Chargement dans…5
×

Talk Session COSMAL du GDR GPL 2011

634 vues

Publié le

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

Publié dans : Formation, Technologie, Business
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
634
Sur SlideShare
0
Issues des intégrations
0
Intégrations
5
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Talk Session COSMAL du GDR GPL 2011

    1. 1. Une approche orientée aspect allant dumodèle d’exigences au modèle de conceptionJournées du GDR GPL 2011, Session COSMAL 1 2 3 4Sébastien Mosser, Gunter Mussbacher, Mireille Blay-Fornarino, DanielAmyot1: INRIA Lille-Nord Europe, LIFL (UMR CNRS 8022), Université Lille 1, France2: SCE, Carleton University, Canada3: I3S (UMR CNRS 6070), Université Nice - Sophia Antipolis, France4: SITE, University of Ottawa, Canada 1
    2. 2. Sébastien Mosser, Gunter Mussbacher, Mireille BlayFornarino, and Daniel Amyot. «From Aspect-orientedRequirements Models to Aspect-oriented Business ProcessDesign Models» 2
    3. 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. 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. 5. Motivation : Vers une boucle de développement interactive 5
    6. 6. Une dichotomie apparente Modèle de conception Modèled’exigences 6
    7. 7. Et pourtant ... 7
    8. 8. Proposition : Une approche dirigée par lesmodè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ératifAnalyse des Conception de exigences l’architecture 8
    9. 9. Contexte : Exigences, Processus Métiers & Aspects 9
    10. 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. 11. Exemple : Récupération d’images 11
    12. 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. 13. Exemple: Récupération d’images 13
    14. 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. 15. Version AoURNLien avec le système initial 15
    16. 16. Version ADORE Lien avec le système initial 16
    17. 17. Transformation «auto-magique» 17
    18. 18. Par l’exemple 18
    19. 19. Par l’exemple 18
    20. 20. Par l’exemple 18
    21. 21. Par l’exemple 18
    22. 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. 23. Avantages Validation, Génération, Conflits, Abstraction 20
    24. 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. 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. 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. 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. 28. Conclusions & Perspectives 25
    29. 29. A retenir: Boucle de rétro-action & Itérativité #1:Validation #3: Conflits #2: Génération #4: Abstraction Transformation automatique 26
    30. 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. 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. 32. Merci de votre attention ! 29graphics by C.line & sxc.hu

    ×