UMLDiagrammes de structure

Diagrammes de paquetages UML

Comment un modèle ou une base de code est regroupé et - la partie qui compte - quel groupe a le droit de dépendre de quel autre. Le diagramme qui rend une règle d'architecture vérifiable au lieu de simplement souhaitable.

27 juillet 20266 min de lectureUML 2.5.124 sur 35

La réponse courte

Les flèches absentes disent autant que celles qui sont tracées. Toute dépendance du code sans flèche sur le diagramme est une violation que l'on peut nommer.
Import fait entrer les membres publics dans l'espace de noms importateur et les ré-exporte ; access les rend utilisables et arrête là la dépendance.
Package merge copie le contenu du paquetage fusionné dans le fusionnant. Très utilisé dans la spécification UML elle-même, rarement dans les modèles ordinaires.
Un diagramme de paquetages porte sur la structure des sources, un diagramme de composants sur les parties déployables. Ce ne sont pas deux vues de la même chose.

Un diagramme de paquetages UML d'une architecture en couches. Le paquetage ui et le paquetage infrastructure dépendent tous deux du paquetage domain. Les trois - ui, domain et infrastructure - dépendent d'un paquetage shared situé en dessous. — Une architecture en couches vue comme un graphe de dépendances. Chaque flèche pointe vers quelque chose de plus stable que sa source, et rien ne remonte.

01Ce qu'il montre#

Un diagramme de paquetages est la table des matières d'un modèle, plus une règle sur qui a le droit de référencer qui. La forme du dossier à onglet est un espace de noms : un groupe de classes, de cas d'utilisation, de composants ou d'autres paquetages.

Le regroupement seul est modérément utile. La valeur est dans les flèches. Une dépendance de ui vers domain dit que la couche interface a le droit de référencer les types du domaine. L'absence de flèche en sens inverse dit que le domaine ne doit pas savoir que l'interface existe - et c'est une règle d'architecture que vous pouvez tester, analyser et faire échouer un build dessus.

02La notation#

Élément	Notation	Ce que cela signifie
Paquetage	dossier à onglet	Un espace de noms. Son nom va dans l'onglet quand le corps contient des éléments, dans le corps sinon.
Dépendance		La source référence quelque chose dans la cible. Le cas général, et souvent suffisant.
«import»		Les membres publics de la cible deviennent visibles dans la source et en sont ré-exportés.
«access»		Visibles dans la source mais pas ré-exportés. La plus étroite, et souvent la plus juste, des deux.
«merge»		Le contenu de la cible est fusionné dans la source. Rare hors des métamodèles ; vous le lirez plus souvent que vous ne l'écrirez.
Imbrication	paquetage dans un paquetage	Contenance, écrite `outer::inner`. Peut aussi se dessiner par un trait avec une croix cerclée du côté du parent.

En pratique, la simple flèche de dépendance porte la plupart des diagrammes de paquetages, et la distinction entre «import» et «access» ne gagne sa place que si vous modélisez un langage ou un framework dont le système de modules rend la différence réelle.

03Lire la direction#

Tout ce qui est intéressant dans un diagramme de paquetages tient à la direction des flèches, et il y a deux choses à chercher.

Les cycles. Si vous pouvez partir d'un paquetage, suivre les flèches et revenir à votre point de départ, ces paquetages ne peuvent pas être construits, testés, compris ni déployés indépendamment. Ils sont un seul paquetage qui fait semblant d'en être plusieurs. Un diagramme de paquetages rend un cycle visible en deux secondes environ, ce qui est le moyen le plus rapide d'en trouver un à défaut d'outil.

La stabilité. Les dépendances devraient pointer vers ce qui change le moins souvent. Sur le diagramme ci-dessus, ui et infrastructure pointent tous deux vers domain, et les trois pointent vers shared. C'est la forme d'une architecture en couches : le volatil dépend du stable, jamais l'inverse. Une flèche de domain vers ui serait la chose la plus importante de la page.

C'est aussi ainsi qu'on repère un paquetage shared ou common qui dérape. Celui vers lequel tout pointe est très bien, tant qu'il ne pointe lui-même vers rien. Dès qu'il acquiert une flèche sortante, chaque paquetage du système dépend transitivement de cette cible.

04Quand en dessiner un#

À utiliser quand

Établir ou documenter une règle de couches destinée à être appliquée
Passer en revue une base de code à la recherche de cycles de dépendances entre modules
Donner à un nouvel arrivant la carte d'un dépôt avant le détail
Planifier le découpage d'un monolithe - les lignes de coupe sont là où les flèches sont fines

Préférer autre chose quand

Il y a trois paquetages et la structure ressort de l'arborescence
L'intéressant, ce sont les contrats entre parties - prenez un diagramme de composants
Vous devriez le redessiner à chaque fichier déplacé
Le regroupement existe mais aucune règle de dépendance ; les flèches seraient du bruit descriptif

Les diagrammes de paquetages marchent bien à deux altitudes et mal entre les deux : le système entier à cinq ou neuf paquetages, ou un sous-système à granularité comparable. Un diagramme de quarante paquetages est un graphe de dépendances, et un graphe de dépendances se lit mieux avec un outil qu'avec les yeux.

En une ligne chacun

01Les paquetages sont des espaces de noms ; les flèches entre eux sont le vrai contenu.
02«import» ré-exporte, «access» non ; une dépendance simple suffit en général.
03Suivez les flèches pour trouver les cycles - des paquetages en cycle sont un seul paquetage.
04Les dépendances devraient pointer vers ce qui change le moins.
05Tout peut pointer vers un paquetage partagé ; lui ne doit pointer vers rien.
06C'est le diagramme UML le plus susceptible de devenir une vérification automatique de build.

05Questions fréquentes#

Quelle différence entre import et access en UML ?

Les deux sont des dépendances entre paquetages. Import fait entrer les membres publics du paquetage importé dans l'espace de noms importateur : ils peuvent être nommés sans qualification et sont ré-exportés plus loin. Access les rend utilisables sans les ré-exporter, si bien que la dépendance s'arrête là.

Comment montrer une architecture en couches en UML ?

Un paquetage par couche et une flèche de dépendance par sens autorisé, toutes orientées pareil. L'intérêt tient à ce que les flèches absentes disent autant que celles qui sont tracées : toute dépendance du code sans flèche sur le diagramme est une violation que l'on peut nommer.

Que signifie package merge ?

Merge signifie que le contenu du paquetage fusionné est conceptuellement copié dans le paquetage fusionnant et combiné à ce qui s'y trouve déjà. C'est très utilisé à l'intérieur de la spécification UML elle-même, et rarement dans les modèles ordinaires.

Quelle différence entre diagramme de paquetages et de composants ?

Un diagramme de paquetages regroupe des éléments de modèle et montre des dépendances d'espaces de noms : il porte sur l'organisation du modèle ou de la base de code. Un diagramme de composants montre des unités remplaçables à l'exécution et les interfaces entre elles. L'un concerne la structure des sources, l'autre les parties déployables.

PartagerX LinkedIn

↑ Retour en haut Tous les articles : UML →

Dans cette série