Soutenance mémoire
L’étude des approches classiques de développement (telles que l’approche procédurale, modulaire, orientée objet, etc.) montre que le problème principal dans l’évolution et la réutilisation des systèmes logiciel est un problème d’organisation des programmes. En effet, l’organisation d’un programme en utilisant ces approches entraîne une multiplication des dépendances et donc des interactions entre les différentes fonctionnalités du programme. Toutes ces dépendances et interactions conduisent aux problèmes d’enchevêtrement et de dispersion de code qui rendent plus difficiles l’évolution et la réutilisation de ces systèmes logiciels [Kiczales et al, 1997].
Afin de pallier ces problèmes, les approches de séparation avancées des préoccupations ont été proposées. Ces approches consistent à promouvoir le principe de séparation des préoccupations qui a été adopté par les approches classiques. Elles proposent, en effet, de décomposer le programme non seulement en unités modulaires propres aux préoccupations de base, mais aussi en unités modulaires spécifiques aux préoccupations transversales. La séparation entre ces préoccupations améliore par la suite la compréhension, la réutilisation et l’évolution des systèmes logiciels.
Séparation des préoccupation
De nos jours, les systèmes logiciels incorporent des fonctionnalités (comme la distribution, la concurrence, la persistance, la tolérance aux pannes, etc) qui alourdissent le développement. Les systèmes logiciels deviennent donc de plus en complexe et difficile à faire évoluer. Nous avons intérêt à gérer cette complexité afin de faire face aux contraintes d’adaptabilité, d’évolution et de réutilisation facilitant ainsi la compréhension du système. De ce fait, au lieu de développer ces systèmes logiciels de front, il est préférable de les décomposer en unités modulaires [Parnas, 1972] distinctes où chaque unité traite un sous problème particulier. Ces unités modulaires sont ensuite composées ensemble afin d’assurer la construction du système final. Ce principe de décomposition se base sur l’approche classique de modularisation qui a été discutée depuis les années 1970 par R. Gauthier [Gauthier et al, 1970]. Cette approche a été adoptée par l’ensemble des approches de développement traditionnelles (procédurale, modulaire et orientée objet). Toutes ces approches visent à appliquer un principe connu, dans le génie logiciel, qui est la séparation des préoccupations [Hursh et al, 1995]. Une préoccupation est un concept, un but particulier ou une unité d’intérêt. Le principe de séparation des préoccupations consiste à identifier séparément l’ensemble des préoccupations d’un système logiciel tout en identifiant leurs interrelations afin de les composer ensuite. Il s’agit d’un principe clé pour la réduction de la complexité de développement de grands systèmes. Il améliore en effet la lisibilité et la flexibilité du système permettant ainsi l’évolution, l’adaptation et la réutilisation de toute ou une partie de l’application.
Approches classiques de développement
En appliquant le principe de séparation de préoccupations, plusieurs approches classiques de développement ont été proposées, à savoir : la programmation procédurale, modulaire et orientée objet.
La programmation procédurale
La programmation procédurale se base sur le concept d’appel procédural. Les constructions de base offertes par les langages qui supportent ce paradigme de programmation sont les procédures et les fonctions. Ces dernières peuvent admettre des arguments et renvoyer des valeurs. Les données du système sont globales à l’ensemble des constructions du programme et donc partagées par celles-ci. La programmation procédurale est un meilleur choix qu’une simple programmation séquentielle. En effet, elle permet de réutiliser le même code à différents emplacements dans le programme sans avoir à le réécrire. Ceci permet la réduction de la taille du code source conduisant ainsi à un gain en localité des modifications et une amélioration donc de la maintenabilité.
La programmation modulaire
La programmation modulaire [Parnas, 1972] utilise les principes d’encapsulation et d’abstraction des données. Selon ces deux principes, l’ensemble des procédures et/ou fonctions dépendantes et les données qu’elles manipulent sont regroupées et séparées dans un module à part définissant un type abstrait. Un programme est alors constitué de plusieurs modules et la collaboration inter-modules se fait à travers des interfaces. L’abstraction et l’encapsulation augmentent la lisibilité et donc la compréhension du code des différents types définis par les modules facilitant ainsi la maintenance et l’évolution de ceux-ci.
La programmation orientée objet
La programmation orientée objet [Nygaard, 1986] prend ses racines à partir de la programmation modulaire (en particulier, à partir de langage Simula [Birtwistle et al, 1973]). Elle met en avant la description d’entités qui s’appellent des objets admettant chacun une identité, un état et un comportement particulier. La programmation orientée objet permet en effet de décomposer le système en classe d’objets indépendants les uns des autres qui fournissent un ou plusieurs services au reste du système. Grâce aux nombreux concepts de la programmation orientée objet (tels que : l’encapsulation des données, l’identification des différentes opérations applicables sur ces données, la notion de classe, la notion d’objet, le mécanisme d’héritage, la relation de généralisation/spécialisation, le polymorphisme, etc), l’approche orientée objet a permis d’assurer une meilleure organisation et structuration des programmes améliorant ainsi la flexibilité, la compréhensibilité, l’évolution et la réutilisation des systèmes logiciels.
Limites et problèmes des approches classiques de développement
Vu ce qu’offrent les approches classiques de développement comme avantages (tels que : la modularisation, lisibilité, compréhension et réutilisation des logiciels), elles restent particulièrement efficace dans l’expression des préoccupations fonctionnelles (dites aussi verticales) qui expriment les fonctionnalités métiers du système. Cependant, comme le note Kiczales et al. [Kiczales et al, 1997], les approches classiques de développement se concentrent et traitent essentiellement la séparation et la composition des préoccupations fonctionnelles. Elles ne garantissent pas, en revanche, une représentation modulaire et séparée de plusieurs autres préoccupations non-fonctionnelles dites transversales (Crosscutting Concerns). Ces préoccupations affectent, à la fois, plus d’une unité modulaire fonctionnelle, ce qui conduit le plus souvent à deux problèmes de fond qui sont : les problèmes de l’enchevêtrement et la dispersion de code.
L’enchevêtrement du code
L’enchevêtrement du code survient quand un module est implémenté pour traiter plusieurs préoccupations en même temps. Un développeur a souvent affaire, pendant qu’il développe un module, à des préoccupations telles que la gestion transactionnelle de la persistance, le logging, la sécurité, etc . Cela conduit à la présence simultanée d’éléments issus de chaque préoccupation et il en résulte un enchevêtrement du code.
La dispersion de code
Les préoccupations transversales concernent, en général, une ou plusieurs préoccupations de base. Leurs définitions se trouvent ainsi disséminées et dispersées au travers de l’ensemble des unités modulaires représentant les préoccupations de bases qu’elles affectent. Par exemple, dans un système utilisant une base de données, le logging est une préoccupation implémentée dans tous les modules qui accèdent à la base.
Conséquences
Les deux problèmes cités précédemment entraînent des conséquences négatives sur le développement du logiciel telles que [Seinturier et al, 2005]:
– Mauvaise traçabilité. L’utilisation de plusieurs préoccupations transversales avec les préoccupations fonctionnelle rend la correspondance entre une préoccupation et son implémentation difficilement identifiables.
– Faible efficacité et productivité. La définition simultanée de plusieurs préoccupations transversales en même temps et dans une même unité modulaire éloigne l’attention du développeur du but final de l’application limitant ainsi son efficacité et sa productivité.
– Maintenabilité et évolution difficiles. Lorsqu’on veut faire évoluer le système, on doit modifier de nombreux modules suite à l’éparpillement du code. Modifier chaque soussystème pour répercuter les modifications souhaitées peut conduire à des incohérences.
– Faible réutilisation du code. L’utilisation de plusieurs préoccupations transversales avec les préoccupations fonctionnelle diminue la compréhension et éventuellement la réutilisation de ces préoccupations.
Approches de séparation avancées des préoccupations
Comme nous l’avons présenté dans la section précédente, le principal problème des approches classique revient à la mauvaise séparation et représentation explicite et modulaire entre les préoccupations fonctionnelles et les préoccupations transversales. Pour cette raison, plusieurs approches de séparation avancées des préoccupations ont ainsi été proposées. Ces approches proposent une décomposition des programmes non seulement en unités modulaires représentant les préoccupations fonctionnelles de base, mais aussi en unités modulaires dédiées à la représentation des préoccupations transversales.
Les principales approches de séparation des préoccupations sont :
– La programmation orientée aspect (POA)
– La composition de Filtres (CF)
– La séparation multidimensionnelle des préoccupations (MDSOC) .
|
Table des matières
Introduction Générale
1. Contexte du travail
2. Problématique
3. Motivations et Objectifs de la thèse
4. Organisation de la thèse
Chapitre 1: La séparation des préoccupations
1.1 Séparation des préoccupations
1.2 Approches classiques de développement
1.2.1 La programmation procédurale
1.2.2 La programmation modulaire
1.2.3 La programmation orientée objet
1.3 Limites et problèmes des approches classiques de développement
1.3.1 L’enchevêtrement du code
1.3.2 La dispersion de code
1.3.3 Conséquences
1.4 Approches de séparation avancées des préoccupations
1.4.1 La programmation orientée aspect (POA)
1.4.1.1 Principe et objectif
1.4.1.2 Concepts de base
1.4.1.3 L’approche orientée aspect avec un exemple illustratif
1.4.2 La composition de filtres (CF)
1.4.2.1 Principe et objectif
1.4.2.2 Concepts de base
1.4.2.3 L’approche composition de filtres avec un exemple illustratif
1.4.3 La séparation multidimensionnelle des préoccupations (MDSOC)
1.4.3.1 Principe et objectif
1.4.3.2 Concepts de base
1.4.3.3 L’approche hyperspace avec un exemple illustratif
1.5 Synthèse des approches de séparation avancées des préoccupations
1.6 Conclusion
Chapitre 2 :Le paradigme aspect et le problème d’interaction des aspects
2.1 Limites et problèmes de la programmation orientée aspect
2.2 Vérification de problème d’interaction des aspects
2.2.1 Travaux qui se basent sur le code source
2.2.1.1 Les travaux de Goldman et Katz [Goldamn et al, 2007] et [Katz et al, 2008]
2.2.1.2 Le travail d’Aksit et al [Aksit et al, 2009] 30
2.2.1.3 Le travail de Katz [Katz, 2006]
2.2.1.4 Le travail de Djoko et al [Djoko Djoko et al, 2012]
2.2.2 Travaux qui se basent sur les modèles
2.2.2.1 Les travaux de Mostefaoui et al [Mostefaoui et al, 2005–2007]
2.2.2.2 Les travaux de Zhang [Zhang, 2010] et [Zhang et al, 2012]
2.2.2.3 Le travail de Chen et al [Chen et al, 2010]
2.3 Conclusion
Chapitre 3: Les systèmes de réécriture et le langage Maude
3.1 Les méthodes de vérification
3.1.1 Les tests logiciels
3.1.2 La vérification formelle
3.1.2.1 La preuve de théorèmes (Theorem proving)
3.1.2.2 La vérification de modèles (model-checking)
3.2 Le model-checking
3.2.1 La modélisation formelle
3.2.1.1 Les systèmes de transitions
3.2.1.2 Les automates à états finis (AEF)
3.2.1.3 Les réseaux de Petri (RdP)
3.2.1.4 Les systèmes de réécriture
3.2.2 La spécification des propriétés
3.2.2.1 La logique temporelle linéaire
3.2.2.2 La logique temporelle arborescente
3.2.3 Les outils de model-checking
3.3 Les systèmes de réécriture
3.3.1 Quelques concepts fondamentaux
3.3.1.1 Algèbre des termes
3.3.1.2 Théorie équationnelle
3.3.1.3 Théorie de réécriture
3.3.2 Propriétés des systèmes de réécriture
3.3.3 La logique de réécriture
3.3.4 Application de la logique de réécriture
3.4 Le langage Maude
3.4.1 Présentation de Maude
3.4.2 Maude et la vérification de modèles
3.4.2.1 Vérification de modèles par la recherche de l’invariant
3.4.2.2 Vérification de modèles en LTL
3.4.3 Caractéristique du Module META-LEVEL et de la Réflexion
3.4.3.1 Les opérations de META-LEVEL: metaRewrite
3.5 Conclusion
Chapitre 4: Vérification formelle de la composition et de l’intégration des aspects : une approche guidée par les cas d’utilisation
4.1 Etude de cas : Application de Telecom
4.1.1 Diagramme de cas d’utilisation de modèle Aspect-UML
4.1.2 Diagramme de classes de modèle Aspect-UML
4.2 Un aperçu général de l’approche de transformation et de vérification
4.3 Présentation de l’approche de transformation et de vérification
4.3.1 Transformation du diagramme de classes Aspect-UML en une spécification Maude
4.3.1.1 Transformation de système de base en spécifications Maude
4.3.1.2 Transformation des aspects en spécifications Maude
4.3.1.3 Spécification de la composition et de tissage des aspects au point de jointure
4.3.2 Vérification des propriétés avec Maude
4.4 Illustration de l’approche proposée avec un exemple
4.4.1 Spécification du système de base de diagramme de classes de modèle Aspect-UML
4.4.2 Spécification des aspects de diagramme de classes de modèle Aspect-UML
4.4.3 Vérification avec Maude
4.4.3.1 Vérification des propriétés locales
4.4.3.2 Vérification des propriétés globales
4.5 Discussion
4.6 Conclusion
Conclusion Générale
