UML et diagramme de classes - HEH

UML et diagramme de classes
A) UML
1. Définition (source : wikipédia)
UML (« Unified Modeling Language » ou « langage de modélisation unifié » en
français) est un langage de modélisation graphique à base de pictogrammes. Il est
apparu dans le monde du génie logiciel, dans le cadre de la « conception orientée
objet ». Couramment utilisé dans les projets logiciels, il peut être appliqué à toutes
sortes de systèmes ne se limitant pas au domaine informatique.
UML est l'accomplissement de la fusion de précédents langages de modélisation
objet : Booch, OMT, OOSE. C’est à présent un standard défini par l'Object
Management Group (OMG). La dernière version diffusée par l'OMG est UML 2.3
depuis mai 2010.
2. Composition
UML se décompose en plusieurs sous-ensembles :
o Les vues : Les vues sont les observables du système. Elles décrivent
le système d'un point de vue donné, qui peut être organisationnel,
dynamique, temporel, architectural, géographique, logique, etc. En
combinant toutes ces vues, il est possible de définir (ou retrouver) le
système complet.
o Les diagrammes : Les diagrammes sont des éléments graphiques.
Ceux-ci décrivent le contenu des vues, qui sont des notions abstraites.
Les diagrammes peuvent faire partie de plusieurs vues.
o Les modèles d'élément : Les modèles d'élément sont les briques des
diagrammes UML, ces modèles sont utilisés dans plusieurs types de
diagramme. Exemple d'élément : cas d'utilisation, classe, association,...
3. Penser objet avec UML, pour concevoir objet.
Pour penser et concevoir objet, il faut savoir "prendre de la hauteur", jongler avec
des concepts abstraits, indépendants des langages d'implémentation et des
contraintes purement techniques.
Pour conduire une analyse objet cohérente, il ne faut pas directement penser en
termes de pointeurs, d'attributs et de tableaux, mais en termes d'associations, de
propriétés et de cardinalités... Utiliser le langage de programmation comme support
de conception ne revient bien souvent qu'à juxtaposer de manière fonctionnelle un
ensemble de mécanismes d'implémentation, pour résoudre un problème qui
nécessite en réalité une modélisation objet.
L'approche objet nécessite une analyse réfléchie, qui passe par différentes phases
exploratoires ! Bien que raisonner en termes d'objets semble naturel, l'approche
fonctionnelle reste la plus intuitive pour nos esprits cartésiens... Voilà pourquoi il ne
faut pas se contenter d'une implémentation objet, mais se discipliner à "penser objet"
au cours d'une phase d'analyse préalable.
C’est pour cela que l'OMG propose UML.
UML comble une lacune importante des technologies objet. Il permet
d'exprimer et d'élaborer des modèles objet, indépendamment de tout langage
de programmation. Il a été pensé pour servir de support à une analyse basée sur
les concepts objet.
En d'autres termes : UML normalise les concepts objet.
4. Un langage universel et visuel.
UML est avant tout un support de communication performant, qui facilite la
représentation et la compréhension de solutions objet :
Sa notation graphique permet d'exprimer visuellement une solution objet, ce
qui facilite la comparaison et l'évaluation de solutions.
L'aspect formel de sa notation, limite les ambiguïtés et les incompréhensions.
Son indépendance par rapport aux langages de programmation, aux
domaines d'application et aux processus, en font un langage universel.
Attention : La notation graphique d'UML n'est que le support du langage. La véritable
force d'UML, la véritable puissance et l'intérêt d'UML, c'est qu'il normalise la
sémantique des concepts qu'il véhicule !
Qu'une association d'héritage entre deux classes soit représentée par une flèche
terminée par un triangle ou un cercle, n'a que peu d'importance par rapport au sens
que cela donne à votre modèle. La notation graphique est essentiellement guidée
par des considérations esthétiques, même si elle a été pensée dans ses moindres
détails.
Par contre, utiliser une relation d'héritage, reflète l'intention de donner à votre modèle
un sens particulier. Un "bon" langage de modélisation doit permettre à n'importe qui
de déchiffrer cette intention de manière non équivoque !
Il est donc primordial de s'accorder sur la sémantique des éléments de modélisation,
bien avant de s'intéresser à la manière de les représenter.
UML est donc bien plus qu'un simple outil qui permet de "dessiner" des
représentations mentales... Il permet de parler un langage commun, normalisé
mais accessible, car visuel.
B) Le diagramme de classes
1. Définition (source : wikipédia)
Le diagramme de classes est un schéma utilisé en génie logiciel pour présenter les
classes et les interfaces des systèmes ainsi que les différentes relations entre cellesci.
Une classe décrit les responsabilités, le comportement et le type d'un ensemble
d'objets. Les éléments de cet ensemble sont les instances de la classe.
Une classe est un ensemble de fonctions et de données (attributs) qui sont liées
ensembles par un champ sémantique. Elles permettent de modéliser un programme
et ainsi de découper une tâche complexe en plusieurs petits travaux simples.
Les classes peuvent être liées entre elles grâce au mécanisme d'héritage qui permet
de mettre en évidence des relations de parenté. D'autres relations sont possibles
entre des classes, chacune de ces relations est représentée par un arc spécifique
dans le diagramme de classes.
Elles sont finalement instanciées pour créer des objets (elle décrit les
caractéristiques des objets, les objets contiennent leurs valeurs propres pour
chacune de ces caractéristiques lorsqu'ils sont instanciés).
2. Représentation
Une classe est représentée par un rectangle séparée en trois parties :
la première partie contient le nom de la classe
la seconde contient les attributs de la classe
la dernière contient les méthodes de la classe
Exemple :
1°) Le nom de la classe est écrit dans le rectangle du haut.
Dans une classe classique, le nom est écrit en normal alors que s’il s’agit d’une
classe abstraite, celui-ci est écrit en italique.
Par conventions, les noms de classes commencent par une majuscule !
2°) Au niveau de la partie concernant les attributs, la syntaxe est la suivante :
Visibilité nomAttribut [multiplicité] : typeAttribut
 Visibilité
La notion de visibilité indique qui peut avoir accès à l'attribut.
Elle ne peut prendre que 3 valeurs possibles :
Caractère
Rôle
+
accès
public
#
accès
protégé
-
Mot clé
Description
public
Toutes les autres classes ont accès à cet attribut.
protected
Seules la classe elle-même et les classes filles ont
accès à cet attribut.
accès privé private
Seule la classe elle-même a accès à cet attribut.
 Nom de l'attribut
Il ne doit pas comporter ni espaces, ni signes de ponctuation, ni accents. A la place
des espaces, il faut utiliser le symbole « _ » ou changer la première lettre du mot en
majuscule (Exemple : nom de l'objet peut s'écrire nomObjet ou nom_Objet.)
Par conventions, les noms d’attributs commencent par une minuscule !
 Multiplicité
La multiplicité représente le nombre de fois où la variable peut exister. Elle est
représentée entre crochets.
Par exemple : si une personne possède 2 numéros de téléphone, on préfèrera
numTelephones[2] à numTelephone1 et numTelephone2.
3°) Concernant les méthodes, il y a également une syntaxe à respecter :
Visibilité nomFonction(directionParamètreX nomParamètreX : typeParamètreX) :
typeRetour
 Visibilité
La notion de visibilité est la même que celle des attributs (+, #, -).
 Direction du paramètre
Indique si le paramètre est rentrant (in) ou s'il est rentrant et sortant (inout).
PS : par convention, comme pour les attributs, les noms des méthodes commencent
également par une minuscule.
3. Relations entre classes
 L’héritage
Principe de division par généralisation et spécialisation, représenté par un trait reliant
les deux classes et dont l'origine (classe fille) se distingue de l'autre extrémité (classe
mère) par un triangle.
Représentation :
Exemple :
 Association
Une association est une relation générique entre deux classes. Elle est modélisée
par une ligne reliant les deux classes. Cette ligne peut être qualifiée avec le type de
relation, et peut également comporter des règles de multiplicité (par exemple un à
un, un à plusieurs, plusieurs à plusieurs) pour la relation. En plus de la multiplicité, on
a également la navigabilité. Celle-ci indique si on pourra accéder d'une classe à
l'autre. Si la relation est entre les classes A et B et que seulement B est navigable,
alors on pourra accéder à B à partir de A mais pas vice versa. Par défaut, la
navigabilité est dans les 2 sens.
Représentation :
 Agrégation
Association avec relation de subordination, représentée par un trait reliant les deux
classes et dont l'origine se distingue de l'autre l'extrémité (c-à-d la classe
subordonnée) par un losange. Une des classes "regroupe" d'autres classes.
Représentation :
Exemple :
 Composition
Si une classe ne peut pas exister par elle-même, mais doit être un membre d'une
autre classe, alors elle possède une relation de composition avec la classe
contenante.
Représentation :
Exemple :
Exemple de diagramme de classes pour l’exercice sur les rectangles du labo 6 :