Soutenance mémoire
Améliorer la capitalisation des connaissances
Améliorer la capitalisation des connaissances peut prendre plusieurs formes. L’une d’elles et non la moindre consiste à assurer une meilleure pérennité du personnel impliqué dans le développement des applications. Cette forme de capitalisation n’est pas l’objet de la recherche car elle ne présente aucun aspect « technique ». Nous nous intéresserons ici à la capitalisation de connaissances contenues dans les modèles ou les codes. Cette typologie de capitalisation est une préoccupation qui date depuis fort long mais, ces dernières années, elle a pris de l’ampleur avec l’idée préconisée par l’OMG de séparer des spécifications thématiques et d’implémentation au sein de deux types de modèles. Cette idée prône de faire un premier modèle, que nous qualifierons pour l’instant de thématique, contenant tous les concepts thématiques et de réaliser un second modèle, que nous qualifierons pour l’instant d’implémentation, où les concepts thématiques sont complétés avec les concepts et les spécifications d’implémentation liées à un langage de programmation ou à une plate-forme matérielle. C’est ce second modèle qui va permettre de générer le binaire de l’application. La vision de l’OMG est que le modèle thématique et le modèle d’implémentation ne sont pas indépendants et qu’il est possible d’établir un couplage entre eux au moyens de transformations de modèles. Selon l’OMG, ces dernières doivent permettre de transférer les concepts contenus dans un modèle thématique vers le modèle d’implémentation. Cette approche est connue sous le nom de Model Driven Architecture (Miller et al., 2001, 2003). Actuellement, une part importante des moyens de recherche en informatique est consacrée à l’étude de ces transformations de modèles. Un des avantages majeurs de l’approche Model Driven Architecture (MDA) est qu’un modèle ne contenant que des concepts thématiques peut être remobilisé à tout moment au cours du développement d’une application mais aussi au cours de cycle de vie de l’application. Au cours du développement, les concepts thématiques étant indépendants du type d’application visé (application monoposte, application répartie avec son système d’information, etc.), ils peuvent être mobilisés dans plusieurs types d’implémentation. Au cours du cycle de vie de l’application, ces concepts thématiques constituent le capital de base résultant de l’analyse du système qui va permettre de réaliser une nouvelle version de l’application. À cette occasion, de nouvelles technologies informatiques peuvent être mises en œuvre sans problème majeur car elles n’affectent pas le modèle thématique. Nous envisageons dans la présente recherche de multiplier le nombre de modèles afin d’avoir une capitalisation plus fine des connaissances qui ne soit pas liée qu’aux seuls aspects techniques comme le préconise les informaticiens dans l’utilisation de l’approche Model Driven Architecture et les exemples qu’ils utilisent pour présenter ou enseigner cette approche. Actuellement, il n’existe pas d’approche fondée sur ce principe car la principale difficulté est de maintenir en cohérence plusieurs modèles. En effet, s’ils sont séparés, le coût pour maintenir en cohérence plusieurs modèles séparés est exorbitant et irréalisable dans un secteur économique hautement concurrentiel comme celui de l’informatique. Cela n’est possible que si le maintien en cohérence est totalement automatisé. C’est l’objet de la présente recherche
LE LANGAGE PICTOGRAMMIQUE DE L’ATELIER DE GENIE LOGICIEL PERCEPTORY
Nous ne nous attarderons pas ici sur le langage pictogrammique déployé par l’équipe d’Yvan Bédard dans l’atelier de génie logiciel Perceptory puisque les langages SIG et pictogrammique du Chapitre 7 en sont issus. Ces langages résultent d’une accumulation d’expérience longue de plus de seize ans (Bédard et al., 2004) puisque les travaux de cette équipe ont été les premiers du genre et ont fortement influencé la plupart des méthodes et des formalismes créés par la suite. Cette influence a porté aussi bien sur la sémantique des concepts de spatialité et de temporalité que sur les pictogrammes utilisés pour annoter les concepts thématiques. Ils font suite aux travaux de recherche en modélisation de bases de données spatio-temporelles (Bédard et al., 1989) qui ont permis de concevoir le formalisme MODUL-R (Bédard et al., 1992 ; Bédard et al., 1996 ; Caron,1991) comme une extension au formalisme Entité/Relation (Chen, 1976) pour renseigner la spatialité et/ou la temporalité des entités référencées. Le formalisme MODUL-R a été implémenté dans Orion, premier atelier de génie logiciel incluant les pictogrammes spatiaux et la génération de code automatique (Bédard et al., 2004). MODUL-R et Orion préfiguraient le langage pictogrammique et l’atelier de génie logiciel Perceptory. Après quelques années d’utilisation de MODUL-R et d’Orion dans différents projets de conception et de développement de bases de données spatio-temporelles, cette équipe a ressentie le besoin d’améliorer le langage pictogrammique. Aussi, en 1996-1997 un langage pictogrammique étendu a été implémenté dans la première version de l’atelier de génie logiciel Perceptory (Bédard et al., 2004). À cette occasion le formalisme Entité/Relation a été abandonné au profit du formalisme objet et du langage UML. Dans sa version actuelle, Perceptory est un plug-in implémenté dans la plate-forme Visio. Toutefois, il est en cours de redéveloppement en Java et sera intégré dans l’atelier de génie logiciel ArgoUML (ArgoUML, Site Web non daté) qui est un logiciel sous licence libre. L’utilisation de Perceptory sera alors totalement gratuite. Dans la version Java, le langage pictogrammique devrait être étendu à la représentation des spatialités dans un espace 3D puisque plusieurs publications (Bédard et al., 2004 ; Larrivée et al., 2005, 2006)) sont issues de cette équipe. Perceptory a été conçu comme une alternative aux ateliers de génie logiciels professionnels car de nombreuses études montrent que ces derniers sont souvent utilisés comme outil de dessin et que la génération de code est peu exploitée. C’est ce constat qui a amené à n’implémenter dans Perceptory que les principaux concepts UML du diagramme de classes (paquetage, classe, attribut, association, généralisation/spécialisation et notes). Perceptory permet de générer le code SQL pour le SGBDR Oracle. Dans son processus interne, Perceptory interprète l’information représentée par les pictogrammes pour générer le code SQL correspondant. De ce fait, la gestion des relations entre concepts SIG est déléguée au SGBDR cible, Oracle dans le cas présent. Perceptory utilise donc virtuellement le schéma d’Oracle. Cet outil simple mais opérationnel donne entière satisfaction pour la modélisation des bases de données. Sur ce créneau, il a les qualités d’un produit industriel. Perceptory peut être mis en œuvre depuis la phase d’analyse jusqu’à la génération de code SQL permettant ainsi de créer des bases de données spatiales et spatio-temporelles. L’atelier de génie logiciel Perceptory est téléchargeable gratuitement sur le site (Bédard, 1998). Bien que téléchargé par les utilisateurs de plus de quarante pays (Bédard et al., 2004), la majorité d’entre eux réside dans les pays du G7. Une documentation et des tutoriaux facilitent la prise en main de cet atelier. Le cadrage stratégique de Perceptory en fait un outil de modélisation particulièrement adapté à un public peu enclin à investir lourdement dans l’appropriation de langage UML et/ou des utilisateurs disposant de moyens financiers limités.
CONGOO (CONception Géographique Orientée Objet)
Le formalisme CONGOO est issu des travaux de (Pantazis et al., 1996 ; Pantazis et al., 1997). C’est un formalisme mis en œuvre dans le cadre de la méthode de conduite de projet MECOSIG13 (Pantazis et al., 1996) qui propose une démarche au concepteur d’un Système d’Information Géographique pour réaliser son application. Ce formalisme distingue trois catégories d’objets géographiques : les objets géographiques simples (OGS), composés (OGC) et complexes (OGX). La première catégorie est composée des entités référencées annotées des concepts de spatialité primitive de nature discrète Point, Ligne et Polygone auxquels il faut ajouter le concept de Surface dont la nature est continue. Le langage SIG défini au Chapitre 7 ne permet pas de modéliser les concepts de spatialité ou de la temporalité de nature continue. La deuxième catégorie inclut d’une part, les objets géographiques homogènes (OGCH) qui correspondent aux entités référencées à multi-spatialité (cf. Chapitre 7-IV.4) et, d’autre part, les objets géographiques composés non homogènes (OGCNH) qui sont les macro-entités référencées d’agrégation (cf. Chapitre 7-IV.3). La troisième catégorie inclut les objets géographiques complexes qui, comme pour la deuxième catégorie, distingue ceux qui sont homogènes (OGXH) de ceux qui sont non homogènes (OGXNH). Les premiers sont les entités référencées à spatialité multiple (cf. Chapitre 7-IV.2.1.1) et les seconds sont des entités macro-entités référencées d’agrégation composées d’entités référencées à spatialité multiple. Le formalisme CONGOO ne permet pas d’exprimer la spatialité alternative. Une limite forte du formalisme CONGOO est qu’il ne s’intéresse qu’aux propriétés spatiales des entités référencées. De ce fait, la temporalité et les combinaisons de spatialité et de temporalité ne peuvent pas être exprimées avec ce formalisme. Les spatialités dérivées et temporalités dérivées n’existent pas dans ce formalisme.
Méthode Processus Unifié (UP) (Extrait de l’Annexe II-II)
Les idées qui donneront naissance à la méthode de conduite Processus Unifié datent de la fin des années soixante alors qu’Ivar Jacobson travaillé chez Ericsson (Jacobson, 2003). La méthode Processus Unifié est la synthèse des meilleures pratiques de développement logiciel sur trois décennies dans des domaines variés (Jacobson et al., 1999). Bien qu’elle soit totalement dissociée du langage UML (Fowler, 2004b ; Millan et al., 2004), elle est adossée à ce langage de modélisation car les auteurs d’UML, Grady Booch, Ivar Jacobson et James Rumbaugh, ont participé à sa formalisation. La méthode Processus Unifié repose sur quatre principes suivants : le processus de développement doit être conduit par les cas d’utilisation, itératif et incrémental, centré sur l’architecture et piloté par les risques (Larman, 2002b ; Muller et al., 2000 ; Roques et al., 2002). Le principe du développement conduit par les cas d’utilisation va permettre de recentrer à tout moment le développement d’une application sur les besoins des acteurs. Le but de tout projet informatique est de reproduire le comportement d’un système afin de satisfaire un besoin. Pour ce faire, il faut d’une part, capturer la connaissance qu’ont les acteurs du système et, d’autre part, identifier les besoins et les exigences des acteurs. Les cas d’utilisation sont l’objet technique qui permet de représenter le comportement du futur système, ce que doit faire le système mais aussi qui et quoi interfèrent avec le système. De ce fait, une fois implémenté, un cas d’utilisation répond aux besoins des acteurs. Si ce n’est pas le cas, c’est qu’il a mal été défini. Les cas d’utilisation doivent donc être décrits au début du projet et tout développement doit être « au service » du fonctionnement et/ou des exigences exprimés dans le cas d’utilisation. Il devient alors un outil de planification. Le principe du développement itératif et incrémental est sans aucun doute le plus important (Larman, 2002a; Roques, 2002). Le qualificatif d’itératif s’applique à la gestion d’une succession de versions exécutables (Booch et al., 2000 ; Muller et al., 2000) alors que celui d’incrémental porte sur l’évolution du modèle. Les nouveaux concepts et les nouvelles spécifications ajoutées dans le modèle au cours de l’itération constituent l’incrément. Un incrément est donc la différence entre l’état du modèle en début d’itération et en fin d’itération (Roques et al., 2002). Selon (Jacobson et al., 1999), le résultat d’une itération est un incrément. La méthode de conduite de projet Processus Unifié prévoit que le développement d’une application soit découpé en itérations de courte durée, 2 à 4 semaines. A chaque itération, les spécifications sont validées par les acteurs (Roques et al., 2002) et un sous-système exécutable est produit. De ce fait, le processus itératif est le meilleur garant d’une part, pour produire un exécutable conforme aux spécifications et aux exigences des acteurs améliorant de fait la qualité du produit final et, d’autre part, pour permettre de suivre l’avancement du projet (Bénard, 2002b), le contrôle des coûts et des délais (Roques et al., 2002). Le processus de développement itératif et incrémentale facilite la capitalisation des connaissances du domaine parce qu’il est toujours possible d’ajouter des concepts nouveaux ou bien oubliés par un acteur lors d’une itération précédente. D’autre part, ce type de processus permet de « mixer » les connaissances d’acteurs ayant des points de vue différents sur le même concept (Booch et al., 2000). Il permet aussi la capitalisation des enseignements des cycles précédents (Bénard, 2002b). Le principe du développement centré sur l’architecture a été introduit par les auteurs de la méthode afin de souligner l’importance du travail de structuration de l’application en systèmes et sous-systèmes que doit impérativement faire le concepteur. La structuration d’une application est nécessaire pour les quatre raisons suivantes (Jacobson et al., 1999) :
-Compréhension du système : souvent, un acteur n’a qu’une connaissance partielle du système et c’est l’assemblage de ces connaissances partielles qui permet de reconstituer la totalité du système.
-Organisation du développement : pour les projets d’une certaine taille, l’application est décomposée afin de pouvoir répartir la charge de développement.
-Réutilisation de composants existants : pour une entreprise, le développement doit être réalisé dans les meilleurs délais et à moindre coût. Cette contrainte conduit tout naturellement à réutiliser les composants logiciels réalisés au cours de projets antérieurs.
-Évolution du système : dans une application bien structurée, la correction de bogues ou la réalisation d’une nouvelle version sera plus facile que dans une application non structurée. Selon (Roques, 2002 ; Roques et al., 2002), la structuration en sous-systèmes ne doit pas être une simple description du système sous forme graphique ou textuelle mais elle doit être matérialisée. Cette exigence introduit par Pascal Roques impose l’utilisation un atelier de génie logiciel lors de la modélisation. Le principe du développement piloté par les risques a été adopté car ces derniers peuvent mettre en difficulté un projet voire le faire échouer (Jacobson et al., 1999). Le pilotage par les risques du développement d’une application permet de prendre en compte des problèmes très tôt voire à leur origine et de les traiter par anticipation. Il existe plusieurs catégories de risques mais les risques les plus importants sont d’une part, les risques financiers et les risques commerciaux (Muller et al., 2000) et, d’autre part, les risques non techniques et des risques techniques (Jacobson et al., 1999). Concernant les risques financiers, la question fondamentale est de s’assurer que le commanditaire de l’application a les moyens financiers pour mener à terme la réalisation de l’application.
Introduction de la notion de traçabilité : L’architecture de traçabilité
Un premier type d’incohérence est induit par la nature multimodèle du Software Development Process Model. Un concept c saisi dans le sous-modèle d’analyse et diffusé jusqu’aux sous-modèles d’implémentation va exister en autant d’exemplaires que de sous-modèles. Or pour que le Software Development Process Model reste en cohérence, il faut que chaque concept source et ses clones soient eux mêmes en cohérence entre sous-modèles mais aussi tout au long du processus de développement. Cette exigence doit être respectée en particulier à l’occasion des activités de modifications (correction d’une faute d’orthographe par exemple) qui sont naturellement effectuées sur n’importe quel sousmodèles. Pour résoudre ce problème, nous avons mobilisé la notion de traçabilité. De façon générale, la traçabilité est une préoccupation récurrente en processus de développement et en modélisation (Desfray, 2001 ; D’Souza et al.,1998 ; Jacobson et al., 1999). Dans un processus de développement sous-tendu par l’approche MDA, Philippe Desfray estime que d’une part, la gestion de la traçabilité est absolument essentielle dans la démarche MDA pour assurer la cohérence entre les modèles et, d’autre part, que si cette gestion n’est pas effectuée automatiquement, les modèles deviennent inévitablement incohérents. Fort de ces recommandations, nous avons généralisé l’utilisation de la traçabilité et nous l’avons automatisée. Nous avons décidé de relier un concept source à son clone par un lien physique, désigné Lien de Traçabilité de Clonage, et ce d’une part, pour tous les concepts et, d’autre part, depuis le sous-modèle d’analyse jusqu’au(x) sous-modèle(s) d’implémentation. L’ensemble de ces liens constitue l’Architecture de Traçabilité de Clonage, architecture qui est indépendante et orthogonale à celle du Software Development Process Model. Un lien de traçabilité relie le concept Parcel du sous-modèle d’analyse à son clone du sous-modèle de conception préliminaire, un autre est établi entre la classe Parcel du sous-modèle de conception préliminaire et son clone du sous-modèle de conception avancée, etc. Il en est de même pour le concept Farm et l’association Use. L’architecture de traçabilité de clonage peut être assimilée à un écheveau dont chaque fil d’Ariane constitue une lignée de clonage entre le concept source et ses clones successifs permettant ainsi d’identifier sans ambiguïté une lignée de clonage dans le dédale des concepts présents dans le Software Development Process Model. Les liens de traçabilité assurent ainsi un accès direct aux clones et une navigation rapide entre sousmodèles. Le principe de créer des lignées de clonage étant acquis et défini, restait à automatiser sa gestion conformément aux recommandations de Philippe Desfray. Devant être appliquée à tout concept d’un sousmodèle source pour créer leurs clones dans le sous-modèle destination, la Transformation de diffusion était toute indiquée pour assurer la gestion du lien de traçabilité de clonage entre un concept source et son clone.
|
Table des matières
Introduction
I Contexte
II Problématique
III Solution proposée
IV Objectif de la recherche
V Cadre informatique de la recherche
VI Processus de recherche mis en œuvre
VII Démarche et Structure de la thèse
Avertissements
Partie A – Étude Bibliographique
Chapitre 1. Étude bibliographie autour des méthodes et formalismes pour la conception des systèmes d’information géographique : Comparaison avec le Métamodèle SIG
I Généralités et spécificités du domaine l’information géographique
II Définitions générales
III Le langage pictogrammique de l’atelier de génie logiciel Perceptory
IV Concepts SIG mis en œuvre par différents formalismes et méthodes de modélisation de système d’information géographique
V Conclusion
Chapitre 2. Étude bibliographique autour de l’approche Model-Driven Architecture et des méthodes de conduite de projet
I Approche Model Driven Architecture (MDA™)
II Méthodes de conduite de projet : Panorama succinct
III Conclusion
Partie B – Contribution à la généralisation de l’approche Model-Driven Architecture : Software Development Process Approach
Chapitre 3. Définitions et descriptions de la méthode Continuous Integration Unified Process, de l’approche Software Development Process Approach et de l’artefact Software Development Process Model
I Visions sur le développement d’une application
II Méthode de conduite de projet Continuous Integration Unified Process : Idées fondatrices et définition
III Software development process approach : Principe fondateur et définition générale
IV Software development process model destiné à la méthode Continuous Integration Unified Process
V Gestion de l’architecture multimodèle du Software development process model : Principe de la transformation de diffusion
VI Conclusion
Chapitre 4. Concepts UML supports des concepts SIG et des entités référencées – Concepts SIG implémentés dans le Profil UML-SIG – Incidence sur les langages SIG et pictogrammique
I Concepts UML supports des entités référencées dans le Profil UML-SIG
II Contraintes imposées par l’atelier de génie logiciel
III Règle de construction des noms des concepts SIG composites de bi-spatialité
IV Langage SIG du Profil UML-SIG : Différences avec Perceptory
V Langage pictogrammique du Profil UML-SIG : Différences avec Perceptory
VI Conclusion
Chapitre 5. Conception des transformations de l’artefact Software Development Process Model
I Les principes qui ont présidé notre démarche de conception des transformations
II Transformations de gestion de l’artefact Software Development Process Model
III Transformations géomatiques
IV Transformations SQL
V Conclusion
Chapitre 6. Implémentation de l’artefact Software Development Process Model et des transformations de diffusion de concepts, géomatiques et SQL
I Réification de l’artefact Software Development Process Model dans l’atelier de génie logiciel Objecteering
II Transformations de gestion de l’artefact Software Development Process Model
III Transformations géomatiques
IV Transformations SQL
V Conclusion
Partie C – Contribution à la Modélisation des Systèmes d’Information Géographique
Chapitre 7. Dérivation d’un Métamodèle SIG de l’étude terminologique des propriétés spatiales et temporelles – Mise en œuvre de la Théorie des ensembles
I Conventions de notation
II Spatialité et temporalité : Définitions générales
III Spatialité primitive et temporalité primitive
IV Spatialité composite et temporalité composite
V Spatialité dérivée et temporalité dérivée
VI Spatialité inconnue et temporalité inconnue
VII Dérivation d’un métamodèle à partir des 3 taxinomies
VIII Améliorations du processus de modélisation grâce aux spatialités et temporalités dérivées, inconnues, compliquées et multiformes
IX Conclusion
Chapitre 8. Concepts de spatialité floue et de temporalité floue – Extension du Métamodèle SIG
I La problématique
II Spatialité primitive floue et de temporalité primitive floue
III Incidence sur le Métamodèle SIG
IV Définition d’un patron de conception entre concepts SIG primitifs flous et non flous
V Application de la spatialité floue et de la temporalité floue aux exemples de présentation de la problématique
VI Conclusion
Conclusion Générale
I Contribution géomatique : Dérivation d’un Métamodèle SIG et d’un Patron de conception SIG
II Contribution en ingénierie des modèles
Perspectives
III À court terme
IV À moyen terme : Thèse sur la Factorisation de modèles
Principe structurant la recherche
Références bibliographiques
Glossaire
Acronymes
Annexe I. Rappels sur le Langage UML
I Le Langage UML
II Historique d’UML
III Les concepts UML et leurs annotations
IV Les Diagrammes UML
V Conclusion
Annexe II. Description plus détaillée des méthodes Rapid Application Development, Processus Unifié et eXtreme Programming
I Rapid Application Development (RAD)
II La méthode de Conduite de Projet Processus Unifié (UP)
III eXtreme Programming (XP)
Annexe III. Rappels sur les Langages, les Langages Naturels et la Théorie des Langages
I Concepts de Langue et de Langage en Contexte Général
II Langue Naturelle et Langage Naturel
III Concept de Langage en Contexte Informatique : Théorie des Langages
IV En Résumé
Annexe IV. Dualité entre les concepts UML d’attribut et d’association
I Concepts UML d’attribut et d’association : Différence conceptuelle ?
II Transformation d’un attribut en association
III Transformation d’une association en attribut
IV Conclusion
Annexe V. Description succincte du générateur de code SQLDesigner de l’atelier de génie logiciel Objecteering
I Les étapes de la génération de code SQL
II Spécifications SQL majeures
III Inconvénients induits par la transformation AM PM T →
IV En résumé
Annexe VI. Fondements théoriques sur le prototypage
I Prototypage évolutif
II Prototypage jetable
III Maquettag
Télécharger le rapport complet
