Manuel uml-poweramc

14 164 vues

Publié le

Publié dans : Formation
1 commentaire
6 j’aime
Statistiques
Remarques
Aucun téléchargement
Vues
Nombre de vues
14 164
Sur SlideShare
0
Issues des intégrations
0
Intégrations
4
Actions
Partages
0
Téléchargements
474
Commentaires
1
J’aime
6
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Manuel uml-poweramc

  1. 1. Expression et analyse des besoins en UML avec PowerAMC Manuel d’utilisation Version 1.1 Février 2005 Réalisé par la Direction des systèmes dinformation du CNRS (DSI)
  2. 2. Table des matières Table des matièresTABLE DES MATIERES __________________________________________________________________ 3A PROPOS DE CE MANUEL ________________________________ ______________________________ 5MISES A JOUR ________________________________________________________________________ 7PRESENTATION GLOBALE DE LA METHODE _______________________________________________ 9VUE METIER _________________________________________________________________________ 11 1. Les acteurs 11 2. Les processus métier 13 3. Le modèle du domaine 16VUE SYSTEME INFORMATIQUE__________________________________________________________ 17 1. Le contexte statique 17 2. Les cas d’utilisation 19 3. Le contexte dynamique 30 4. Le modèle du domaine affiné 32VUE APPLICATIVE ____________________________________________________________________ 37 1. La maquette 37 2. La navigation (optionnel) 39 3. Les classes participantes (optionnel - début de conception de l’architecture) 41Manuel d’utilisation UML - PowerAMC Février 2005 3 / 42
  3. 3. Table des matières A propos de ce manuel Ce manuel d’utilisation a pour but de décrire la méthode d’expression et d’analyse des besoins, utilisant le langage de modélisation UML et supportée par l’outil PowerAMC. Il s’adresse aux concepteurs des équi- pes projet, qui partent d’une expression initiale des besoins par des utilisateurs ou des maîtres d’ouvrage. UML (Unified Modeling Langage) n’est pas une méthode de développement mais un langage de modélisa- tion qui définit des standards relatifs à la modélisation orientée objet. Ce langage permet de mettre en œu- vre neuf diagrammes différents . Dans la mise en œuvre d’une méthode de développement, l’un ou l’autre des diagrammes est choisi en fonction des concepts que l’on veut représenter à une étape de développe- ment donnée. Les concepts permettent de couvrir les étapes, depuis l’expression des besoins jusqu’au co- dage. Diagrammes Diagrammes de cas dutilisation de séquence Diagrammes Diagrammes de classes de collaboration Diagrammes dobjets Diagrammes dactivités Diagrammes de composants Diagrammes Diagrammes détats-transitions de déploiement La démarche définie dans le présent guide, a pour objectifs de couvrir l’expression et l’analyse des be- soins ; elle utilise cinq diagrammes UML : deux diagrammes statiques (diagrammes de classes et de cas d’utilisation), trois diagrammes dynamiques (diagramme d’activités, de collaboration et de séquence). L’expression et l’analyse des besoins se matérialise par des documents Word de différents niveaux, dans lesquels on insère des diagrammes UML produits à l’aide de l’outil PowerAMC. Les plans types de ces do- cuments sont disponible s depuis le site développement Web : http://www.dsi.cnrs.fr/bureau_qualite/developpement-web/guides-modeles/guides-modeles.asp : • Note de cadrage (inclut des diagrammes de la vue métier) • Exigences fonctionnelles (inclut des diagrammes de la vue système informatique) • Conception de l’interface utilisateur (inclut des diagrammes de la vue applicative)Manuel d’utilisation UML - PowerAMC Février 2005 5 / 42
  4. 4. Table des matières Remarques : • Le terme stéréotype est fréquemment utilisé dans ce guide et mérite une définition préalable : « Ex- tension du vocabulaire UML, qui permet de créer de nouvelles variétés déléments constitutifs dé- rivés déléments existants, mais qui sont spécifiques à votre problème. » [PowerAMC MOO – Guide de l’utilisateur]. Exemple d’utilisation de stéréotypes : dans la première étape de la démarche, qui s’intéresse aux processus métier du domaine étudié, l concept « processus métier » n’étant pas directement e supporté par UML, un stéréotype de cas d’utilisation est utilisé. • Le terme système est utilisé dans ce document pour désigner de manière globale l’application in- formatique. Utilisation de ce manuel • Le premier chapitre « Présentation globale de la méthode » donne un aperçu global de la méthode utilisée et montre la progressivité de l’approche. • Les autres chapitres se lisent a priori dans l’ordre, chacun d’entre eux décrit une étape de la dé- marche de modélisation. Naturellement, le concepteur peut être amené à revenir sur l’un ou l’autre des chapitres dans le c adre des itérations successives qu’il va mettre en œuvre pour son projet. Chaque chapitre sépare la présentation des concepts manipulés et leur représentation avec l’outil PowerAMC. Utilisation de l’outil PowerAMC • Un modèle type PowerAMC est mis à la disposition des concepteurs. Ce modèle permet de démar- rer une modélisation avec les packages et les diagrammes déjà créés, ainsi que quelques exe mples de concepts dans chaque diagramme. Le nom du modèle est : Modèle – application web.moo. Ce modèle contient également un exemple de rapport, produit à l’aide d’un modèle de rapport (il inclut les diagrammes créés dans chacune des vues, ainsi que les classes définies avec leur liste d’attributs et d’opérations). • Par ailleurs, des exemples de projets modélisés selon la démarche contenue dans le présent guide sont disponibles. Les documents Word et modèles PowerAMC sont mis à disposition des équipes DSI dans le répertoire PROJETS de TOULOUSE Uml/DSI/Démarche UML DSI. • Pour accéder au modèle type et aux exemples PowerAMC, le fichier à ouvrir est l’espace de tra- vail : « Espace de travail - Démarche UML DSI.sws ». Conventions Les noms de fenêtre, de zone de dialogue ou de zone de saisie apparaissent entre guillemets. Les noms de commande d’un menu apparaissent en gras italique séparés par des /, par exemple : menu Fi- chier/Imprimer… Ce pictogramme identifie des remarques utiles mais sans incidence sur le cours des instructions exposées. Ce pictogramme identifie des informations à lire et/ou à exécuter impérativement qui peuvent influencer le cours des instructions suivantes. Assistance Pour des compléments d’information, vous pouvez contacter le groupe de travail UML à la DSI : « Liste Uml(at)dsi.cnrs.fr ».6 / 42 Février 2005 Manuel d’utilisation UML - PowerAMC
  5. 5. Table des matières Mises à jour V 0.1 Septembre Version initiale du manuel d’utilisation PowerAMC pour 2003 l’expression des besoins avec UML, créée suite à la formation du groupe de travail. V1.0 Janvier 2005 Création d’un manuel séparé de présentation de PowerAMC. Mise à jour de la démarche suite aux retours d’expérience de projets pilotes et ajouts de compléments issus de l’état de l’art (en particulier, conseils pour la rédaction des cas d’utilisation). V1.1 Février 2005 Ajout d’un chapitre « Modèle du domaine affiné » dans la vue système informa tique, décrivant les concepts du diagramme de classe et mise à niveau du chapitre « Modèle du domaine ». Pour une première prise en main de PowerAMC, pour quelques trucs et astuces, pour en savoir plus sur les rapports, ou pour connaître la liste des stéréotypes définis, consulter le « Manuel d’utilisation de PowerAMC : Généralités- Rapports-Stéréotypes », accessible dans le répertoire PROJETS de TOULOUSE Uml/DSI/PowerAMC ou depuis le site développement Web : http://www.dsi.cnrs.fr/bureau_qualite/developpement-web/guides- modeles/guides-modeles.asp. Avec la version 9 de PowerAMC, ne pas utiliser de fonctions sur les symboles car ces fonctions provoquent des dégradations du modèle irréversibles. Ces fonctions sont accessibles à partir du menu principal Symbole/ ou bien à partir du menu contextuel sur un objet (clic droit de la souris et Disposition ou Cacher le symbole…).Manuel d’utilisation UML - PowerAMC Février 2005 7 / 42
  6. 6. Présentation globale de la méthode Présentation globale de la méthodeLa première étape de la démarche consiste à mieux connaître et comprendre les processus dans lesquels va s’intégrerle futur système informatique. C’est ce qu’on appelle la vue métier.Il s’agit à ce niveau d’identifier les acteurs, les processus et les concepts métiers qui composent le domaine étudié.Les concepts métier sont modélisés sous forme de classes. La description des processus métier permet de définirprécisément le périmètre que couvrira le futur système informatique, c’est-à-dire les activités qui vont faire l’objetd’une automatisation.Vue métier Proce ssus métier Modèle du domaine : concepts métierActeurs Activités d’un processus métierL’étape suivante s’intéresse au système informatique. On représente dans un premier temps le contexte d’utilisation :le système vu comme une boîte noire et les acteurs qui interagissent avec lui (contexte statique). Ensuite on décrit lesservices rendus aux différents utilisateurs sous forme de cas d’utilisation. Il est possible de compléter ces descrip-tions par des représentations de la dynamique des échanges de messages entre le système et les utilisateurs (contextedynamique). Ces différentes représentations forment la vue système informatique.Vue système Cas d’utilisation Modèle du domaineinformatique affinéContexte statique Contexte dynamique = di agramme de collaboration ou = diagramme de séquenceManuel d’utilisation UML - PowerAMC Février 2005 9 / 42
  7. 7. Présentation globale de la méthode Enfin, la vue applicative permet de donner une vision concrète du futur système grâce à une maquette et à la modélisa- tion des principes de navigation entre les pages. Egalement, il est possible de représenter un début d’architecture applicative : la séparation entre les couches Dialogue, Traitements applicatifs et Données. Vue applicative Navigation entre les pages (optionnel) Classes participantes « Dialogue, contrôleur, enti- té » Maquette En pratique, les diagrammes de la vue métier sont réalisés en premier. Puis les diagrammes des vues système informatique et applicative en parallèle. Des itérations successives entre ces deux vues permettent d’affiner les différents diagrammes. Par exemple, la réalisation d’une maquette permet de préciser la spécification des cas d’utilisation avec les utilisateurs. De même, l’identification des classes participantes peut permettre de compléter le modèle du domaine affiné. L’expression et l’analyse des besoins se matérialisent par des documents Word de différents niveaux, dans lesquels on insère des diagrammes UML produits à l’aide de l’outil PowerAMC. Les plans types de ces documents sont dis- ponibles depuis le site développement Web : http://www.dsi.cnrs.fr/bureau_qualite/developpement-web/guides- modeles/guides-modeles.asp : • Note de cadrage (inclut des diagrammes de la vue métier) • Exigences fonctionnelles (inclut des diagrammes de la vue système informatique) • Conception de l’interface utilisateur (inclut des diagrammes de la vue applicative) Dans l’outil PowerAMC, les différents diagrammes prennent place dans des packages qui structurent le modèle. Le modèle type DSI (Modèle – application web.moo) se présente ainsi :10 / 42 Février 2005 Manuel d’utilisation UML - PowerAMC
  8. 8. Vue métier Vue métier La vue métier permet de mieux connaître et comprendre les processus dans lesquels va s’intégrer le futur système informatique.1. Les acteurs Pour démarrer, les acteurs métier concernés par le système d’information sont identifiés. 1.1. Modélisation des acteurs métiers • Identifiez les acteurs • Les acteurs sont décrits par une abstraction ne retenant que le rôle qu’ils jouent dans le cadre du métier étudié. • Il est possible de préciser si le rôle est attribué à une fonction au sein du CNRS ou une structure. • Le nom de l’acteur commence par une majuscule. Entre parenthèses, mettre à la fin du nom de l’acteur une abréviation si possible connue au CNRS. Exemple : Acteurs • Identifiez les relations de généralisation entre acteurs • Si un ensemble d’acteurs jouent le même rôle, on peut créer un acteur généralisé, qui permet de factoriser ce rôle commun. Exemple :Manuel d’utilisation UML - PowerAMC Février 2005 11 / 42
  9. 9. Vue métier 1.2. Utilisation de PowerAMC : diagramme de cas d’utilisation Dans le package « Vue métier », un diagramme de cas d’utilisation nommé « Acteurs », contient les acteurs du système, représentés sous forme d’acteurs PowerAMC. Dans le cas de fonctions CNRS, stéréotypez les acteurs <<Fonction>>. Dans le cas de structures, stéréotypez les acteurs <<Structure>>.12 / 42 Février 2005 Manuel d’utilisation UML - PowerAMC
  10. 10. Vue métier2. Les processus métier A ce niveau, il s’agit dans un premier temps de décrire les fonctions de l’organisme qui sont au cœur de son métier, les acteurs externes concernés et les échanges entre processus. Dans un deuxième temps, les processus les plus significatifs pour le projet sont détaillés sous forme d’événements déclencheurs et d’enchaînements d’activités. 2.1. Modélisation des processus métier • Identifiez les processus métier du domaine étudié • Le domaine étudié est décrit sous forme de processus métier et d’échanges avec les acteurs exter- nes. Des dépendances entre processus peuvent être représentées.Exemple : Dépendance 2.2. Utilisation de PowerAMC : diagrammes de cas d’utilisation Dans le package «Vue métier», un diagramme de cas d’utilisation nommé «Les processus métier» , contient les processus, représentés sous forme de cas d’utilisation PowerAMC, stéréotypés <<Processus>>.Manuel d’utilisation UML - PowerAMC Février 2005 13 / 42
  11. 11. Vue métier Les acteurs sont copiés sous forme de raccourcis depuis le diagramme des acteurs de la vue métier. 2.3. Modélisation des activités concourant a u processus métier étudié • Identifiez les activités • Le processus est décrit sous forme d’un enchaînement d’activités . • Des transitions relient les activités. Des synchronisations représentent l’attente de plusieurs événements pour la réalisation d’une activité. Des décisions représentent des choix de réalis ation d’une ou l’autre activité en fonction de conditions. • Chaque diagramme commence par un début (un seul début) et se termine par une ou plusieurs fin(s). • Des états d’objets peuvent être représentés afin de modéliser les concepts sous-jacents (ces concepts permettent d’initialiser le modèle du domaine, cf. chapitre suivant). • Si le processus est organisé, on peut modéliser les acteurs participants au processus ainsi que l’enchaînement des opérations de cette procédure. Exemple : Acteur Activité Etat d’objet (concept du domaine) Synchronisation Périmètre du système informatique 2.4. Utilisation de PowerAMC : diagrammes d’activités Dans le package «Vue métier», un diagramme d’activités est créé par processus que l’on souhaite décrire en détail.14 / 42 Février 2005 Manuel d’utilisation UML - PowerAMC
  12. 12. Vue métier Le nom de chaque diagramme reprend le nom du processus qui est décrit. Le diagramme contient l’enchaînement des activités du processus. Pour représenter les acteurs dans les colonnes, créez des unités d’organisation (reprendre si possible l’abréviation du nom d’un rôle, d’une fonction ou structure : pour des raisons de taille de la colonne). Pour créer un état d’objet (concept métier), créez une nouvelle classe dans le diagramme de classes «Mo- dèle du domaine ». Copiez cette classe et collez la en raccourci dans le diagramme d’activités : un état d’objet se crée sur le diagramme. Saisissez le nom de l’état dans la fenêtre « Propriétés de l’état d’objet ». On peut modéliser la référence à un autre processus, en le représentant sous forme d’activité, stéréotypée <<Processus>>. Matérialisez le périmètre du système en entourant avec un élément de dessin les activités qui vont être sup- portées par le système informatique.Manuel d’utilisation UML - PowerAMC Février 2005 15 / 42
  13. 13. Vue métier 3. Le modèle du domaine Le modèle du domaine permet de représenter les concepts du domaine, les objets métier, c’est-à-dire les in- formations créées, transformées ou manipulées par les experts du domaine. Les concepts sont modélisés dans un diagramme de classes. L’objectif de ce diagramme est que l’expert du domaine y retrouve le vocabulaire de son métier. Un concept fait partie du domaine s’il est nécessaire à la compréhension du problème et s’il répond à des exigences fonctionnelles visibles par un utilisateur. Les concepts liés à la mise en œuvre du système informatique (contraintes techniques par exe mple) ne doi- vent pas apparaître à ce niveau, il ne s’agit pas de décrire le modèle de données de l’application mais d’identifier les principaux concepts ainsi que leur définition. On aboutit ainsi à un glossaire du voc abulaire métier. Lors de la description des cas d’utilisation (chapitre suivant : vue système informatique), le modèle du d o- maine est affiné : complété par de nouvelles classes ou attributs, par des définitions et règles de gestion, par les types et taille s des attributs... 3.1. Modélisation des concepts du domaine • Identifiez les concepts du domaine • Modélisez les concepts sous forme de classes (convention d’écriture : majuscule à la première let- tre pour les noms de classe). Exemple : Classe • Précisez la définition des concepts dans un glossaire. 3.2. Utilisation de PowerAMC : diagramme de classes Dans le package «Vue métier», un diagramme de classes, nommé «Modèle du domaine», contient les clas- ses du domaine.16 / 42 Février 2005 Manuel d’utilisation UML - PowerAMC
  14. 14. Vue système informatique Vue système informatiqueLa vue système informatique permet de s’intéresser au contexte d’utilisation du système puis au x services rendus auxdifférents utilisateurs (cas d’utilisation) et d’affiner le modèle du domaine.1. Le contexte statique On modélise ici le système informatique dans son environnement, en le représentant comme une « boîte noire », en relation avec des acteurs externes. Ce diagramme est utile pour avoir une vision générale externe du système. De plus il permet de donner les premiers éléments de volumétrie des utilisateurs. 1.1. Modélisation du contexte statique du système • Représentez le système étudié • Le système est représenté au centre du diagramme, avec les acteurs en relation autour. • Identifiez les acteurs • Modélisez les acteurs externes au système : ils attendent un ou plusieurs services du système, ils interagissent avec le système par envoi ou réception de messages. Les acteurs sont décrits par une abstraction ne retenant que le rôle qu’ils jouent vis -à-vis du système. • Les acteurs externes peuvent être des acteurs déjà identifiés au niveau métier ou bien d’autres ac- teurs liés au système informatique, par exemple un « Administrateur ». • Pour chaque acteur humain, précisez le nombre susceptible d’intervenir simultanément sur le sys- tème. Exemple : 1.2. Utilisation de PowerAMC : diagramme de cas d’utilisationManuel d’utilisation UML - PowerAMC Février 2005 17 / 42
  15. 15. Vue système informatique Dans le package « Vue système informatique », un diagramme de cas d’utilisation nommé « Contexte stati- que », contient le système, représenté sous forme d’un cas d’utilisation PowerAMC, stéréotypé <<Sy s- tème>>. Les acteurs sont copiés sous forme de raccourcis depuis le diagramme des acteurs de la vue métier ou bien créés dans ce diagramme.18 / 42 Février 2005 Manuel d’utilisation UML - PowerAMC
  16. 16. Vue système informatique2. Les cas d’utilisatio n L’identification et la description des cas d’utilisation sont certainement la partie la plus délicate de la démarche. Les conseils donnés ci-après sont issus des retours d’expérience des projets DSI et de référen- ces bibliographiques, dont en particulier : « Rédiger des cas d’utilisation efficaces » d’Alistair Cock - burn. Les cas d’utilisation (= use cases) permettent de capturer et décrire les besoins fonctionnels d’un système. Ils illustrent le comportement du système, suite à des stimulations externes, via la description des actions exécutées et les réponses fournies à ces stimulations. Les cas d’utilisation permettent d’exprimer les besoins des utilisateurs, pas la solution. Les cas d’utilisation modélisent les différents services rendus par le système aux utilisateurs. Un cas d’utilisation apporte une valeur ajoutée notable dans l’utilisation du système à l’acteur concerné. Les cas d’utilisation sont le fil conducteur du projet : au niveau de la planification, de l’analyse, de la conception puis des scénarios de tests. Tous les cas d’utilisation sont identifiés puis chacun d’eux est étudié plus précisément. Certains cas d’utilisation peuvent ne pas être décrits dans un premier temps : lorsque l’on n’a pas suffisamment d’informations de la part des utilisateurs ou lorsque le cas d’utilisation fait partie d’une itération ou d’une version future du système. Les cas d’utilisation sont spécifiés de manière textuelle. Pour certains d’entre eux, la spécification peut être complétée par un diagramme dynamique simple : le diagramme de séquence des messages. 2.1. Modélisation et spécification des cas d’utilisation Il s’agit ici de modéliser les fonctionnalités du système telles quelles sont perçues par les utilisateurs exter- nes, également appelés acteurs externes. L’ensemble des cas d’utilisation et des acteurs intervenant dans le système est représenté sur un diagramme, appelé « diagramme des cas d’utilisation ». L’objectif de ce diagramme est de faire clairement apparaître quels sont les acteurs qui participent aux cas d’utilisation : un acteur et un cas d’utilisation sont reliés par une association qui signifie « participe à ». Sur le diagramme, on distingue les acteurs principaux qui réalisent le cas d’utilisation pour atteindre un ob- jectif (récupèrent un résultat du système), des acteurs secondaires qui sont sollicités par le système : les acteurs principaux sont positionnés à gauche du cas d’utilisation et les acteurs secondaires à droite. On peut utiliser les acteurs identifiés au niveau métier ou identifier de nouveaux rôles vis -à-vis du système, en utilisant la relation de généralisation entre acteurs. Les trois exemples ci-dessous sont équiv alents :Manuel d’utilisation UML - PowerAMC Février 2005 19 / 42
  17. 17. Vue système informatique • Identifiez les cas d’utilisation Pour chaque acteur, recherchez les différents objectifs qu’il a d’utiliser le système. Chaque cas d’utilisation est nommé par un verbe à l’infinitif, indiquant un objectif de l’acteur principal, de son point de vue. Un cas d’utilisation correspond à « une raison d’être du système », « à une session utilisateur », « à une tâche utilisateur avant la pause café »… Pour chaque cas d’utilisation, vérifiez qu’il fournit une valeur ajoutée notable aux acteurs principaux et contrôlez qu’un événement en déclenche l’exécution. Uniformisez le niveau d’abstraction des cas d’utilisation : • un cas d’utilisation doit représenter une tâche métier pour les acteurs (partir de la description des processus métier : une activité d’un processus métier donne généralement lieu à un ou plusieurs cas d’utilisation) ; • un cas d’utilisation n’est pas une fonction atomique mais un ensemble de séquences d’actions (des scénarios). Certains cas d’utilisation peuvent correspondre à des « sous fonctions informatiques » pour des raisons de lisibilité ou parce que plusieurs cas d’utilisation y font appel (voir ci-après la relation « include »)… Mais il n’est parfois pas la peine de les rédiger : par exemple, le cas d’utilisation « s’authentifier ». Exemple :20 / 42 Février 2005 Manuel d’utilisation UML - PowerAMC
  18. 18. Vue système informatique • Structurez la spécification Il peut être souhaitable de structurer la spécification en créant plusieurs diagrammes de cas d’utilisation. Les critères de regroupement des cas d’utilisation peuvent être les domaines d’expertise métier, les itéra- tions définies, les acteurs concernés. Remarque : les cas d’utilisation ne s’enchaînent pas entre eux : si on veut décrire un enchaînement, le faire au n iveau de la vue métier. • Identifiez les dépendances entre cas d’utilisation • Relation « include » : Si un même enchaînement peut être utilisé plusieurs fois (partageable), il peut faire l’objet d’un cas d’utilisation à part, inclus dans d’autres cas d’utilisation. : ce sous cas d’utilisation permet de factoriser la partie commune de la description de plusieurs cas d’utilisation. Les cas d’utilisation qui l’incluent, précisent explicitement l’endroit où il est inclus dans les scénarios (cf. paragraphe suivant). Un cas d’utilisation inclus n’est jamais exécuté seul, mais seulement en tant que partie d’un cas plus vaste, il n’a pas d’acteur déclencheur. • Relation « extend » : Un enchaînement complexe, optionnel par rapport à un enchaînement obligatoire d’actions (variante de comportement), peut faire l’objet d’un cas d’utilisation à part, qui étend d’autres cas d’utilisation. Les cas d’utilisation qui sont étendus par ce cas d’utilisation, précisent explicitement les points d’extension (cf. paragraphe suivant). Les cas d’utilisation qui sont étendus peuvent fonctionner seuls , ils ont un acteur déclencheur. N’utiliser cette relation qu’en cas de nécessité car elle est plus difficile à comprendre. Les situations qui la nécessitent sont : - lorsque l’utilisateur dispose d’un grand nombre de services asynchrones ou de services provo- quant une interruption, qui ne doivent pas déranger le cas de d’utilisation de base, - pour compléter un cas d’utilisation dans une version ultérieure. Pour savoir si on utilise une relation « include » ou « extend », se poser la question : Si le cas 1 sait quand, où, pourquoi le cas 2 doit être Si le cas 2 sait quand, où, pourquoi il doit être déclen- déclenché, alors le cas 1 « inclut » le cas 2. ché, alors le cas 2 « étend » le cas 1.Manuel d’utilisation UML - PowerAMC Février 2005 21 / 42
  19. 19. Vue système informatique Exemple : « Extend » = « étend » ou « interrompt » « Include » = « appelle » ou « fait référence à » Dans le cas d’utilisation « Prendre commande », on trouve : « Le responsable clientèle choisit des produits (cas d’utilisation « Choisir produits »). » Dans le cas d’utilisation « Enregistrer client », on trouve : « A chaque fois que le client est nouveau quand on passe une commande (cas d’utilisation « Prendre commande »), le responsable clientèle enregistre le client. » • Décrivez de manière textuelle chaque cas d’utilisation • La spécification doit tenir en une à trois pages de texte (document Word). Elle doit être lisible, la perfection n’est pas indispensable. • Un cas d’utilisation contient l’ensemble des scénarios possibles pour la réalisation d’un objectif. Un scénario correspond à l’exécution d’un ou plusieurs enchaînements, joignant le début du cas d’utilisation à une fin normale ou pas. • Le cas d’utilisation débute avec un événement déclencheur (première action) et se poursuit ju s- qu’à ce que l’objectif soit atteint ou abandonné et que le système assume ses responsabilités par rapport à l’interaction. • Lors de la description des cas d’utilisation, vous pouvez compléter si besoin est, les concepts du modèle du domaine. La trame de la spécification d’un cas d’utilisation est la suivante : Objectif Présenter succinctement ce que perme t de faire le cas d’utilisation. Acteurs principaux Donner la liste des acteurs qui déclenchent le cas d’utilisation dans le but d’atteindre son objectif et qui récupèrent un résultat du système (positionnés à gauche du cas d’utilisation dans le dia- gramme). Préciser leurs intérêts vis -à-vis de la réalisation du cas d’utilisation.22 / 42 Février 2005 Manuel d’utilisation UML - PowerAMC
  20. 20. Vue système informatique Acteurs secondaires Donner la liste des acteurs qui sont sollicités par le système (positionnés à droite du cas d’utilisation dans le diagramme). Préciser leurs intérêts vis -à-vis de la réalisation du cas d’utilisation. Préconditions Décrire les contraintes qui doivent être vérifiées lorsque le cas d’utilisation est déclenché. En géné- ral une précondition indique qu’un autre cas d’utilisation s’est déroulé auparavant. Postconditions Décrire les contraintes qui doivent être vérifiées lorsque le cas d’utilisation est terminé. Scénario nominal Décrire la séquence normale dactions associée au cas dutilisation. En général, utiliser 3 à 9 actions. Numéroter les actions de manière chronologique. 1. Action 1 2. Action 2 3. … La première action est généralement le déclencheur du cas d’utilisation. A la fin du scénario nomi- nal, l’objectif du c as d’utilisation doit être atteint. Chaque action donne lieu à une phrase. Commencer systématiquement chaque phrase par « l’acteur xxx… » ou « le système… ». La phrase indique l’intention de l’acteur (pas ses gestes) : les détails de l’IHM ne doivent pas appa- raître. Eviter : 1. Le système demande le nom. 2. L’utilisateur saisit son nom. 3. Le système invite l’utilisateur à saisir son adresse. 4. L’utilisateur saisit son adresse. 5. L’utilisateur clique sur « ok ». 6. Le système présente le profil de l’utilisateur. Préférer : 1. L’utilisateur saisit son nom et son adresse. 2. Le système présente le profil de l’utilisateur. Il faut insister sur les événements entre les acteurs et le système sans décomposer le traitement ef- fectué à l’intérieur du système (vu comme une boîte noire). Chaque action n’a de justification que si elle décrit une action protégeant ou accroissant les intérêts de l’intervenant. On peut associer une action à une partie d’une transaction : 1. l’acteur envoie la requête et les données au système. 2. le système valide la requête et les données. 3. le système change d’état interne. 4. le système répond à l’acteur en lui présentant le résultat. …ou associer les différentes parties en une ou plusieurs actions, selon le degré de complexité de chaque partie et les lieux de rupture naturels dans le traitement. Par exemple : Version 1 : 1. Le client saisit son numéro de commande. 2. Le système détecte que ce numéro correspond au numéro gagnant du mois, inscrit l’utilisateur et le numéro de commande comme gagnant du mois, envoie un mèl au responsable des ventes, félicite le client et lui donne les instructions nécessaires pour retirer son prix. Version 2 : 1. Le client saisit son numéro de commande. 2. Le système détecte que ce numéro correspond au numéro gagnant du mois.Manuel d’utilisation UML - PowerAMC Février 2005 23 / 42
  21. 21. Vue système informatique 3. Le système inscrit l’utilisateur et le numéro de commande comme ga- gnant du mois, envoie un mèl au responsable des ventes, félicite le client et lui donne les instructions nécessaires pour ret irer son prix. Ecrire des phrases simples, montrant clairement « qui a le ballon » et montrant le processus en train d’avancer. Mentionner le déroulement temporel uniquement lorsque c’est nécessaire. Exemple : « A tout moment entre les actions 3 et 5, l’utilisateur… » ou « Dès que l’utilisateur…, le système… ». Il est possible de souligner le fait que des actions peuvent se répéter ou s’effectuer dans n’importe quel ordre. Exe mples : « Le client répète les actions 3 à 5 jusqu’à ce qu’il indique qu’il a terminé » (à placer après l’action 5) ou « Les actions 3 à 5 peuvent se produire dans n’importe quel ordre » (à placer avant l’action 3). Il ne doit pas y avoir de « si… sinon ». Le système ne « vérifie » pas mais « valide » (en cas d’erreur il y aura un scénario alternatif, cf ci-après). Exemple : Eviter : 2. Le système vérifie si le mot de passe est correct. 3. Si c’est le cas, le système présente les actions disponibles à l’utilisateur. Préférer : 2. Le système valide que le mot de passe est correct. 3. Le système présente les actions disponibles à l’utilisateur. Faire référence explicite aux cas d’utilisation inclus ou qui étendent le cas d’utilisation courant (on peut souligner ces cas d’utilisation). Scénarios alternatifs Il s’agit d’identifier toutes les autres situations possibles de succès ou d’échec. Pour chaque action du scénario nominal, se poser la question si quelque chose d’autre peut se pas- ser : si c’est le cas, décrire les actions qui prolongent la séquence dactions normale. Ces scénarios alternatifs ouvrent le cas dutilisation à une possibilité de prolongement (extension). Le titre de chaque scénario alternatif est la condition nécessaire pour que se déroule ce scénario. Chaque scénario alternatif est numéroté en faisant référence aux numéros du scénario nominal pré- cédemment décrit. Ajouter une sous-numérotation 1, 2, 3… (et si besoin a, b, c... de nouveau ainsi qu’une indentation). Un scénario alternatif s’achève par la satisfaction ou l’abandon de son objectif. Terminer chaque scénario alternatif par « le cas d’utilisation se termine » ou « le cas d’utilisation reprend au point N » ou « le cas d’utilisation continue au point N ». Faire référence explicite aux cas d’utilisation inclus ou qui étendent le cas d’utilisation courant (on peut souligner ces cas d’utilisation). Exemple : 1-a : description du scénario alternatif a de l’action 1 du scénario nominal 1. Action 1 2. Action 2 Le cas d’utilisation se termine (échec). 1-b : description du scénario alternatif b de l’action 1 du scénario nominal 1. Action 1 Le cas d’utilisation continue au point 4. 2-a : description du scénario alternatif a de l’action 2 du scénario nominal 1. Action 1 2. L’utilisateur exécute le cas d’utilisation xxx24 / 42 Février 2005 Manuel d’utilisation UML - PowerAMC
  22. 22. Vue système informatique 3. Action 3 4. … Variantes de technologies et de données (optionnel) Les scénarios alternatifs indiquent que ce que fait le système diffère (le quoi). Si on veut indiquer qu’il y a plusieurs façons de procéder (le comment), les lister dans ce paragraphe. Exemple : Scénario nominal : 7. Rembourser le client du montant des marchandises rendues. Variantes de technologies et de données : 7a. Rembourser par chèque, virement électronique ou crédit sur les prochains achats. Règles de gestion (optionnel) Décrire les règles de gestion du cas d’utilisation. Les numéroter. Exigences supplémentaires (optionnel) Décrire les exigences non fonctionnelles du cas d’utilisation : fréquence d’utilisation du cas d’utilisation, contraintes de performance… Les numéroter. Questions en suspend (optionnel) Les questions à poser aux utilisateurs peuvent être regroupées dans un paragraphe spécifique en fin de description du cas d’utilisation. Les numéroter.Exemple de spécification du cas d’utilisation « Valider et compléter les ressources actuelles » :ObjectifValider et compléter les ressources actuelles.Acteurs principaux-directeur dunitéPréconditionsImport de la description des ressources actuelles effectué avec succèsScénario nominal1 : le directeur dunité demande à décrire un personnel2 : le système présente la liste des personnels3 : le directeur sélectionne 1 personnel4 : le système présente les informations relatives à ce personnel5 : le directeur modifie des informations6 : le système valide et présente les informations à jourLe directeur répète les actions 1 à 6 jusqu’à ce qu’il indique qu’il a terminé.Scénarios alternatifs1a : le directeur demande la modification de la description de lunité 1a1 : le système présente les informations relatives à son unité 1a2 : le directeur saisi les informations obligatoires t Le cas dutilisation continue au point 63a : le directeur demande la création dun nouveau personnel 3a1 : le système affiche un formulaire viergeManuel d’utilisation UML - PowerAMC Février 2005 25 / 42
  23. 23. Vue système informatique 3a2 : le directeur saisit les informations obligatoires Le cas dutilisation continue au point 6 5a : le directeur demande la suppression du personnel 5a1 : le système valide quil ny a pas dactivité décrite pour ce personnel Le cas dutilisation continue au point 6 2.2. Utilisation de PowerAMC : diagramme de cas d’utilisation Dans le package « Vue système informatique », un diagramme de cas d’utilisation, nommé « Les cas d’utilisation », contient les cas d’utilisation. Les cas d’utilisation qui ne sont pas étudiés dans la version en cours peuvent être stéréotypés <<Cas d’utilisation non étudié>> ou bien il est possible de les décrire mais on peut préciser s’ils ne sont pas réali- sés dans la version en cours. Les acteurs sont copiés sous forme de raccourcis depuis le diagramme des acteurs de la vue métier ou de- puis le diagramme de contexte statique. Des associations sont établies entre les acteurs et les cas d’utilisation. Positionnez s’il y a lieu les dépendances entre cas d’utilisation. Stéréotypez ces dépendances « include » ou « extend ». Structurez les représentations des cas d’utilisation dans un ou plusieurs diagrammes pour favoriser la clar- té de lecture par les utilisateurs. A la DSI, nous avons choisi de ne pas renseigner la description des cas d’utilisation dans PowerAMC mais plutôt dans le document Word d’exigences fonctionnelles - cf modèle sur le site : http://www.dsi.cnrs.fr/bureau_qualite/developpement-web/guides- modeles/guides -modeles.asp. Dans l’onglet « Classes de mise en oeuvre » des propriétés de chaque cas d’utilisation, indiquez les clas- ses du modèle du domaine affiné utilisées par le cas d’utilisation. Remarque : les classes choisies comme classes de mise en œuvre dans le package « Vue métier » sont au- tomatiquement copiées sous forme de raccourcis dans le package « Vue système in formatique ». Si une classe est une classe de mise en œuvre pour plusieurs cas d’utilisation, sélectionnez le raccourci déjà créé.26 / 42 Février 2005 Manuel d’utilisation UML - PowerAMC
  24. 24. Vue système informatique 2.3. Modélisation de la séquence des messages (optionnel) Pour certains cas d’utilisation, il peut être intéressant d’illustrer la succession temporelle des événements causés par les messages venant des acteurs. Ce diagramme est en général bien accepté par les experts mé- tier. Il est surtout utile dans le cas où plusieurs acteurs interviennent. Le système est considéré comme une boîte noire, l’acteur principal est à gauche, les acteurs secondaires à droite. C’est une autre manière de représenter le scénario nominal du cas d’utilisation. Les extensions peuvent être représentées sous forme de note graphique sur le diagramme. Exemple de diagramme de séquence du cas d’utilisation « Importer la description des ressources actuelles » : Ne pas abuser de ces diagrammes, veiller à ce qu’ils apportent une plue value. 2.4. Utilisation de PowerAMC : diagramme de séquence Dans le package « Vue système informatique », créez un diagramme de séquence pour chaque cas d’utilisation qui le nécessite. Le nom du diagramme commence par « Séquence » et est suivi du nom du cas d’utilisation. Représentez le système sous forme d’un objet instance d’une classe ayant pour nom le système étudié. Cet objet est stéréotypé <<Sy stème>>. Les acteurs sont copiés sous forme de raccourcis depuis le diagramme des acteurs de la vue métier ou de- puis le diagramme de contexte statique. Les messages sont créés dans le diagramme ou copiés depuis le diagramme de contexte dynamique s’il existe.Manuel d’utilisation UML - PowerAMC Février 2005 27 / 42
  25. 25. Vue système informatique 2.5. Autres conseils pour la rédaction des cas d’utilisation • Les cas d’utilisation « CRUD » (= Create, Retrieve, Update, Delete) : Comment classer les cas d’utilisation du type Créer, sélectionner, modifier et supprimer ? Dans un seul cas d’utilisation « Gérer » ou dans plusieurs indépendants ? En principe ils sont séparés car chacun poursuit un objectif précis, éventuellement accompli par des acteurs différents ayant différents niveaux de sécurité. Mais ils surchargent l’ensemble donc il est préférable de les regrouper au sein d’un cas d’utilisation « Gé- rer » : le scénario nominal permet par exemple de sélectionner, modifier et enregistrer, les scénarios alterna- tifs permettent de créer, supprimer, imprimer. Si certains scénarios sont complexes (par exe mple l’enregistrement) alors on peut en faire un sous cas d’utilisation (relation « include »). Les droits d’accès sont décrits dans un paragraphe spécifique, en dehors de la description des cas d’utilisation. • Les cas d’utilisation « paramétrés » : Si on doit écrire des cas d’utilisation presque identiques (par exemple la recherche d’une donnée dans une liste à l’aide de critères), utiliser la même formulation (par exemple : trouver xxx à l’aide de critères yyy, triés par zzz). Si besoin est, décrire le cas d’utilisation, par exemple, le cas d’utilisation « Trouver un quelque chose » : 1. L’utilisateur identifie les critères de recherche du quelque chose. 2. Le système trouve les «quelque chose » correspondants et affiche leurs valeurs d’affichage dans une liste. 3. L’utilisateur peut les trier à nouveau en fonction des critères de tri. 4. L’utilisateur sélectionne celui qui l’intéresse. • Les fins des cas d’utilisation : Chaque cas d’utilisation a deux fins possibles : la réussite et l’échec. S’assurer que chaque cas d’utilisation satisfait aux intérêts de chaque intervenant. S’assurer que l’échec de chaque cas d’utilisation appelé est traité. • Le niveau de précision à atteindre : travailler « en largeur » d’abord ! Les descriptions des cas d’utilisation sont plus ou moins détaillées, selon le moment et les interlocuteurs (utilisateurs ou bien équipe de réalisation). Pensez toujours à la lisibilité pour vos interlocuteurs. La première version présente uniquement la liste de cas d’utilisation avec pour chacun d’entre eux ses ob- jectifs puis, par itérations, on affine et complète progressivement les descriptions. On peut distinguer quatre étapes dans les niveaux de précision atteints : 1. Acteurs et objectifs : o Recenser les acteurs principaux (humain ou non humain), sur toute la durée de vie du système. o Dresser la liste exhaustive par acteur des objectifs pris en charge par le système. o Assigner des priorités : quels objectifs sont pris en charge par le système, dans quelle version. 2. Résumé des cas d’utilisation ou scénario nominal : o Esquisser le scénario nominal pour les cas d’utilisation à étudier. La première formulation de ce scénario peut être sous forme d’un récit. o Vérifier que chacun d’eux satisfait aux intérêts des acteurs. 3. Scénarios alternatifs et conditions d’échec : o Identifier tous les scénarios alternatifs et la liste des conditions d’échec. 4. Prise en compte des échecs : o Indiquer comment le système est sensé répondre à chaque type d’échec. La prise en compte des échecs peut révéler un nouvel acteur, un nouvel objectif ou de nouvelles rè- gles métier.28 / 42 Février 2005 Manuel d’utilisation UML - PowerAMC
  26. 26. Vue système informatique • La mise en œuvre de la démarche : Une première séance de travail en groupe (équipe projet + utilisateurs) peut permettre d’identifier les ac- teurs, objectifs, résumés des cas d’utilisation et le formalisme utilisé pour un cas d’utilisation. Puis l’équipe projet rédige une première version des descriptions des cas d’utilisation à l’étude. Cette rédaction est ensuite revue en groupe (équipe projet + utilisateurs). • Check-list pour la description des cas d’utilisation : Extraite et adaptée de : « Rédiger des cas d’utilisation efficaces » d’Alistair Cockburn.Champ QuestionTitre du cas d’utilisation 1. L’objectif de l’acteur principal est-il formulé à l’aide d’une expression verbale ac- tive ?Objectif 2. Le système est-il en mesure de remplir cet objectif ?Préconditions 3. Sont-elles obligatoires et peuvent-elles être mises en place par le système ? 4. Est-il vrai qu’elles ne sont à aucun moment vérifiées dans le cas d’utilisation ?Scénario nominal 5. Comprend-il entre 3 et 9 actions ? 6. Se déroule -t-il du déclencheur à la satisfaction des postconditions en cas de suc- cès ? 7. Autorise-t-il les bonnes variantes de séquencement ?Chaque action de scénario 8. Est-elle formulée comme un objectif à mener à bien ? 9. Le processus avance-t-il clairement après sa réalisation fructueuse ? 10. Voit-on clairement quel acteur poursuit l’objectif (qui « a le ballon ») ? 11. L’intention de l’acteur est-elle claire ? 12. Etes-vous sûr que l’action ne décrit pas la conception de l’IHM ? 13. Voit-on clairement quelles sont les informations transmises dans cette action ? 14. Cette action est-elle une validation, par opposition à une vérification d’une condi- tion ?Scénarios alternatifs 15. Le système peut-il et doit-il les détecter ? 16. Est-ce vraiment ce dont le système a besoin ?Variantes de technologies et 17. Etes-vous sûr que ce n’est pas là simplement une alternative au scénario nom inal ?de donnéesContenu général du cas 18. Question aux représentants maîtrise d’ouvrage et aux utilisateurs : « est-ce vraimentd’utilisation ce que vous voulez ? » 19. Question aux représentants maîtrise d’ouvrage et aux utilisateurs : « serez-vous en mesure à la livraison de dire si oui ou non, vous avez obtenu cela ? » 20. Question à l’équipe de réalisation : « êtes -vous en mesure d’implémenter ceci ? »Manuel d’utilisation UML - PowerAMC Février 2005 29 / 42
  27. 27. Vue système informatique 3. Le contexte dynamique Ce diagramme présente les mêmes éléments que le contexte statique mais en y ajoutant les flux de messa- ges qui transitent entre le système et les acteurs externes. Ce diagramme permet de représenter globalement les interactions entre les acteurs et le système. Il est produit en parallèle à la description des cas d’utilisation. 3.1. Modélisation du contexte dynamique du système Deux diagrammes peuvent être utilisés au choix : un diagramme de collaboration et un diagramme de sé- quence. Les critères de choix entre l’un ou l’autre des diagrammes sont les suivants : • Le diagramme de collaboration est utile lorsqu’il y a de multiples acteurs, et pour chacun, peu de flux de messages différents. • Le diagramme de séquence est préférable lorsque l’on veut montrer l’enchaînement des interac- tions des différents acteurs avec le système. • Diagramme de collaboration • Représentez le système étudié et les acteurs externes • De la même façon que pour le contexte statique, le système est représenté au centre du diagramme, avec les acteurs en relation autour. • Identifiez les flux entre le système et les acteurs • Pour chaque acteur, modélisez les messages envoyés au système et les messages que l’acteur re- çoit du système . Exemple : • Diagramme de séquence • Représentez le système étudié et les acteurs externes • Le système est représenté au centre du diagramme, avec les acteurs en relation de part et d’autre. • Identifiez les flux entre le système et les acteurs30 / 42 Février 2005 Manuel d’utilisation UML - PowerAMC
  28. 28. Vue système informatique • Pour chaque acteur, modélisez les messages envoyés au système et les messages que l’acteur re- çoit du système. Exemple : 3.2. Utilisation de PowerAMC : diagramme de collaboration Dans le package « Vue système informatique », un diagramme de collaboration nommé « Contexte dynami- que », contient le système, représenté sous forme d’un objet, instance d’une classe ayant pour nom le sys- tème étudié. Cet objet est stéréotypé <<Système>>. Les acteurs sont copiés sous forme de raccourcis depuis le diagramme des acteurs de la vue métier ou de- puis le diagramme de contexte statique. Créez les messages entrants et sortants du système. Dans l’onglet « Général » des propriétés de chaque message, enlevez le num d’ordre. éro 3.3. Utilisation de PowerAMC : diagramme de séquence Dans le package « Vue système informatique », créez un diagramme de séquence nommé « Contexte dyna- mique », contient le système, représenté sous forme d’un objet instance d’une classe ayant pour nom le système étudié. Cet objet est stéréotypé <<Système>>. Les acteurs sont copiés sous forme de raccourcis depuis le diagramme des acteurs de la vue métier ou de- puis le diagramme de contexte statique. Les messages sont créés dans le diagramme.Manuel d’utilisation UML - PowerAMC Février 2005 31 / 42
  29. 29. Vue système informatique 4. Le modèle du domaine affiné A ce niveau il s’agit de préciser le modèle du domaine initialisé dans la vue métier. 4.1. Modélisation des concepts du domaine • Identifiez les concepts du domaine • Un concept possède une identité propre et des propriétés. Un concept encapsule un état et un comportement. (L’état regroupe les valeurs instantanées de toutes les propriétés d’un concept ; l’état évolue au cours du temps. Le comportement du concept décrit les actions applicables au concept ; il se représente sous la forme d’opérations.) • Modélisez les concepts sous forme de classes et les propriétés des classes sous forme d’attributs (convention d’écriture : majuscule à la première lettre pour les noms de classe, tout en minuscule pour les noms d’attributs et d’associations). Un attribut est une propriété nommée dune classe qui définit les caractéristiques de cette classe. Exemple : Classe Attribut • Parmi les classes candidates, écart ez celles qui sont redondantes (indiquer les synonymes dans la documentation), trop générales ou trop spécifiques, celles qui représentent une valeur (dans ce cas c’est un attribut d’une classe) ou un comportement (dans ce cas ce serait une opération d’une classe). • Parmi les classes identifiées, précisez les classes qui sont des référentiels partagés (par exemple, BAP, emploi-type…) pour le domaine étudié. Examinez la liste des référentiels partagés du CNRS pour réutiliser leur modélisation dans le projet. Exemple : • Déterminez les attributs qui sont dérivés, c’est-à-dire dont la valeur est déductible d’autres infor- mations du modèle (autres attributs du même objet ou éléments externes à la classe). Explicitez la règle de dérivation des attributs dérivés d ans la documentation. Exemple : âge = partie entière (date courante - date de naissance) • Identifiez les liens entre les concepts du domaine • Modélisez les liens sous forme d’associations. L’association est une relation de type « est en rela- tion avec » ou « communique avec ». • Nommez les associations entre classes avec un verbe conjugué précis et évitez autant que possi- ble les verbes "à tout faire" (faire, appartenir, référencer …).32 / 42 Février 2005 Manuel d’utilisation UML - PowerAMC
  30. 30. Vue système informatique Exemple : Association • Il est possible d’ajouter de l’information sur l’association pour préciser le rôle des classes dans la relation. Exemple : Rôle • Définissez la multiplicité de l’association (notation min..max) : c’est-à-dire le nombre d’instances d’une classe qui peuvent être mises en relation avec une seule instance de la classe associée. Exemples : 1..1 obligatoire 0..1 optionnel 0..* quelconque 1..* au moins 1 1..5, 10 entre 1 et 5, ou 10 Les multiplicités sont positionnées sur l’association à l’inverse de Merise. • Une association entre classes peut aussi porter des attributs (surtout utile quand on a une multi- plicité 0..* des deux côtés). Dans ce cas l’association est aussi considérée comme une classe, ap- pelée classe d’association. (Cette représentation est toutefois plutôt déconseillée : il est préférable de représenter une classe intermédiaire.) Exemple : Classe d’associationManuel d’utilisation UML - PowerAMC Février 2005 33 / 42
  31. 31. Vue système informatique • Il existe des cas particuliers d’association : agrégations et compositions. L’agrégation spécifie une relation « est composé de ». La composition est une agrégation forte, de type « est construit avec » ou « est élaboré à base de » : un composé n’appartient qu’à un seul composite à un mo- ment donné (la multiplicité du côté de la classe composite doit toujours être à 1..1 ou 0..1) ; si le composite est détruit tous ses composés le sont auss i. Exemple : Association de composition Ne pas abuser de l’agrégation et de la composition. • Modélisation de l’héritage entre classes : généralisation-spécialisation. La généralisation consiste à regrouper des caractéristiques communes à un ensemble de classes au sein d’une sur-classe plus générale (relation de type « est un » ou « est une sorte de »). La spécialisation consiste à ajouter des caractéristiques spécifiques dans une sous-classe ou à adapter les caractéristiques transmises. La sur-classe peut être abstraite, c’est-à-dire qu’il n’y a pas d’instance de cette classe. Exemple : Sur-classe Sous - classe Ne pas abuser de la généralisation (4 niveaux maximum conseillés). 4.2. Utilisation de PowerAMC : diagramme de classes Pour des raisons pratiques (utilisation des raccourcis des classes déjà créées dans le modèle du domaine), le diagramme du modèle de domaine affiné est créé dans la vue métier.34 / 42 Février 2005 Manuel d’utilisation UML - PowerAMC
  32. 32. Vue système informatique Dans le package «Vue métier», un diagramme de classes, nommé «Modèle du domaine affiné», contient les classes du domaine. • Représentation des classes, attributs et associations Dans l’onglet « Général » des propriétés de la classe : • si la classe est abstraite, cochez la case « Abstrait », • si la classe est un référentiel, stéréotypez la classe en <<Référentiel partagé>>. Dans l’onglet « Notes », sous-onglet « Description » des pro priétés de la classe, commentez la classe ou importez un fichier texte. Dans l’onglet « Attributs » des propriétés de la classe : saisis sez les noms des attributs et leur type de don- nées . Si un attribut est dérivé, cochez la case « Dérivé » dans l’onglet « Général » des propriétés de l’attribut. Documentez la règle de dérivation dans l’onglet « Notes », sous-onglet « Description » des propriétés de l’attribut ou sous forme d’une règle de gestion associée (idem : texte dans l’onglet « Notes », sous-onglet « Description » des propriétés de la règle de gestion). Si les valeurs d’un attribut sont connues, saisissez les dans l’onglet « Contrôles standard » des propriétés de l’attribut. Dans l’onglet « Général » des propriétés d’une association : saisissez le nom de l’association. Spécifiez les multiplicités pour les associations entre classes dans l’onglet « Détails » des propriétés de l’association. Cochez la case « navigable » des deux côtés pour supprimer les flèches sur le diagramme. • Structuration du modèle : création de plusieurs diagrammes de classes Il peut être nécessaire de structurer le modèle du domaine : en particulier si la taille du diagramme est trop importante et en devient illis ible. Des classes ayant des sémantiques proches et des relations fortes entre elles vont être regroupées. Chaque groupe de classes peut faire l’objet : • d’une page A4 dans le diagramme de classe. Si une classe doit être représentée sur deux pages, elle est copiée sous forme de synonyme graphique, • ou d’un diagramme de classes différent. Si une classe doit être représentée sur deux diagrammes, elle est copiée sous forme de raccourci. Les diagrammes sont nommés en fonction des groupes de classes qui y sont contenus. Vous pouvez aussi créer des sous-packages. Il est possible de transformer un diagramme en package (clic droit de la souris sur le diagramme dans l’explorateur d’objet et choisir l’option Convertir en package…). Mais attention dans PowerAMC (V 9), un diagramme ne peut pas être changé de package. Et on ne peut pas supprimer un package sans supprimer aussi tout ce qu’il contient.Manuel d’utilisation UML - PowerAMC Février 2005 35 / 42
  33. 33. Vue applicative Vue applicativeLa vue applicative permet de donner une vision concrète du futur système grâce à une maquette, à la modélis ation desprincipes de navigation entre les pages et d’un début d’architecture.1. La maquette Maquette = représentation graphique des pages, du système de navigation et donc du découpage en tâ- ches pour lutilisateur. Son développement ne seffectue pas forcément dans la technologie retenue pour lapplication ; la maquette est a priori jetable. La maquette permet aux utilisateurs de concrétiser le résultat de leur expression de besoins. Elle est essen- tielle dans la phase d’expression et analyse des besoins. Elle se réalise en parallèle avec les autres modéli- sations, en particulier le diagramme de navigation décrit ci-après. 1.1. Réalisation de la maquette • Définissez l’ergonomie La maquette permet de définir lenchaînement des pages de lapplication et les règles d’ergonomie. Dans un premier temps, il s’agit d’identifier les principes génériques dergonomie (navigation, en respectant la charte graphique CNRS) puis ensuite de définir les règles dergonomie spécifiques à lapplication : pour cela faire intervenir lergonome de la DSI. La charte graphique CNRS doit être appliquée sur les pages de l’application. Pour cela, faire intervenir le graphiste de la DSI. • Développez les pages et effectuez une revue ergonomique et graphique de la maquette On peut ne maquetter qu’une branche type de l’application : la plus importante ou la plus délicate. Il est préférable d’utiliser des données réalistes dans la maquette. L’objectif est que les utilisateurs ne se focalisent pas sur les données e lles-mêmes. La revue ergonomique et graphique s’effectue en présence de lergonome et du graphiste de la DSI et de représentants de léquipe projet : elle permet dajuster les règles dergonomie avant de montrer la maquette aux utilis ateurs. • Organisez pour les utilisateurs une réunion de présentation et dévaluation Au cours de cette réunion, précisez leur les éléments à valider, laissez leur manipuler la maquette, recueillez leurs remarques. Pour cela : • soit on leur demande de réaliser une succession de tâches que l’on aura décrites dans un scéna- rio, tâches représentatives des tâches réelles, • soit on leur laisse le temps de naviguer et de découvrir l’application comme bon leur semble à tra- vers une exploration libre mais commentée de leur part. En plus des observations que l’on aura faites, on pourra demander ensuite aux utilisateurs ce qu’ils pen- sent de l’application : est-ce que la navigation leur semble intuitive, les informations faciles à trouver et s’ils se sont bien familiarisés avec l’ensemble de l’application, est-ce que l’organisation de l’application est en accord avec leur mode de travail, est-ce que les informations sont pertinentes, complètes… • Itérez avec la spécification Vérifiez la cohérence entre la maquette et la spécification des cas d’utilisation.Manuel d’utilisation UML - PowerAMC Février 2005 37 / 42
  34. 34. Vue applicative 1.2. Utilisation d’un outil En interne DSI, utilisez loutil Frontpage pour la maquette, PowerPoint ou Word. Frontpage est le plus per- formant au niv eau graphisme. Faire appel au graphiste de la DSI.38 / 42 Février 2005 Manuel d’utilisation UML - PowerAMC
  35. 35. Vue applicative2. La navigation (optionnel) Cette modélisation s’effectue en parallèle avec la réalisation d’une maquette. Il s’agit de représenter les dif- férents cheminements possibles des utilisateurs dans l’application. Contrairement à la maquette (qui peut ne couvrir qu’une branche de l’application), tous les cheminements possibles sont représentés dans le dia- gramme de navigation. Si la navigation dans l’application est très simple (peu de niveaux d’imbrication des pages), il n’est pas utile de réaliser ce diagramme. 2.1. Modélisation de la navigation • Identifiez les pages principales de l’application • Modélisez les pages sous forme de classes. • Les paramètres saisis par les utilisateurs peuvent être représentés sous forme d’attributs de la classe. • Les actions proposées à l’utilisateur sur chaque page peuvent être représentées sous forme d’opérations, nommées par un verbe. • Identifiez les liens, boutons d’action ou options de menu • Modélisez les liens hypertextes, les boutons d’action ou les options de menu qui permettent de cheminer d’une page à l’autre sous forme d’association entre les classes. On ne représente pas les actions qui font demeurer sur la même page. Exemple : Page Bouton d’action Lien hypertexte Paramètres à saisir Option de menuManuel d’utilisation UML - PowerAMC Février 2005 39 / 42
  36. 36. Vue applicative 2.2. Utilisation de PowerAMC : diagramme de classes Dans le package «Vue applicative», un diagramme de classes, nommé «Navigation», contient les classes stéréotypées <<Dialogue>>. Il existe deux autres stéréotypes qui peuvent être utilisés : • <<Dialogue – nouvelle fenêtre>> : pour préciser que la page s’affiche dans une autre fenêtre que la fenêtre courante du navigateur, avec la barre doutils complète (deux fenêtres du navigateur sont ouvertes en même temps), • <<Dialogue – popup>> : pour indiquer que la page s ’affiche dans une petite fenêtre qui se super- pose à la fenêtre courante, avec une barre doutils minimale ou même inexistante (message, de- mande dinformations…). Dans l’onglet « Général » des propriétés de la classe : saisissez le nom de la classe, en commençant généra- lement par « Page… ». Représentez les liens hypertextes, les boutons d’action ou les options de menu sous forme d’association entre les classes. Dans le cas d’un lien hypertexte, stéréotypez l’association <<Lien pour navigation>> et nommez la avec le texte du lien qui apparaîtra à l’utilisateur. Dans le cas d’un bouton d’action, stéréotypez l’association <<Bouton pour navigation>> et nommez la avec le texte du bouton qui apparaîtra à l’utilisateur, entouré des caractères < et >. Dans le cas d’une option de menu, n’utilisez aucun stéréotype. Veillez à ce que la navigabilité entre les pages soit bonne (cochez la case « navigable » dans l’onglet « Dé- tails » des propriétés de l’association, pour positionner la flèche sur le diagramme du côté de la page desti- nation). Pour ne pas afficher les multiplicités sur les associations (elles n’ont aucun sens dans ce diagramme ), faites apparaître le menu contextuel du diagramme avec un clic droit de la souris sur le fond du diagramme. Choi- sissez l’option Préférences d’affichage… puis « Association ». Décochez « Afficher la multiplicité ».40 / 42 Février 2005 Manuel d’utilisation UML - PowerAMC
  37. 37. Vue applicative3. Les classes participantes (optionnel - début de conception del’architecture) Un diagramme de classes participantes est réalisé pour chaque cas d’utilisation. Ces diagrammes permet- tent d’initialiser la conception de l’architecture de l’application sous forme de composants : il s’agit en e ffet d’identifier les classes « dialogue », « contrôleur » et « entité ». Ces diagrammes sont construits en parallèle ou juste en suivant la description de la navigation et la réalisa- tion de la maquette. Ils permettent de les préciser ou les compléter (ajout de classes « dialogue ») en étant exhaustif au niveau de la couverture de l’application (la maquette peut ne couvrir qu’une branche de l’application). Le lien va également être fait avec le modèle du domaine, dans lequel on va récupérer les classes « entité », c’est-à-dire les concepts dont se sert le cas d’utilisation. Si besoin est, le modèle du domaine peut être aus- si complété par de nouveaux concepts identifiés à ce stade. 3.1. Modélisation des classes participantes (« dialogue », « contrôleur », « entité ») par cas d’utilisation • Identifiez les classes « dialogue », « contrôleur » et « entité » Créez un diagramme par cas d’utilisation. • Les classes « dialogue » servent à modéliser les interactions entre le système et ses utilis ateurs. Les classes « dialogue » sont issues du diagramme de navigation ou nouvellement créées dans le diagramme. Comme dans le diagramme de navigation, les paramètres saisis par les utilisateurs peuvent être re- présentés sous forme d’attributs de la classe. Les actions proposées à l’utilisateur sur chaque page sont représentées sous forme d’opérations, nommées par un verbe. • Les classes « contrôleur » sont utilisées pour représenter la coordination, l’enchaînement et le contrôle d’autres objets. Généralement, représentez une seule classe « contrôleur » par cas d’utilisation. Mais sur le diagramme on peut montrer qu’un contrôleur appele le contrôleur d’un autre cas d’utilisation. Il est possible de modéliser les opérations effectuées par le contrôleur, dé- clenchées par des actions au niveau des dialogues ou périodiquement (mise à jour de données batch). • Les classes « entité » servent à modéliser des informations durables et souvent persistantes. Les classes « entité » sont issues des concepts métier du modèle de domaine ou bien sont nouvelle- ment créées dans le diagramme si ce sont des entités purement « applicatives », techniques (états, types d’états …). • Identifiez les liens entre ces classes Liez les classes « dialogue » à la classe « contrôleur », puis la classe « contrôleur » aux classes « entité ». Il n’y a pas de lien entre classes « dialogue », ni directement avec les classes « entité » : c’est le contrôleur qui gère la synchronisation. Les liens de retour à la page d’accueil ou autre retour n’ont pas à apparaître à ce niveau (ils sont représen- tés dans le diagramme de navigation). Exemple :Manuel d’utilisation UML - PowerAMC Février 2005 41 / 42
  38. 38. Vue applicative 3.2. Utilisation de PowerAMC : diagramme de classes Dans le package «Vue applicative», créez un diagramme de classes, nommé «DCP» (= Diagramme Classes Participantes) suivi du nom du cas d’utilisation. Copiez sous forme de raccourcis les classes « dialogue » déjà définies dans le diagramme de navigation ou bien créez en de nouvelles. Créez une classe, stéréotypée <<Contrôleur>>, dont le nom commence par « CTRL », suivi généralement du nom du cas d’utilisation. Copiez sous forme de raccourcis les classes « entité » déjà définies dans le modèle du domaine (ainsi que les associations entre elles) ou bien créez en de nouvelles. Représentez les liens sous forme d’associations entre les classes. Veillez à ce que la navigabilité, essentiellement entre le contrôleur et les classes « entité », soit bonne (sens du flux) : cochez la case « navigable » dans l’onglet « Détails » des propriétés de l’association, pour posi- tionner la flèche sur le diagramme soit du côté de l’entité (signifie une écriture de données) ou du côté du contrôleur (signifie une lecture de données ). Supprimer les multiplicités sur les associations entre les classes « dialogue », « contrôleur » et « entité » (les multiplicités doivent par contre être conservées entre les classes « entité » issues du modèle du d o- maine). Pour cela, dans l’onglet « Détails » des propriétés de l’association, mettre à vide la rubrique « Mul- tiplicité ».42 / 42 Février 2005 Manuel d’utilisation UML - PowerAMC

×