Archyno

Šablona UML diagramu komponent

Čtyři komponenty a tři rozhraní, každé poskytované právě jednou komponentou a vyžadované jinou - což je jediné uspořádání, kvůli kterému diagram komponent existuje.

Notace: UML 2.5.1Diagram: Diagram komponent

Storefront«interface»OrderIntake«interface»OrderRepositoryOrder service«interface»PaymentGateway«database»Order storePayment adapter
Šablona tak, jak se otevře. Každá závislost končí na rozhraní, ne na jiné komponentě.

Otevřete tuto šablonu v Archynu

Otevře se jako upravitelný model, ne jako obrázek. Změňte ho v prohlížeči a exportujte do PNG, SVG, Mermaidu, XMI nebo souboru Sparx .qea.

Otevřít šablonu

Co je na tomto diagramu

Storefront
Spotřebitel. Rozhraní vyžaduje a žádné neposkytuje - okraj systému.
OrderIntake
Smlouva mezi obchodem a službou. Přejmenujte ji dřív než kteroukoli z komponent.
Order service
Komponenta, která jedno rozhraní poskytuje a dvě vyžaduje. Takhle vypadá většina vašich komponent.
OrderRepository
Perzistence jako smlouva, aby šlo úložiště za ní vyměnit bez zásahu do služby.
Order store
Realizující komponenta. Stereotyp «database» říká, o jaký druh věci jde.
Payment adapter
Zabalená třetí strana. Rozhraní je vaše, i když dodavatel za ním není.

Jak si ho přizpůsobit

  1. Nejdřív přejmenujte rozhraní. Diagram komponent je diagram o smlouvách a názvy komponent jsou ta část, na které se už všichni shodli.
  2. Ověřte, že každé rozhraní poskytuje právě jedna komponenta. Dva poskytovatelé jsou diagramem nevyřešeného sporu.
  3. Vyžadovaný konec kreslete jako závislost a poskytovaný jako realizaci. Jejich záměna obrátí směr celého návrhu.
  4. Nikdy nespojujte dvě komponenty přímo. Pokud mezi nimi není rozhraní, diagram je náčrt z boxů a čar a notace nedělá nic.
  5. Stereotyp přidejte jen tam, kde druh komponenty mění způsob nasazení - «database», «service», «device». Stereotypovat všechno neříká nic.
  6. Adaptér třetí strany nechte. Rozhraní, které vlastníte před dodavatelem, kterého nevlastníte, je celý důvod tenhle diagram kreslit.

Časté dotazy

Jaký je rozdíl mezi poskytovaným a vyžadovaným rozhraním?

Poskytované rozhraní komponenta implementuje - volat ho může kdokoli. Vyžadované rozhraní je takové, které musí implementovat někdo jiný, jinak komponenta nefunguje. V této šabloně Order service poskytuje OrderIntake a vyžaduje OrderRepository i PaymentGateway, takže je dodavatelem i spotřebitelem, čímž je většina skutečných komponent.

Mám raději použít notaci kuličky a objímky?

Obě jsou správné UML a znamenají totéž. Kulička a objímka je kompaktnější a čte se dobře, když rozhraní spojuje přesně dvě komponenty; forma s klasifikátorem použitá zde lépe škáluje, protože druhý spotřebitel je jen další přerušovaná šipka místo překreslení konektoru. Použijte tu, kterou váš tým čte bez ptaní.

Je diagram komponent totéž co diagram nasazení?

Ne. Diagram komponent říká, jaké jsou části softwaru a jak na sobě závisí; diagram nasazení říká, na jakém stroji každá část běží. Běžně se kreslí spolu a jejich sloučení do jednoho obrázku bývá důvod, proč není čitelný ani jeden.

Přečtěte si notaci

Diagramy komponent

Jak číst a kreslit UML diagram komponent: komponenty, poskytovaná a vyžadovaná rozhraní, notace koule a objímky, porty a čím se liší od diagramu tříd.

Symboly komponent

Přehled všech symbolů UML diagramu komponent: box komponenty, poskytovaná a vyžadovaná rozhraní, koule a objímka, konektory sestavy a delegování, porty a stereotypy.

Kreslení diagramu komponent

Návod krok za krokem: vyberte části, nakreslete boxy, pojmenujte, co každá poskytuje, doplňte, co vyžaduje, a spusťte čtyři kontroly, které řeknou, že je diagram hotový.

Příklady komponent

Pět hotových příkladů UML diagramu komponent - sdílený katalog, porty a adaptéry, výměna legacy systému, pluginy a cyklus závislostí - a k čemu je každý dobrý.

Všechny šablony