Creative Commons Paternité-Pas d'Utilisation Commerciale-Pas de Modification 2.0 France (plus d'infos...

)
http://ecrucru.free.fr/?page=uml

UML simplement pour les nuls

Vue imprimable

Cette page a pour simple objectif d'être une sorte de fiche récapitulative relative à UML. Nous
supposons que vous savez ce qu'est la programmation objet.

Ce document est toujours en cours de rédaction... Il n'a aucune prétention à devenir

une "référence".

Pourquoi UML ?
Si vous faites de la programmation (pas seulement), il faudra sûrement penser à comment
concevoir votre logiciel avant de vous lancer tête baissée dans le code. En effet, la manière de
coder est conditionnée par la structure du problème.

UML est un langage qui permet de montrer les liens qu'entretient votre logiciel ou plus
simplement un objet de la vie courante. En effet, il est possible de tout modéliser tant que les
objets restent des concepts connus : une entreprise, un système électrique, un logiciel de
compression, un dictionnaire...

Pour décrire, UML utilise 13 diagrammes. Ceux implémentés dans ArgoUML sont listés ci-
dessous. C'est un logiciel gratuit et multi-plateforme pour tracer des diagrammes. Tous les
schémas ont été réalisés avec cet outil.

diagramme des cas d'utilisation (Use case diagram)

diagramme de classe (Class diagram)
diagramme de séquence (Sequence diagram)
diagramme de collaboration (Collaboration diagram)
diagramme d'état-transition (Statechart diagram)
diagramme d'activité (Activity diagram)
diagramme de déploiement (Deployment diagram)

Les autres diagrammes non traités sont :

diagramme d'objets (Object diagram),

diagramme de composants (Component diagram),
diagramme de paquetages (Package diagram),
diagramme de structure composite (Composite structure diagram),
diagramme de temps (Timing diagram),
diagramme global d'interaction (Interaction overview diagram).

Diagramme de classe
 Ce diagramme est le plus connu, donc le plus utilisé. Il va nous permettre de modéliser notre
système. Par exemple, la classe MachineACafe aura des liens logiques avec les classes Filtre et
Recipient. Chaque classe sera caractérisée par des propriétés. Ce graphique est donc purement
structurel.

Classe
C'est notre élément de base qui désigne des choses qui ont des caractéristiques communes : par
exemple une Renault et une Peugeot sont avant tout une Voiture. La classe est différenciée en
objet après avoir été instanciée (opérateur NEW pour Java et C++). La classe est nommée avec
une majuscule et contient le nom (au-dessus), les variables (au milieu) et les méthodes (au-
dessous). Ces deux dernières ont différentes portées : privée (-), publique (+) ou protégée (#).

ArgoUML ne présente pas ces signes, mais dans l'exemple ci-dessous, la classe Voiture est
définie par une "marque" privée. On y accède en lecture avec getMarque() et en écriture avec
setMarque().

En effet, pour éviter que l'utilisateur ait à gérer des cas tordus, getMarque() et setMarque()
encapsulent des traitements qui peuvent être complexes. A titre d'exemple, si on modifie la
marque, le faire sur les papiers ne suffit pas, car il faut changer le logo sur le capot, avertir le
constructeur... On peut imaginer tout ce qu'on veut, et la méthode setMarque() regroupe ces
modifications massives avec prudence.

Note

C'est un texte rattaché à une classe ou une méthode qui expose une contrainte le plus souvent.
Le trait de lien est en pointillés.

Association et navigabilité

Elle désigne un lien entre des classes qui ont une valeur équivalente. Plus discrètement, dès
qu'une classe est déclarée dans les variables d'une autre classe, il y a relation.
 On a ici une relation 1-n (notée aussi 1-0..*) parce qu'une personne peut posséder plusieurs
voitures. Et comme on peut connaître le propriétaire du fait de la carte grise, on a une association
qui va dans les deux sens.

Voici un exemple pour lequel l'association est directionnelle :

Le concessionnaire possède plusieurs voitures (non considérées comme partie), mais le client
ne loue pas toujours la même chaque jour. Le fait de connaître la voiture n'indique pas qui l'a
loué, sauf en demandant au concessionnaire. La relation 1->n dit que le client peut louer
plusieurs voitures à la fois (cas d'une entreprise). Cette flèche est la navigabilité.

Aggrégation
Lorsque l'association fait penser à une sous-partie, il y a aggrégation. C'est un lien dont on peut
se passer : un siège, une roue, un GPS...

Ici, la Voiture utilise un tableau de sièges dont toutes les cellules ne sont pas nécessairement
affectées : il peut être vide ou plein.

Composition

Ici, la relation est forte, car ce ne sont pas des gadgets mais des éléments essentiels qui
conditionnent les durées de vie.

En gros, si notre moteur recherche n'a pas initialisé ses bases de données, on peut considérer
qu'il ne fonctionnera pas. C'est critique, donc en noir.
 La différence entre agrégation et composition est mince et sujette à débat.

Héritage
Il est possible d'avoir deux objets qui ont des critères similaires, à quelques différences près.
Une voiture tunée est avant tout une voiture, mais une voiture ordinaire n'est pas tunée. Par
conséquent, le tunage est une spécificité d'une voiture tunée qui dispose de tout ce qu'a une
voiture normale.

Hériter, c'est se spécialiser et redéfinir le fonctionnement de certaines méthodes.

Par héritage, seules les variables et méthodes protégées (#) ou publiques (+) seront accessibles
à VoitureTunee. Tout ce qui est privé reste propriété de Voiture. N'oublions pas que
VoitureTunee peut redéfinir la portée des éléments dont elle a hérité.

VoitureTunee est vue comme un cas particulier de Voiture. Les relations avec d'autres classes
sont donc conservées par héritage.

Dépendance / Utilisation

Le comportement ou fonctionnement peut être guidé par une classe externe. Ici, une
modification de la réglementation influe sur l'attitude du conducteur et des caractéristiques des
voitures (troisième feu, feu de recul...).

Le marqueur est une flèche en tirets. Il représente donc l'utilisation d'une classe référencée par
un pointeur.

Paquet

C'est un ensemble réutilisable (un groupe d'objets le plus souvent) qui s'inclut dans un autre
projet. C'est à l'image d'un plugin ou d'un framework de développement.
 Un paquet est souvent dédié à une tâche précise, et donc ne contient que les objets nécessaires à
cette tâche. Le contenu est varié et importe peu tant qu'il répond aux besoins.

Le nommage d'un paquet se fait souvent comme l'adresse d'un site web mais écrit à l'envers. Par
exemple: fr.free.ecrucru.vehicules

Diagramme des cas d'utilisation

Ce diagramme permet de faire le point sur les besoins de l'utilisateur. Aucune compétence
informatique n'est exigée.

Acteur
C'est une personne qui va interagir avec le système.

Cas d'utilisation

C'est une action qu'il est possible de réaliser et que le système doit savoir gérer. Elle se
représente avec une ellipse et utilise un verbe à l'infinitif.

Système

C'est un rectangle qui délimite acteurs et actions. Toutes les actions sont incluses dans le
système.

Exemple
 Sur ce schéma, le garagiste hérite du client (flèche creuse). En effet, il peut être un client mais il
a surtout la faculté spécifique de savoir réparer des voitures.

On voit également un cas interne qui ne dépend pas des acteurs : Vérifier le paiement. La flèche
est en pointillé et doit être complétée par un stéréotype (sorte d'attribut assigné au lien) :

<<includes>> : l'appel sera systématique dès que le cas non flèché sera appelé.

<<extends>> : il est probable que le cas interne soit appelé.

Dans notre exemple, si le garagiste ne fait pas crédit, on utilisera <<includes>>. S'il fait crédit
mais veut parfois vérifier que le client a les moyens de payer, on utilisera <<extends>>.

Diagramme d'état-transition
Ce diagramme met en valeur l'évolution du système lorsqu'il est soumis à des évènements
extérieurs. On ne se soucie guère du fonctionnement interne.

Un exemple d'application serait le passage d'un état marche à arrêt dès l'appui sur le bouton
d'urgent (l'événement extérieur).

Les outils utilisés ressemblent au GRAFCET.

Etat
Une situation dans laquelle se trouve notre système.

Transition

C'est ce qui permet de changer d'état. Le sens de navigation est donné nécessairement par une
flèche.
Activité de changement d'état
Lorsqu'on change d'état, il faut parfois faire des trucs en plus. Par exemple, si je suis le système
et que je rentre dans le bureau, il faudra peut-être que je pose mon manteau avant de passer dans
l'état "travaille dans le bureau".

Avec "entry", on effectue une action à l'entrée dans l'état. Avec "exit", elle se fait en sortant.
Entre les deux, on utilise "do".

Pour notre voiture :

Etat initial et final

Quand l'objet est créé (opérateur NEW), il est dans son état initial.

L'état final correspond parfois à la fin de vie de l'objet.

Il est impossible de revenir au point initial.

Transition conditionnelle

On met entre crochets la condition qui permet de franchir la transition.

La conséquence se met après une barre oblique.

Jonction / Choix
La jonction permet de regrouper des liens qui pointent vers la même cible. C'est esthétique et
rien ne peut se produire au niveau du point.

Si une transition opère un choix (1+ entrée et 2+ sorties), on met en place un choix.

ArgoUML représente la jonction avec un losange et le choix avec un rond, alors qu'a priori, c'est
l'inverse.

Fourches

Le passage d'une fourche force le système à être dans plusieurs états à la fois. Il ne peut sortir de
cet état qu'une fois les conditions de chaque état vérifiées.
C'est utile pour synchroniser des états.

Imbrication
On peut emboîter les états les uns dans les autres.

Diagramme d'activité
Bientôt ou à l'occasion...