Modèle de diagramme de composants UML
Quatre composants et trois interfaces, chacune fournie par exactement un composant et requise par un autre - la seule disposition pour laquelle un diagramme de composants existe.
Notation: UML 2.5.1Diagramme: Diagramme de composants
Ouvrir ce modèle dans Archyno
Il s'ouvre comme un modèle modifiable, pas comme une image. Modifiez-le dans le navigateur, puis exportez en PNG, SVG, Mermaid, XMI ou fichier Sparx .qea.
Ouvrir ce modèleCe que contient ce diagramme
- Storefront
- Un consommateur. Il requiert une interface et n'en fournit aucune - le bord du système.
- OrderIntake
- Le contrat entre la boutique et le service. Renommez-le avant l'un ou l'autre composant.
- Order service
- Le composant qui fournit une interface et en requiert deux. La plupart de vos composants ressemblent à cela.
- OrderRepository
- La persistance en tant que contrat, pour que le stockage derrière reste remplaçable sans toucher au service.
- Order store
- Le composant réalisateur. Le stéréotype «database» dit de quel genre de chose il s'agit.
- Payment adapter
- Le tiers, encapsulé. L'interface vous appartient même quand le fournisseur derrière elle non.
Comment se l'approprier
- Renommez d'abord les interfaces. Un diagramme de composants parle de contrats, et les noms des composants sont la partie sur laquelle tout le monde est déjà d'accord.
- Vérifiez que chaque interface est fournie par exactement un composant. Deux fournisseurs, c'est le diagramme d'un désaccord non tranché.
- Tracez l'extrémité requise en dépendance et l'extrémité fournie en réalisation. Les inverser retourne le sens de toute la conception.
- Ne reliez jamais deux composants directement. S'il n'y a pas d'interface entre eux, le diagramme est un croquis de boîtes et de traits et la notation ne sert à rien.
- N'ajoutez un stéréotype que là où la nature du composant change son déploiement - «database», «service», «device». Tout stéréotyper ne dit rien.
- Laissez l'adaptateur du tiers en place. L'interface que vous possédez devant un fournisseur que vous ne possédez pas est toute la raison de tracer ce diagramme.
Questions fréquentes
Quelle est la différence entre interface fournie et requise ?
Une interface fournie est implémentée par le composant - n'importe qui peut l'appeler. Une interface requise doit être implémentée par quelqu'un d'autre, faute de quoi le composant ne fonctionne pas. Dans ce modèle, Order service fournit OrderIntake et requiert OrderRepository et PaymentGateway : il est donc fournisseur et consommateur, ce que sont la plupart des composants réels.
Faut-il plutôt utiliser la notation en boule et douille ?
Les deux sont du UML correct et signifient la même chose. La boule et douille est plus compacte et se lit bien quand une interface relie exactement deux composants ; la forme classifieur employée ici passe mieux à l'échelle, car un second consommateur n'est qu'une flèche pointillée de plus au lieu d'un connecteur redessiné. Utilisez celle que votre équipe lit sans poser de question.
Un diagramme de composants est-il un diagramme de déploiement ?
Non. Un diagramme de composants dit quelles sont les pièces logicielles et comment elles dépendent les unes des autres ; un diagramme de déploiement dit sur quelle machine chaque pièce s'exécute. On les dessine souvent ensemble, et les fondre en une seule image est la raison habituelle pour laquelle aucun des deux n'est lisible.
Lire la notation
Comment lire et dessiner un diagramme de composants UML : composants, interfaces fournies et requises, notation rotule et cavité, ports, et ce qui le distingue d'un diagramme de classes.
Une référence de tous les symboles du diagramme de composants UML : la boîte composant, les interfaces fournies et requises, rotule et cavité, connecteurs d'assemblage et de délégation, ports et stéréotypes.
Dessiner un diagramme de composants
Pas à pas : choisir les pièces, dessiner les boîtes, nommer ce que chacune fournit, ajouter ce qu'elle requiert, puis passer les quatre vérifications qui disent que le diagramme est terminé.
Cinq exemples de diagrammes de composants UML : un catalogue partagé, ports et adaptateurs, le remplacement d'un système legacy, une architecture à plugins et un cycle de dépendances.