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