Soutenance mémoire
Ingénierie dirigée par les modèles
L’Ingénierie Dirigée par les Modèles est une approche contemporaine [Selic, 2003] très utilisée dans les développements des logiciels. Elle apporte une robustesse à la production des logiciels en termes d’efficacité et de gain de coût (le délai) tout en pérennisant le système d’information étudié. D’après Barry Boehm [Boehm, 2006], cette approche n’est pas très récente en terme d’application, mais la formalisation de ces contributions est l’effort des recherches menées dans les années 1980. Notamment, le développement de CASE 1 a permis de faire émerger des outils et des techniques pour une large communauté. L’Ingénierie Dirigée par les Modèles (IDM) ou Model Driven Engineering (MDE) en anglais [Kent, 2002] prône l’utilisation des modèles pour guider le développement en mettant à notre disposition un corpus de concepts, de méthodes et d’outils, mais aussi de langages pour créer, organiser, restructurer et transformer des modèles (cf. définition 2.1). Ces derniers sont décrits par des modèles de plus haut niveau appelés méta-modèles (cf. définition 2.2). Un des principes de l’IDM est de découpler l’aspect métier des aspects structurels et organisationnels liés à l’implémentation. Il en résulte un gain de capitalisation. De ce fait, le modèle constitue l’artefact essentiel pour développer des applications informatiques. Ces modèles représentent une vision naturelle du contexte que l’utilisateur est amené à concevoir. Plusieurs langages de modélisation généralistes ont ainsi été créés, parmi lesquels les plus connus ont d’abord été Merise [Arnold Rochfeld, 1989] puis UML [Booch et al., 2000]. Ce dernier propose une large gamme de diagrammes d’expression des besoins, de conception et de comportement dont l’utilité est intéressante dans les différentes phases de développement d’un logiciel.
IDM et MDA
L’Architecture Dirigée par les Modèles (Model Driven Architecture (MDA) en anglais) est une initiative du consortium industriel OMG ( 2) conçue pour réaliser la conception des applications, en proposant des outils, des langages, et des modèles pour faciliter le développement, la maintenance et l’évolution des modèles. Le MDA est souvent vu comme une restriction de l’ingénierie dirigée par les modèles aux outils et aux modèles développés par l’OMG. La principale idée de MDA réside en la séparation du métier de son implémentation, via l’introduction de modèles dits indépendants de la plateforme, et de modèles dits dépendants de la plateforme. L’approche MDA propose ainsi de structurer le développement d’une application suivant trois types de modèles :
1. Computation Independent Model (CIM) : ce modèle représente la vue des utilisateurs sur le système et en particulier les exigences pour une meilleure utilisation. Ici les aspects structurels ne sont pas retenus. Autrement dit, le modèle représente l’application dans son environnement.
2. Platform Independent Model (PIM) : ce modèle, indépendant des plateformes de programmation cibles, modélise l’analyse et la conception abstraite tout en représentant l’architecture de l’application.
3. Platform Specific Model (PSM) : il étend le PIM en ajoutant les détails d’implémentation propres au langage de programmation cible. Le modèle Computation Independent Model (CIM) a été ajouté à l’architecture MDA en 2003 afin de combler la distance existant entre les experts du domaine thématique et les experts de la conception et de la construction de l’application [Miller et Mukerji, 2003]. Le modèle CIM est destiné à décrire les exigences des acteurs du domaine. Une caractéristique importante du modèle CIM est que le vocabulaire familier des acteurs du domaine est utilisé pour sa spécification [Miller et Mukerji, 2003]. En outre, il est explicitement mentionné dans ce guide que ce modèle est utile, non seulement comme aide à la compréhension du problème, mais aussi comme source de vocabulaire partagé à utiliser dans d’autres modèles. Dans la communauté des bases de données, le dictionnaire de données joue partiellement le rôle de source de vocabulaire du modèle CIM.
Méthode eXtreme Programming (XP)
La méthode eXtreme Programming a été conçue par Kent Beck[Beck et Andres, 2004], Ward Cunningham et Ron Jeffries, tous trois experts en développement logiciel. La phase du développement est au cœur du projet. Cette méthode est fondée d’une part, sur une implication forte des utilisateurs et, d’autre part, sur la mise en œuvre systématique de tests implémentés assurant la qualité du code remanié par les développeurs. De ce fait, elle facilite la maintenance du code mais aussi son évolution pour répondre à de nouveaux besoins. La factorisation des codes sources est présente tout au long du développement et l’utilisation de patrons (des méthodes recettes) mais aussi de frameworks est très importante. Elle prône la programmation en binôme avec une conception modulaire. Ainsi, la livraison se fait au fur et à mesure de l’état d’avancement afin d’avoir des retours par l’utilisateur final. La communication constante avec l’utilisateur, la simplicité du développement et le retour d’information constituent ses principaux atouts par rapport aux méthodes traditionnelles.
Indicateurs de qualité et de complexité d’un modèle
L’évolution d’un logiciel ou d’un système d’information peut se produire à des intervalles de temps aléatoire, générant de nouveaux cycles. Les travaux de recherche dans le domaine de l’évolution du logiciel sont principalement focalisés sur la minimisation des effets indésirables induits par un changement. D’après [carpers Jones, 1991], l’obtention des mesures tôt dans le cycle de vie et la continuité de cette capture de mesures sont fondamentales. La mesure est essentielle pour l’analyse de l’évolution afin d’avoir une vision descriptive et globale du système d’information à tout instant et plus précisément dans le domaine de l’ingénierie [Zuse, 1998]. Une mesure (ou métrique) n’a de sens que si elle est accompagnée d’un attribut [Fenton et Pfleeger, 1991]. En général, ces métriques seront séparées en deux groupes : les métriques quantitatives et les métriques qualitatives. Les métriques quantitatives peuvent être mesurées automatiquement sur le modèle restructuré. Par contre, les métriques qualitatives nécessitent l’intervention d’un ou plusieurs experts.Une classification des métriques, proposée par [Fenton et Pfleeger, 1991], est largement partagée dans le domaine de logiciel. Elle distingue trois types de mesure :
1. les métriques de processus sont liées aux activités.
2. les métriques de produits concernent les artefacts créés et modifiés.
3. les métriques de ressources mesurent les ressources nécessaires à chacune des activités du processus de développement. Dans la littérature, nous observons que certaines métriques appartiennent à plusieurs de ces catégories. Néanmoins, elles participent à toutes les phases de développement de logiciel. En d’autres termes, elles mesurent l’évolution du logiciel en se concentrant sur sa fiabilité et sa capacité à répondre aux besoins définis par l’utilisateur [Fenton et Neil, 1999]. Actuellement, de plus en plus de résultats de recherche sur des mesures sur des diagrammes de classes sont rapportés dans la littérature. Ces mesures ont pour but d’étudier les caractéristiques des diagrammes de manière systématique. Avec [Yi et al., 2004], l’analyse et la comparaison des mesures classiques sur les diagrammes de classes UML reflètent les différents types de relations existants, la complexité mais aussi la validation théorique et empirique de ces modèles. Ces auteurs définissent aussi les avantages et inconvénients de ces métriques ainsi que les problèmes existants.
|
Table des matières
1 Introduction
1.1 Contexte
1.2 Problématique et Objectif
1.2.1 Problématique à résoudre
1.2.2 Objectif et Approches mises en œuvre
1.3 Motivations personnelles et institutionnelles
1.4 Organisation du rapport de thèse
I Étude Bibliographique
2 Factorisation et Évolution de modèles
2.1 Introduction
2.2 Contexte : les modèles dans le cycle de vie d’un système d’information
2.2.1 Ingénierie dirigée par les modèles
2.2.2 IDM et MDA
2.2.3 Cycles de vie d’un système d’information
2.2.3.1 Les phases d’un cycle de développement
2.2.3.2 Cycle en cascade, cycle en V et en W
2.2.3.3 Cycle en spirale
2.2.3.4 Méthode Rapid Application Development (RAD)
2.2.3.5 Méthodes Agiles
2.2.3.6 Méthodes spécifiques
2.3 Indicateurs de qualité et de complexité d’un modèle
2.3.1 Métriques sur la qualité des modèles
2.3.2 Métriques sur la complexité et l’abstraction
2.3.3 Métriques sur l’analyse de l’évolution
2.3.4 Métriques sur les bases de données
2.3.5 Métriques quantitatives et qualificatives basées sur l’AFC et l’ARC
2.4 Conclusion
3 Analyse Formelle de Concepts et Analyse Relationnelle de Concepts
3.1 Introduction
3.2 L’Analyse Formelle de Concepts
3.3 Analyse Relationnelle de Concepts
3.4 Description des formes normales
3.5 Application de l’AFC et l’ARC dans le domaine du génie logiciel
3.5.1 Différentes applications de l’AFC et l’ARC en Génie Logiciel
3.5.2 Utilisation de l’AFC et de l’ARC pour la restructuration de modèles de classes
3.5.3 Expérimentations menées dans le cadre de l’application de FCA/RCA pour la factorisation de modèles de classes
3.5.3.1 Expérimentations sur un modèle de classes de France Télécom (Orange)
3.5.3.2 Expérimentation sur un modèle de classe de la société JETSGO
3.5.3.3 Expérimentations pour des modèles UML2 et EMF
3.5.3.4 Expérimentations sur plusieurs configurations de FCA/RCA sur un modèle de classes de l’open-source Java Salomé-TMF
3.6 Conclusion
II Contexte expérimental : Cas d’Étude
4 Cas d’Étude :Projets applicatifs et outils
4.1 Introduction
4.2 Projets applicatifs
4.2.1 Projet SIE-Pesticides
4.2.2 Projet SI-GPE
4.3 Eléments de modélisation intervenant dans l’AFC et l’ARC
4.3.1 Relations retenues pour l’Analyse Formelle de Concepts (AFC)
4.3.1.1 Description des éléments de modélisation
4.3.1.2 Relation R1
4.3.1.3 Relation R2
4.3.1.4 Relation R3
4.3.1.5 Relation R4
4.3.1.6 Relation R5
4.3.2 Configurations retenues pour l’Analyse Relationnelle de Concepts (ARC)
4.3.2.1 Configuration C1
4.3.2.2 Configuration C2
4.3.2.3 La notion de la navigabilité
4.4 Aspects techniques et outils utilisés
4.4.1 L’atelier de génie logiciel Objecteering
4.4.2 Le Plugin ERCA : Eclipse’s Relational Concept Analysis
4.4.3 Caractéristique du cluster utilisé pour les expérimentations
III Contributions de la thèse :Analyse de l’évolution de modèle UML
Étude comportementale de l’ARC
Factorisation Inter-modèle
5 Analyse de l’évolution de modèles UML
5.1 Introduction
5.1.1 Rappel sur l’origine du modèle SIE-Pesticides
5.1.2 Historique des versions du modèle SIE-Pesticides
5.1.3 Présentation de la problématique
5.2 Analyse de l’évolution basée sur des métriques portant sur le modèle
5.2.1 Métriques basées sur le nombre d’éléments de modélisation
5.2.1.1 Évolution du nombre de classes (#Classes)
5.2.1.2 Évolution du nombre d’attributs (#Attributs)
5.2.1.3 Évolution du nombre d’opérations (#Opérations)
5.2.1.4 Évolution du nombre d’associations (#Associations)
5.2.1.5 Évolution du nombre de rôles (#Rôles)
5.2.2 Métriques basées sur le rapport entre éléments de modélisation
5.2.2.1 Évolution du rapport classes / éléments de modélisation (#Classes/ #Éléments du Modèle)
5.2.2.2 Évolution du rapport attributs / classes (#Attributs / #Classes)
5.2.2.3 Évolution du rapport associations / classes (#Associations /#Classes)
5.3 Analyse de l’évolution basée sur des métriques issues de l’Analyse Formelle de Concepts
5.3.1 Description des expérimentations
5.3.2 Quantification de l’évolution des éléments de modélisation
5.3.3 Vers une méthode d’analyse de l’évolution d’un modèle
5.4 Analyse de l’évolution basée sur des métriques issues de l’Analyse Relationnelle de Concepts
5.4.1 Description des paramètres de factorisation
5.4.2 Analyse de l’évolution basée sur des métriques issues du treillis
5.4.2.1 Métriques sur les classes
5.4.2.2 Métriques sur les attributs
5.4.2.3 Métriques sur les associations
5.4.2.4 Métriques sur les opérations et les rôles
5.5 Conclusion
5.5.1 Analyse de l’évolution sur les métriques entre éléments de modélisation
5.5.2 Analyse de l’évolution basée sur l’Analyse Formelle de Concepts et l’Analyse Relationnelle de Concepts
6 Étude comportementale de l’Analyse Relationnelle de Concepts sur des modèles UML
6.1 Introduction
6.2 Démarche suivie et paramètres d’analyse
6.2.1 Description de la démarche suivie
6.2.2 Paramètres choisis
6.2.3 Récapitulatif des exécutions
6.3 L’impact des paramètres
6.3.1 Le nommage des éléments de modélisation
6.3.2 L’impact du sens de la navigabilité des associations
6.3.3 Discussion et recommandation
6.4 Mesure de la complexité pratique
6.4.1 Temps d’exécution
6.4.2 Espace mémoire utilisé
6.5 Métriques sur la complexité du modèle
6.5.1 Description de la structure des modèles par des graphes
6.5.2 Métriques basées sur les graphes
6.5.2.1 Métrique sur l’évolution de nombre d’arcs et de sommets du graphe
6.5.2.2 La densité du graphe
6.5.2.3 Le nombre d’étapes dans le pire des cas
6.5.2.4 Degré des sommets du graphe
6.6 Conclusion
7 Factorisation inter-modèles
Introduction de la notion et construction du Plus Grand Modèle Commun
7.1 Introduction
7.2 Description des deux modèles Station de mesure utilisés pour l’explication
7.3 L’approche basée sur la factorisation inter-modèles
7.3.1 Définitions dans le contexte de la factorisation inter-modèles
7.3.2 L’objectif de la factorisation inter-modèles
7.3.3 Treillis utilisés
7.4 Processus d’extraction du Plus Grand Modèle Commun
7.4.1 Application de l’Analyse Formelle de concepts sur les modèles (M1 et M2 )
7.4.2 Analyse des treillis
7.4.2.1 Analyse des concepts fusion
7.4.2.2 Analyse des nouveaux concepts : nouvelles abstractions créées
7.4.2.3 Analyse des concepts immuables ou pérennes
7.5 Démarche suivie et mise en œuvre
7.6 Analyse des résultats obtenus
7.7 Travaux connexes
7.8 Conclusion
IV Conclusion et Perspectives
8 Conclusion générale
9 Perspectives
9.1 Introduction
9.2 Perspectives sur l’analyse de l’évolution
9.2.1 La contextualisation de concepts
9.2.2 Concepts Parents, Ascendants, Fils et Descendants
9.3 Perspectives sur la factorisation inter-modèles avec l’Analyse Relationnelle de Concepts
9.4 Perspectives sur l’étude des relations lexicales : Rapprochement sémantique de concepts
9.5 Perspectives sur le processus global d’une factorisation maximale
9.5.1 La traçabilité des concepts
9.5.2 Définition d’un processus de construction
A Annexe
A.1 Table de contexte formel correspondant à la description des classes par les attributs et les rôles (voir section 4.3.1.5)
A.2 Table de contexte formel correspondant à la description des classes par les attributs, les opérations et les rôles (voir section 4.3.1.6)
A.3 Algorithme de Calcul du Plus Long Chemin
A.4 Le plus long chemin dans le graphe de configuration C2 sans la navigabilité
A.5 Le degré de chaque sommet du graphe de configuration C2 sans la navigabilité
A.6 Treillis des rôles de la configuration C2 sans la navigabilité
A.7 Pseudo-code de métrique
A.8 Dimensionnement de la structure sous-jacente de la factorisation d’un modèle de classe : leçons tirées du modèle de classe d’un système d’information
Index
Bibliographie
Table des figures
Liste des tableaux
Listings
Télécharger le rapport complet
