Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

8820448.doc ___________________________________________________________________

8820448.doc ______________________________________________________________________________ Méthodologie des systèmes d'information - UML Cours du Cycle Probatoire ___________________________________________________________________ DI GALLO Frédéric Page 1 15/10/200808 UML UP 8820448.doc ______________________________________________________________________________ Cours dispensé par Annick Lassus. CNAM ANGOULEME 2000-2001 METHODOLOGIES METHODOLOGIES DES SYSTEMES DES SYSTEMES D'INFORMATION D'INFORMATION : : UML UML ___________________________________________________________________ DI GALLO Frédéric Page 2 15/10/200808 8820448.doc ______________________________________________________________________________ UP - LE PROCESSUS UNIFIÉ............................5 I. LE PROCESSUS DE DÉVELOPPEMENT : NOUVELLE APPROCHE.....................................................5 II. LE PROCESSUS UNIFIÉ : CADRE GÉNÉRAL............................................................................6 III. LE PROCESSUS UNIFIÉ EST PILOTÉ PAR LES CAS D’UTILISATION..............................................6 3.1) Présentation.......................................................................................................6 3.2) Exemple: guichet de banque..............................................................................6 IV. LE PROCESSUS UNIFIÉ EST CENTRÉ SUR L’ARCHITECTURE......................................................8 4.1) Liens entre cas d’utilisation et architecture ?....................................................8 4.2) Marche à suivre :................................................................................................8 V. LE PROCESSUS UNIFIÉ EST ITÉRATIF ET INCRÉMENTAL............................................................8 5.1) Avantages d’un processus itératif contrôlé........................................................9 VI. LE CYCLE DE VIE DU PROCESSUS UNIFIÉ............................................................................9 6.1) Présentation du cycle de vie de UP..................................................................10 6.2) Exemple sur les différents modèles...................................................................11 VII. CONCLUSION : UN PROCESSUS INTÉGRÉ.........................................................................12 APPROCHE DU LANGAGE UML...................17 I. LES MÉTHODES OBJET ET LA GENéSE D'UML....................................................................17 1.1) Méthodes ?.......................................................................................................17 1.2) A quoi sert UML ?............................................................................................18 1.3) Les points forts d'UML.....................................................................................20 1.4) Les points faibles d'UML..................................................................................20 II. CARACTÉRISTIQUES DE LA MÉTHODE UML......................................................................21 2.1) UML est basé sur un méta-modèle...................................................................21 2.2) UML: visualisation complète d'un système .....................................................21 III. INTRODUCTION À LA NOTATION UML.............................................................................22 3.1) La notion d'objet...............................................................................................22 3.2) Les méthodes objet...........................................................................................22 3.3) Intérêt d'une méthode objet..............................................................................22 3.4) La normalisation OMG....................................................................................23 IV. MODÉLISER AVEC UML .............................................................................................24 4.1) Qu'est-ce qu'un modèle ?.................................................................................24 4.2) Comment modéliser avec UML ?.....................................................................25 4.3) Modélisation UML...........................................................................................29 INTRODUCTION AU LANGAGE UML..........39 I. LES CAS D’UTILISATION..................................................................................................39 1.1) Objectifs des cas d’utilisation..........................................................................39 1.2) Éléments constitutifs des cas d’utilisation.......................................................40 1.3) Description des cas d’utilisation......................................................................41 1.4) Structuration des cas d’utilisation...................................................................43 1.6) Notion de paquetage.........................................................................................45 1.7) Exercice TVServices (parties I et II)................................................................45 II. LE DIAGRAMME DE CLASSES...........................................................................................50 ___________________________________________________________________ DI GALLO Frédéric Page 3 15/10/200808 8820448.doc ______________________________________________________________________________ 2.1) Les classes........................................................................................................50 2.2) Les associations................................................................................................51 III. LE DIAGRAMME DE COLLABORATION...............................................................................56 3.1) Interaction........................................................................................................56 3.2) De nouveaux stéréotypes de classe..................................................................56 3.3) Les Messages :.................................................................................................58 3.4) Exercice TVServices (parties III et IV).............................................................60 3.5) TP de synthèse: Création d'un site Web...........................................................63 ___________________________________________________________________ DI GALLO Frédéric Page 4 15/10/200808 8820448.doc ______________________________________________________________________________ METHODOLOGIE – CNAM ANGOULEME 2000-2001 METHODOLOGIE – CNAM ANGOULEME 2000-2001 UP - LE PROCESSUS UNIFIÉ UP - LE PROCESSUS UNIFIÉ Comparaison des méthodologies UP et Merise: UP MERISE Cycle de vie itératif et incrémental Méthode générique Séquentiel I. Le processus de développement : nouvelle approche Dans une démarche traditionnelle, le processus de développement était caractérisé par : • Un processus de type séquentiel : développement organisé en phases qui regroupent des étapes, elles mêmes décomposées en tâche. • Les niveaux de découpage coïncident : la fin d’une phase correspond à la conclusion de ses étapes, qui elles mêmes se terminent avec l’accomplissement des tâches qui les composent. Dans une approche objet tout change : • Le processus est de type itératif ; • Les découpages ne coïncident pas : les activités (taches, phases, étapes, etc…) se déroulent dans plusieurs dimensions. La maîtrise des processus de développement implique pourtant une organisation et un suivi des activités : c’est ce à quoi s’attachent les différentes méthodes qui s’appuient sur l’utilisation du langage UML pour modéliser un système d’information. UP (Unified Process) est une méthode générique de développement de logiciel. Générique signifie qu'il est nécessaire d'adapter UP au contexte du projet, de l'équipe, du domaine et/ou de l'organisation (exemple: R.UP ou X.UP). C'est, entre parenthèses, plus ou moins vrai pour toute méthode, qu'elle se définisse elle-même comme générique ou pas. Il existe donc un certain nombre de méthodes issues de UP. ___________________________________________________________________ DI GALLO Frédéric Page 5 15/10/200808 8820448.doc ______________________________________________________________________________ II. Le processus unifié : cadre général Le processus unifié est un processus de développement logiciel : il regroupe les activités à mener pour transformer les besoins d’un utilisateur en système logiciel. Caractéristiques essentielles du processus unifié : - Le processus unifié est à base de composants, - Le processus unifié utilise le langage UML (ensemble d'outils et de diagramme), - Le processus unifié est piloté par les cas d’utilisation, - Centré sur l’architecture, - Itératif et incrémental. III. Le processus unifié est piloté par les cas d’utilisation 3.1) Présentation L’objectif principal d’un système logiciel est de rendre service à ses utilisateurs ; il faut par conséquent bien comprendre les désirs et les besoins des futurs utilisateurs. Le processus de développement sera donc centré sur l'utilisateur. Le terme utilisateur ne désigne pas seulement les utilisateurs humains mais également les autres systèmes. L’utilisateur représente donc une personne ou une chose dialoguant avec le système en cours de développement. Ce type d’interaction est appelé cas d’utilisation. Les cas d’utilisation font apparaître les besoins fonctionnels et leur ensemble constitue le modèle des cas d’utilisation qui décrit les fonctionnalités complètes du système. 3.2) Exemple: guichet de banque retirer de l'argent mettre de l'argent déposer de l'argent virement entre comptes client de la banque employé de la banque On va se demander, en premier, quels sont les utilisateurs du système (pas forcément des utilisateurs physiques, mais plutôt des rôles). Ici, l'employé est aussi un client de la banque. On a donc une personne physique pour deux rôles. Nous ne sommes pas dans une approche de type fonctionnelle mais une approche pilotée par des cas d'utilisation. ___________________________________________________________________ DI GALLO Frédéric Page 6 15/10/200808 Acteur Cas d'utilisation 8820448.doc ______________________________________________________________________________ 3.3) Stratégie des cas d’utilisation Que doit pouvoir faire le système pour chaque utilisateur ? Les cas d’utilisation ne sont pas un simple outil de spécification des besoins du système. Ils vont complètement guider le processus de développement à travers l’utilisation de modèles basés sur l’utilisation du langage UML A partir du modèle des cas d’utilisation, les développeurs créent une série de modèles de conception et d’implémentation réalisant les cas d’utilisation. Chacun des modèles successifs est ensuite révisé pour en contrôler la conformité par rapport au modèle des cas d’utilisation. Enfin, les testeurs testent l’implémentation pour s’assurer que les composants du modèle d’implémentation mettent correctement en œuvre les cas d’utilisation. Les cas d’utilisation garantissent la cohérence du processus de développement du système. S’il est vrai que les cas d’utilisation guident le processus de développement, ils ne sont pas sélectionnés de façon isolée, mais doivent absolument être développés "en tandem" avec l’architecture du système. ___________________________________________________________________ DI GALLO Frédéric Page 7 15/10/200808 8820448.doc ______________________________________________________________________________ IV. Le processus unifié est centré sur l’architecture Dès le démarrage du processus, on aura une vue sur l'architecture à mettre en place. L’architecture d’un système logiciel peut être décrite comme les différentes vues du système qui doit être construit. L’architecture logicielle équivaut aux aspects statiques et dynamiques les plus significatifs du système. L’architecture émerge des besoins de l’entreprise, tels qu’ils sont exprimés par les utilisateurs et autres intervenants et tels qu’ils sont reflétés par les cas d’utilisation. Elle subit également l’influence d’autres facteurs : - la plate-forme sur laquelle devra s’exécuter le système ; - les briques de bases réutilisables disponibles pour le développement ; - les considérations de déploiement, les systèmes existants et les besoins non fonctionnels (performance, fiabilité..) 4.1) Liens entre cas d’utilisation et architecture ? Tout produit est à la fois forme et fonction. Les cas d’utilisation doivent une fois réalisés, trouver leur place dans l’architecture. L’architecture doit prévoir la réalisation de tous les cas d’utilisation. L’architecture et les cas d’utilisation doivent évoluer de façon concomitante. 4.2) Marche à suivre : L’architecte crée une ébauche grossière de l’architecture, en partant de l’aspect qui n’est pas propre aux cas d’utilisation (plate forme..). Bien que cette partie de l’architecture soit indépendante des cas d’utilisation. L’architecte doit avoir une compréhension globale de ceux ci avant d’en esquisser l’architecture. Il travaille ensuite, sur un sous ensemble des cas d’utilisations identifiés, ceux qui représentent les fonctions essentielles du système en cours de développement. L’architecture se dévoile peu à peu, au rythme de la spécification et de la maturation des cas d’utilisation, qui favorisent, à leur tour, le développement d’un nombre croissant de cas d’utilisation. Ce processus se poursuit jusqu’à ce que l’architecture soit jugée stable. V. Le processus unifié est itératif et incrémental Le développement d’un produit logiciel destiné à la commercialisation est une vaste entreprise qui peut s’étendre sur plusieurs mois. On ne va pas tout développer d’un coup. On peut découper le travail en plusieurs parties qui sont autant de mini projets. Chacun d’entre eux représentant une itération qui donne lieu à un incrément. Une itération désigne la succession des étapes de l’enchaînement d’activités, tandis qu’un incrément correspond à une avancée dans les différents stades de développement. ___________________________________________________________________ DI GALLO Frédéric Page 8 15/10/200808 8820448.doc ______________________________________________________________________________ Le choix de ce qui doit être implémenté au cours d’une itération repose sur deux facteurs : • Une itération prend en compte un certain nombre de cas d’utilisation qui ensemble, améliorent l’utilisabilité du produit à un certain stade de développement. • L’itération traite en priorité les risques majeurs. Un incrément constitue souvent un additif. A chaque itération, les développeurs identifient et spécifient les cas d’utilisations pertinents, créent une conception en se laissant guider par l’architecture choisie, implémentent cette conception sous forme de composants et vérifie uploads/Industriel/ methodologie-uml-cours-du-cycle-b-du-cnam.pdf