Rational Unified Process

Transcription

1 Rational Unified Process For Christiane DAVOINE-GUHUR Société GICAB - Vannes Christiane.Davoine@CA-GICAB.fr

2 Table des Matières 1 INTRODUCTION LES COMPOSANTS ET LES GRANDS PRINCIPES DU PROCESSUS Les composants du produit RUP Le pilotage par les cas d utilisation Définition Les flots des événements d un cas d utilisation Les cas d utilisation dans le processus de développement Exemple de cas d utilisation «Retirer de l argent» Le processus centré sur l architecture Importance des modèles et de l architecture Définition de l architecture Représentation de l architecture par le modèle à 4+1 vues Architecture et conception architecturale Exemple sur le cas d utilisation «Retirer de l argent» Le processus Itératif et Incrémental Qu est-ce qu une itération? La dimension statique du processus La dimension dynamique du processus LES ENCHAÎNEMENTS D ACTIVITÉS DU PROCESSUS La modélisation métier Pourquoi modéliser le métier? Comment modéliser le métier? Les enchaînements d activités Les outils de modélisation métier La gestion des exigences Définitions Comment exprimer les exigences? Conception de l interface utilisateur Enchaînements d activités Les outils pour la gestion des exigences Exemple des exigences pour le cas d utilisation «Retirer de l argent» L analyse et la conception Objectif Travailleurs et artefacts Enchaînements d activités Exemple d analyse du cas d utilisation «Retirer de l argent» Les outils pour l analyse et la conception L implémentation Objectifs Les activités d implémentation Les types de prototypes Les outils pour l implémentation Les tests Les objectifs Le rôle des tests dans le cycle de vie du logiciel Les travailleurs et artefacts Exemple de tests pour le cas d utilisation «retirer de l argent» Les types de tests Les outils de tests Christiane DAVOINE GUHUR 02/05/02

3 3.6 La gestion de configuration Les objectifs Les définitions Les travailleurs et les artefacts Les enchaînements d activités Les outils support de la gestion de configuration Le déploiement Les objectifs Les travailleurs et les artefacts Exemple de configuration pour le cas d utilisation «Retirer de l argent» Les enchaînements d activités LES ENCHAÎNEMENTS D ITÉRATION, RÔLE DES TRAVAILLEURS DANS LE DÉVELOPPEMENT D UN PROJET AVEC RUP Exemple : Définir la vision du produit Exemple : Construire un prototype architectural Exemple : Implémenter le système Cartographie des enchaînements d activités d un développement de projet avec RUP CONCLUSION BIBLIOGRAPHIE... 1 Christiane DAVOINE GUHUR 02/05/02

4 Table des illustrations Figure 1 : RUP, Les composants Figure 2 : Les cas d'utilisation, la description fonctionnelle des objets[lopez, et al 1998]... 3 Figure 3 : Cas d'utilisation retirer de l'argent[jacobson, et al 1999]... 4 Figure 4 : Les cas d utilisation à travers les différents modèles[kruchten 2000]... 4 Figure 5 : Cas d utilisation retirer de l argent... 5 Figure 6 : Modèle d'analyse "retirer de l'argent"... 6 Figure 7 : Le modèle d architecture à 4+1 vues[int2] Figure 8 : Structure statique de la vue architecturale du modèle de conception pour le système DAB... 9 Figure 9 : diagramme de collaboration du système DAB[Jacobson, et al 1999]... 9 Figure 10 : Le modèle de déploiement du système DAB[Jacobson, et al 1999] Figure 11 : La vue architecturale du modèle de déploiement[jacobson, et al 1999] Figure 12 : Une approche itérative au développement[int1] Figure 13 : Travailleurs, activités et artefacts [Kruchten 2000] Figure 14 : Exemple d enchaînement d activités [Kruchten 2000] Figure 15 : Les quatre phases et jalons du processus itératif[kruchten 2000] Figure 16 : D un cycle de vie séquentiel à un cycle de vie itératif [Kruchten 2000] Figure 17 : Les neufs principaux enchaînements d activités du processus [Kruchten 2000] Figure 18 : Travailleurs et artefacts dans les activités de modélisation métier.[kruchten 2000] Figure 19 : Des modèles métier aux modèles systèmes[kruchten 2000] Figure 20 : Un enchaînement d'activités de modélisation métier.[kruchten 2000] Figure 21 : Différents artefacts de l'ensemble des exigences et leurs relations avec d'autres artefacts[kruchten 2000] Figure 22 : Travailleurs et artefacts dans l'enchaînement des activités de gestion[kruchten 2000] Figure 23 : Enchaînement des activités de gestion des exigences [Kruchten 2000] Figure 24 : comparaison des modèles des cas d'utilisation et d'analyse[jacobson, et al 1999] Figure 25 : Un enchaînement des activités d'analyse et de conception[kruchten 2000] Figure 26 : identification de paquetages d'analyse généraux à partir des classes du domaine[jacobson, et al 1999] Figure 27 : paquetages de services «comptes et de risques» encapsulant chacun des classes fonctionnellement liées[jacobson, et al 1999] Figure 28 : Enchaînement d'activités d'implémentation Figure 29 : point de convergence de l'implémentation [Jacobson, et al 1999] Figure 30 : Travailleurs et artefacts impliqués dans les tests [Jacobson, et al 1999] Figure 31 : Modèle de tests [Jacobson, et al 1999] Figure 32 : Cas, procédures et scripts de test pour un terminal bancaire [Kruchten 2000] Figure 33 : Le cube CCM [Kruchten 2000] Figure 34 : Travailleurs et artefacts dans l'activité de déploiement [Jacobson, et al 1999] Figure 35 : Modèle de déploiement du Cas DAB[Jacobson, et al 1999] Figure 36 : Enchaînement d'activités de l'itération générique [Jacobson, et al 1999] Figure 37 : Répartition du temps de planification par phase [Jacobson, et al 1999] Figure 38 : les "patatoï des" tracées à la main regroupent les principales activités de la phase création Figure 39 : La "patatoï de" tracée à la main regroupe les principalement activités de la phase création[jacobson, et al 1999] Figure 40 : Cartographie d'un projet développé avec RUP[Jacobson, et al 1999] Figure 41 : L'approche typique pour mettre en place un processus et les outils [Jacobson, et al 1999] Christiane DAVOINE GUHUR 02/05/02

5 Préambule «Le Rational Unified Process est un processus de génie logiciel développé et commercialisé par la société Rational Software. Il permet d affecter et de gérer de manière rigoureuse et disciplinée les tâches et les responsabilités au sein d une organisation de développement...»[kruchten 2000] «Le processus unifié a précisément pour but de spécifier les différentes phases d un projet, de l élaboration du cahier des charges au déploiement de l application. Il est le complément idéal du standard UML qui est un langage de modélisation graphique, dont la vocation n est pas de couvrir tous les aspects du génie logiciel.»[jacobson, et al 1999] On remarque dans ces deux citations que RUP 1 est une démarche de développement génie logiciel et dans la deuxième de ces citations l utilisation de sigle UML 2. De fait, la découverte de RUP suppose des pré-requis de modélisation objet et d UML. On considère dans cette bibliographie que ces deux points sont acquis, il n y aura pas de présentation d UML, ni de l approche objet. RUP est un outil de modélisation UML, ses possibilités sont très étendues et sont décrites dans 3200 pages de la documentation de référence de Rational. L objectif de cette bibliographie n est donc pas d être exhaustif. Les chapitres suivants fourniront au lecteur les points importants. Ils porteront sur une présentation de RUP qui sera découpée en trois parties, 1. Le processus, ses composants et ses grands principes 2. Les principaux enchaînements d activité qui composent chaque itération du processus, 3. Les enchaînements d itération, le rôle des travailleurs dans le développement d un projet avec RUP. Les références citées permettront une étude approfondie de ce vaste sujet. Afin de rendre la lecture de cette bibliographie plus agréable, le même exemple servira de fil rouge, tout au long de ces pages, il s agit d un client bancaire qui effectue un retrait d argent sur un automate bancaire. Les références aux ouvrages, sites, documents consultés sont indiqués par une référence entre crochet par exemple [Jacobson, et al 1999]. 1 RUP : Rational Unified Process 2 UML : Unified Modeling Language Christiane DAVOINE GUHUR 02/05/02

6 1 INTRODUCTION RUP est le Rational Unified Process, c est un processus commercial, un produit développé et maintenu par la société Rational Software. Il contient des directives et des conseils sur les techniques modernes pour le développement logiciel. Ce produit est une source de connaissances, toujours à jour, accessible à partir du poste de travail du développeur. Il est parfaitement intégré à l ensemble des outils de développement proposés par la société. Rational Unified Process est aussi un cadre de processus (Process framework), pour une organisation qui l adopte. Cette dernière peut l adapter et l étendre en fonction de ses besoins [Kruchten 2000]. Pour développer des systèmes logiciels modernes, l expérience a mis en évidence six meilleures pratiques à respecter. En les combinant, on s attaque aux causes profondes des problèmes de développement logiciel [INT3]. Les meilleures pratiques pour le développement de logiciel moderne respectent les points suivants : - Développer le logiciel de manière itérative, - Gérer les exigences, - Utiliser des architectures à base de composants, - Modéliser graphiquement le logiciel, - Vérifier la qualité du logiciel, - Contrôler les changements apportés au logiciel. RUP présente ces meilleures pratiques sous une forme adaptée à un grand nombre de projets et d organisations, comme nous allons le découvrir dans la suite de ce document en abordant : les composants et les principes du processus, les principaux enchaînements d activités et le rôle des travailleurs dans le développement d un projet avec le processus unifié. 2 LES COMPOSANTS ET LES GRANDS PRINCIPES DU PROCESSUS 2.1 LES COMPOSANTS DU PRODUIT RUP RUP ne ressemble en rien à la documentation des productions classiques de méthodes de développements qui fournissaient des étagères de classeurs. Ce produit présente les atouts suivants : - Il publie les mises à jour de manière régulière, - Il utilise la technologie du Web, le mettant à portée de souris des développeurs, - Une organisation peut aisément l adapter pour ses besoins, - Il est intégré à un grand nombre d outils de développement logiciel de Rational, de sorte que les développeurs peuvent accéder aux recommandations du processus à partir de l outil qu ils utilisent. Le produit en ligne permet d accéder via intranet : - A la version la plus récente, - Aux informations clés du processus, moteur de recherche, index, table des matières dynamiques, - Aux références externes (comme UML) ou d activer directement l outil ou une tâche. Christiane DAVOINE GUHUR Page /05/02

7 Le produit RUP comprend : - Un CD-Rom qui contient la description de tous les éléments du RUP (tâches, activités, recommandations, procédures et exemples), sous forme d un site Web que l usager installe sur sa machine, où sur un serveur de l entreprise, - Le manuel d introduction RUP en ligne propose : - Des guides d utilisation d outils qui établissent des ponts entre les processus et les outils de développement du logiciel et donnent des conseils supplémentaires sur leur usage. Il y a par exemple des guides pour Rational Rose qui aide à la modélisation graphique ou ClearCase qui facilite la gestion de configuration. - Des canevas (templates) pour tous les artefacts importants du processus quel que soit l outil utilisé pour les créer et les gérer. On trouve ainsi : - Rational Rose pour l aide à la modélisation, - Rational SoDA pour automatiser la documentation du logiciel, - RequisitePro pour gérer le cahier des charges, - Adobe FrameMaker et Microsoft Word pour créer la plupart des documents classiques, - ClearCase qui facilite la gestion de configuration, - Microsoft Project pour planifier le processus, - Microsoft FrontPage pour étendre RUP lui-même [Rational, 2000]. Figure 1 : RUP, Les composants. Avant toute chose, le Processus Unifié est un processus de développement logiciel, c est-àdire qu il regroupe les activités à mener pour transformer les besoins d un utilisateur en système logiciel. Mais c est plus qu un simple processus, c est un framework de processus génériques pouvant être adapté à une large classe de systèmes logiciels, à différents domaines d application, à différents types d entreprises, à différents niveaux de compétence et à différentes tailles d entreprises. Le Processus Unifié utilise le langage UML pour la création des plans d élaboration et de construction du système logiciel. En fait UML fait partie intégrante du Processus Unifié : l un et l autre ont été développés en parallèle. Néanmoins, les traits distinctifs du Processus unifié tiennent en trois expressions clés : - piloté par les cas d utilisation, - centré sur l architecture, - itératif et incrémental. Voilà ce qui fait toute l originalité du Processus unifié [Jacobson, et al 1999]. Christiane DAVOINE GUHUR Page /05/02

8 2.2 LE PILOTAGE PAR LES CAS D UTILISATION Les cas d utilisation constituent le concept principal de la méthode OOSE de Ivar Jacobson, un des pères d UML. Dans le processus de standardisation des méthodes objet ayant abouti au formalisme UML, le concept des «use cases», cas d utilisation en français, a été repris dans le but d effectuer une bonne délimitation du système et d améliorer la compréhension de son fonctionnement. Figure 2 : Les cas d'utilisation, la description fonctionnelle des objets [Lopez, et al 1998]. Les cas d utilisation représentent le moyen de décrire le caractère fonctionnel des objets. Il se positionne sur trois axes : - La description des objets, leurs propriétés et leurs attributs. Elle représente la vue statique de l objet, - L identification des états et des événements. Elle représente la vue dynamique de l objet, - La traduction du savoir-faire et du métier. Elle met en évidence les exigences, les règles fonctionnelles liées au métier [Lopez, et al 1998] Définition Les cas d utilisation sont un moyen d exprimer les exigences fonctionnelles du système. RUP définit les concepts de cas d utilisation et d acteur de la façon suivante : - Un cas d utilisation est une séquence d actions que réalise un système et qui fournit un résultat observable ayant une valeur pour un acteur particulier. - Un acteur est quelqu un ou quelque chose se situant à l extérieur du système et qui interagit avec lui. Il y a dans ces définitions plusieurs notions importantes : - Action : il s agit d une procédure de traitement quand un acteur envoie un signal au système ou qu un système est activé à l échéance d une temporisation. - Une séquence d actions : la séquence dont parle la définition est un flot spécifique d événements. - Un résultat observable ayant une valeur : une séquence d actions fournit un résultat utile à un acteur du système. On garantit ainsi que le cas d utilisation est pertinent et exprimé à un niveau de granularité que comprend l utilisateur [Kruchten 2000]. Christiane DAVOINE GUHUR Page /05/02

9 Figure 3 : Cas d'utilisation retirer de l'argent [Jacobson, et al 1999]. La description d un cas d utilisation rend compte de ce qui se passe dans le système quand le cas d utilisation se réalise. La fonctionnalité complète est définie par un ensemble de cas d utilisation, chacun d eux représentant un flot spécifique d événements Les flots des événements d un cas d utilisation Du point de vue des activités de gestion des exigences, l élément le plus important de la description d un cas d utilisation est le flot d événements. Un flot décrit une séquence d actions en langage naturel, dans une prose simple et précise [Jacobson, et al 1999] Les cas d utilisation dans le processus de développement RUP est une approche pilotée par les cas d utilisation, cela signifie qu ils servent de base au processus complet de développement. Figure 4 : Les cas d utilisation à travers les différents modèles [Kruchten 2000]. Le modèle de cas d utilisation est le résultat de l enchaînement des activités de gestion des exigences. Durant les activités d analyse et de conception, on se sert du modèle de cas d utilisation pour créer le modèle de conception. On décrit comment les cas d utilisation se réalisent en termes d interactions entre les objets du modèle de conception. On exploite les réalisations des cas d utilisation pour comprendre la dynamique du système et optimiser les performances. Pendant les tests, on recourt aux cas d utilisation pour identifier et organiser des cas et procédures de test. Comme les cas d utilisation décrivent la façon dont un acteur interagit avec le système, ils constituent une base idéale pour la rédaction des manuels utilisateurs. Ils servent également au chef de projet qui peut définir les contenus et les objectifs des itérations. Christiane DAVOINE GUHUR Page /05/02

10 Pour faire évoluer les cas d utilisation, on commence par développer un squelette de cas d utilisation avant d approfondir sa description. Au cours des premières itérations de la phase d élaboration, seuls les cas d utilisation sont décrits en détail Exemple de cas d utilisation «Retirer de l argent». Parmi les cas d utilisation fréquemment rencontrer sur les DAB 3, on retiendra le cas «retirer de l argent» qui est le cas d utilisation le plus important pour le client de la banque. Client de la banque Retirer de l argent Figure 5 : Cas d utilisation retirer de l argent La séquence de cas d utilisation qu on peut établir pour un retrait d argent sur un automate de type DAB pourrait se décomposer de la façon suivante : - Le client de la banque s identifie, - Le client de la banque choisit le compte sur lequel il veut effectuer son retrait et spécifie le montant du retrait. - Le système déduit le montant de son compte et délivre l argent. Ce cas d utilisation met en évidence des exigences de disponibilité, de précision, de sécurité. Un exemple de cas d utilisation «Retirer de l argent» peut s écrire comme suit en établissant le squelette du flot des événements : - Le cas d utilisation se déclenche quand le client insère sa carte bancaire, le système lit la carte et valide l information écrite sur la piste magnétique. - Le système demande le code secret, le client le saisit, le système le valide. - Le système demande quelle opération le client désire effectuer. Le client choisit de retirer de l argent. - Le système demande le montant du retrait. Le client saisit un montant. - Le système demande sur quel type de compte bancaire le retrait doit s effectuer (compte courant ou compte épargne ) - Le système entre en communication avec le réseau de la banque pour vérifier le numéro de compte, le code et la disponibilité du montant demandé. - Le système demande au client s il désire un reçu. Cette étape n est effectuée que s il reste du papier pour l impression. - Le système invite le client à retirer sa carte. Le client s exécute. - Le système fournit la somme d argent demandée. 3 DAB : Distributeur Automatique de Billets Christiane DAVOINE GUHUR Page /05/02

11 - Le système imprime le reçu. - Fin du cas d utilisation. On a décrit un flot d événements précis, il en existe d autres, on peut envisager différents déroulements. Figure 6 : Modèle d'analyse "retirer de l'argent" Ce modèle d analyse indique de quelle façon le cas d utilisation est réalisé par une collaboration, l un et l autre reliés par une dépendance de «traçabilité» et fait apparaître quatre classes qui prennent part à la réalisation du cas d utilisation. Les classes distributeur et interface guichet sont des classes frontières, la classe retrait est une classe de contrôle et la classe compte est une classe entité. 2.3 LE PROCESSUS CENTRE SUR L ARCHITECTURE Cette partie définit le concept d architecture logicielle et explique son rôle central dans RUP. En effet le processus unifié propose des principes et des conseils sur ce qui constitue l essence même d une architecture et UML dispose de puissantes constructions qui permettent de formuler l architecture. L architecte reçoit ainsi dans cette tâche, le soutien d UML et du Processus unifié[jacobson, et al 1999] Importance des modèles et de l architecture Une part importante de RUP est consacrée à la modélisation. En effet les modèles aident à simplifier la réalité et à appréhender les solutions d un nouveau système. Les modèles sont des représentations cohérentes, plus ou moins complètes du système à construire qui regroupés, constituent la description de l architecture du système. Comme on le dit souvent «L architecture est ce qui reste de la description d un système quand on simplifie au maximum et que l on peut encore comprendre ce que fait ce système et comment il fonctionne!» [Kruchten 2000] Définition de l architecture L architecture est un concept complexe qui se représente par des vues architecturales multiples et coordonnées. Elle est l ensemble des décisions prises sur l organisation du système logiciel, les choix des éléments structuraux, la définition des interfaces et leurs comportements. L architecture logicielle s intéresse non seulement à la structure et au comportement du système, mais aussi à son contexte, à ses contraintes économiques et technologiques. Christiane DAVOINE GUHUR Page /05/02

12 2.3.3 Représentation de l architecture par le modèle à 4+1 vues Comme le montre la figure ci-dessous, RUP propose une approche à cinq vues appelée par Philippe Kruchten «Modèle d architecture à 4+1 vues». Figure 7 : Le modèle d architecture à 4+1 vues [INT2]. - La vue logique de l architecture s intéresse aux aspects fonctionnels du système et à ce qu il doit produire pour les utilisateurs finaux. Elle décrit les classes majeures du système et leur organisation en paquetages et sous-systèmes. - La vue d implémentation décrit l organisation des modules statiques du logiciel dans l environnement de développement, en terme de paquetages et de couches. Elle prend en compte la gestion de configuration, la politique de gestion de versions. On trouve par exemple le code source d un plan de vol et la bibliothèque de code pour une base de données d espaces aériens. - La vue des processus définit les tâches, les flots de contrôle ou les processus et leurs interactions. - La vue de déploiement réconcilie l ingénierie du logiciel avec l ingénierie système. Elle s occupe des problèmes de déploiement, d installation, de performances. - La vue des cas d utilisation contient les quelques scénarios et cas d utilisation les plus importants. On les utilise pour guider l étude et la conception de l architecture pendant les phases de création (d inception) et d élaboration et on les exploite ensuite pour valider les différentes vues architecturales[kruchten 2000] Architecture et conception architecturale. Comment l obtient-on? L architecture est développée de façon itérative au cours de la phase d élaboration au travers de l expression des besoins, de l analyse, de la conception, de l implémentation et des tests. Comment la décrit-on? La description de l architecture est une vue des modèles du système : modèles des cas d utilisation, d analyse, de conception, d implémentation et de déploiement. Elle Christiane DAVOINE GUHUR Page /05/02

13 décrit les parties du système qu il est important de comprendre pour les développeurs et les autres intervenants [Jacobson, et al 1999].. La conception architecturale Une fois qu on a choisi une représentation de l architecture adaptée au problème à résoudre, il faut se préoccuper du processus de conception architecturale. RUP définit deux artefacts importants liés à l architecture : - la description de l architecture logicielle pour le projet, - le prototype architectural qui sert à valider l architecture et constitue une référence pour le reste du projet. L intérêt de l architecture porte principalement sur trois points : - Elle permet le contrôle intellectuel sur l ensemble du projet, - Elle situe les composants principaux et les interfaces majeures les uns par rapport aux autres, - Elle permet de raisonner sur la réutilisation interne (identification des parties communes) ou externes (l incorporation de composants logiciels prêts à l emploi). L architecture fournit une base pour la gestion de projet [Kruchten 2000]. On distinguera trois catégories de composants : - Les composants d exécution qu on livre, installe et exécute directement (les DLL, ou les bibliothèques liées dynamiquement). - Les composants de développement, il s agit là de sous-systèmes d implémentation réutilisables, de bibliothèques de logiciels avec une forte cohérence interne. - Les composants métier, il s agit d ensembles cohérents de composants d exécution qui assurent une fonctionnalité identifiée dans un métier donné (gestion des comptes, retirer de l argent ) Il y a d autres concepts architecturaux tels que le style architectural, les mécanismes architecturaux et les pattern [Jacobson, et al 1999]. - Le style architectural impose un certain degré d uniformité dans l architecture au niveau des formes. On le définit par le choix d un framework architectural, une infrastructure logicielle, une technique ou un outil de description architectural (le client-serveur et les styles pilotés par les événements). - Le mécanisme architectural est une classe, un groupe de classes ou un pattern. Il fournit une solution commune à un problème commun. Il donne un comportement spécifique aux classes. - Le pattern architectural représente un savoir-faire de conception éprouvé. Il identifie des abstractions, au-delà des classes, des instances et des composants propres à un système Exemple sur le cas d utilisation «Retirer de l argent». La vue architecturale du modèle de conception. On a vu dans le modèle d analyse l existence de trois sous-systèmes : l interface du DAB, la gestion des transactions et la gestion des comptes. Ces sous-systèmes étant nécessaires à la réalisation du cas d utilisation «retirer de l argent», ils sont donc signifiants sur le plan de l architecture. Christiane DAVOINE GUHUR Page /05/02

14 Figure 8 : Structure statique de la vue architecturale du modèle de conception pour le système DAB. La structure statique ne suffit pas, il faut montrer la façon dont les sous-systèmes réalisent les cas d utilisation signifiants pour l architecture à l aide d un diagramme de collaboration. Les objets des classes appartenant aux sous-systèmes dialoguent les uns avec les autres pour exécuter une instance de cas d utilisation. Ces objets échangent des messages comme l indique le diagramme. Figure 9 : diagramme de collaboration du système DAB [Jacobson, et al 1999].. On explique ici le flot de la réalisation du cas d utilisation. Le texte est presque identique au flot d événement du modèle d analyse, mais il est vu sous l angle des sous-systèmes et non des classes. La vue architecturale du modèle de déploiement. Le modèle de déploiement définit l architecture physique du système en termes de nœuds connectés. Ces nœuds sont des unités matérielles sur lesquelles s exécutent les composants logiciels. Les nœuds et connexions peuvent alors être modélisés dans le modèle de déploiement dès l enchaînement d activités des besoins. Dans notre exemple, le client de la banque accède au système par l intermédiaire d un nœud client du DAB qui accède au serveur d applications du DAB pour effectuer les transactions. Le serveur d applications du DAB utilise à son tour, le serveur de données du DAB pour effectuer des transactions spécifiques sur des comptes. Figure 10 : Le modèle de déploiement du système DAB [Jacobson, et al 1999].. Une fois les nœuds définis, il est possible de déployer les fonctionnalités. On déploie chaque sous-système dans son entier sur un seul nœud. Le sous-système interface du DAB est ainsi déployé sur le nœud client du DAB, le sous-système gestion des Christiane DAVOINE GUHUR Page /05/02

15 transactions sur le nœud serveur d applications du DAB, le sous-système gestion des comptes sur le nœud serveur de données du DAB. Figure 11 : La vue architecturale du modèle de déploiement [Jacobson, et al 1999].. La vue architecturale d implémentation. Le modèle d implémentation présente une correspondance directe avec les modèles de conception et de déploiement. Chaque sous-système de service du modèle de conception se traduit par un composant pour chaque type de nœud sur lequel il doit être installé. 2.4 LE PROCESSUS ITERATIF ET INCREMENTAL La démarche séquentielle ou en cascade est acceptable pour des petits projets qui comportent peu de risques et utilisent une technologie éprouvée. En revanche, elle ne convient pas au projet complexe qui comporte un degré élevé d innovation ou de risque. Partant de ce constat, on peut découper le cycle de vie d un grand projet en une succession de petits projets. On adopte alors l approche itérative. On sélectionne un sous-ensemble réduit d exigences et limité au niveau des risques, on effectue une partie de la conception et de la réalisation, on valide à nouveau et ainsi de suite jusqu à ce que le système soit complet. Pour être efficace on établit une séquence de jalons mineurs et majeurs clairement articulés fournissant aux responsables et à l équipe de développement les critères nécessaires au passage d une phase à l autre du cycle de vie du produit. Figure 12 : Une approche itérative au développement [INT1] Qu est-ce qu une itération? Une itération est un mini-projet, c est-à-dire un déroulement plus ou moins complet des principaux enchaînements d activités, aboutissant à une version livrée en interne. Les itérations respectent les cinq enchaînements principaux «besoins, analyse, conception, implémentation, tests». Chaque itération débute par une activité de planification et se termine par une activité d évaluation. Christiane DAVOINE GUHUR Page /05/02

16 2.4.2 La dimension statique du processus Dans le processus itératif et incrémental, la dimension statique du processus correspond à la partie descriptive de celui-ci, la description du qui fait quoi, comment et quand. C est sur ces quatre éléments primaires de modélisation que RUP a choisi de présenter ses concepts clés : - Le qui le travailleur. Celui-ci fait référence au rôle que doit tenir un individu dans le cadre de son travail et de ses responsabilités. L individu désigné comme travailleur possède un ensemble de compétences. Exemple : un concepteur est un individu qui définit les responsabilités, les opérations, les attributs et les relations de dépendances d une ou plusieurs classes et détermine comment elles s insèrent dans l environnement d implémentation [Kruchten 2000]. - Le comment les activités et les étapes d activité. Une activité est une unité de travail qu un individu agissant en tant que travailleur peut être amené à effectuer. Elle doit apparaître comme un élément de planification et de progression. En terme de modélisation objet, un travailleur est un objet actif et les activités effectuées par ce travailleur sont les opérations faites sur cet objet. Exemples d activités: planifier une itération, trouver des cas d utilisation et des acteurs, exécuter un test de performance. Une activité se subdivise en étapes suivant trois catégories : - étapes de réflexion (trouver les acteurs, les cas d utilisation et leurs interactions avec les acteurs), - étapes d actions (constituer les paquetages, représenter le modèle de cas d utilisation par des diagrammes de cas d utilisation), - étapes d inspection (évaluer les résultats). - Le quoi les artefacts. Un artefact est un élément d information fabriqué, modifié ou utilisé par un processus. Il est le matériau dont se servent les travailleurs pour réaliser une activité. En conception orientée objet, les activités sont les opérations d un objet actif et les artefacts sont les paramètres de ces activités. Ils se présentent sous différentes formes, un modèle, un élément de modèle, un document, du code source, un exécutable. Exemple d artefacts : le modèle de conception, le modèle d architecture. Figure 13 : Travailleurs, activités et artefacts [Kruchten 2000]. Christiane DAVOINE GUHUR Page /05/02

17 - Le quand les enchaînements d activités. Une suite d activités qui produit un résultat observable se nomme un enchaînement d activités. Un enchaînement d activités est représenté dans RUP par un diagramme d activités. Les activités, les étapes et les principes sont des guides généraux mis à la disposition de l utilisateur. Les guides d utilisation d outil sont les seuls documents qui font une référence directe à des outils. Ils expliquent comment effectuer certaines étapes à l aide des outils. Des principes et conseils, des canevas, des guides d utilisation d outils complètent la description du processus en donnant davantage d informations à l utilisateur. Figure 14 : Exemple d enchaînement d activités [Kruchten 2000] La dimension dynamique du processus Un processus itératif subdivise le cycle de développement en une succession d itérations. Chaque itération ressemble à une mini-cascade et comporte les activités de gestions des exigences, de conception, d implémentation et d évaluation. L approche itérative permet la prise en compte des changements dans le cahier des charges et au niveau de la stratégie d implémentation. Elle s attaque aux risques et les réduit dès que possible. Elle permet à l organisation de progresser, d acquérir un savoir et de s améliorer. Elle se concentre sur des objectifs réels et tangibles [Kruchten 2000]. Dans une approche itérative, il est important de mesurer l avancement du projet, de vérifier qu on s achemine réellement vers l objectif final, pour cela le processus itératif est organisé en quatre phases dont chacune d elles est ponctuée par un jalon majeur. Figure 15 : Les quatre phases et jalons du processus itératif [Kruchten 2000]. Christiane DAVOINE GUHUR Page /05/02

18 - La phase inception décrit le produit final, et permet de réaliser une étude de rentabilité et de définir les ambitions du projet. Cette phase se conclut par le jalon Objectif de cycle de vie. Dans cette phase on met l accent sur l évaluation de l enveloppe globale du développement. - La phase d élaboration qui permet de planifier les activités et les ressources nécessaires à la réalisation du projet, de spécifier les fonctionnalités et de concevoir l architecture. Elle détermine le jalon de l architecture du cycle de vie. Ici on porte les efforts sur le cahier des charges et sur l élaboration d une maquette exécutable. - La phase construction qui construit le système, en fait évoluer la vision et l architecture jusqu à l obtention d un produit prêt à livrer. Son aboutissement est le jalon de capacité opérationnelle initial. L attention se porte sur la conception détaillée et l implémentation. - La phase transition dont l objectif est de transmettre le produit aux utilisateurs, d assurer le soutien et la maintenance jusqu à ce que l utilisateur soit satisfait. La phase de transition se conclut par le jalon livraison de produit. On s assure ici que le système a un niveau de qualité suffisant pour répondre au cahier des charges. Par rapport à une approche traditionnelle, la démarche itérative atténue les risques, s adapte mieux aux changements et permet aux équipes d acquérir des connaissances pendant le déroulement du projet. Elle offre également un grand niveau de réutilisation et une meilleure qualité globale. Figure 16 : D un cycle de vie séquentiel à un cycle de vie itératif [Kruchten 2000]. 3 LES ENCHAINEMENTS D ACTIVITES DU PROCESSUS Maintenant que nous avons abordé les notions élémentaires qui sous-tendent les pratiques essentielles du Processus unifié, nous allons décrire en détail chacun des enchaînements d activités. Dans RUP, il existe neuf principaux enchaînements d activités : - De modélisation métier - De gestion des exigences - D analyse et de conception - D implémentation - De test - De déploiement Christiane DAVOINE GUHUR Page /05/02

19 - De gestion de projet - De gestion de configuration et des changements - Liés à l environnement. Figure 17 : Les neufs principaux enchaînements d activités du processus [Kruchten 2000]. On peut ajouter des éléments additionnels du processus pour faciliter la compréhension et l utilisation qui sont les principes et conseils, les canevas, les guides d utilisation d outils et les concepts. Chaque enchaînement d activité fait appel au même formalisme dans sa représentation graphique. Chacun d eux est représenté par : - un diagramme «travailleurs et artefacts» qui précise pour un travailleur la responsabilité qui lui incombe dans la production des artefacts. - Un diagramme d enchaînement d activités qui précise la chronologie des activités et le lien de dépendance entre les activités et d autres travailleurs. On reprendra chacun de ces enchaînements en détail dans les paragraphes suivants. C est le diagramme d enchaînement des activités qui permet de passer de la conception vers le modèle système. 3.1 LA MODELISATION METIER Pourquoi modéliser le métier? La modélisation métier est une technique qui permet de comprendre les processus métier d une entreprise. On modélise un métier pour comprendre sa structure et sa dynamique, pour s assurer que tous les intervenants ont une vision commune à l organisation et pour déduire les cahiers des charges des futurs systèmes informatiques de cette organisation. On modélise un métier lorsque le nombre d utilisateurs et la quantité d informations sont importants Comment modéliser le métier? La modélisation du métier est prise en charge par deux types de modèles UML : le modèle des cas d utilisation et le modèle objet : - Le modèle des cas d utilisation est décrit par les diagrammes des cas d utilisation. - Le modèle objet métier est un modèle interne du métier. Il décrit la façon dont chaque cas d utilisation du métier est réalisé par un groupe de travailleurs utilisant un ensemble d entités métier et d unités de travail. Chaque réalisation de cas d utilisation métier peut être montrée sous forme de diagrammes d interactions et de diagrammes d activités [Jacobson, et al 1999]. Christiane DAVOINE GUHUR Page /05/02

20 Figure 18 : Travailleurs et artefacts dans les activités de modélisation métier [Kruchten 2000]. De plus, il existe deux autres artefacts : - Les spécifications métier complémentaires : les définitions, les règles, les procédures et les normes. - Un glossaire qui définit les termes importants utilisés dans le métier. Un avantage de cette approche de la modélisation du métier est qu elle montre bien les dépendances entre les modèles métier et les modèles du système informatique utilisés dans ce métier. Les travailleurs métier deviennent les acteurs du système informatique. Les actions et comportements des travailleurs métiers déterminent les cas d utilisation du système, pour les parties qu on souhaite automatiser. A partir des entités métier on peut déduire les classes d entités du modèle [Kruchten 2000]. Figure 19 : Des modèles métier aux modèles systèmes [Kruchten 2000] Les enchaînements d activités La figure ci-dessous montre un enchaînement typique de modélisation métier. Dans un premier temps, il s agit d identifier les processus métier clés et les acteurs métier concernés, de les décrire sous forme d un modèle de cas d utilisation. Ensuite, il convient de détailler les descriptions des cas d utilisation métier mis en évidence, d identifier les rôles, de définir les responsabilités, les opérations, les attributs et les relations entre les travailleurs et les entités métier. Ces activités relèvent de la compétence du concepteur métier. Une fois ces modèles élaborés, l auditeur du modèle se charge de vérifier qu ils représentent correctement l organisation. Christiane DAVOINE GUHUR Page /05/02