Interaction Analysis in Aspect Oriented Models - Article de Katharina Mehner, Mattia Monga, Gabriele Taentzer
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
Interaction Analysis in
Aspect Oriented
Models
Article de Katharina Mehner, Mattia Monga,
Gabriele Taentzer
Présenté par: Arsène Sabas
IFT6310
2008-02-11 1
Plan de la présentation
Introduction
Contexte
Contenu
Approche orienté-aspect (OA)
Modélisation des exigences par OA
Transformation de graph
Conclusion
Discussion
2008-02-11 2
Introduction
Article publié
2006 IEEE International requirements
Engineering conference
Auteurs:
Katharina Mehner (Siemens AG
Allemangne)
Mattia Monga (Milan University)
Gabriele Taentzer (Technical University of
Berlin)
2008-02-11 3
Contexte
Motivations
Redondance dans le code source dans les
classes écrites dans un langage objet.
synchronisation des accès aux ressources.
Optimisation de l’utilisation des ressources.
Sauvegarde de certaines données dans des
bases de données.
Traitement des exceptions.
Terme préoccupations transversales
(crosscutting concerns)
2008-02-11 4Contexte
Motivations
Implique que les classes sont peu
réutilisables et les applications sont
difficiles à maintenir.
POA vient combler ces limites de POO.
Cependant POA engendre certaines
interactions indésirables.
Cet article présente une approche formelle
permettant de résoudre certaines de ces
interactions.
2008-02-11 5Contexte
Knuth’s Structured Programming with
goto Statements.
″A "calculus" of program transformations
is gradually emerging, a set of operations
which can be applied to programs without
rethinking the specific problem each time″
(p.283).
2008-02-11 6Contexte
Knuth’s Structured Programming with
goto Statements.
″We understand complex things by
systematically breaking them into
successively simpler parts and
understanding how these parts fit together
locally″(291).
2008-02-11 7Approche orienté-aspect (OA)
OA est une technologie qui permet de
modéliser les préoccupations
transversales. C’est un complément à
OO.
Un framework OA devrait fournir:
Un mécanisme de séparation.
Un mécanisme de composition.
2008-02-11 8Approche orienté-aspect (OA)
Terme Description
Tangled code Code embrouillé, code spaghetti.
Crosscutting Aspects (parties) de la programmation qui concernent plusieurs
concerns classe, et qui donc transcendent le modèle objet
(synchronisation, logging, persistance…).
Advice Fragment de code destiné à être greffé.
Joinpoint, pointcut Infrastructure mise en place pour définir le lieu des greffes dans
le code, et éventuellement quand elles doivent être appliquées
ou pas.
Aspect Module définissant les greffons (advices) et leurs pointcuts.
Weaver Infrastructure mise en place pour greffer le code des aspects
dans le code des méthodes de base. Le tissage peut avoir
lieu avant, pendant ou après la compilation ou l’exécution.
2008-02-11 9Approche orienté-aspect (OA)
Vue abstraite du concept de séparation des aspects
des méthodes de base
2008-02-11 10Approche orienté-aspect (OA)
OA est une méthode
de développement
logiciel horizontale.
OO est une méthode
de développement
logiciel verticale.
OA versus OO
2008-02-11 11Modélisation des exigences
par OA
Objectif de l’article:
Analyser les interactions et détecter le
plutôt possible les potentielles
inconsistances en utilisant une méthode
formelle.
Les approches existantes sont soit
informelles, soit formelles mais pour
l’implémentation.
2008-02-11 12Modélisation des exigences
par OA
Étapes:
Construction du
diagramme des uses
case.
Construction du
diagramme de
classes.
2008-02-11 13Modélisation des exigences
par OA
Étapes:
Construction des
diagrammes
d’activités.
Diagramme d’activités du
Spécification des pré use case ″Buy flight″
et post-conditions
Pré et post condition de l’activité
″Create custumer″
2008-02-11 14Modélisation des exigences
par OA
Étapes:
Un advice est modélisé par un use case
avec des diagrammes d’activités et des
pré, post conditions.
Les pointcuts sont les activités. Chaque
activité peut représentée un joint point.
Les aspects représentent les exigences
transversales.
Ex: ″earn bonus″ est un aspect (″buy
flight″ et ″rent car″).
2008-02-11 15Modélisation des exigences
par OA
Étapes:
Les modificateurs
before, after, replace
indiquent quand est-
ce que le tissage a
lieu.
″earn bonus″ est
avant ″Pay flight″ et
″Pay rental″
Leur pointcut est
″ Pay″.
2008-02-11 16Modélisation des exigences
par OA
Interactions lors du tissage
Deux sortes d’interactions:
A2 est en conflit avec A1 si A2 after A1 ne
peut être réalisé car pre(A2) sont violées par
post(A1).
A2 dépends de A1 si un output de A1 est
requis par A2 ou A1 supprime quelque chose
interdit par A2.
Il peut y avoir des interactions entre
aspects, et entre aspects et méthodes de
base.
2008-02-11 17Transformation de graphe
Théorie:
Un graphe est défini par des ensembles de
nœuds et d’arcs, et deux fonctions (source
et cible) qui apparient les arcs sur les
nœuds.
Une transformation de graphe est une
modification basée sur des règles d’un
graphe G en un graphe H.
2008-02-11 18Transformation de graphe
Théorie:
Les règles sont exprimées par deux
graphes (L,R) où L = pré-conditions; R=
post-conditions.
Une phase de transformation de graphe
s’exécute en trouvant un appariement m
de L relatif à l’actuelle instance G tq m
préserve la structure et la compatibilité du
type G.
2008-02-11 19Transformation de graphe
Théorie:
Une phase de transformation se fait en
deux étapes:
Construire D := G\m(\L∩R), ie supprimer tous
les items du graphe qui sont à supprimer.
Construire H:= D∪(R\(L∩R)), ie créer tous les
items du graphe qui sont à créer.
Une transformation de graphe consiste en
une ou plusieurs phases de transformation.
2008-02-11 20Transformation de graphe
Théorie:
Des conditions positives ou négatives
(NAC) peuvent être appliquées.
Un système de transformation de graphe
(GTS) est un ensemble de règles et de
type de graphe.
AGG (Attribut graph Grammar) peut être
utilisé pour spécifier les systèmes de
transformation de graphe et analyser leurs
règles.
2008-02-11 21Transformation de graphe
Analyse des conflits et des
dépendances.
Utilise les paires critiques.
Une paire critique est une paire d’étapes
de transformation qui sont
en conflits.
sont en conflit ssi p1 peut
désactiver p2 ou p2 peut désactiver p1.
2008-02-11 22Transformation de graphe
Analyse des conflits et des
dépendances.
Différents types de conflit:
Delete/use: p1 supprime un objet du graphe
utilisé par m2.
Produce/forbid: p1 produit une structure de
graphe qu’un NAC de p2 interdit.
Change/use: p1 change la valeur d’un attribut
d’un objet du graphe qui est utilisé par m2.
2008-02-11 23Transformation de graphe
Analyse des conflits et des
dépendances.
Différents types de dépendance:
Produce/use: p1 produit un objet du graphe
nécessaire à m2 de p2.
Delete/forbid: p1 supprime des objets du
graphe qu’un NAC de p2 interdit.
Change/use: p1 change l’attribut d’un objet
du graphe qui est utilisé par m2 de p2.
2008-02-11 24Transformation de graphe
Passage des modèles OA aux graphes.
Les graphes peuvent être utilisés comme
une représentation abstraites des
diagrammes.
Les graphes apparaissent à deux niveaux:
Niveau type qui représente les diagrammes
de classes: graphe de types (TG).
Niveau instance qui représente les
diagrammes objets.
2008-02-11 25Transformation de graphe
Passage des modèles OA aux graphes.
Les pré et post conditions des activités
sont représentées par les règles.
2008-02-11 26Transformation de graphe
Analyse des
interactions
Les paires critiques
sont utilisées pour
détecter les
potentiels conflits et
dépendances entre
aspects, et aspects
et méthodes de
base.
2008-02-11 27Transformation de graphe
Application à
l’agence de voyage
avec AGG.
Détection de conflits
Une entrée de
colonne A
désactive une
entrée de ligne B
si aij > 0: B est en
conflit avec A.
2008-02-11 28Transformation de graphe
Application à
l’agence de voyage
avec AGG.
Détection de
dépendances
Une entrée de
colonne A active
une entrée de
ligne B si aij > 0: B
dépends de A.
2008-02-11 29Conclusion
L’article décrit une approche formelle
basée sur la théorie de transformation
de graphe pour analyser et détecter les
conflits et dépendances potentiels entre
aspects, et aspects et méthodes de
base.
2008-02-11 30Discussion
Approche pertinente pour la validation et
la vérification des systèmes logiciels.
Ne détermine pas toutes les interactions
non désirables.
Pas de projection sur le future de la part
des auteurs.
Manque un peu d’explication sur
l’application des règles.
2008-02-11 312008-02-11 32
Vous pouvez aussi lire
