Samira SI-SAID CHERFI 44 Partie 2 : Modélisation avec UML Samira SI-SAID CHERFI 45 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.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
1
Samira SI-SAID CHERFI 44
Partie 2 : Modélisation avec UML
Samira SI-SAID CHERFI 45
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.
2
Samira SI-SAID CHERFI 46
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'incertitudequi caractérisent les systèmes complexes.
Samira SI-SAID CHERFI 47
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 etvalide 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
3
Samira SI-SAID CHERFI 48
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 logiqueVue logique Vue des composantsVue des composants
Vue de déploiementVue de déploiementVue des processusVue des processus
Besoin des utilisateursBesoin des utilisateurs
Samira SI-SAID CHERFI 49
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...
4
Samira SI-SAID CHERFI 50
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 sous-systèmes et leurs dépendances (avec d'autres sous-systèmes ou modules).
Samira SI-SAID CHERFI 51
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).
5
Samira SI-SAID CHERFI 52
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 noeudsdu réseau.
• Les exigences en terme de performances (temps de réponse, tolérance aux fautes et pannes...)
Samira SI-SAID CHERFI 53
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.
6
Samira SI-SAID CHERFI 54
Processus de développement
Analyse
Conception
Implémentation
Comprendre le problème en terme de métier du client
Comprendre le problème en terme de métier du client
Concevoir une solution informatique en terme de responsabilité fonctionnelle
Concevoir une solution informatique en terme de responsabilité fonctionnelle
Réaliser la solution en terme de programme
Réaliser la solution en terme de programme
Samira SI-SAID CHERFI 55
É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.
7
Samira SI-SAID CHERFI 56
Digrammes d'UML
Diagramme
ActivitéComposants Classes Séquence Objets
Déploiement Cas d’utilisation États -Transitions Collaboration
Samira SI-SAID CHERFI 57
Digrammes d'UML
Capture des besoins :• Diagramme de cas d’utilisation: fonctions du système du point de vue de
l’utilisateurAnalyse :• 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
8
Samira SI-SAID CHERFI 58
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 59
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.
9
Samira SI-SAID CHERFI 60
• 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 non-fonctionnels pour compléter la spécification des besoins.
La capture des besoins: la spécification
Samira SI-SAID CHERFI 61
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.
10
Samira SI-SAID CHERFI 62
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 naturel-est 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 63
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.
.
11
Samira SI-SAID CHERFI 64
Diagrammes de cas d'utilisation : les concepts
• Il comprend les acteurs, le système et les cas d'utilisation eux-mê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
Cas d'utilisation YActeur A Acteur B
Samira SI-SAID CHERFI 65
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 lesystè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.
Gérant
réapprovisionnement
Inventaire ComptableTraitement
factures
12
Samira SI-SAID CHERFI 66
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 67
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
13
Samira SI-SAID CHERFI 68
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 69
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.
14
Samira SI-SAID CHERFI 70
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).
Secrétaire Médecin
Créer infos patient
Créer dossier
Consulter dossier
Samira SI-SAID CHERFI 71
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»
15
Samira SI-SAID CHERFI 72
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 73
Raffinement des cas d'utilisation :la relation « include »
Exemple du cabinet médical
Secrétaire« include »
« include »
Éditer infos patient
Modifier infos patient
Créer infos patient
16
Samira SI-SAID CHERFI 74
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’extensionpour la préciser.
Samira SI-SAID CHERFI 75
Raffinement des cas d'utilisation :la relation « extend »
Médecin
Créer ordonnance
«extend»Le médecin souhaite vérifier les antécédents
Consulter dossier
Vérifier antécédents: le système affiche le dossier
Points d’extension
17
Samira SI-SAID CHERFI 76
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 objetsutilisé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 77
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. »
18
Samira SI-SAID CHERFI 78
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 ordonnanceActeur Réponse du systeme
2- Le système lui demande de choisir un patient4- Le système édite une ordonnance vierge6- le système demande à saisir les doses et la fréquence des prises…
1- Le médecin demande à créer une ordonnance3- 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
Samira SI-SAID CHERFI 79
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
19
Samira SI-SAID CHERFI 80
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 81
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?
20
Samira SI-SAID CHERFI 82
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 83
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.
Cas d'utilisation
Scénario 1
Scénario 2
Scénario 3
21
Samira SI-SAID CHERFI 84
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 85
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.
22
Samira SI-SAID CHERFI 86
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
Changer informations objetUsager Opérateur
Samira SI-SAID CHERFI 87
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 …"
23
Samira SI-SAID CHERFI 88
Raffinement des cas d'utilisation :la relation « include »
Exemple de la machine à recycler
Ramener objetsRécupérer objets
Changer informations objetUsager Opérateur
Éditer informations
« include »« include »
Samira SI-SAID CHERFI 89
Raffinement des cas d'utilisation :la relation « extend »
Ramener objetsÉditer rapport
Changer informations objet
Usager OpérateurTraiter blocage
« extend »
24
Samira SI-SAID CHERFI 90
Exemple
Samira SI-SAID CHERFI 91
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.
25
Samira SI-SAID CHERFI 92
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
Services des paiements
Enseignant
Étudiant
Samira SI-SAID CHERFI 93
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
26
Samira SI-SAID CHERFI 94
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 95
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• ….
27
Samira SI-SAID CHERFI 96
É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
Secrétaire général
Enseignant
Inscription
m. à. J. programme
Consulter emploi du temps
Service de paiement
Samira SI-SAID CHERFI 97
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 »
authentification
M. à. J. programme
« include »
28
Samira SI-SAID CHERFI 98
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 99
Décrire les diagrammes de séquence
• Un diagramme de séquence représente les interactions entre objets en tenant compte du temps.
Dupondun formulaire d’inscription un gestionnaire
d’inscription Info 19768
1: remplir
2: soumettre
3: ajouter_cours(dupond, Info 19768)
4: ouvert?
6: ajouter étudiant(dupond)
29
Samira SI-SAID CHERFI 100
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 101
Trouver les classes
Formulaire d’inscription
Gestionnaire d ’inscriptions
Module
Étudiant
CoursEnseignant
30
Samira SI-SAID CHERFI 102
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 103
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érolieuhoraire
31
Samira SI-SAID CHERFI 104
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
4: ouvert?
6: ajouter (dupond)
Gestionnaire d ’inscriptions
Module
Samira SI-SAID CHERFI 105
Les relations
Formulaire d’inscription Gestionnaire d ’inscriptions
Module
Étudiant
CoursEnseignant
NomNb_inscrits
lieuhoraire
Ouvert()Ajouter étudiant(info)
grade
Ajouter étudiant (module, info)
Nom
32
Samira SI-SAID CHERFI 106
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 Gestionnaire d ’inscriptions
Module
Étudiant
CoursEnseignant
NomNb_inscrits
lieuhoraire
Ouvert()Ajouter étudiant(info)
Nomgrade
Ajouter étudiant (module, info)
Nomâge
0..*
0..*
11
3..10
4
1..*
0..4
1
Samira SI-SAID CHERFI 107
Trouver les relations d’héritage
• Deux moyens pour trouver les relations d’héritage :– Généralisation,– spécialisation