UML simplement pour les nuls

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

Dernière modification le 30 juin 2012 à 21:08