partie 2 : modélisation avec uml

1

Samira SI-SAID CHERFI 44

Partie 2 : Modélisation avec UML


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



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.



• 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



• 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



• 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



• 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).



• 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



• 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...)



• 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


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


É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


Digrammes d'UML

Diagramme

ActivitéComposants Classes Séquence Objets

Déploiement Cas d’utilisation États -Transitions Collaboration


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


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


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


• 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


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


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.


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


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


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


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


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


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.


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


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


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


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


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


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.



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


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.


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


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



• 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


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.


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


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.


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


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.


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


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



• 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


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 »



Ramener objetsÉditer rapport

Changer informations objet

Usager OpérateurTraiter blocage

« extend »

24


Exemple


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


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


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


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


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


É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


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


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


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


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


Trouver les classes

Formulaire d’inscription

Gestionnaire d ’inscriptions

Module

Étudiant

CoursEnseignant

30


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)


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


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


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


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


Trouver les relations d’héritage

• Deux moyens pour trouver les relations d’héritage :– Généralisation,– spécialisation

ÉtudiantEnseignant

grade âge

Utilisateur

Nom

partie 2 : modélisation avec uml

Documents