Modélisation à objets pour la conception de systèmes d'information (B350)

Transcription

1 Modélisation à objets pour la conception de systèmes d'information (B350) Pascal ANDRÉ, Emmanuel DESMONTILS, Alain VAILLY (Université de Nantes) juin 2014 version imprimable du cours

2 Chapitre 2 Modèles des besoins La première étape, incontournable, d'un développement logiciel est celle de la définition des besoins. Elle va permettre de préciser les objectifs, les services attendus et les principales contraintes pesant sur le système étudié. Qu'il s'agisse d'un système existant qu'il faut reprendre ou d'une création ex nihilo, quel que soit le type d'application informatique (système d'information, système industriel, système embarqué...), la première étape est celle qui va permettre de comprendre ce que veut le client. Plan I. Introduction... 4 A. Ce qui est traité ce module... 4 B. Ce qui n est pas traité dans ce module... 4 II. Les diagrammes de cas d'utilisation... 5 A. Acteurs... 5 B. Cas d'utilisation... 8 C. Description textuelle... 8 D. Diagrammes de cas d'utilisation E. Conclusion III. Les scénarios A. Structuration B. Scénarios C. Scénarios en UML1.x et en UML2.x D. Exemples IV. Le modèle du domaine V. Le modèle métier VI. Un exemple support A. Introduction B. Enoncé du cas fil rouge : le cas CROUS C. Modèles des besoins D. Conclusion VII. Références Chapitre 2 Modélisation à objets B350 2/38

3 VIII. Annexes Chapitre 2 Modélisation à objets B350 3/38

4 I. Introduction Que nous propose UML pour nous aider au niveau de cette étape d'analyse des besoins? Nous disposons des diagrammes de cas d'utilisation et des scénarios (et éventuellement des diagrammes d'activités) pour modéliser les besoins fonctionnels. Ils sont complétés par le diagramme de classes qui servira en début de processus pour clarifier un peu les concepts du domaine et par le diagramme d'activités pour représenter les processus métiers. Nous nous concentrerons, dans ce qui suit, sur les cas d'utilisation et les scénarios, les deux autres modèles n'étant qu'effleurés. Les diagrammes de cas d'utilisation font l'objet d'une présentation détaillée dans un des paragraphes suivants. Les scénarios sont une version simplifiée des diagrammes de séquences. Ils font l'objet d'une présentation dans un des paragraphes suivants. Les diagrammes d'activité (dans leur "version" avec couloirs) modélisent le fonctionnement de l'organisation à travers ses acteurs. Ils font l'objet d'une description détaillée dans un autre chapitre de ce cours. Nous ne détaillerons pas davantage ici. Les diagrammes de classes font l'objet d'une présentation détaillée dans un autre chapitre de ce cours. Nous ne détaillerons pas davantage ici. Nous terminerons cette présentation par un exemple. [1]. Dans ce module, la référence principale de ce module est un ouvrage sur UML 2.0 et OCL A. Ce qui est traité ce module Ce module traite des deux types de diagrammes principaux, à savoir les cas d'utilisation et les scénarios. B. Ce qui n est pas traité dans ce module Ce module ne traite ni le diagramme de classes ni les diagrammes d'activité, qui sont vus dans d'autres chapitres. Nous n'abordons que brièvement les diagrammes de séquences, même si les scénarios en sont une version simplifiée. Nous ne présentons d'eux que ce qui est utile à la modélisation des interactions entre les acteurs et le système. Chapitre 2 Modélisation à objets B350 4/38

5 II. Les diagrammes de cas d'utilisation Les diagrammes de cas d'utilisation fournissent une description de ce que perçoivent les utilisateurs du système en matière de fonctionnalités, d'usages. Ces diagrammes comprennent des acteurs et des utilisations. Nous complétons cette présentation en abordant la description des cas et la constitution de ces schémas. A. Acteurs Un acteur, selon le dictionnaire, est une personne qui joue un rôle dans une pièce de théâtre ou un film. La poursuite de l'analogie acteur = personne, comme nous y incitent les logiciels d'aide à la conception (il suffit de regarder la représentation graphique d'un acteur dans StarUML), est toutefois dangereuse. Un acteur (au sens UML du terme) n'est pas forcément une personne. Cela peut être : une "partie" de personne, plusieurs personnes, plusieurs personnes, une machine... En fait, l'analogie la plus proche de la notion d'acteur est celle qui consiste à dire qu'un acteur est un rôle. Un acteur joue un rôle par rapport au logiciel que l'on décrit. Il va s'en servir ou répondre à ses questions ou recevoir une information... Il est concerné par le fonctionnement de ce logiciel, de façon plus ou moins proche. Le fait qu'un acteur puisse être une "partie" de personne ou bien plusieurs personnes s'explique alors naturellement. Une personne peut jouer plusieurs rôles. Un même rôle peut être joué par plusieurs personnes. Prenons quelques exemples pour illustrer ceci. Un logiciel qui pilote un distributeur de billets dans une banque peut être utilisé par les clients, par la personne en charge de sa maintenance, par le responsable d'agence... Tous vont utiliser le logiciel de différentes façons. Une banque a plusieurs clients. Chacun se servira du distributeur de la même façon. On aura donc un acteur Client, un acteur Maintenance et un acteur Responsable agence. Lorsque vous passez une commande sur Internet, vous agissez en tant que client. Vous êtes donc l'acteur client. Lorsque vous avez rempli votre panier et que vous vous apprêtez à payer par carte, le logiciel qui gère ces commandes va interroger le groupement des cartes bancaires pour savoir si vous avez de l'argent sur votre compte, si la carte n'est pas volée... Ce groupement (en fait, le logiciel de ce groupement en charge des cartes bancaires) est un acteur. Il répond à la demande de son "confrère" du magasin virtuel. Il est donc également impliqué dans l'usage que vous faites du logiciel du magasin virtuel. Bien entendu, on conçoit aisément que le responsable des ventes, le responsable du magasin... soient également concernés et interviennent, à des degrés divers, dans l'usage du logiciel. Chapitre 2 Modélisation à objets B350 5/38

6 Un acteur est à l'extérieur du logiciel (ce n'est pas une partie de ce logiciel) qui interagit avec lui, soit en lui posant une question, soit en répondant à une de ses questions, soit les deux. On n'étudie pas le comportement interne d'un acteur. On se "contente" d'étudier ses réactions. Un acteur peut, dans certains cas, prendre la "place" d'un autre et jouer son rôle. C'est notamment le cas lorsqu'un responsable se met à la place d'un de ses employés et exécute, provisoirement, une de ses tâches. Cet acteur va alors hériter de ses "pouvoirs" (exactement comme dans un jeu de rôle ou, en fonction de données, vous pouvez acquérir de nouveaux pouvoirs et faire d'autres "choses". L'héritage de rôle se traduit aisément en UML : figure 1 : expression de l'héritage entre acteurs Dans cette figure, les acteurs B et C héritent des "pouvoirs" de l'acteur A. Ils vont donc pouvoir utiliser le logiciel comme le fait A. Cet héritage permet, entre autres choses, de simplifier les schémas, comme le montre l'exemple ci- dessous. figure 2 : schéma avant utilisation de l'héritage Chapitre 2 Modélisation à objets B350 6/38

7 figure 3 : schéma après utilisation de l'héritage Cet héritage ne doit toutefois pas être utilisé à la légère. Il doit y avoir "pouvoirs" communs et pouvoirs spécifiques, utilisations communes et utilisations spécifiques. Ainsi, dans le schéma ci- dessous, l'héritage a- t- il été utilisé à tort. figure 4 : exemple, incorrect, d'héritage entre acteurs Dans ce schéma, il y a deux types de pilotes, les passagers et les instructeurs. Outre le fait que, sémantiquement, il est difficile de considérer un passager comme un pilote (sauf en cas de malaise de ce dernier...), les passagers et les instructeurs n'ont aucun "pouvoir". Tout se concentre dans les mains des pilotes. Il n'y a donc rien à transmettre et l'héritage est superflu. En général, la mise en évidence d'héritage entre acteurs (comme pour d'autres concepts) ne doit se faire qu'une fois les besoins soigneusement modélisés, maîtrisés. En fin de travail, donc. Jamais au début. On associera le plus souvent acteur et droit, lors de la phase de conception. On distingue les acteurs primaires et les acteurs secondaires : un acteur primaire est celui qui a l'initiative, qui lance "l'exécution". Le système est utilisé à sa demande. En ce sens, il est actif. Il n'y en a qu'un seul par utilisation. un acteur secondaire est un acteur qui intervient dans le processus mais sans en être l'instigateur. Il va recevoir une information du système ou bien fournir une information au système. Il réagit à une demande du système. En ce sens, il est passif. Il peut y avoir plusieurs acteurs secondaires par utilisation. Un acteur peut fort bien être primaire pour une utilisation et secondaire pour une autre. Qu'il s'agisse d'acteurs primaires ou bien d'acteurs secondaires, leur mise en évidence passe toujours par un recensement des rôles joués par les personnes et les organisations. Ce n'est pas toujours facile. Ainsi, dans un processus de prêt de livres dans une bibliothèque, qui joue le rôle principal? Le lecteur? La bibliothécaire? Il n'y a pas de réponse unique dans la mesure où cela dépend de l'organisation mise en place. Chapitre 2 Modélisation à objets B350 7/38

8 B. Cas d'utilisation Un logiciel est constitué de programmes et de données. Les programmes "travaillent" sur les données, les saisissent, les mémorisent, les transforment, les analysent... Un logiciel peut être utilisé par différentes personnes, certaines ayant plus de droits, de pouvoirs que d'autres. Certaines ne feront que de la saisie, d'autres auront accès è quelques fonctionnalités, d'autres pourront tout faire... Chaque utilisateur perçoit une partie de ce que fait réellement le logiciel, cette perception pouvant du reste être partiellement erronée. En UML, les programmes sont représentés, pour ce qui concerne les besoins, par la notion d'utilisation. Cette notion intègre celle de perception plus ou moins déformée, de droits plus ou moins étendus... Une utilisation est représentée graphiquement par une ellipse : figure 5 : représentation graphique d'une utilisation Cette notation est "pauvre". Elle ne véhicule que très peu d'informations. Dans l'exemple ci- dessus, on n'a que peu de renseignements sur ce que recouvre vraiment la gestion des membres. Il est donc vital d'associer à cette représentation d'autres éléments, comme une description textuelle ou des scénarios. Le système est utilisé, par différents acteurs, pour faire différentes choses. Compte- tenu du fait que la modélisation des besoins se positionne au début de la chaîne de développement du logiciel, la perception que l'on a de ce que fait le système doit se représenter au niveau macroscopique (en identifiant les processus- métier). Un cas d'utilisation n'est pas une fonction. Dans un logiciel de gestion d'une bibliothèque, par exemple, le bon niveau sera celui de la gestion des prêts (celle- ci intégrant les emprunts, les retours, les non- retours, les réservations...). Assimiler utilisation et fonction conduirait à produire des diagrammes beaucoup trop détaillés (il suffit de jeter un coup d'œil sur le contre- exemple fourni en annexes pour s'en convaincre), très difficiles à valider par les clients et très consommateurs de temps pour les architectes. C. Description textuelle Les diagrammes (cas d'utilisation, acteurs) sont peu expressifs. Ils n'apparaissent que sous forme graphique restreinte et ne sont identifiés que par quelques caractères. Que signifie, par exemple, dans le schéma ci- dessous qui comprend deux cas d'utilisation et trois acteurs, "Gérer les membres"? Chapitre 2 Modélisation à objets B350 8/38

9 figure 6 : exemple de diagramme pauvre en sens Ces diagrammes donnent une idée générale des fonctionnalités attendues. Il faut leur donner du sens. Cela se fait de deux façons différentes, en fournissant une description textuelle de chaque cas et en précisant, par un scénario, les principales interactions. Nous traiterons les scénarios un peu plus loin. Nous proposons une description textuelle non normalisée pour spécifier chaque UC : figure 7: cadre descriptif d'un cas d'utilisation NB : il y a d'autres propositions. Cette description repose sur les six éléments suivants : Chapitre 2 Modélisation à objets B350 9/38

10 le nom donné au cas (c'est lui qui figure dans le diagramme), une énumération des types de liaisons existant entre les cas d'utilisation, la liste et le type (primaire, secondaire) des acteurs impliqués, l'énoncé de l'invariant, c'est- à- dire de la loi que le cas doit respecter, une description textuelle synthétique des différents cas constituant le cas décrit, une description textuelle des différentes exceptions pouvant se rencontrer (avec, à chaque fois, le traitement associé). Il est d'usage d'ajouter dans ces descriptions des informations de gestion de projet : identification, auteur, priorité, criticité, risques... Selon A. COCKBURN [2], la description textuelle est plus importante que la description graphique. Voici un extrait de son livre Comment rédiger des cas d'utilisation efficaces (voir sa référence exacte dans la bibliographie) :... ce que j'ai à dire sur un cas d'utilisation pouvait s'intégrer dans... le standard UML... Ce qui signifie que vous pouvez exploiter les idées avancées dans cet ouvrage en parfaite comptabilité avec le standard UML En revanche, si vous vous contentez de consulter le standard UML, qui n'aborde ni le contenu, ni l'écriture des cas d'utilisation, vous ne comprendrez pas ce qu'est un cas d'utilisation, pas plus que vous ne saurez comment l'utiliser, et vous aurez l'impression - dangereuse- que les cas d'utilisation sont des constructions graphiques, par opposition à des constructions textuelles. On pourra voir un exemple de description dans la partie 0. D. Diagrammes de cas d'utilisation 1. Associations entre acteurs et utilisations Acteurs et utilisations sont réunis dans un ou plusieurs diagrammes appelés diagrammes de cas d'utilisation. Ces éléments sont associés les uns aux autres, l'association pouvant être orientée ou non. associations entre acteurs : la seule possible est celle qui correspond à l'héritage. Les acteurs étant à l'extérieur du système, leur comportement interne n'étant pas étudié, il n'y a pas lieu de représenter les échanges pouvant survenir entre deux acteurs. Les liaisons entre acteurs ne doivent pas être représentées. associations entre acteurs et utilisations : le lien traduit l'implication, l'orientation le sens de cette implication. Chapitre 2 Modélisation à objets B350 10/38

11 L'acteur Secrétaire est impliqué dans l'utilisation Gérer les membres. Comment? On ne le sait pas. L'acteur Secrétaire est impliqué dans l'utilisation Gérer les membres. C'est l'acteur principal (c'est lui qui initie le "traitement"). L'acteur Secrétaire est impliqué dans l'utilisation Gérer les membres. C'est un acteur secondaire. associations entre utilisations : les seules associations possibles sont l'héritage (la généralisation/spécialisation), l'inclusion et l'exclusion. Ces notions sont définies un peu plus loin. Il n'y a PAS d'association entre acteurs exprimant un lien de causalité ("pour faire ceci, il faut d'abord faire cela" ou bien "parce que j'ai fait ceci, je peux faire cela") ou un enchaînement temporel ("j'ai fait ceci, je fais maintenant cela"). La notation n'est PAS prévue pour cela. Il n'y a donc pas lieu de l'utiliser de cette façon : Les liaisons entre utilisation n'expriment pas doivent la causalité ou l'enchaînement. 2. Diagrammes de cas d'utilisation Le diagramme des cas d'utilisation structure le besoin en UC et donne une vue synthétique des UC et de leurs relations pour un contexte donné. Le contexte est le système ou une partie de système (un paquetage). Chapitre 2 Modélisation à objets B350 11/38

12 figure 8 : diagramme de contexte - Air Form La figure 8illustre ce type de diagramme pour l'exemple de la compagnie aérienne AirForm. Le cadre délimite le contexte du système. Trois acteurs principaux sont représentés : le client, le gérant et l'agent. Rien n'indique dans la notation qu'un cas d'utilisation puisse être le contexte d'un autre cas d'utilisation. Le concept n'est pas hiérarchique. Ce contexte délimite, quelque part, le périmètre d'intervention. Tout ce qui se trouve à l'intérieur (i.e. dans le rectangle) est étudié, tout ce qui est à l'extérieur non. Les acteurs sont toujours placés à l'extérieur. On ne va en effet pas reproduire leur comportement. Ils sont producteurs et/ou consommateurs d'informations de données ou de contrôle. La figure suivante détaille la Gestion des réservations. Elle met en évidence différentes sortes de relations. Chapitre 2 Modélisation à objets B350 12/38

13 figure 9 : détails de la gestion des réservations La relation entre les acteurs et les UC est de type association. Les acteurs déclenchent les cas d'utilisation, mais peuvent aussi interagir, c'est pourquoi l'association n'est pas orientée a priori. Certains auteurs classent les acteurs en acteurs primaires (à l'origine du cas d'utilisation) et acteurs secondaires (participants). La relation de généralisation/spécialisation entre Gestion des réservations et Réservation à distance signifie que des traitements spécifiques sont à faire pour les opérations en agence ou à distance (téléphone, internet). La notation ne met pas en oeuvre de contrôle de la spécialisation. Il est de la responsabilité du spécifieur de la mettre en évidence dans la description textuelle et les scénarios. La notation des UC définit deux stéréotypes pour la relation de dépendance : l'extension et l'inclusion. L'inclusion signifie qu'un cas d'utilisation est incorporé dans un autre à un point d'insertion bien déterminé. Par exemple, la Gestion des réservations nécessite de vérifier les Autorisations. figure 10 : stéréotype d'inclusion (B est une inclusion de A) L'extension signifie que le cas d'utilisation est incorporé sous conditions. Une extension est donc une dépendance facultative. Par exemple, lorsqu'on ne dispose pas de vols, la Gestion des réservations fait éventuellement appel à des traitements spécifiques pour rechercher d'autres vols auprès du consortium. Chapitre 2 Modélisation à objets B350 13/38

14 figure 11 : stéréotype d'extension (A est une extension de B) La différence entre les deux stéréotypes est finalement le côté facultatif ou obligatoire de l'appel à l'uc "serveur". Il y a longtemps eu confusion entre extension et spécialisation dans la littérature sur UML. La confusion est légitime car l'extension correspond bien à un traitement spécifique, le sens de la dépendance est inversé dans ces deux stéréotypes et enfin le choix des noms est souvent maladroit. Par exemple, dans [3], Passer une commande urgente est une extension de Passer une commande. Autre exemple, dans [4], Virement par minitel est une extension de Virement bancaire. Nous pensons qu'il s'agit d'une erreur dans la notation : la relation d'extension devrait être orientée de l'uc appelante vers l'uc appelée. Ceci met en valeur l'appel facultatif d'uc. Nous proposons de ne pas utiliser la relation d'extension à cause de toutes ces ambiguïtés. Nous utiliserons simplement l'inclusion en précisant, dans la description textuelle, si elle est optionnelle ou systématique. Un bon diagramme est un diagramme est un diagramme synthétique, n'ayant pas plus d'une dizaine d'éléments à appréhender. Un parfait exemple de ce qu'il ne faut PAS faire est disponible. Ce découpage fonctionnel ne correspond pas à ce que l'on veut. Le stéréotype Include dénote un appel systématique du cas d'utilisation inclus. Pour gérer les membres, il faut gérer les réunions. Tout le temps. La gestion des adhérents est une utilisation indépendante de celles des réunions. La relation Include est donc trop forte. Il faut autre chose. On pourrait imaginer avoir recours à la spécialisation : Cela n'a pas plus de sens. Il n'y a aucune utilisation, dans Gérer des AG, qui soit héritée de Gérer les membres. On ne peut pas utiliser l'héritage pour traduire la composition des fonctions. Chapitre 2 Modélisation à objets B350 14/38

15 Mais alors, comment faire? On va regrouper les fonctions dans un même paquetage. Utiliser un paquetage signifie regrouper structurellement des cas d'utilisation indépendants sur un critère connu : E. Conclusion Les cas d'utilisation, avec leurs concepts sous- jacents d'acteur et d'utilisation, sont les deux outils dont dispose l'architecte logiciel pour décrire les besoins. Ces notations sont simples, voire même simplistes : un bonhomme pour les acteurs, une ellipse pour les utilisations. Leur usage, par contre, est un peu plus délicat. Si la mise en évidence des acteurs (un acteur est un rôle joué par une personne ou un groupe de personnes dans l'organisation) est aisée, il n'en est pas de même avec les utilisations. Un cas d'utilisation correspond à la perception par les utilisateurs de ce que fait le système. Celle- ci peut être déformée. Qui dit perception, dit subjectivité. En première approximation, un cas d'utilisation représente une exigence fonctionnelle du système. C'est, en première approximation, un ensemble cohérent de fonctions assurées par ce système. Ce n'est toutefois qu'une approximation, la structuration par fonctions débouchant le plus souvent sur une vision trop détaillée de ce que fait le système. Deux approches de construction s'opposent en pratique [5] : Les tenants du "tout fonctionnel" suggèrent de nombreux petits cas d'utilisation, des fonctions, faciles à décrire et à scénariser (Iconix UP). Cette approche convient pour le développement dirigé par le test ou Test Driven Development (TDD). Le risque est l'explosion combinatoire du nombre de cas et de relations entre cas. Les promoteurs des cas d'utilisation voient plutôt la synthèse d'un ensemble de situations, dans une vue structurée globale. Les cas d'utilisation sont alors décrits sur 5-10 pages (RUP). Cette approche convient pour les systèmes complexes. De façon caricaturale, c'est l'opposition processus agile vs. processus lourd. La principale difficulté est celle de la granularité des cas d'utilisation. Le raisonnement de "bonne structuration" s'appuie sur la bonne utilisation des relations entre UC, sur la qualité des descriptions textuelles et sur les illustrations par des scénarios. C'est à l'usage que l'on se convainc que l'on a trouvé le bon degré. Il faut probablement accepter d'en passer par des étapes- brouillon et accepter des retours- arrière. Chapitre 2 Modélisation à objets B350 15/38

16 Un bon diagramme de cas d'utilisation est un compromis entre fonctionnel pur (trop détaillé) et modulaire pur (trop concis). Chapitre 2 Modélisation à objets B350 16/38

17 III. Les scénarios A. Structuration Un scénario met en évidence les interactions qui existent entre le système et les acteurs de son contexte. Un scénario illustre un cas d'utilisation. Par abus de langage, on dit qu'il l'instancie. Un cas d'utilisation peut comporter des variantes, des factorisations ou des extensions d'autres cas. La description des cas comportera toujours le cas nominal (celui qui correspond au "standard"). Il pourra être complété par la description de cas alternatifs et/ou des cas exceptionnels. Pour mieux cerner la différence entre alternative et exception, il faut revenir à la notion d'objectif. Un cas d'utilisation est une réponse à une demande de l'utilisateur. Il répond à un objectif précis. Nous appellerons : cas nominal ce qui contribue à atteindre directement l'objectif, fin, cas alternatif une variante du cas nominal, l'objectif étant, malgré la variante, atteint à la exception ce qui contribue à ne pas pouvoir atteindre l'objectif. La figure suivante - qui nous a été fournie par un collègue nantais, Olivier Le Marrec- illustre bien ces différents cas : figure 12 : cas nominal, alternatives et exception Chapitre 2 Modélisation à objets B350 17/38

18 Chaque alternative, chaque exception peut faire l'objet d'un scénario. Le cas nominal est, bien entendu, lui aussi décrit sous forme d'un scénario. Dans le cas de la figure 12, il pourrait donc y avoir quatre scénarios. En pratique, il y en aura entre 1 (le cas nominal) et 4. B. Scénarios Un scénario décrit le dialogue entre le système et les acteurs concernés. Le dialogue va donc être basé sur ces deux "concepts", le système étant placé au centre du diagramme et les acteurs à la "périphérie". À chaque fois qu'il y aura transmission d'information, question... une flèche la mettra en évidence et l'orientation de celle- ci désignera l'émetteur et le récepteur. Lorsque le système mettra en oeuvre une de ses fonctionnalités, cela sera modélisé par une flèche recourbée (elle partira du système et arrivera au système). Chaque "traitement" sera matérialisé par un petit rectangle, plus ou moins long. figure 13 : exemple de scénario NB : ce scénario respecte la syntaxe UML1.x (voir plus bas la différence entre celle- ci et la syntaxe UML2.x) L'acteur Secrétaire envoie un message au système (il veut ajouter un membre). Le système commence par vérifier l'existence du membre dans sa "base". S'il existe, alors un message "Membre connu" est envoyé à l'acteur. En principe, on ne représente pas les opérations exécutées par les acteurs (on ne s'intéresse pas à leur comportement interne. Ce qu'ils font des informations reçues, comment ils les traitent... tout cela est hors propos). C. Scénarios en UML1.x et en UML2.x Le passage de la version UML1.x à la version UML2.x n'a pas entraîné beaucoup de changements de la notation à appliquer aux scénarios. Les différences "majeures" concernent ce que l'on peut appeler l'algorithmique qui, en UML1.x, s'exprimait sous forme de commentaires et qui s'exprime maintenant, en UML2.x, sous une forme de cadres (de frames) : Chapitre 2 Modélisation à objets B350 18/38

19 figure 14 : départ d'un étudiant - CROUS - Version UML1.x figure 15 : départ d'un étudiant - CROUS - Version UML2.x Chapitre 2 Modélisation à objets B350 19/38

20 Ces cadres peuvent être typés, le type étant inscrit en haut et à gauche du cadre. Les principaux types disponibles sont : opt : séquence optionnelle, la garde spécifiant la condition. Ce type donne lieu à un cadre unique. alt : séquences alternatives, la garde spécificant la condition, "else" correspondant aux autres valeurs. Ce type donne lieu à autant de cadres qu'il y a de valeurs possibles et intéressantes pour la condition. loop : itération, ce type étant assorti en paramètre d'un entier ou d'un intervalle. sd : fragment réutilisable, le nom de celui- ci étant associé au type. ref : fragment Il y en a d'autres. D. Exemples Voici quelques exemples de scénarios : Le premier concerne le cas de la réservation de billets. Une réservation "normale" implique une recherche préalable selon les critères du vol et la disponibilité de places. Lorsqu'il existe des places disponibles, le client en choisit un certain nombre parmi les places proposées et on les réserve. Sinon, un message "Imposisble" est envoyé au client. Les exceptions et les alternatives font l'objet d'autres scénarios. figure 16 : réservation d'un vol - Air Form Le second scénario traite de l'annulation, par le client, d'une réservation. Chapitre 2 Modélisation à objets B350 20/38

21 figure 17 : annulation d'une réservation d'un vol - Air Form Le premier travail à faire est de vérifier l'existence de la réservation. Si elle existe, on l'affiche puis on la retire. Dans le cas contraire, le client est informé de l'erreur. Chapitre 2 Modélisation à objets B350 21/38

22 IV. Le modèle du domaine Le modèle du domaine (Domain Model) définit les termes techniques par un diagramme de classes. Il permet de mieux comprendre le vocabulaire spécifique. Ce diagramme est allégé, en ce sens qu'il ressemble plus à un modèle Entité- Association : certains concepts, tels que les opérations, ne sont pas utilisés. Ce modèle ne sera pas plus décrit ici puisque le diagramme de classes est approfondi dans un chapitre spécifique. Nous donnons juste un exemple. figure 18 : exemple de modèle du domaine Chapitre 2 Modélisation à objets B350 22/38

23 V. Le modèle métier Le modèle du métier (Business Model), on parle aussi de modélisation d'entreprise, est une abstraction du fonctionnement d'une organisation [6], notamment comment elle crée et fournit de la valeur économique, sociale, culturelle... Selon Eriksson et Penker [6], le modèle couvre quatre vues : La vision décrit les objectifs. Le diagramme de classes peut aider à les structurer. Les processus métier sont la partie essentielle. Ils modélisent le fonctionnement de l'organisation à travers ses acteurs. La structure définit les ressources de l'entreprise. Le diagramme de classes peut aider à les structurer. Le comportement décrit l'évolution des ressources. Le diagramme états- transition peut aider à les représenter. Du point de vue de la conception de systèmes d'information, ce sont surtout les processus métier qui sont utilisés. Ils décrivent les processus opérationnels de l'organisation visée, essentiellement à travers des diagrammes d'activités avec des couloirs. Le lecteur trouvera de nombreux ouvrages traitant de ce sujet [7], [8], [9]. Dans la mesure où les diagrammes sont présentés ailleurs, le modèle du métier n'est pas plus détaillé ici. Nous illustrons simplement un exemple de diagramme d'activités avec couloirs sur la figure suivante. L'emprunt est réalisé selon trois responsabilités : adhérent, boutique, stock. Les activités manipulent des objets. Ces objets circulent sur des flots d'objets. Les flots sont représentés par des flèches discontinues. Un même objet peut apparaître dans plusieurs flots, nous avons indiqué l'état des objets entre crochets. UML 2.X autorise des couloirs à deux dimensions. Chapitre 2 Modélisation à objets B350 23/38

24 figure 19 : exemple de modèle métier Chapitre 2 Modélisation à objets B350 24/38

25 VI. Un exemple support A. Introduction L'exemple développé ici est celui d'un organisme de gestion de chambres à destination d'étudiants (de type CROUS). Nous présentons successivement : l'énoncé, texte que l'on pose rédigé à la suite d'une rencontre avec les responsables de cet organisme. les modèles des besoins : nous proposons une modélisation (partielle) des besoins fonctionnels pour le cas d'étude énoncé. En suivant la démarche proposée dans ce chapitre, nous commençons par structurer les besoins dans un diagramme de cas d'utilisation. Les descriptions textuelles des cas et les illustrations par des scénarios permettent de préciser permettent aussi de mettre à l'épreuve la structure des cas d'utilisation. Le formalisme est simple et permet la communication entre spécialistes et non spécialistes. Nous avons choisi de présenter ensemble les cas d'utilisation et les scénarios correspondants. Une description détaillée de l'analyse des besoins et de l'analyse de ce cas d'étude en UML 1.5 est accessible à l'adresse Web suivante : nantes.fr/~andre- p/fr/ellipses.htm B. Enoncé du cas fil rouge : le cas CROUS Le CROUS gère un fichier de logements en ville pour les étudiants. Ce fichier comporte deux volets. Le premier volet comprend les fiches descriptives des logements, il est accessible librement par les étudiants. Le second volet contient les informations précises sur les propriétaires, il est sous contrôle des administrateurs du CROUS. Les logements sont classés selon leur type : chambre, studio, T1, T1bis, T2, T3, T4 ou plus, maison individuelle. Les fiches sont de couleur différente pour chaque groupe de type (chambre, studio, T1, T1bis, T2, T3, T4 ou plus, maison individuelle). Elles sont rangées dans un fichier manuel. Pour chaque logement, les informations descriptives des logements apparaissent dans les fiches sous la forme de la figure ci- après. Chapitre 2 Modélisation à objets B350 25/38

26 Les propositions sont numérotées séquentiellement (Numéro). La localisation est la donnée d un nom de quartier (Quartier) et d une référence dans le plan de l agglomération (Plan est un code formé d une lettre et d un nombre e.g. H10). Le logement est caractérisé par son type, sa superficie en m2 et divers renseignements sur le logement et son contenu. Le prix du loyer, celui des charges, lorsqu elles ne sont pas comprises dans le loyer, et le nombre de mois de la caution sont ensuite précisés. Le champ Divers contient des informations sur l environnement (transports en commun, parking, services et commerces de proximité, administrations, nature du contrat (garde d enfants, ménage), interphone, garage, ascenseur...). Les informations concernant les propriétaires sont les suivantes : nom, prénom, adresse du propriétaire (rue, code postal, ville), numéro de téléphone au bureau, numéro de téléphone au domicile, liste des propositions faites. Pour chaque proposition d un propriétaire on mémorise l adresse du logement (rue, code postal, ville), divers renseignements (étage, porte, nom à l interphone et à l étage) et l état de la location (libre, loué, annulé). Les fiches de propositions et de propriétaires sont saisies au secrétariat. Pour accéder aux informations sur les propriétaires, le demandeur doit passer à la caisse du CROUS retirer un ticket nominatif (nom, prénom, numéro de carte d étudiant) qu il obtient après un paiement en liquide forfaitaire annuel de 5 euros. Lorsqu un étudiant est intéressé par des propositions, il s adresse au secrétariat en fournissant les fiches correspondantes (il peut en emprunter au plus deux à la fois), qu il aura retiré du fichier manuel et son ticket individuel obtenu à la caisse. La (le) secrétaire vérifie que l étudiant n a pas de fiches en attente et imprime alors une feuille de visite par logement avec l adresse précise du logement, le nom du propriétaire et ses numéros de téléphone. Cette feuille de visite doit être remise au propriétaire qui la renvoie au CROUS avec la décision définitive. Il arrive que ce soit l étudiant qui renvoie la feuille de visite. A réception de cette feuille, si la décision est positive, on met à jour le fichier des logements. Si la feuille de visite n est pas revenue une semaine après la date d emprunt ou si la décision est négative, la fiche de proposition est remise dans le fichier manuel. Le CROUS souhaite établir une liste des Chapitre 2 Modélisation à objets B350 26/38

27 propriétaires et de leurs logements, une liste des logements libres (qui sera comparée avec le fichier manuel), une liste des logements par quartier, par prix ou par type, etc. C. Modèles des besoins Nous commençons par présenter les diagrammes de cas d'utilisation et certains des scénarios les plus caractéristiques (voir ci- dessous). Nous présentons également une première version du diagramme de classes. 1. Cas d'utilisation et scénarios Le texte met en évidence, et de façon très précise, plusieurs traitements et notamment : la saisie des fiches de propositions et de propriétaires (ce qui sous- entend vraisemblablement la mise à jour de ces fiches) ; l'impression des feuilles de visite ; la mise à jour du fichier des logements en cas de visite fructueuse ; l'édition d'une liste des propriétaires et de leurs logements ; l'édition de la liste des logements libres ; l'édition de la liste des logements par quartier, par prix... En filigrane, la gestion des fiches en attente. Pour mettre en place cette gestion des fiches, nous ajoutons également une gestion des étudiants demandeurs. Par contre, nous ne prévoyons pas d'archivage des visites, aucune production de statistiques ne figurant dans les objectifs énoncés dans le texte. Peu de contraintes sont mentionnées. Trois sont explicites : pas plus de deux fiches par étudiant et par sortie ; seuls les étudiants ayant payé le forfait annuel de cinq euros peuvent consulter le fichier ; les feuilles de visite ont une durée de vie maximale d'une semaine. Par déduction, on peut également dire que : les propositions de logement sont examinées en séquence (un étudiant après l'autre) ; une décision positive est fournie exclusivement par le propriétaire ; une décision négative pouvant l'être par défaut. Les acteurs sont au nombre de trois, l'étudiant, le propriétaire et le CROUS (divers rôles de celui- ci étant mentionnés : caisse, secrétariat). La gestion de ce service peut se résumer en un ensemble de quatre cas d'utilisation, selon le schéma ci- après : Chapitre 2 Modélisation à objets B350 27/38

28 figure 20 : cas d'utilisation général - CROUS Nous pouvons préciser davantage chaque cas. Chapitre 2 Modélisation à objets B350 28/38

29 Sur les sept cas que comprend ce cas d'utilisation (trois "normaux" et quatre exceptionnels), nous allons en détailler deux. Le premier correspond à l'ajout d'un propriétaire inconnu (cf. figure 21), le second décrit le départ d'un propriétaire connu (cf. figure 22). figure 21 : scénario Ajout d'un propriétaire inconnu - CROUS figure 22 : scénario Départ d'un propriétaire connu - CROUS NB : la suppression éventuelle du propriétaire se fait dans le cas Suppression d'une proposition du cas d'utilisation Gérer les propositions. Ces deux scénarios illustrent l'imbrication qui existe entre les cas d'utilisation : le cas Ajout d'un propriétaire de l'uc Gérer les propriétaires comprend, à la vérification près de l'existence de ce propriétaire, le cas Ajout d'une proposition de l'uc Gérer les propositions. Le cas Départ d'un Chapitre 2 Modélisation à objets B350 29/38

30 propriétaire de l'uc Gérer les propriétaires comprend le cas Suppression d'une proposition du cas Gérer les propositions, qui lui même comprend le cas Suppression d'une visite de l'uc Gérer les visites. La gestion des étudiants est sous l'influence essentielle de l'acteur Étudiant, l'acteur CROUS est primaire pour les éditions. Sur les onze scénarios, nous en présentons deux. Le premier décrit le traitement mis en œuvre lors du départ d'un étudiant (cf. figure 23) le second à l'édition d'un ticket (cf. figure 24). Chapitre 2 Modélisation à objets B350 30/38

31 figure 23 : scénario Départ d'un étudiant connu - CROUS figure 24 : scénario Édition du ticket d'un étudiant ayant payé le forfait - CROUS La gestion des propositions est sous l'influence essentielle de l'acteur Propriétaire, l'acteur Étudiant est primaire pour les consultations ; l'acteur CROUS est primaire pour les éditions. Chapitre 2 Modélisation à objets B350 31/38

32 Nous présentons ci- après un seul des onze scénarios "possibles", celui qui correspond à la suppression d'une proposition. Le lecteur notera que, là encore, l'imbrication entre les cas est visible. Chapitre 2 Modélisation à objets B350 32/38

33 figure 25 : scénario Suppression d'une proposition, cas normal - CROUS Chapitre 2 Modélisation à objets B350 33/38

34 De tous ces scénarios, nous en présentons deux. Le premier correspond à l'ajout d'une visite (cf. figure 26), le deuxième décrit la suppression d'une visite (cf. figure 27). Chapitre 2 Modélisation à objets B350 34/38

35 figure 26 : scénario Ajout d'une visite, cas normal - CROUS figure 27 : scénario Suppression d'une visite, cas normal - CROUS Chapitre 2 Modélisation à objets B350 35/38

36 2. Modèle du domaine Beaucoup d'informations sont mentionnées dans l'énoncé. De tous les renseignements relatifs aux fiches, aux étudiants... il est assez facile de dessiner la structure de données suivantes : figure 28 : diagramme de classes métier V1 - CROUS Le logement pouvant être loué, retiré de la location... nous avons prévu une variable (État) qui servira à mémoriser ces différents états pris par le logement. Nous avons associé à certains attributs des classes Propriétaire, Logement et Étudiant le stéréotype << key >> qui indique qu'ils jouent le rôle d'identificateurs. Nous ne l'avons pas fait pour les autres classes (et notamment pour Accès, Équipement et Frais). S'agissant d'une modélisation à objets, le besoin d'identifiants n'est pas avéré. Il est toutefois possible que nous soyons obligés (lors du passage à un ensemble de tables relationnelles, notamment) d'en ajouter. D. Conclusion Après avoir présenté rapidement le cas (cette présentation ayant pris la forme d'un énoncé), nous avons modélisé les besoins. Les étapes suivantes, l'analyse, la conception (générale tout d'abord, détaillée ensuite), la programmation et la définition de l'ihm, ne faisant pas partie du périmètre de ce module, elles n'ont pas été traitées. Nous pensons toutefois que les éléments disponibles permettent, même s'ils ne sont pas au complet, de comprendre le travail à accomplir lorsque l'on développe un logiciel avec UML. C'était là notre premier objectif. Chapitre 2 Modélisation à objets B350 36/38

37 VII. Références [1] P. André and A. Vailly. Développement de logiciel avec UML2 et OCL ; cours et exercices corrigés, Collection Technosup. Editions Ellipses, ISBN [2] Alistair Cockburn. Rédiger des cas d'utilisation efficaces. Eyrolles, 1999, Collection Références Technologie objet. ISBN [3] James Rumbaugh, Ivar Jacobson, and Grady Booch. The Unified Modeling Language User Guide. Object- Oriented Series. Addison- Wesley, ISBN Bernard [4] Pierre- Alain Muller. Modélisation objet avec UML. Eyrolles, ISBN X. [5] Jim Conallen. Concevoir des applications Web avec UML. Eyrolles, ISBN , 1e édition. [6] Hans- Erik Eriksson and Magnus Penker. Business Modeling with UML Business Patterns At Work. John Wiley & Sons eds., ISBN [7] Gérard Roucairol and Yves Caseau. Urbanisation, SOA et BPM : Le point de vue du DSI. InfoPro, Management des systèmes d information. Dunod, 4 edition, 2011 [8] Debauche and Patrick Mégard. BPM, Business Process Management : pilotage métier de l entreprise. Management et informatique. Hermes Science Publications, [9] Marie Bia- Figueiredo, Yves Gillette, and Chantal Morley. Processus métiers et S.I. - Gouvernance, management, modélisation - 3e édition : Gouvernance, management, modélisation. Management des systèmes d information. Dunod, 3 edition, Chapitre 2 Modélisation à objets B350 37/38

38 VIII. Annexes Chapitre 2 Modélisation à objets B350 38/38