UML-Komponentendiagramm-Vorlage
Vier Komponenten und drei Schnittstellen, jede von genau einer Komponente angeboten und von einer anderen benötigt - die einzige Anordnung, für die ein Komponentendiagramm überhaupt existiert.
Notation: UML 2.5.1Diagramm: Komponentendiagramm
Diese Vorlage in Archyno öffnen
Sie öffnet sich als bearbeitbares Modell, nicht als Bild. Im Browser ändern, dann als PNG, SVG, Mermaid, XMI oder Sparx-.qea-Datei exportieren.
Vorlage öffnenWas auf diesem Diagramm steht
- Storefront
- Ein Konsument. Benötigt eine Schnittstelle und bietet keine an - der Rand des Systems.
- OrderIntake
- Der Vertrag zwischen Storefront und Service. Benennen Sie ihn vor beiden Komponenten um.
- Order service
- Die Komponente, die eine Schnittstelle anbietet und zwei benötigt. So sehen die meisten Ihrer Komponenten aus.
- OrderRepository
- Persistenz als Vertrag, damit der Speicher dahinter ohne Eingriff in den Service austauschbar bleibt.
- Order store
- Die realisierende Komponente. Der Stereotyp «database» sagt, um welche Art Ding es sich handelt.
- Payment adapter
- Der gekapselte Dritte. Die Schnittstelle gehört Ihnen, auch wenn der Anbieter dahinter es nicht tut.
So machen Sie es zu Ihrem
- Benennen Sie zuerst die Schnittstellen um. Ein Komponentendiagramm handelt von Verträgen, und die Komponentennamen sind der Teil, über den ohnehin schon Einigkeit besteht.
- Prüfen Sie, dass jede Schnittstelle von genau einer Komponente angeboten wird. Zwei Anbieter sind das Diagramm eines ungeklärten Streits.
- Zeichnen Sie das benötigte Ende als Abhängigkeit und das angebotene als Realisierung. Vertauscht kehren sie die Richtung des gesamten Entwurfs um.
- Verbinden Sie nie zwei Komponenten direkt. Fehlt die Schnittstelle dazwischen, ist das Diagramm eine Kästchen-und-Linien-Skizze und die Notation tut nichts.
- Setzen Sie einen Stereotyp nur dort, wo die Art der Komponente die Bereitstellung ändert - «database», «service», «device». Alles zu stereotypisieren sagt nichts.
- Lassen Sie den Adapter des Drittanbieters stehen. Die eigene Schnittstelle vor einem fremden Anbieter ist der ganze Grund, dieses Diagramm zu zeichnen.
Häufige Fragen
Was ist der Unterschied zwischen angebotener und benötigter Schnittstelle?
Eine angebotene Schnittstelle implementiert die Komponente - jeder darf sie aufrufen. Eine benötigte Schnittstelle muss jemand anderes implementieren, sonst funktioniert die Komponente nicht. In dieser Vorlage bietet der Order Service OrderIntake an und benötigt OrderRepository und PaymentGateway, ist also Anbieter und Konsument zugleich - so wie die meisten echten Komponenten.
Sollte ich stattdessen die Ball-and-Socket-Notation verwenden?
Beide sind korrektes UML und bedeuten dasselbe. Ball and Socket ist kompakter und liest sich gut, wenn eine Schnittstelle genau zwei Komponenten verbindet; die hier verwendete Klassifiziererform skaliert besser, weil ein zweiter Konsument nur ein weiterer gestrichelter Pfeil ist statt eines neu gezeichneten Konnektors. Nehmen Sie die, die Ihr Team ohne Rückfrage liest.
Ist ein Komponentendiagramm dasselbe wie ein Verteilungsdiagramm?
Nein. Ein Komponentendiagramm sagt, welche Softwareteile es gibt und wie sie voneinander abhängen; ein Verteilungsdiagramm sagt, auf welcher Maschine jeder Teil läuft. Sie werden oft zusammen gezeichnet, und beides in ein Bild zu pressen ist der übliche Grund, warum keines von beiden lesbar ist.
Die Notation nachlesen
Wie man ein UML-Komponentendiagramm liest und zeichnet: Komponenten, angebotene und benötigte Schnittstellen, Kugel-Pfanne-Notation, Ports, und der Unterschied zum Klassendiagramm.
Eine Referenz für jedes Symbol im UML-Komponentendiagramm: Komponentenkasten, angebotene und benötigte Schnittstellen, Kugel und Pfanne, Assembly- und Delegations-Konnektoren, Ports und Stereotypen.
Schritt für Schritt: die Teile wählen, die Kästen zeichnen, benennen was jedes anbietet, ergänzen was es braucht, und die vier Prüfungen laufen lassen, die sagen, dass das Diagramm fertig ist.
Fünf ausgearbeitete UML-Komponentendiagramm-Beispiele: ein geteilter Katalog, Ports und Adapter, eine Legacy-Ablösung, eine Plugin-Architektur und ein Abhängigkeitszyklus.