Partie 2 : Modélisation avec UML Modélisation avec UML

Transcription

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.
45
1
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.
46
• 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.
47
• A chaque itération de la phase de test, on vérifie que les
besoins des utilisateurs sont satisfaits
2
• 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
Vuelogique
logique
Vue
Vuedes
descomposants
composants
Besoin
Besoindes
des
utilisateurs
utilisateurs
Vue
Vue de déploiement
Vuedes
desprocessus
processus
Samira SI-SAID CHERFIVue de déploiement
48
• 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...
49
3
• 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
50
ou modules).
• 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).
51
4
• 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...)
52
• 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
surSI-SAID
les problèmes
importants.
Samira
CHERFI
53
5
Processus de développement
Comprendre
Comprendreleleproblème
problème
en
enterme
termede
demétier
métierdu
duclient
client
Analyse
Concevoir
Concevoirune
unesolution
solutioninformatique
informatique
en
terme
de
responsabilité
en terme de responsabilitéfonctionnelle
fonctionnelle
Conception
Implémentation
Réaliser
Réaliserlalasolution
solutionen
enterme
terme
de
deprogramme
programme
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.
55
6
Digrammes d'UML
Diagramme
Composants
Déploiement
Classes
Séquence
Activité
Cas d’utilisation États -Transitions
Objets
Collaboration
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
57
7
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
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.
59
8
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.
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.
61
9
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.
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.
63
10
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
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
65
11
l'acteur
• Dans le cas du cabinet médical, nous avons deux
acteurs:
– Le médecin
– Le secrétaire
Secrétaire
Médecin
66
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
67
12
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.
68
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.
69
13
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 dossier
Créer infos patient
Secrétaire
Consulter dossier
Médecin
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»
71
14
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
72
la relation « include »
Exemple du cabinet médical
Créer infos patient
« include »
Éditer infos patient
« include »
Secrétaire
Modifier infos patient
73
15
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.
74
Créer ordonnance
Points d’extension
Vérifier antécédents: le
système affiche le dossier
«extend»
Le médecin souhaite
vérifier les antécédents
Médecin
Consulter
dossier
75
16
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. »
77
17
• 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 2- Le système lui demande de choisir un
patient
une ordonnance
4- Le système édite une ordonnance
3- Le médecin choisi le patient
vierge
souhaité
6- le système demande à saisir les doses
5- le médecin sélectionne un
et la fréquence des prises
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
78
• 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
-- quelque chose
fin de boucle
ou
Tant que
-- autre chose
fin tant que
79
18
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.
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?
81
19
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.
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
83
20
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.
84
Autre exemple
• Machine à recycler
La machine doit :
reçu
•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.
85
21
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
Usager
Éditer rapport
Changer informations objet
Opérateur
86
• 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 …"
87
22
la relation « include »
Exemple de la machine à recycler
Ramener objets
Récupérer objets
« include »
« include »
Éditer informations
Usager
Opérateur
88
Ramener objets
Éditer rapport
« extend »
Usager
Traiter blocage
Opérateur
89
23
Exemple
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
24
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
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
93
25
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
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
• ….
95
26
É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.
Consulter emploi du temps
Enseignant
Étudiant
Inscription
Service de paiement
m. à. J. programme
Secrétaire général
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
« include »
Inscription
« include » authentification
M. à. J. programme
97
27
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
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
un 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)
99
28
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
100
Trouver les classes
Formulaire d’inscription
Gestionnaire d ’inscriptions
Module
Étudiant
Enseignant
Cours
101
29
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)
ajouter_cours(Étudiant, module)
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
103
30
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)
Module
104
Les relations
Ajouter étudiant (module, info)
Module
Nom
Nb_inscrits
Étudiant
Nom
Cours
Enseignant
lieu
horaire
grade
105
Ouvert()
Ajouter étudiant(info)
31
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).
0..*
1
1
Module
Ajouter étudiant (module, info)
0..*
Étudiant
Nom
Nb_inscrits
3..10
Nom
âge
Enseignant
1..*
4
1
Cours
lieu
horaire
Nom
grade
0..4
106
Ouvert()
Ajouter étudiant(info)
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
107
32

Partie 2 : Modélisation avec UML Modélisation avec UML

Transcription

Documents pareils

Agent et MER du mois Juillet

CONTACTS Compagnie Les Arts Oseurs Village des Arts – 34 800

Exemples de diagrammes SysML sur un portail automatique

gestionnaire adv

CLASSE : 6ème CONTROLE sur le chapitre : Symétrie axiale La

NIBRAS Production 2012-2015

Présentation PowerPoint

dossier_de_presse_-_.. - Mairie de Clermont l`Hérault