Cedric Dumoulin
Diagrammes de classes : présentation générale Diagrammes fondamentaux
les plus connus, les plus utilisés Présentent la vue statique du système
représentation de la structure et des déclarations comportementales
classes, relations, contraintes, commentaires… Permettent de modéliser plusieurs niveaux
conceptuel (domaine, analyse) implémentation (code)
Utilisation des diagrammes de classes Expression des besoins
modélisation du domaine Conception
spécification : gros grain Construction
implémentation : précis rétro-ingénierie
Relations entre classes/ liens entre objets Association
les instances des classes sont liées possibilité de communication entre objets relation forte : composition
Généralisation/spécialisation les instances de la sous-classe sont des instances de la super-classe
(niveau conceptuel) héritage (niveau implémentation)
Dépendance la modification d’une classe peut avoir des conséquences sur une
autre Réalisation
une classe réalise une interface
Association Nommage des rôles Le rôle décrit une extrémité d’une association
L’université à 0 ou plusieurs étudiants
public class Personne { public Collection<Universite> employeur; … }
public class Universite { public Collection<Personne> etudiant; public Collection<Personne> professeur; … }
- 13 -
Multiplicité des rôles
1 Un et un seul 0..1 Zéro ou un M .. N De M à N (entiers naturels ex: 3..5) * Plusieurs 0 .. * De zéro à plusieurs 1 .. * D'un à plusieurs
- 14 -
Visibilité des rôles Public + Protégé # Private -
- 15 -
Exemple : graphe non orienté
- 16 -
Exemple : graphe orienté
Association Navigabilité
Par défaut, une association est bidirectionnelle Une flèche sur l’association restreint la navigabilité à
un seul sens : celui de la flèche
Un électeur connaît un candidat Un candidat ne connaît pas un électeur : on ne peut pas
naviguer du candidat vers l’électeur.
- 19 -
Les classes-associations Ajout d’attributs ou d’opérations dans la relation
Pour chaque instance de l’association (A,B), il y a une instance de C
+op1()+op2()
-a1-a2
C
* *A B
D
* *
- 20 -
Associations ternaires (et plus) Pas d’agrégation, pas de qualifier Multiplicité plus difficile à lire
- 21 -
La composition (losange noir) Modélisation de la
composition physique Multiplicité au max de 1
du coté de l’agrégat Propagation
automatique de la destruction
Agrégat Partie
1 *
Généralisation / spécialisation Deux interprétations
niveau conceptuel organisation : un concept est plus général qu’un autre
Implémentation héritage des attributs et méthodes
Pour une bonne classification conceptuelle principe de substitution / conformité à la définition
toutes les propriétés de la classe parent doivent être valables pour les classes enfant
« A est une sorte de B » (mieux que « A est un B ») toutes les instances de la sous-classe sont des instances de la super-
classe (définition ensembliste) Spécialisation
relation inverse de la généralisation
Hiérarchie de classes
Conseils pour la classification conceptuelle Partitionner une classe en sous-classes
la sous-classe a des attributs et/ou des associations supplémentaires pertinents
par rapport à la superclasse ou à d’autres sous-classes, la sous-classe doit être gérée, manipulée, on doit agir sur elle ou elle doit réagir différemment, et cette distinction est pertinente
le concept de la sous-classe représente une entité animée (humain, animal, robot) qui a un comportement différent de celui de la superclasse, et cette distinction est pertinente
Définir une super-classe les sous-classes sont conformes aux principes de substitution et
« sorte-de » toutes les sous-classes ont au moins
un même attribut et/ou une même association qui peut être extrait et factorisé dans la superclasse
Généralisation multiple Autorisée en UML Attention aux conflits : il faut
les résoudre Possibilité d’utiliser aussi
délégations ou interfaces
Interfaces et classes abstraites
- 30 -
Les notes Commentaire attaché à un ou plusieurs éléments de
modélisation Appartient à la vue, pas au modèle Peut être stéréotypée en contrainte
A
B
Ceci est uncommentaire
Blah blah
Quel est l’équivalent Java ? public class Compteur { protected int valeur; protected static int count; public void incrementer() {…} public void decrementer() {…} }
Compteur valeur : int count : int
incrementer() decrementer()
Association Equivalent Java Le rôle décrit une extrémité d’une association
L’université à 0 ou plusieurs étudiants
public class Personne { public Collection<Universite> employeur; … }
public class Universite { public Collection<Personne> etudiant; public Collection<Personne> professeur; … }
- 36 -
Les Paquetages Elément de structuration par excellence,
un paquetage peut contenir des paquetages, des classes, des diagrammes, ….
C’est un conteneur qui définit un espace de nommage et qui permet de voir (de cacher) son contenu
Les noms sont uniques à l’intérieur d’un paquetage Mais le même nom peut être utilisé dans 2 paquetages différents
Le nom complet d’un élément contient le nom des paquetages <nomP1> ::<nomP2> : ::<nomElement>
- 37 -
PkgClientPkgService
FactureProduit
Prix Prix
Quelques exemples de paquetages (tirés du métamodèle UML)
BehavioralElements
ModelManagement
Foundation
Core ExtensionM echanisms
DataType
CollaborationsUsesCases
ActivityGraphs
StateMachines
Common
Dépendances entre packages Découlent des dépendances
entre éléments des packages notamment les classes
Les dépendances ne sont pas transitives modifier Fournisseur n’oblige pas à
modifier Clientèle
Utilisation des diagrammes de packages
Organisation globale du modèle
hiérarchies de packages contenant diagrammes et éléments Organisation des classes en packages pour
contrôler la structure du système comprendre et partager obtenir une application plus évolutive et facile à maintenir
ne pas se faire déborder par les modifications viser la généricité et la réutilisabilité des packages
avoir une vue claire des flux de dépendances entre packages les minimiser
Packages et nommage Noms pleinement qualifiés
équivalent à chemin absolu ex. package java::util, classe java::util::Date
Principes du découpage en packages Cohérence interne du package : relations étroites entre
classes fermeture commune
les classes changent pour des raisons similaires
réutilisation commune les classes doivent être réutilisées ensemble
Indépendance par rapport aux autres packages Un package d’analyse contient généralement moins de
10 classes
Bien gérer les dépendances Les minimiser pour maintenir un couplage faible
dépendances unidirectionnelles cf. associations navigables
pas de cycles de dépendances ou au moins pas de cycles inter-couches
stabilité des dépendances plus il y a de dépendances entrantes, plus les interfaces de
package doivent être stables
Packages : divers Packages considérés comme
simples regroupements sous-systèmes opérationnels comportement + interfaces
Package vu de l’extérieur classe publique gérant le comportement externe (cf. pattern
Façade) Interfaces
Utilité pratique d’un package Commun regrouper les concepts largement partagés, ou épars
Lien entre packages et couches (niveaux) une couche est composée de packages
- 46 -
Diagrammes de classes Ils servent à modéliser l’aspect statique d’un système On peut les utiliser pour:
expliquer le vocabulaire du système (audit) modéliser une collaboration ….
- 47 -
Diagrammes de classes Utilisation des diagrammes de classes pour un audit
(ingénierie du métier, du besoin) Prendre un mot important du vocabulaire, il correspond à un
objet l’abstraire en classe Construire un nouveau diagramme de classes Construire la classe (si elle n’existe pas déjà), la placer au
centre du diagramme Placer autour les mots du vocabulaire (en tant que classes) et
relier les classes entre elles avec les relations appropriées. Recommencer avec un autre mot important du vocabulaire
Lors de la modélisation métier, il ne doit pas y avoir de
référence à la future application / à son implémentation
- 48 -
Diagrammes de classes Conseils Sur le fond
Utiliser plusieurs diagrammes !!! Un seul thème par diagramme.
Il ne doit contenir que des éléments nécessaires Les détails doivent être en relation avec le niveau d’abstraction
(attribut et opérations des classes, décoration des associations,..) Pas plus dépouillé que nécessaire, il ne doit pas induire en erreur le
lecteur Ne pas être trop précis trop vite!
Sur la forme Le nom doit exprimer clairement le thème du diagramme Éviter les croisements, rapprocher les éléments liés Utiliser les notes et la couleur pour ajouter du sens
- 49 -
Login Impression Horloge Trigger Scenario avec variantes et différents acteurs
Exemple L’application doit permettre à des membres de se
connecter. Les membres ont accès à des CUs auxquels les visiteurs n’ont pas accès.
Problème Comment modèliser :
Le CU pour se connecter Les CUs dans lesquels les membres doivent être
connectés Les CUs dans lesquels les visiteurs peuvent se connecter
Définitions: Identification / Authentification /Autorisation Wikipedia :
« L'authentification est la procédure qui consiste à vérifier l'identité d'une personne ou d'un ordinateur afin d'autoriser l'accès de cette entité à des ressources (systèmes, réseaux, applications…). L'authentification permet donc de valider l'authenticité de l'entité en question. L'identification permet donc de connaître l'identité d'une entité alors que l'authentification permet de vérifier cette identité. »
Après identification et authentification, le système donne des autorisations à l’entité identifiée
Proposition 1 include L’appel à ‘SeConnecter’ est systèmatique à chaque fois
que l’on effectue le CU. L’acteur est donc obligé de se connecter à chaque fois !
Proposition 2 extends Le CU SeConnecter peut être appelé quand nécessaire Inconvénient :
Il faut dessiner la relation avec le CU SeConnecter pour chaque CU
L’appel à SeConnecter devra aussi être décrit dans la description du CU
Proposition 3 Pas d’association, mais une pré-condition 2 Cus distincts Utiliser les pré et post-conditions
Post-condition : L’acteur est authentifié.
Pré-condition : L’acteur est authentifié.
(imprimante, distributeur …)
Exemple Le système doit imprimer quelque chose Le système doit distribuer quelque chose (des billets,
des articles …)
Proposition La ressource permettant l’impression ou la distribution est
vue comme une ressource exterieur au système. La ressource est modélisée sous la forme d’un acteur.
Note : association avec navigation indique le sens du déclenchement. Navigation est optionnelle
Exemple Ex1
Le déclenchement du calcul des feuilles de paies doit se faire tous les mois
Ex2 Dans un système d’intégration continue, la compilation
des sources est déclenchée à intervalles régulier.
Généralisation Une fonction doit être déclenché à intervalle de temps
prédéfini
Proposition 1 Modéliser les horloges ou le temps Inconvénients :
L’horloge est malgré tout une ressource du système Un CU doit apporter une fonction à l’acteur qui le déclenche.
Le CU n’apporte rien à l’acteur horloge
Proposition 2 Aller plus loin dans la réflexion :
Peut-on faire un déclenchement manuel ? Quel acteur le fait ? Qui fixe les intervalles ou les dates ?
Utiliser cet acteur plutôt que l’horloge ! Voir :
Dear Dr. Use Case: Is the Clock an Actor? http://www.ibm.com/developerworks/rational/library/content/RationalEdge/jun
02/DrUseCaseJun02.pdf
Exemple Ex1
Alice s’inscrit sur un site de covoiturage. Le système lui envoie un mail de confirmation.
Généralisation du problème Un CU doit être déclenché suite à un événement interne
Proposition 1 Pour
On voit la fonction EnvoyerMail Contre
EnvoyerMail est effectué par le système, pas par l’acteur. doit on avoir un CU EnvoyerMail ? limite de la décomposition fonctionnelle
Proposition 2 Le fait d’envoyer un mail sera dit dans la description du CU.
Pour
Uniquement les CUs apportant quelque chose à l’utilisateur Contre :
Le fait d’envoyer un mail n’apparait pas clairement Mais pourquoi pas !
Question subsidiaire Alice reçoit le mail, qui lui demande de suivre un lien
pour valider l’inscription
Ne pas oublier CU ValiderInscription
Exemple Bob veut publier une annonce sur un site d’annonces.
C’est la première fois que Bob publie sur ce site. Le site propose à Bob de rédiger son annonce, et demande un titre et une catégorie. Après vérification de l’annonce, le site demande a Bob de se connecter ou de s’inscrire. Bob choisit de s’inscrire. Bob remplit le formulaire d’inscription, puis valide celle-ci. Bob étant maintenant membre, l’application lui permet de publier son annonce.
Généralisation L’acteur commence un CU avec des droits insuffisants
pour le terminer. L’acteur est à un moment dérouté sur un autre CU lui permettant d’acquérir les droits nécessaire. L’acteur peut alors compléter le CU initiale.
Proposition Les visiteurs et les membres peuvent effectuer PublierAnnonce
Il y aura 2 scénarios abstrait : Un pour le cas visiteur
Il décrira l’appel à s’inscrire Un pour le cas membre
Classes avec catégories Données associées à un acteur Hierarchie, discriminant, propriétés multiples
Exemple Alice est membre d’une application de covoiturage.
L’application permet à Alice de créer un profil dans lequel elle peut donner des renseignement sur elle.
Questions Comment stocker les informations du profil ? L’acteur est-il dans le système ?
Proposition L’acteur n’est jamais dans le système ! Mais des classes peuvent avoir le même nom qu’un acteur
Cependant, il faut éviter ce cas.
- 86 -
Utilisation de diagrammes de classes pour décrire une structure (modélisation métier)
Un établissement de santé est composé de différents services (médicaux, administratifs, gestions des ressources, hôtelier,…). A la tête de chaque service, on trouve un chef de service qui coordonne une équipe. Différents types d’établissement de santé, les maisons médicalisées, les cliniques, les hôpitaux qui doivent obligatoirement mettre en place un service des urgences. Parmi les hôpitaux, les CHRU sont en relation avec une université. Règle métier: Un chef de service est un médecin hospitalier.
Utilisation de diagrammes de classes pour décrire une structure (modélisation métier)
les agrégats Il s’agit d’une association par référence, c'est-à-dire que la classe référencée peut avoir une existence en dehors de la classe référençante
Structuration en paquetages
L’exemple ci-dessus montre que très rapidement, il est nécessaire de regrouper pour s’y retrouver. On décide de créer un paquetage organisation, un paquetage LesPersonnes et un paquetage Général où on mettra ce qu’on n’arrive pas à mettre dans les autres paquetages et qui ont un sens en dehors de ces paquetages. Des dépendances existent entre ces paquetages On construit un diagramme de classes santeStructure pour introduire les dépendances:
Utilisation de diagrammes de classes pour décrire une structure (modélisation métier)
Chaque paquetage peut être traité indépendamment (re divisé, nouveaux diagrammes,…)
Le paquetage LesPersonnes
les agrégats forts ou composition. La classe référencée ne peut pas avoir d’existence en dehors de la classe référençante Si une instance de Personne est créée, une instance (au moins) de Coordonnée est créée également ; si l’instance de Personne disparaît, l’instance de coordonnée disparaît également. Les durées de vie sont liées
PersonneCoordonnee
Adressenom : stringprenom : stringsexe : stringdateNaissance : DatenomMarital : string
telephone : undefinedeMail : undefinedfax : undefined
1 *
1 *
Zoom sur Personne (changement de granularité)
Attributs
Opérations
Personne
MedecinReferent
Dossier
Resultat
MedecinHospitalier
Medical
MembrePersonnel
DossierMedical DossierAdministratif
Patient
VisiteReference : undefined
1
*
1
*
date : Dateduree : integercoût : integer
CPS : undefined1
La classe association: Visite