Partie 2 : Modélisation avec UML

Partie 2 : Modélisation avec UML Samira SI-SAID CHERFI 44 Modélisation avec UML Comment modéliser avec UML? UML est un langage qui permet de représenter des modèles, mais il ne définit pas le processus d'élaboration des modèles! Cependant, dans le cadre de la modélisation d'une application informatique, les auteurs d'uml préconisent d'utiliser une démarche : itérative et incrémentale, guidée par les besoins des utilisateurs du système, centrée sur l'architecture logicielle. D'après les auteurs d'uml, un processus de développement qui possède ces qualités devrait favoriser la réussite d'un projet. Samira SI-SAID CHERFI 45

Modélisation avec UML Une démarche itérative et incrémentale? L'idée est simple : pour modéliser (comprendre et représenter) un système complexe, il vaut mieux s'y prendre en plusieurs fois, en affinant son analyse par étapes. Cette démarche devrait aussi s'appliquer au cycle de développement dans son ensemble, en favorisant le prototypage. Le but est de mieux maîtriser la part d'inconnu et d'incertitude qui caractérisent les systèmes complexes. Samira SI-SAID CHERFI 46 Modélisation avec UML Une démarche pilotée par les besoins des utilisateurs? Avec UML, ce sont les utilisateurs qui guident la définition des modèles : Le périmètre du système à modéliser est défini par les besoins des utilisateurs (les utilisateurs définissent ce que doit être le système). Le but du système à modéliser est de répondre aux besoins de ses utilisateurs (les utilisateurs sont les clients du système). Les besoins des utilisateurs servent aussi de fil conducteur, tout au long du cycle de développement (itératif et incrémental) : A chaque itération de la phase d'analyse, on clarifie, affine et valide les besoins des utilisateurs. A chaque itération de la phase de conception et de réalisation, on veille à la prise en compte des besoins des utilisateurs. A chaque itération de la phase de test, on vérifie que les besoins des utilisateurs sont satisfaits Samira SI-SAID CHERFI 47

Modélisation avec UML Une démarche centrée sur l'architecture? Une architecture adaptée est la clé de voûte du succès d'un développement. Elle décrit des choix stratégiques qui déterminent en grande partie les qualités du logiciel (adaptabilité, performances, fiabilité...). Ph. Kruchten propose différentes perspectives, indépendantes et complémentaires, qui permettent de définir un modèle d'architecture (publication IEEE, 1995). Cette vue ("4+1") a fortement inspiré UML : Vue Vue logique Vue Vue des des composants Besoin des utilisateurs Vue Vue des des processus Vue Vue de de déploiement Samira SI-SAID CHERFI 48 Modélisation avec UML La vue logique Cette vue de haut niveau se concentre sur l'abstraction et l'encapsulation, elle modélise les éléments et mécanismes principaux du système. Elle identifie les éléments du domaine, ainsi que les relations et interactions entre ces éléments : les éléments du domaine sont liés au(x) métier(s) de l'entreprise, ils sont indispensables à la mission du système, ils gagnent à être réutilisés (ils représentent un savoir-faire). Cette vue organise aussi (selon des critères purement logiques), les éléments du domaine en "catégories" : pour répartir les tâches dans les équipes, regrouper ce qui peut être générique, isoler ce qui est propre à une version donnée, etc... Samira SI-SAID CHERFI 49

Modélisation avec UML La vue des composants Cette vue de bas niveau (aussi appelée "vue de réalisation"), montre : L'allocation des éléments de modélisation dans des modules (fichiers sources, bibliothèques dynamiques, bases de données, exécutables, etc...). En d'autres termes, cette vue identifie les modules qui réalisent (physiquement) les classes de la vue logique. L'organisation des composants, c'est-à-dire la distribution du code en gestion de configuration, les dépendances entre les composants... Les contraintes de développement (bibliothèques externes...). La vue des composants montre aussi l'organisation des modules en "sous-systèmes", les interfaces des soussystèmes et leurs dépendances (avec d'autres sous-systèmes ou modules). Samira SI-SAID CHERFI 50 Modélisation avec UML La vue des processus Cette vue est très importante dans les environnements multitâches ; elle montre : La décomposition du système en terme de processus (tâches). Les interactions entre les processus (leur communication). La synchronisation et la communication des activités parallèles (threads). Samira SI-SAID CHERFI 51

Modélisation avec UML La vue de déploiement Cette vue très importante dans les environnements distribués, décrit les ressources matérielles et la répartition du logiciel dans ces ressources : La disposition et nature physique des matériels, ainsi que leurs performances. L'implantation des modules principaux sur les noeuds du réseau. Les exigences en terme de performances (temps de réponse, tolérance aux fautes et pannes...) Samira SI-SAID CHERFI 52 Modélisation avec UML La vue des besoins des utilisateurs Cette vue (dont le nom exact est "vue des cas d'utilisation"), guide toutes les autres. Dessiner le plan (l'architecture) d'un système informatique n'est pas suffisant, il faut le justifier! Cette vue définit les besoins des clients du système et centre la définition de l'architecture du système sur la satisfaction (la réalisation) de ces besoins. A l'aide de scénarios et de cas d'utilisation, cette vue conduit à la définition d'un modèle d'architecture pertinent et cohérent. Cette vue est la "colle" qui unifie les quatre autres vues de l'architecture. Elle motive les choix, permet d'identifier les interfaces critiques et force à se concentrer sur les problèmes importants. Samira SI-SAID CHERFI 53

Processus de développement Analyse Comprendre le le problème en en terme de de métier du du client Conception Concevoir une une solution informatique en en terme de de responsabilité fonctionnelle Implémentation Réaliser la la solution en en terme de de programme Samira SI-SAID CHERFI 54 Étapes du processus de développement et modèles Capture des besoins : Modèle des cas d utilisation -décrit les besoins de l utilisateur. Analyse : Modèle d analyse - définit la structure statique et le comportement dynamique des objets. Conception : Modèle de conception - définit la structure statique du système en termes de sous-systèmes, de classes et d'interfaces et les collaborations entre les sous-systèmes, les classes et les interfaces. Modèle de déploiement - définit la disposition physique des différents matériels. Implémentation : Modèle de réalisation - définit les composants de réalisation et le passage des classes vers ces composants. Test : Modèle de test - décrit les scénarios de test. Samira SI-SAID CHERFI 55

Digrammes d'uml Diagramme Composants Classes Séquence Activité Objets Déploiement Cas d utilisation États -Transitions Collaboration Samira SI-SAID CHERFI 56 Digrammes d'uml Capture des besoins : Diagramme de cas d utilisation: fonctions du système du point de vue de l utilisateur Analyse : Diagramme de classes: structure statique en termes de classes et de relations Diagramme de séquence: représentation temporelle des objets et de leurs interactions Diagramme de collaboration: représentation spatiale des objets, des liens et des interactions Diagramme d objets : Objets et leurs relations. Diagrammes de collaboration simplifiés, sans représentation des envois de message Diagramme d états-transitions: comportement d une classe en terme d états (Statecharts) [Harel, D. 1987. Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming vol. 8. ] Diagramme d activités: comportement d une opération en termes d actions Samira SI-SAID CHERFI 57

Digrammes d'uml Conception : Diagramme de déploiement: déploiement des composants sur les dispositifs matériels Diagrammes de composants: composants physiques d une application Samira SI-SAID CHERFI 58 La capture des besoins: l acquisition Un SI doit répondre aux besoins des utilisateurs. Leurs capture nécessite: L étude du système existant L acquisition des nouveaux besoins Fonctionnels : fonctionnalités du futur système Non fonctionnels: performances, sécurité etc. D utilisation: critères d acceptation par les utilisateurs, facteurs situationnels etc. L utilisation de techniques d acquisition: Analyser la documentation existante, interviews, observation des utilisateurs, questionnaires etc. Samira SI-SAID CHERFI 59

La capture des besoins: la spécification UML propose les diagrammes de cas d utilisation pour modéliser et documenter les besoins Un cas d utilisation n est pas un besoins mais une fonctionnalité du système devant répondre à un besoin Les diagrammes de cas d utilisation ne permettent pas la spécification des besoins non-fonctionnels Il est nécessaire d établir une liste des besoins nonfonctionnels pour compléter la spécification des besoins. Samira SI-SAID CHERFI 60 Diagramme de cas d utilisation Formalisés par Ivar Jacobson. Décrivent sous la forme d'actions et de réactions, le comportement d'un système du point de vue de l'utilisateur. Définissent les limites du système et les relations entre le système et l'environnement. Manière spécifique d'utiliser un système. C'est l'image d'une fonctionnalité du système, déclenchée en réponse à la stimulation d'un acteur externe. Samira SI-SAID CHERFI 61

Intérêt des diagrammes de cas d'utilisation La détermination et la compréhension des besoins sont difficiles. Les cas d'utilisation recentrent l'expression des besoins sur les utilisateurs: un système est avant tout construit pour ses utilisateurs. On structure la démarche par rapport aux interactions d'une seule catégorie d'utilisateurs à la fois; réduit la complexité de la détermination des besoins. Le formalisme des cas d'utilisation - basé sur le langage naturelest accessible sans formation particulière des utilisateurs. Les cas d'utilisation permettent aux utilisateurs de structurer et d'articuler leurs besoins. Ils concrétisent le futur système dans une formalisation visuelle proche de l'utilisateur. Samira SI-SAID CHERFI 62 Exemple de besoins Gestion des malades dans un cabinet médical. Un médecin doit pouvoir Créer des dossiers médicaux de patients, les modifier, les consulter et les supprimer Créer des ordonnances, les modifier, les imprimer et les supprimer Créer et modifier des instructions à l attention du secrétariat Créer et modifier les informations sur le patient (informations non médicales) Un secrétaire doit pouvoir Créer et modifier les informations sur le patient (informations non médicales) Éditer une feuille de soin Imprimer un récépissé lors de l encaissement d un paiement Etc. Samira SI-SAID CHERFI 63

Diagrammes de cas d'utilisation : les concepts Il comprend les acteurs, le système et les cas d'utilisation euxmêmes. Les acteurs se représentent sous la forme de petits personnages qui déclenchent des cas d'utilisation; ces derniers sont représentés par des ellipses contenues par le système. Frontière du système Cas d'utilisation X Acteur A Cas d'utilisation Y Acteur B Samira SI-SAID CHERFI 64 Diagrammes de cas d'utilisation :l'acteur Un acteur représente tout ce qui est externe au système, humain on non, qui interagit avec le système et qui correspond à une catégorie d'utilisateurs (plus précisément à un rôle). Les acteurs se déterminent en observant les utilisateurs directs du système, ainsi que les autres systèmes qui interagissent avec le système en question. La même personne physique peut jouer le rôle de plusieurs acteurs (vendeur, client). Plusieurs personnes peuvent jouer le même rôle, et donc agir comme le même acteur (tous les clients). Le nom de l'acteur décrit le rôle joué par l'acteur. réapprovisionnement Gérant Inventaire Traitement factures Comptable Samira SI-SAID CHERFI 65

Diagrammes de cas d'utilisation : l'acteur Dans le cas du cabinet médical, nous avons deux acteurs: Le médecin Le secrétaire Médecin Secrétaire Samira SI-SAID CHERFI 66 Diagrammes de cas d'utilisation : les cas d utilisation Un cas d utilisation Est représenté graphiquement par une ellipse avec le nom du cas en dessous Décrit une séquence d action effectuée par le système pour livrer un résulat à l acteur Médecin Créer dossier Samira SI-SAID CHERFI 67

Diagrammes de cas d'utilisation : les cas d utilisation Les cas d'utilisation se déterminent en observant et en précisant, acteur par acteur, les séquences d'interaction - les scénarios - du point de vue de l'utilisateur. La participation de l'acteur est signalée par un lien de communication entre l'acteur et le cas d'utilisation. Ce lien peut être orienté pour indiquer l'initiateur de l'interaction. Samira SI-SAID CHERFI 68 Diagrammes de cas d'utilisation : Les cas d'utilisation Les cas d'utilisation doivent être vus comme des classes dont les instances sont les scénarios. Chaque fois qu'un acteur interagit avec le système, la cas d'utilisation instancie un scénario; ce scénario correspond au flot de messages échangés par les objets durant l'interaction particulière qui correspond au scénario. Les cas d'utilisation servent de fil conducteur pour l'ensemble du projet. Samira SI-SAID CHERFI 69

Le modèle de cas d'utilisation Le modèle de cas d'utilisation comprend une collection de cas d'utilisation Caractérise le comportement de l'ensemble du système et des acteurs externes (dans leur interaction). Créer infos patient Créer dossier Secrétaire Consulter dossier Médecin Samira SI-SAID CHERFI 70 Raffinement des cas d'utilisation Relations entre cas d utilisation Deux relations Extend et Include entre les cas d utilisation Apparaissent comme des relations stéréotypées Les stéréotypes sont écrits sous forme de texte entre guillemets: «extend» et «include» Samira SI-SAID CHERFI 71

Raffinement des cas d'utilisation : la relation «include" Une relation d inclusion entre cas d'utilisation signifie que toute instance du cas d'utilisation source comprend nécessairement le comportement décrit dans le cas d'utilisation destination. Quand l'utiliser: lorsqu'un ensemble d'actions peut être utilisé dans plusieurs cas d'utilisation et que l'on ne souhaite pas répéter cet ensemble, Un tel ensemble est alors décrit dans un cas d'utilisation séparé et est lié au cas d'utilisation qui l'utilise par un lien «include» L'avantage d'une telle démarche est la réutilisation Samira SI-SAID CHERFI 72 Raffinement des cas d'utilisation : la relation «include» Exemple du cabinet médical «include» Créer infos patient Éditer infos patient «include» Secrétaire Modifier infos patient Samira SI-SAID CHERFI 73

Raffinement des cas d'utilisation : la relation «extend» Une relation d'extension entre cas d'utilisation signifie que le cas d'utilisation source étend le comportement du cas d'utilisation destination. Quand l'utiliser: lorsqu'un cas d'utilisation est similaire à un autre cas d'utilisation à l'exception d'une petite variation, une telle variation est décrite dans un cas d'utilisation à part, Les deux cas d'utilisation sont ensuite liés par une relation d'extension. Les points d extension montrent à quel moment survient l extension une condition peut être rajoutée à la relation d extension pour la préciser. Samira SI-SAID CHERFI 74 Raffinement des cas d'utilisation : la relation «extend» Créer ordonnance Points d extension Vérifier antécédents: le système affiche le dossier Médecin «extend» Le médecin souhaite vérifier les antécédents Consulter dossier Samira SI-SAID CHERFI 75

Diagrammes de cas d'utilisation : Les cas d'utilisation Un cas d'utilisation : est un ensemble complet d'actions (avec des événements de début et de fin, les acteurs impliqués dans les actions, et les objets utilisées dans les actions) et de règles qui régissent l'enchaînement des actions. Il définit les interactions entre le système et l'acteur inclut le déroulement normal et tous les déroulements alternatifs. Un scénario : est un déroulement spécifique des événements, ce déroulement dépend des événements à l'origine et à l'issue de chaque action spécifié dans le cas d'utilisation et dont dépend l'enchaînement des actions. Il est possible de dériver plusieurs scénario à partir d'un cas d'utilisation. Il suffit pour cela que l'enchaînement des actions ne soit une simple séquence. Samira SI-SAID CHERFI 76 Description des cas d'utilisation La description peut être sous une forme textuelle simple et peu structurée. Exemple «le médecin cherche le patient dans la liste des patients. Si celui-ci n existe pas il le crée, sinon il crée son dossier. Le médecin introduit les informations sur les antécédents du patient, ses allergies, la liste des substances auxquelles il est allergique, la liste des traitements qu il suit et la durée de ces traitements etc.» Samira SI-SAID CHERFI 77

Description des cas d'utilisation Elle peut également être décomposée en précisant les interactions entre le système et l acteur en distinguant le déroulement de base des déroulements alternatifs Créer ordonnance Acteur Réponse du systeme 1- Le médecin demande à créer une ordonnance 3- Le médecin choisi le patient souhaité 5- le médecin sélectionne un médicament dans une liste Déroulement alternatif 5-6 - Le médecin entre le nom du médicament ainsi que les doses et les fréquences des prises 2- Le système lui demande de choisir un patient 4- Le système édite une ordonnance vierge 6- le système demande à saisir les doses et la fréquence des prises Samira SI-SAID CHERFI 78 Description des cas d'utilisation La description d'un cas d'utilisation comprend les éléments suivants: le début :"Le cas d'utilisation débute quand X se produit."; la fin:"quand X se produit, le cas d'utilisation est terminé."; l'interaction entre le cas d'utilisation et les acteurs; les échanges d'informations: par exemple, "L'utilisateur se connecte au système et donne son nom et son mot de passe."; La chronologie et l'origine des informations; Les répétitions de comportement qui peuvent être décrites au moyen de pseudo-code, avec des constructions du type: boucle ou Tant que -- quelque chose -- autre chose fin de boucle fin tant que Samira SI-SAID CHERFI 79

Règles de mise en œuvre des cas d'utilisation Un cas d'utilisation décrit une fonctionnalité ou une motivation et aussi une interaction entre un acteur et un système sous la forme d'un flot d'évènements. La description de l'interaction se concentre sur ce qui doit être fait. Un cas d'utilisation doit être simple. Il ne faut pas mélanger les cas d'utilisation. Un cas d'utilisation doit éviter d'employer des expressions floues et imprécises. Samira SI-SAID CHERFI 80 Règles de mise en œuvre des cas d'utilisation les situations optionnelles: "L'acteur choisit l'un des éléments suivants, éventuellement plusieurs fois de suite: a) choix X, b) choix Y, c) choix Z puis l'acteur continue en..."; Il est également primordial de trouver le bon niveau d'abstraction. Les réponses apportées aux deux interrogations suivantes peuvent servir de gabarit: est-il possible d'exécuter une activité donnée indépendamment des autres, ou faut-il toujours l'enchaîner avec une autre activité? Est-il judicieux de regrouper certaines activités en vue de les documenter, de les tester ou de les modifier? Samira SI-SAID CHERFI 81

Construction des cas d'utilisation En règle générale, il n'y a qu'un seul acteur par cas d'utilisation. Lors de la construction, il faut se demander: Quelles sont les tâches de l'acteur? Quelles informations l'acteur doit-il créer, sauvegarder, modifier, détruire ou simplement lire? L'acteur devra-t-il informer le système des changements externes? Le système devra- t-il informer l'acteur des conditions internes? Cas d'utilisation peuvent : être présentés aux travers de vues multiples. être groupés selon leurs séquences de déclenchement types ou en fonction des différents points de vue. Samira SI-SAID CHERFI 82 Processus d'élaboration des cas d'utilisation Définir un guide de style pour la rédaction. Définir grossièrement les cas d'utilisation. Approfondir la compréhension et la description d'un cas d'utilisation particulier. Identifier les scénarios. Un scénario est un chemin particulier au travers de la description abstraite et générale fournie par le cas d'utilisation. Scénario 3 Scénario 1 Scénario 2 Cas d'utilisation Samira SI-SAID CHERFI 83

Résumé Dans ce cours nous avons vu: L objectif des diagrammes de cas d utilisation La notation des des diagrammes de cas d utilisation Comment les dessiner Comment les décrire Comment les construire. Samira SI-SAID CHERFI 84 Autre exemple Machine à recycler reçu La machine doit : recevoir et vérifier les objets introduits par les utilisateurs, imprimer et sortir un reçu pour les objets introduits, imprimer la liste de tous les objets reçus pour l'opérateur, mettre à jour les données du système, declenche un signal d'alarme en cas de problème. Samira SI-SAID CHERFI 85

Le modèle de cas d'utilisation Le modèle de cas d'utilisation comprend une collection de cas d'utilisation Caractérise le comportement de l'ensemble du système et des acteurs externes (dans leur interaction). Ramener objets Éditer rapport Usager Changer informations objet Opérateur Samira SI-SAID CHERFI 86 Description des cas d'utilisation Exemple de «ramener objets» "ramener des objets est initié par l'usager qui introduit des boites de conserves,. A chaque objet introduit, le système incrémente le nombre d'objets de ce type d'objets introduits par l'usager d'une part et le total introduit dans la machine durant la journée. Lorsque l'usager a finit, il doit appuyer sur un bouton pour imprimer un reçu. Dans le cas ou un objet introduit n'est pas prévu par la machine, le système doit l'éjecter. De même, si un objet provoque un blocage le système déclenche le traitement du blocage " Samira SI-SAID CHERFI 87

Raffinement des cas d'utilisation : la relation «include» Exemple de la machine à recycler Usager Ramener objets Récupérer objets «include» «include» Éditer informations Changer informations objet Opérateur Samira SI-SAID CHERFI 88 Raffinement des cas d'utilisation : la relation «extend» Ramener objets Éditer rapport Usager «extend» Traiter blocage Opérateur Changer informations objet Samira SI-SAID CHERFI 89

Exemple Samira SI-SAID CHERFI 90 Application de la notation UML Une école d'ingénieurs souhaite informatiser son système d'inscriptions. Le secrétaire général établit le programme du semestre. Pour un module il peut y avoir plusieurs cours. Les étudiants doivent choisir 4 cours obligatoires et 2 optionnels Dès qu'un étudiant est inscrit, le service des paiements en est informé pour qu'il puisse convoquer l'étudiant pour le paiement des droits d'inscription. L'étudiant dispose d'un délai d'un mois pour modifier son choix de modules. Il peut ainsi, pendant cette période, supprimer / ajouter des cours en se connectant directement au système. Les enseignants utilisent également le système pour consulter leur emploi du temps Les utilisateur du système d'inscription se voient affectés des mots de passes leur permettant de valider leurs connexions. Samira SI-SAID CHERFI 91

1- Identifier les acteurs Un acteur est tout ce qui peut interagir avec le système en cours de développement. Secrétaire général Étudiant Enseignant Services des paiements Samira SI-SAID CHERFI 92 2- Identifier les cas d'utilisation Un cas d'utilisation renferme un modèle de comportement que le système manifeste Chaque cas d'utilisation est un ensemble de transactions pouvant être impliquées lors d'un dialogue entre un acteur et le système. Il faut examiner les acteurs pour identifier leurs besoins : Secrétaire général : établit et met à jour le programme de l'école Enseignant : consulte les emplois du temps Étudiant : inscription Service des paiements : reçoit les informations de paiement de l'inscription. Mise à jour programme Inscription Consulter emploi du temps Samira SI-SAID CHERFI 93

3- Documenter les cas d'utilisation Créer un flux d'événements pour chacun des cas d'utilisation Ils sont écrit en adoptant la vue de l'acteur Détailler la réaction du système lors de l'exécution du cas d'utilisation Exemples de contenus Comment débute et finit un cas d'utilisation Les flux normaux Le flux alternatifs Les flux exceptionnels Samira SI-SAID CHERFI 94 Exemple : Flux d'évènements de "Maintenir programme" Ce cas d'utilisation débute lorsque le secrétaire général se connecte au système et entre son mot de passe. Le système vérifie que le mot de passe est valide et demande à l'utilisateur de choisir le semestre (1er ou 2nd). Le secrétaire général choisit alors le semestre. Le système invite alors le secrétaire à choisir une action : AJOUTER, MODIFIER, CONSULTER ou QUITTER. Si l'action choisie est AJOUTER, le flux d'événements "Ajouter cours" est exécuté. Si l'action choisie est CONSULTER, le flux d'événements "Consulter programme" est exécuté. Si l'action choisie est QUIT, le cas d'utilisation se termine. Samira SI-SAID CHERFI 95

Établir le diagramme de cas d'utilisation Les diagrammes de cas d'utilisation sont créés pour visualiser les relations qui lient les acteurs et les cas d'utilisation. Étudiant Consulter emploi du temps Enseignant Inscription Service de paiement m. à. J. programme Secrétaire général Samira SI-SAID CHERFI 96 Affiner les cas d'utilisation Au moment de documenter les cas d'utilisation d'autres relations peuvent être découvertes entre les cas d'utilisation. La relation «include» montre un comportement commun à plusieurs cas d'utilisation. La relation «extend» montre un comportement alternatif ou optionnel Inscription «include» «include» authentification M. à. J. programme Samira SI-SAID CHERFI 97

Réalisation des cas d utilisation Les cas d utilisation représentent comment le système est vu depuis son environnement (l extérieur). Les diagrammes d interaction décrivent comment sont réalisés les cas d utilisation à travers les interactions entre objets. Deux types de diagrammes d interaction Diagrammes de séquence Diagrammes de collaboration Samira SI-SAID CHERFI 98 Décrire les diagrammes de séquence Un diagramme de séquence représente les interactions entre objets en tenant compte du temps. Dupond 1: remplir 2: soumettre un formulaire d inscription un gestionnaire d inscription 3: ajouter_cours(dupond, Info 19768) 4: ouvert? Info 19768 6: ajouter étudiant(dupond) Samira SI-SAID CHERFI 99

Construire le diagramme de classes Un diagramme de classes montre l existence de classes et de relations entre celles-ci. Les éléments qui doivent y figurer sont les suivants : Les classes, leur structure et leur comportement Les relations d association, d agrégation, de dépendance et d héritage Les multiplicités et les indicateurs de navigation Les noms de rôles Samira SI-SAID CHERFI 100 Trouver les classes Formulaire d inscription Gestionnaire d inscriptions Module Étudiant Enseignant Cours Samira SI-SAID CHERFI 101

Trouver les opérations Les opérations expriment le comportements d une classe Des opérations peuvent être déduites de l examen des diagrammes d interaction un formulaire d inscription un gestionnaire d inscription 3: ajouter_cours(dupond, Info 19768) Gestionnaire d inscriptions ajouter_cours(étudiant, module) Samira SI-SAID CHERFI 102 Trouver les attributs Les attributs représentent la structure d une classe Les attributs peuvent être trouvés en examinant les définitions des classes, l expression des besoins, et en appliquant les connaissances acquise sur le domaine. L enseignement d un module est faite sous forme de cours. Chaque cours a un numéro, un lieu et un horaire dans la semaine. Cours numéro lieu horaire Samira SI-SAID CHERFI 103

Trouver les relations entre classes Les relations sont déduites de l examen des diagrammes d'interaction : si deux objets doivent «converser» il doit y avoir un support une relation - pour cette communication. un gestionnaire d inscription Info 19768 Gestionnaire d inscriptions 4: ouvert? 6: ajouter (dupond) Module Samira SI-SAID CHERFI 104 Les relations Formulaire d inscription Gestionnaire d inscriptions Ajouter étudiant (module, info) Module Nom Nb_inscrits Étudiant Nom Enseignant grade Cours lieu horaire Samira SI-SAID CHERFI 105 Ouvert() Ajouter étudiant(info)

Définir les multiplicités et la navigation Comme les associations et les agrégations sont bidirectionnelles, il est souhaitable de préciser la navigation (une seule direction). Formulaire d inscription 0..* 1 Gestionnaire d inscriptions Ajouter étudiant (module, info) 1 0..* Module Nom Nb_inscrits Étudiant Nom âge 3..10 1..* Enseignant Nom grade 1 Cours lieu horaire Samira SI-SAID CHERFI 0..4 106 Ouvert() Ajouter étudiant(info) 4 Trouver les relations d héritage Deux moyens pour trouver les relations d héritage : Généralisation, spécialisation Utilisateur Nom Enseignant grade Étudiant âge Samira SI-SAID CHERFI 107