méthode Continuous Integration Unified
Process, de l’approche Software
Development Process Approach et de
l’artefact Software Development Process
Model
Ce chapitre présente la démarche intellectuelle d’élaboration des nouveaux concepts qui a permis d’atteindre l’objectif général de réaliser un outil d’aide à la conception de Systèmes d’Information Géographique adapté à un processus de développement permettant le prototypage rapide en séance d’analyse assurant la capitalisation des connaissances (cf. Introduction-IV).
Ces nouveaux concepts sont une méthode de conduite de projet dérivée de la méthode Processus Unifié, désignée Continuous Integration Unified Process, une généralisation de l’approche MDA que nous avons appelée Software Development Process Approach et un artefact34 multimodèle que nous avons nommé Software Development Process Model
Avant d’introduire ces trois concepts, nous précisons, dans le paragraphe I, notre vision de deux « ingrédients » importants du développement d’une application : le processus et les modèles.
Le paragraphe II introduit les raisons qui ont conduit à proposer et à définir la nouvelle méthode de développement : Continuous Integration Unified Process.
Le paragraphe III identifie la capitalisation des connaissances qui sous-tend l’approche MDA comme étant la principale préoccupation. Or c’est une préoccupation qui se pose tout au long du cycle de développement ce qui a amené à proposer et à définir l’approche Software Development Process Approach, nouvelle approche qui généralise l’approche MDA.
Le paragraphe IV détaille et définit l’artefact multimodèle, nommé Software Development Process Model, qui réifie la nouvelle approche Software Development Process Approach adaptée à la méthode Continuous Integration Unified Process.
Pour atteindre l’objectif élémentaire de réaliser un outil d’aide à la conception, nous avons été conduits à concevoir d’une part, des mécanismes de transferts des concepts entre les modèles constituant le Software
Development Process Model et, d’autre part, une architecture assurant le maintien en cohérence de cet artefact multimodèle.
Le paragraphe V décrit les notions qu’il a été nécessaire de mobiliser pour cela. Il présente aussi le principe général de la diffusion des concepts entre modèles.
Sommaire détaillé
I Visions sur le développement d’une application... 62
I.1 Vision machine à états finis du processus de développement ... 62 I.2 Vision ensembliste des modèles impliqués dans un processus de développement ... 63II Méthode de conduite de projet Continuous Integration Unified Process : Idées
fondatrices et définition ... 64
III Software development process approach : Principe fondateur et définition générale
... 66
IV Software development process model destiné à la méthode Continuous Integration
Unified Process ... 68
IV.1 Définition d’un Software development process model spécifique à la méthode Continuous integration unified process... 68 IV.2 Définition et activités de chacun des sous-modèles... 68
V Gestion de l’architecture multimodèle du Software development process model :
Principe de la transformation de diffusion ... 71
V.1 Introduction de la notion de clonage ... 72 V.2 Introduction de la notion de traçabilité : L’architecture de traçabilité ... 72 V.3 Transformation de diffusion : Principe général ... 73
VI Conclusion ... 74
VI.1 Méthode Continuous Integration Unified Process... 74 VI.2 Software Development Process Approach et Software Development Process Model ... 74I
VISIONS SUR LE DEVELOPPEMENT D’UNE APPLICATION
I.1Vision machine à états finis
35du processus de développement
Qu’ils soient linéaires ou itératifs, tous les processus de développement possèdent une phase d’analyse, une phase de conception et une phase d’implémentation.
Au cours du développement, c’est le chef de projet ou la personne faisant36 office qui prend la décision de changer de phase. Lors de ces transitions, le modèle d’analyse devient modèle de conception et ensuite modèle d’implémentation. Ces changements s’effectuent toujours suivant la même séquence.
Le développement de l’application peut être vu comme une machine à états finis. Il peut donc être modélisé par un diagramme d’états (figures 34 et 35).
La transition d’un état à l’autre est le résultat de la décision du chef de projet de changer de phase de développement. En phases d’analyse et de conception, les activités au sein des états sont l’ajout, la modification et la suppression de concepts thématiques, de spécifications propres au domaine, etc. Le développement progressant, en phase d’implémentation mais aussi en phase de conception, les concepts et les spécifications introduits dans le modèle sont destinés à une plate-forme logicielle et/ou matérielle.
Dans un processus de développement linéaire, toutes les exigences des commanditaires étant traitées, le développement de l’application prend fin.
/ start Development
/ end Development
Linear Development Process
Design
do /add Modify Remove Thematic Specifications + add Modify Remove Implementation Specifications
/ start Design Phase
/ start Implementation Phase
Implementation
do /add Modify Remove Implementation Specifications
Analysis
do /add Modify Remove Actor Specifications / start Analysis Phase
/ start Development
/ end Development
Linear Development Process
Design
do /add Modify Remove Thematic Specifications + add Modify Remove Implementation Specifications
/ start Design Phase
/ start Implementation Phase
Implementation
do /add Modify Remove Implementation Specifications
Analysis
do /add Modify Remove Actor Specifications / start Analysis Phase
Linear Development Process Linear Development Process Linear Development Process
Design
do /add Modify Remove Thematic Specifications + add Modify Remove Implementation Specifications
/ start Design Phase
/ start Implementation Phase
Implementation
do /add Modify Remove Implementation Specifications
Analysis
do /add Modify Remove Actor Specifications / start Analysis Phase
Design
do /add Modify Remove Thematic Specifications + add Modify Remove Implementation Specifications
Design
do /add Modify Remove Thematic Specifications + add Modify Remove Implementation Specifications
Design Design
do /add Modify Remove Thematic Specifications + add Modify Remove Implementation Specifications
/ start Design Phase
/ start Implementation Phase
Implementation
do /add Modify Remove Implementation Specifications
Implementation
do /add Modify Remove Implementation Specifications
Implementation Implementation
do /add Modify Remove Implementation Specifications
Analysis
do /add Modify Remove Actor Specifications
/ start Analysis Phase Analysis
do /add Modify Remove Actor Specifications
Analysis
do /add Modify Remove Actor Specifications
Analysis Analysis
do /add Modify Remove Actor Specifications / start Analysis Phase
Figure 34Processus de développement linéaire.
Dans un processus de développement itératif, le chef de projet vérifie, en fin d’itération, s’il reste des sous- systèmes à implémenter et si toutes les exigences des commanditaires sont satisfaites. Dans l’affirmative, le développement s’arrête sinon une nouvelle itération est effectuée et un nouvel incrément de l’application est réalisé. Ce nouvel incrément peut être soit un sous-système qui est analysé, conçu et ensuite implémenté, soit des améliorations qui ont été différées lorsque le développement d’une application est en cours de finalisation.
En effet, le pilotage par les risques du processus de développement amène à traiter en priorité les risques majeurs, c’est-à-dire à approfondir la conception des sous-systèmes dont l’analyse a été la moins élaborée. L’adoption de ce principe amène tout naturellement à différer les améliorations d’une application en fin de développement.
35 Bien qu’il existe d’autres activités (planification de projet, gestion de personnel, etc.) associées à chacune des phases, dans ce chapitre
nous nous intéressons uniquement à celles relatives à l’action de modélisation.
Iterative Development Process
/ start Development
[isApplicationEnded=True] / end Development
Analysis
do /add Modify Remove Thematic Specifications
Design
do /add Modify Remove Thematic Specifications + add Modify Remove Implementation Specifications
/ start Design Phase
/ start Implementation Phase / start Analysis Phase
Implementation
do /add Modify Remove Implementation Specifications
[isApplicationEnded=False] / start Analysis Phase
Iterative Development Process Iterative Development Process Iterative Development Process
/ start Development
[isApplicationEnded=True] / end Development
Analysis
do /add Modify Remove Thematic Specifications
Design
do /add Modify Remove Thematic Specifications + add Modify Remove Implementation Specifications
/ start Design Phase
/ start Implementation Phase / start Analysis Phase
Implementation
do /add Modify Remove Implementation Specifications
Analysis
do /add Modify Remove Thematic Specifications
Analysis
do /add Modify Remove Thematic Specifications
Analysis Analysis
do /add Modify Remove Thematic Specifications
Design
do /add Modify Remove Thematic Specifications + add Modify Remove Implementation Specifications
Design
do /add Modify Remove Thematic Specifications + add Modify Remove Implementation Specifications
Design Design
do /add Modify Remove Thematic Specifications + add Modify Remove Implementation Specifications
/ start Design Phase
/ start Implementation Phase / start Analysis Phase
Implementation
do /add Modify Remove Implementation Specifications
Implementation
do /add Modify Remove Implementation Specifications
Implementation Implementation
do /add Modify Remove Implementation Specifications
[isApplicationEnded=False] / start Analysis Phase
Figure 35Processus de développement itératif.
Quel que soit le processus de développement, les activités de modélisation sont exercées préférentiellement au cours d’une des phases du processus de développement. Pour ces processus simplifiés, la phase de conception déroge à la règle puisque deux types d’activités de natures différentes sont réalisés.
I.2Vision ensembliste des modèles impliqués dans un processus de développement
En 1994, Philippe Desfray (Desfray, 1994) écrivait : Modelling is gradually decomposed from phase to phase by bringing in additional information. La figure 36 accompagnait ce texte pour illustrer l’augmentation du volume d’information contenu dans un modèle depuis l’analyse jusqu’à l’implémentation. Cette figure a un second intérêt, c’est l’organisation des ellipses.
Development
Design
Analysis
Design
Analysis
Analysis
Development
Design
Analysis
Development
Design
Analysis
Development
Development
Design
Analysis
Design
Design
Analysis
Design
Analysis
Design
Analysis
Design
Design
Analysis
Analysis
Analysis
Figure 36
Évolution de la taille du modèle au cours du développement (Desfray, 1994).
L’inclusion de l’ellipse d’analyse dans celle de conception, elle-même contenue dans celle de développement montre parfaitement qu’il existe une relation ensembliste :
Entre les états d’un mono-modèle37 au cours du cycle de développement. Entre les modèles successifs des phases d’un cycle de développement qui sont parfois archivés (vision multimodèle).Les ellipses de la figure 36 expriment que le modèle d’analyse est un sous-ensemble du modèle de conception, ce dernier étant lui-même un sous-ensemble du modèle d’implémentation ce qui s’écrit :
I D A
M
M
M
⊂⊂⊂⊂
⊂⊂⊂⊂
M
A : Modèle d’analyse DM
: Modèle de conception IM
: Modèle d’implémentation (Development)Quelque soit type de l’application, le développement suit toujours cette vision ensembliste puisque les concepts manipulés par les acteurs sont capturés lors de l’analyse et restent, exceptés ceux qui sont jugés inutiles par les acteurs, présents dans le modèle jusqu’à l’implémentation.
II
METHODE DE CONDUITE DE PROJET CONTINUOUS INTEGRATION UNIFIED
PROCESS :IDEES FONDATRICES ET DEFINITION
La méthode de conduite de projet Processus Unifié est un recueil des meilleures pratiques récentes de développement logiciel dans des domaines très variés (cf. Annexe II-II.1). Bien qu’indépendante du langage UML, cette méthode a été conçue par les pères d’UML et articulée avec ce langage.
Par ailleurs, de par la complexité de leur domaine de recherche lié à l’environnement, les scientifiques du Cemagref sont amenés à décrire et à modéliser des systèmes qui atteignent rapidement quelques dizaines voire quelques centaines de concepts.
Par exemple, le modèle du Système d’Information à Référence Spatiale des Digues permettant d’assurer la gestion patrimoniale de l’état des digues et historiques des travaux effectués comprend plus de cent cinquante classes. Dans ce contexte, le principe du développement centré sur l’architecture de la méthode Processus Unifié (cf. Chapitre 2-II.1.4), principe dont la méthode eXtreme Programming se désintéresse totalement, est très séduisant car il permet de structurer les concepts d’une application au sein de paquetages thématiques.
Il n’est pas rare aussi que dans des disciplines proches, deux concepts voisins mais ayant des différences portent le même nom. Par exemple, le concept de
Bief
d’un cours d’eau n’est pas du tout le même que leBief
d’une raie pour l’irrigation par gravité. Pourtant, ces deux concepts sont très voisins. Tous deux vont être utilisés par les hydrauliciens/numériciens pour décrire la géométrie et faire tourner des modèles de calculs hydrauliques à surface libre. Dans ce contexte, la structuration des concepts par discipline s’avère aussi être un plus.L’articulation de la méthode Processus Unifié avec le langage UML et les problèmes de structuration rencontrés par les scientifiques nous ont fait adopter la méthode de conduite de projet Processus Unifié.
De plus, le principe du développement centré sur l’architecture est très intéressant dans le cadre des travaux menés car il est alors possible de structurer les concepts du domaine SIG qui seront générés automatiquement.
L’objectif élémentaire de mettre en œuvre un outil d’aide à la conception de Systèmes d’Information Géographique dans un processus de développement permettant le prototypage rapide en séance d’analyse ne peut pas être atteint avec la méthode Processus Unifié car la durée d’une itération est de 2 à 4 semaines (cf. Chapitre 2-II.1.4) et qu’en outre les activités de modélisation à réaliser aux différentes phases sont souvent manuelles.
Fort de ce constat et dans l’objectif d’œuvrer suivant un processus de développement permettant le prototypage rapide en séance d’analyse, nous avons mobilisé des concepts de la méthode eXtreme Programming pour concevoir et proposer une variante de la méthode Processus Unifié.
37
Un mono-modèle est un modèle unique utilisé au cours de tout le cycle de développement depuis l’analyse jusqu’à l’implémentation. Le code produit avec des méthodes de développement centré sur le code, eXtreme Programming par exemple, est un mono-modèle.
Le choix de réaliser du prototypage en séance d’analyse a été effectué afin de placer le concepteur d’une application dans un contexte simailaire à celui d’un développeur d’une équipe eXtreme Programming.
Au cours de l’analyse, les acteurs et le concepteur sont réunis en un même lieu et font ensemble l’analyse du système. Ils sont alors dans les conditions de la pratique du Client sur Site prônée par la méthode eXtreme Programming (cf. Chapitre 2-II.2.2). Or, cette pratique est destinée à améliorer la communication entre le client et les développeurs et ce à deux niveaux :
L’activité première du client est d’« alimenter » l’équipe en concepts, en spécifications, etc. qui vont permettre aux développeurs de réaliser l’application. C’est l’activité classique d’analyse. La seconde activité du client est d’évaluer la pertinence des spécifications qu’il a fournies en validant le produit obtenu. Cette activité correspond à la validation de l’incrément produit. Elle n’est possible que parce que la mèthode eXtreme Programming a adopté la pratique d’Intégration continue.En eXtreme Programming, l’analyse, la conception, l’implémentation et la réalisation des tests, activités d’un cycle Processus Unifié, sont donc effectuées en continu tout au long du projet. L’intégration d’un incrément dans le code général finalise la validation.
L’objectif élémentaire d’œuvrer suivant un processus de développement permettant le prototypage rapide en séance d’analyse relève de la conjonction des deux pratiques : Client sur site assurant les deux fonctions d’analyse et de validation et l’Intégration continue.
En séance d’analyse, la pratique du Client sur site est satisfaite de fait, reste à relever le challenge lié à la pratique de l’Intégration continue.
Effectuer une intégration suppose qu’un incrément a été produit et que toutes les activités des phases de conception, d’implémentation voire de tests ont été réalisées.
Si ces activités sont effectuées manuellement, la séance d’analyse va être entrecoupée de temps-morts improductifs donc onéreux. Le travail d’analyse qui est fondamental va rapidement devenir fastidieux pour les acteurs. Ils vont alors se démobiliser et se désintéresser du problème. L’analyse devient donc moins pertinente et la qualité de l’application se dégrade.
Par contre, si ces mêmes activités sont automatisées alors les temps-morts n’existent plus et, face à un prototype, la réactivité ainsi que le feedback des acteurs sont bien meilleures que face à un modèle dont ils ne connaissent pas toutes les finesses du langage de modélisation. Ils peuvent alors valider, modifier ou supprimer les concepts capturés et régénérer un nouveau prototype immédiatement.
De fait, l’objectif de modéliser un système suivant un processus de développement permettant le prototypage rapide en séance d’analyse accroît la communication entre les acteurs et le concepteur. La communication est la valeur érigée en valeur fondamentale par Kent Beck concepteur de la méthode eXtreme Programming (cf. Chapitre 2-II.2.2).
Fort de ces réflexions, nous proposons de définir une variante de la méthode Processus Unifié qui permette de satisfaire l’objectif élémentaire d’opérer suivant un processus de développement permettant le prototypage rapide en séance d’analyse :
Définition 4 La méthode Continuous Integration Unified Process superpose, au cycle principal de la
méthode Processus Unifié, un cycle de prototypage rapide (figure 37) doté d’un processus automatisant l’évolution des modèles depuis l’analyse jusqu’à l’implémentation.
Nota En figure 37, seules les phases d’analyse, de conception, d’implémentation et de validation du cycle
de prototypage rapide ont été représentées car ce sont les phases qui ont été automatisées dans le cadre de cette recherche. Toutefois, la définition 4 ne restreint pas le principe de la méthode à ces seules phases et d’autres phases peuvent être automatisées.
L’idée d’évolution automatique des modèles depuis l’analyse jusqu'à l’implémentation est une préoccupation de la communauté MDA. Cette idée n’est pas affichée comme un objectif dans les textes fondateurs de l’approche MDA (Miller et al., 2001, 2003) mais il est évident à la lecture de ces textes que c’est l’un des objectifs recherchés et atteint dans certains environnements contraints. Par exemple, le standard CWM38 (OMG, 2001b) permet de couvrir le cycle complet de conception, réalisation et gestion des entrepôts de données (Miller et al., 2001). Certains auteurs qualifient de full MDA (Kleppe, 2004 ; Softeam, 2005) le processus d’évolution automatique des modèles depuis l’analyse jusqu'à l’implémentation. Pour faire évoluer automatiquement un
modèle depuis l’analyse jusqu’à l’implémentation, la communauté MDA suggère de faire appel aux
transformations de modèle (cf. Chapitre 2-I.2).
Exigences
Planning
Étude
d’opportunité
Analyse
Implémentation
Déploiement
Tests
Validation
Conception
Analyse Conception Automatisée Implémentation Automatisée Validation Itération Principale Itération de Prototypage RapideExigences
Planning
Étude
d’opportunité
Analyse
Implémentation
Déploiement
Tests
Validation
Conception
Analyse Conception Automatisée Implémentation Automatisée ValidationExigences
Planning
Étude
d’opportunité
Analyse
Implémentation
Déploiement
Tests
Validation
Conception
Analyse Conception Automatisée Implémentation Automatisée Validation Analyse Conception Automatisée Implémentation Automatisée Validation Itération Principale Itération de Prototypage RapideFigure 37Cycle de prototypage rapide de la méthode Continuous Integration Unified Process.
Nous avons adopté ces idées novatrices dans le contexte de la méthode Continuous Integration Unified Process. Aussi, l’automatisation complète des phases de conception et d’implémentation suppose la mise en œuvre d’une panoplie de transformations de modèle que nous détaillerons au Chapitre 5.
Doté de cette panoplie de transformations, la durée des phases de conception et d’implémentation du cycle de prototypage rapide est réduite au temps d’exécution de ces transformations lui-même lié au volume de concepts réifié dans le modèle.
III
SOFTWARE DEVELOPMENT PROCESS APPROACH :PRINCIPE FONDATEUR ET
DEFINITION GENERALE
Le guide de l’approche MDA (Miller et al., 2003) stipule que : « The three primary goals of MDA are portability, interoperability and reusability through architectural separation of concerns ». Afin de satisfaire ces objectifs, les concepteurs de l’approche MDA ont introduit en 2001 les concepts de modèle indépendant des plates-formes (modèle PIM) et de modèle spécifique à une plate-forme (modèle PSM) (Miller et al., 2001).
La séparation des préoccupations via une architecture à plusieurs modèles relève en fait d’une préoccupation plus fondamentale qui est la capitalisation des concepts, des spécifications, etc.
Le guide d’utilisation de l’approche MDA publié en 2003 vient confirmer ce constat. Le modèle CIM a été introduit dans ce guide pour combler le fossé existant entre les experts du domaine thématique et les experts de la conception et de la construction de l’application (Miller et al., 2003) mais ce n’est pas sa seule fonction puisque il 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. De fait dans cette seconde fonction, il capitalise une partie de la connaissance des acteurs du domaine.
La dichotomie entre branches fonctionnelle et technique introduite dans le processus de développement en Y (cf. Chapitre 2-II.1.5) n’est pas sans rappeler la séparation des spécifications métiers de celles d’implémentation préconisée par l’approche MDA. La préoccupation sous-jacente en adoptant le processus de développement en Y est aussi une préoccupation de capitalisation, plus des acquis peut-être que des connaissances.