Diapositive 1

Version 1.0

Programmation et Développement orientés objets

Cours B4Chapitre 5: Le processus et la

méthode UMLExtrait du livre UML en action*

* UML en ACTIONPascal ROQUES et Franck VALLEEEditeur EYROLLESISBN 2-212-09127-3

Diapositive 2

07/05/2001 Chapitre 5: Le processus et la méthode unifiés 2/12

Le processus UPUP = Unified Process

RUP = Rational Unified Process

C’est un processus de développement logiciel construit sur la méthode UML

ItératifCentré sur l’architecture, Conduit par les cas d’utilisationPiloté par les risques

Dans le processus UP, les activités de développement sont organisée suivant 5 workflows qui décrivent: La capture des besoins, L’analyse, La conception, L’implémentation Et le test. Le UP est une trame des meilleures pratiques de développement, il doit être utilisé comme un guide pour réaliser un projet et non comme l’arme ultime et universelle de développement. Incrémental: Il favorise la définition d’incréments de réalisation utilisables et fonctionnels. Un projet ne produisant rien de tangible dans les 9 mois court un risque majeur d’échec. Les incréments garantissent que les équipes sont capables de développer et d’intégrer le produit, ils garantissent aussi des résultats tangibles aux utilisateurs et permettent de détecter tôt les écarts par rapport aux spécifications fonctionnelles. Enfin ce sont d’excellents moyens de contrôle des coûts et des délais. Chaque itération porte sur la conception et la réalisation d’une fonctions Piloté par les risques: Les causes majeures d’échec d’un projet logiciel sont: l’incapacité du système à répondre au exigences opérationnelles (défaillance de l’architecture technique du système) et l’inadéquation du système aux attentes des utilisateurs (non respect des exigences fonctionnelles). Ces causes d’échec doivent être contrôlées et supprimées.

Ces processus sont organisés autour du développement et du maintien de modèles plutôt qu’autour d’une montagne de documents. Ces modèles ont une densité d’informations importante et nécessite l’utilisation d’une méthode pour maintenir une organisation stricte des différents points de vue du système au différents niveaux d’abstractions. Bien entendu les processus UP sont orientés composants pour assurer le niveau de souplesse et de réutilisabilité nécessaire aux différents incréments Les processus UP orientés utilisateurs car les spécifications et la conception sont bâtis à partir des modes d’utilisation attendus par les utilisateur du système (décrits par les cas d’utilisation).

Diapositive 3

07/05/2001 Chapitre 5: Le processus et la méthode unifiés 3/12

Exemple de processus UP:Le processus 2TUP

2TUP = 2 Tracks Unified Process Le processus 2TUP constate que toute évolution imposée au système peut se décomposer et se traiter parallèlement, suivant un axe fonctionnel et un axe technique. On peut donc étudier indépendamment les évolutions liées aux changements des besoins fonctionnels et celle liées aux besoins techniques. A l’issue de ces étapes d’analyse, la conception fusionne les besoins pour réaliser le système. La branche gauche (fonctionnelle) comporte : la capture des besoins fonctionnels, qui produit un modèle des besoins focalisé sur le métier des utilisateurs. Elle qualifie au plus tôt le risque de produire un système inadapté aux utilisateurs. De son côté, la maîtrise d’œuvre consolide les spécifications et en vérifie la cohérence et l'exhaustivité. L'analyse, qui consiste à étudier précisément la spécification fonctionnelle de manière à obtenir une idée de ce que va réaliser le système en termes de métier. Les résultats de l'analyse ne dépendent d'aucune technologie particulière. La branche droite (architecture technique} comporte : la capture des besoins techniques, qui recense toutes les contraintes et les choix dimensionnant la conception du système. Les outils et les matériels sélectionnés ainsi que la prise en compte de contraintes d'intégration avec l'existant conditionnent généralement des pré-requis d'architecture technique ; la conception générique, qui définit ensuite les composants nécessaires à la construction de l'architecture technique. Celle conception est complètement indépendante des aspects fonctionnels. Elle a pour objectif d'uniformiser et de réutiliser les mêmes mécanismes pour

tout un système. L'architecture technique construit le squelette du système informatique et écarte la plupart des risques de niveau technique. L'importance de sa réussite est telle qu'il est conseillé de réaliser un prototype pour assurer sa validité. La branche du milieu comporte la conception préliminaire, qui représente une étape délicate, car elle intègre le modèle d'analyse dans l'architecture technique de manière à tracer la cartographie des composants du système à développer, la conception détaillée, qui étudie ensuite comment réaliser chaque composant ; l'étape de codage, qui produit ces composants et teste au fur et à mesure les unités de code réalisées l'étape de recette, qui consiste enfin à valider les fonctions du système développé. PROCESSUS UNIFIÉ (UNIFIED PROCESS) Un processus unifié est un processus de développement logiciel construit sur UML ; il est itératif centré sur l'architecture, conduit par les cas d'utilisation et piloté par les risques. La gestion d'un tel processus est organisée suivant les 4 phases suivantes: pré-étude, élaboration, construction et transition. Ses activités de développement sont définies par 5 workflows fondamentaux qui décrivent la capture des besoins, l'analyse, la conception, l'implémentation et le test. Le processus unifié doit donc être compris comme une trame commune des meilleures pratiques de développement, et non comme l'ultime tentative d'élaborer un processus universel. La définition d'un processus UP est donc constituée de plusieurs workflows d'activités de production et de contrôle de cette production. Tout processus UP répond aux caractéristiques ci-après. Il est incrémental. La définition d'incréments de réalisation est en effet la meilleure pratique de gestion des risques d'ordre à la fois technique et fonctionnel. On peut estimer qu'un projet qui ne produit rien d'exécutable dans les 9 mois court un risque majeur d'échec. Chaque incrément garantit que les équipes sont capables d'intégrer l'environnement technique pour développer un produit final et fournit aux utilisateurs un résultat tangible de leurs spécifications. Le suivi des incréments constitue par ailleurs un excellent contrôle des coûts et des délais. Nous identifions une première cause provenant de l'incapacité de l'architecture technique à répondre aux contraintes opérationnelles, et une seconde cause liée à l'inadéquation du développement aux besoins des utilisateurs. Il est construit autour de la création et de la maintenance d'un modèle, plutôt que de la production de montagnes de documents. Le volume d'informations de ce modèle nécessite une organisation stricte qui présente les différents points de vue du logiciel à différents degrés d'abstraction. L'obtention de métriques sur le modèle fournit par ailleurs des moyens objectifs d'estimation. Il est itératif. Chaque itération porte sur des degrés d'abstraction de plus en plus précis et permet de produire des traces nécessaires au contrôle du changement. Il est orienté composant. Tant au niveau modélisation que production, c'est une garantie de souplesse pour le modèle lui-même et le logiciel qu'il représente. Cette pratique constitue le support nécessaire à la réutilisation logicielle et offre des perspectives de gains non négligeables. Il est orienté utilisateur, car la spécification et la conception sont construites à partir des modes d'utilisation attendus par les acteurs du système.

Le processus 2TUP 2TUP signifie « 2 Tracks Unifed Process ». C'est un processus UP qui répond aux caractéristiques que nous venons de citer. Le processus 2TUP apporte une réponse aux contraintes de changement continuel imposées aux systèmes d'information de l'entreprise. En ce sens, il renforce le contrôle sur les capacités d'évolution et de correction de tels systèmes. « 2 Tracks » signifie littéralement que le processus suit deux chemins. II s'agit des chemins « fonctionnels » et « d'architecture technique », qui correspondent aux deux axes des changements imposés au système informatique. L'axiome fondateur du 2TUP consiste à constater que toute évolution imposée au système d'information peut se décomposer et se traiter parallèlement, suivant un axe fonctionnel et un axe technique. Pour illustrer cet axiome, prenons les trois exemples suivants I. une agence de tourisme passe des accords avec une compagnie aérienne de sorte que le calcul des commissions change. En l'occurrence, les résultats issus de la branche fonctionnelle évoluent pour prendre en compte la nouvelle spécification ; 2. cette même entreprise décide d'ouvrir la prise de commande sur le Web Si rien ne change fonctionnellement, en revanche, l'architecture technique du système évolue ; 3. cette entreprise décide finalement de partager son catalogue de prestations avec les vols de la compagnie aérienne. D'une part, la fusion des deux sources d'informations imposera une évolution de la branche fonctionnelle, d'autre part, les moyens techniques de synchronisation des deux systèmes conduiront à étoffer l'architecture technique du système. L'étude de ces évolutions pourra être menée indépendamment, suivant les deux branches du 2TUP. A l'issue des évolutions du modèle fonctionnel et de l'architecture technique, la réalisation du système consiste à fusionner les résultats des deux branches. Cette fusion conduit à l'obtention d'un processus de développement en forme de Y, comme illustré par la figure 2-2. La branche gauche (fonctionnelle) comporte : la capture des besoins fonctionnels, qui produit un modèle des besoins focalisé sur le métier des utilisateurs. Elle qualifie au plus tôt le risque de produire un système inadapté aux utilisateurs. De son côté, la maîtrise d’œuvre consolide les spécifications et en vérifie la cohérence et l'exhaustivité. L'analyse, qui consiste à étudier précisément la spécification fonctionnelle de manière à obtenir une idée de ce que va réaliser le système en termes de métier. Les résultats de l'analyse ne dépendent d'aucune technologie particulière. La branche droite {architecture technique} comporte : la capture des besoins techniques, qui recense toutes les contraintes et les choix dimensionnant la conception du système. Les outils et les matériels sélectionnés ainsi que la prise en compte de contraintes d'intégration avec l'existant conditionnent généralement des pré-requis d'architecture technique ; la conception générique, qui définit ensuite les composants nécessaires à la construction de l'architecture technique. Celle conception est complètement indépendante des aspects fonctionnels. Elle a pour objectif d'uniformiser et de réutiliser les mêmes mécanismes pour tout un système. L'architecture technique construit le squelette du système informatique et écarte la plupart des risques de niveau technique. L'importance de sa réussite est telle qu'il est conseillé de réaliser un prototype pour assurer sa validité. La branche du milieu comporte la conception préliminaire, qui représente une étape délicate, car elle intègre le modèle d'analyse dans l'architecture technique de manière à tracer la cartographie des composants du système à développer, la conception détaillée, qui étudie ensuite comment réaliser chaque composant ;

l'étape de codage, qui produit ces composants et teste au fur et à mesure les unités de code réalisées l'étape de recette, qui consiste enfin à valider les fonctions du système développé. L'ensemble de ces étapes de développement sera illustré tout au long de cet ouvrage par la mise en application du processus 2TUP à l'étude de cas SIVEx. Seules les deux dernières étapes, ne relevant pas de l'utilisation d'UML, ne seront pas abordées dans cet ouvrage. LES BRANCHES DU "Y" PRODUISENT DES MODÈLES RÉUTILISABLES La branche gauche capitalise la connaissance du métier de l'entreprise. Elle constitue généralement un investissement pour le moyen et le long terme. Les fonctions dit système d'informations sont en effet indépendantes des technologies utilisées. L'entreprise qui maintient le modèle fonctionnel de sa branche gauche est à même de le réaliser sous différentes technologies. Il suffit de « greffer » une nouvelle architecture technique pour mettre à jour un système existant. La branche droite capitalise quant à elle un savoir-faire technique. Elle constitue un investissement pour le court et le moyen terme. Les techniques développées pour le système peuvent l'être en effet indépendamment des fonctions à réaliser. Une architecture technique est en effet immédiatement réutilisable pour les différentes composantes fonctionnelles d'un même système d'entreprise. C’est un processus incrémental: Un incrément constitue un ensemble d'étapes de développement qui aboutit à la construction de tout ou partie du système. Le contenu d'un incrément est porteur d'améliorations ou d'évolutions du système et il peut être évalué par les utilisateurs. En général, les incréments s’inscrivent dans une phase du projet et sont cohérents avec elle: en phase de pré-étude l’incrément conduit à l’évaluation des problèmes techniques et du bien fondé de la réalisation; en phase d’analyse, l’incrément consiste à étudier l’adéquation du système aux besoins des utilisateurs… Par définition, chaque incrément passe en revue toutes tes activités du processus en Y. Mais l'effort consacré à chaque activité n'est pas identique suivant la phase de développement du projet. On peut estimer que l'incrément de pré-étude consacre relativement plus d'effort à la capture des besoins que les incréments d'élaboration. Les incréments conduisent à une vue de plus en plus précise et riche du système à réaliser. Chaque incrément correspond à une niveau d’abstraction (la vision du système est de plus en plus concrète après chaque itération). Chaque itération utilise un modèle adapté au niveau d’abstraction considéré: capture des besoins fonctionnels -> boite noire de définition des contours du système et cas d’utilisations; Capture des besoins techniques -> cas d’utilisations Analyse -> diagrammes de classes et d’objets Conception générique -> diagrammes de déploiement et diagrammes de composants Conception préliminaire -> diagrammes de classes, de séquence et d’activité Conception détaillée -> diagrammes de classes, de séquence et d’activité C’est un processus qui permet de contrôler les risques : C’est un processus qui permet de contrôler les risques tout au long du déroulement du projet: la nécessité de produire régulièrement des incréments conduit à contrôler les risques d’inadéquation aux besoins des utilisateurs (risques fonctionnels) et les risques d’incapacité à intégrer techniquement la solution (risques techniques). C’est un processus centré sur les besoins des utilisateurs:

Comme les risques d’échec d’un projet proviennent souvent de la non adéquation du système réalisé aux besoin des utilisateurs, le process 2TUP prend en compte deux groupes d’utilisateurs: l’utilisateur fonctionnel du système et l’exploitant. Cette prise en compte permet d’assurer un système qui réponde aux besoin du métier et aux besoins de l’exploitation (administration, sécurité, sauvegardes, performances…) Les deux sommets du Y sont modélisés à l’aide de cas d’utilisation centrés sur les acteurs fonctionnels et sur les acteurs exploitants. Ces cas d’utilisation forment les points de départ de l’analyse. Pendant la phase de conception préliminaire, on vérifie que les interactions entre les classes identifiées respectent les contraintes exprimées dans les cas d’utilisation.

Diapositive 4

07/05/2001 Chapitre 5: Le processus et la méthode unifiés 4/12

Les Diagrammes d’UMLLes diagrammes de cas d’utilisation

UML s'articule autour de neuf diagrammes différents, chacun d'eux étant dédié à la représentation des concepts particuliers d'un système logiciel. Par ailleurs, UML modélise le système suivant deux modes de représentation: la structure du système pris « au repos », La dynamique de fonctionnement. Les deux représentations sont nécessaires et complémentaires pour schématiser la façon dont est composé le système et comment ses composantes fonctionnent entre elles. Le diagramme de cas d'utilisation représente la structure des fonctionnalités nécessaires aux utilisateurs du système. Il est utilisé dans les deux étapes de capture des besoins fonctionnels et techniques. Le cas d’utilisation est utilisé pour spécifier le comportement du système en interaction avec les acteurs externes (humains ou matériels).

Diapositive 5

07/05/2001 Chapitre 5: Le processus et la méthode unifiés 5/12

Les Diagrammes d’UMLLe diagramme de classes

Le diagramme de classes représente le concept le plus important dans un développement orienté objet. Il permet pendant l’analyse fonctionnelle de représenter les entités connues des utilisateurs Il permet ensuite dans les phases de conception de décrire la représentation objet du système

Diapositive 6

07/05/2001 Chapitre 5: Le processus et la méthode unifiés 6/12

Les Diagrammes d’UMLLe diagramme d’objets

Le diagramme d'objets sert à illustrer des structures de classes compliquées. Ce diagramme est utilisé en analyse pour vérifier l'adéquation d'un diagramme de classes à différents cas possibles Ce modèle permet d’illustrer concrètement des exemples de structures de données

Diapositive 7

07/05/2001 Chapitre 5: Le processus et la méthode unifiés 7/12

Les Diagrammes d’UMLLe diagramme de composants

Le diagramme de composants représente en premier lieu les concepts connus de l'exploitant pour installer et dépanner le système. I! s'agit dans ce cas de déterminer la structure des composants d'exploitation que sont les librairies dynamiques, les instances de bases de données, les applications, les progiciels, les objets distribués, les exécutables, etc. Le diagramme de composants représente en second lieu les concepts de configuration logicielle, pour fabriquer une version de composant d'exploitation ou tout autre produit intermédiaire tel qu'une librairie ou un archive. Il s'agit de montrer comment s'agencent des composants comme les fichiers source, les packages de code ou les librairies. Le modèle de composants représente le lien entre le modèle logique issu de l’analyse et de la conception et le modèle physique (d’implémentation). Il permet de spécifier l’architecture logicielle dans un environnement de développement donné. Ce modèle n’est pas toujours utilisable car tous les langages ne supportent pas nécessairement le concept de module et de composant.

Diapositive 8

07/05/2001 Chapitre 5: Le processus et la méthode unifiés 8/12

Les Diagrammes d’UMLLe diagramme de déploiement

Le diagramme de déploiement correspond à la fois à la structure physique qui prend en charge le système logiciel, et la façon dont les composants d'exploitation y sont installés. Le modèle de déploiement constitue un diagramme de l’organisation matérielle du système ou de l’application. Il constitue une sorte de synoptique du système. Un diagramme de déploiement permet de donner l’architecture de la plate-forme technique, de préciser où se trouvent les processus et de montrer comment les objets se déplacent dans une architecture distribuée.

Diapositive 9

07/05/2001 Chapitre 5: Le processus et la méthode unifiés 9/12

Les Diagrammes d’UMLLe diagramme d’états

Le diagramme d'états représente le cycle de vie commun aux objets d'une même classe. Ce diagramme complète la connaissance des classes en analyse et en conception.

Diapositive 10

07/05/2001 Chapitre 5: Le processus et la méthode unifiés 10/12

Les Diagrammes d’UMLLe diagramme d’activités

Diapositive 11

07/05/2001 Chapitre 5: Le processus et la méthode unifiés 11/12

Les Diagrammes d’UMLLe Diagramme de séquences

Les diagrammes de séquences expriment le déroulement de plusieurs messages pour une exécution données. Ces diagrammes sont équivalents aux diagrammes de collaboration mais autorisent une appréciation visuelle du temps (il s’écoule de « haut en bas » du diagramme).

Diapositive 12

07/05/2001 Chapitre 5: Le processus et la méthode unifiés 12/12

Les Diagrammes d’UMLLe diagramme de collaboration

Ils présentent la collaboration entre objets pour une exécution donnée sans mettre l’accent sur la chronologie des messages (à la différence des diagrammes de séquence). L’apport du diagramme de collaboration est la possibilité de préciser les règles de visibilité d’un objet.