Rubrique « Info »

Les 5 relations UML ?

Voilà ce que l'on peut extraire du modèle UML1.4  :

On trouve donc :

La relation : connexions entre les éléments d'un modèle.

La généralisation (héritage) : relation de taxinomique entre un élément plus général et un élément plus spécifique.
[On rappellera que la taxinomie, selon sa définition la plus simple est l'«étude théorique de la classification, de ses bases, de ses principes, des méthodes et des règles». Il s'agit de la méthodologie de la systématique et de la classification.]
Saviez-vous que :
1/ la relation "realize" (qui se note comme la généralization, mais avec un trait pointillé) n'est pas une généralisation, mais une dépendance de type abstraction avec le stéréotype "realize" ?
2/ La généralisation s'applique entre des classes que entre des associations (en théorie, on peut relier deux lignes représentant deux associations par une flèche représentant une généralisation ! en pratique... on préférera représenter les associations comme des classes et les relier entre elles... mais surtout, on ne fait jamais de généralisation entre association !!!)

La dépendance : relation sémantique (c.à.d. "porteuse de sens") indiquant une utilisation entre deux concepts : cela concerne uniquement les concepts et non leurs instance. Toute dépendance joue un rôle majeur dans le problème du couplage, déjà vigoureusement dénoncé dans ce site.
On distingue :
    L'utilisation (« usage ») : une dépendance simple, en terme d'utilisation. Simplement, les stéréotype de cette dépendance permet de préciser le type d'utilisation concerné. C'est elle qui est la source la plus courante des couplages malheureux!
        - l'appel (« call » ) : appel d'une opération par une autre opération ;
        - la création (« create » ) : le client crée des instances du fournisseur ;
        - l'instanciation (« instanciate » ) : une opération du client crée des instances du fournisseur ;
        - l'envoi (« send » ) : une opération envoie un signal à un élément cible.
    L'abstraction : relie 2 éléments qui représentent le même concept à différents niveaux d'abstraction ou selon différents points de vue. Les 4 abstractions (via stéréotype) prévues par UML sont :
        - la dérivation (« derive » ) : un élément peut être calculé depuis un autre ;
        - la réalisation (« realize » ) : déjà mentionnée plus haut, elle implique qu'un élément implémente complètement un autre élément dit de spécification (courant pour implémenter les "interfaces") Encore une fois, il ne s'agit pas d'héritage!
        - le rafinement (« refine » ) : permet de relier deux éléments qui se trouvent à deux niveaux sémantiques différents : typiquement, 2 classes de mêmes noms, mais dont l'une se trouve au niveau "Analyse" et l'autre au niveau "Conception". En pratique, aucun outil de type AGL ne permet de mettre en oeuvre facilement ces relations qui permettraient pourtant de résoudre un des grands écarts des AGL : la dégradation du modèle d'analyse en modèle de conception.
        - le traçage (« trace » ) : permet de suivre les différentes évolutions d'un même concept de modèle en modèle. Là encore, c'est très peu mis en oeuvre...
    L'instanciation de template (« binding ») : relation entre un template (fournisseur) et élément (client) généré à partir du template, qui instancie le template en substituant aux paramètres du template les siens.
    La permission : permet à un élément d'accéder à un autre issu d'un espace de nommage différent. L'espace de nommage est un élément d'UML 1.4 qui regroupe d'autre éléments afin d'éviter tout conflit d'identification. 3 types de permissions sont distingués :
        - l'accès (« access » ) : concerne 2 espaces de nommage dont l'un peut accéder aux éléments de l'autres ;
        - l'ami (« friend » ) : permet à un élément du modèle (opération, classe, package) d'accéder à un autre élément du modèle, quelque soit la visibilité de ce dernier ;
        - l'import (« import » ) : le contenu publique de l'espace de nommage cible est ajouté à l'espace de nommage source.

L'association : relation sémantique plus forte que la dépendance, elle indique une relation stable entre 2 concepts (à opposer à la relation ponctuelle d'utilisation de la dépendance). Un concept à besoin d'un autre pour être défini.
    La "classe-association" : une association qui est aussi une classe ! Pratique lorsque l'on a un attribut qui porte sur un couple de classe. On met alors cet attribut dans une "classe association" qui relie les 2 classes. (une réminiscence des dépendances fonctionnelles en Base de Données!) Exemple : l'attribut "salaire" dépend de la Personne (employé) et de la Société (employeur): on créera la classe "Métier" (avec attribut "salaire") pour relier les 2.
    Le "rôle-association" : une utilisation spécifique d'une association au sein d'une collaboration. Rappelons que la collaboration permet de décrire comment une opération ou un cas d'utilisation est réalisé avec des éléments et associations

Le flot : relation entre deux versions d'un élément, ou entre un élément et une copie. 2 stéréotypes existent :
    L'évolution (« become ») : une même instance à 2 instants t différents, avec potentiellement des valeurs, états et rôles différents. 
    La copie (« copy ») : deux instances différentes, mais avec les mêmes valeurs, états et rôles. 

L'inclusion : défini un cas d'utilisation comme l'inclusion des comportements d'un autre cas d'utilisation. C'est une factorisation du comportement.

L'extension : étend le comportement d'un cas d'utilisation avec de nouveau comportements d'une autre cas d'utilisation.