UML diagramy komponent

Diagram komponent popisuje systém jako vyměnitelné části. Komponenta v UML není ledajaká třída - je to jednotka s definovanou hranicí, kterou by šlo v principu vyměnit za jinou implementaci týchž smluv, aniž by si toho okolí všimlo.

V té definici je celá hodnota. Diagram vás nutí u každé části zapsat právě dvě věci: co poskytuje a co vyžaduje. Tyhle dva seznamy jsou smlouvou dané části se zbytkem systému a jsou přesně tím, co opravdu potřebujete při plánování migrace, odhadu přepisu nebo rozhodování, zda je hranice služby na správném místě.

Forma kuličky a objímky (ball and socket) je kompaktní a většina nástrojů ji kreslí ve výchozím stavu: lízátko trčící z komponenty je rozhraní, které poskytuje, polovina kalíšku je to, které vyžaduje, a kulička spočívající v objímce jsou obě zapojené do sebe. Je to tatáž informace jako šipky výše, jen na menším místě. Použijte tu, kterou vaši čtenáři zvládnou snáz; v rámci jednoho diagramu buďte konzistentní.

Každá značka, kterou tenhle druh diagramu unese - obě notace rozhraní, assembly i delegační konektory, porty a čtyři stereotypy, které se vyplatí psát - je vysvětlena v symbolech diagramu komponent.

Na téhle otázce uvázne každý první diagram komponent a specifikace nepomůže: UML říká, že komponenta je vyměnitelná jednotka s definovanou smlouvou, a velikost nechává zcela na vás. Pro normu je to správná odpověď a u tabule nepoužitelná, takže tady je pracovní pravidlo.

Komponenta je to, co byste uměli vypsat do soutěže. Pokud si dokážete představit, že jinému týmu podáte seznamy poskytovaných a vyžadovaných rozhraní a řeknete „postavte tohle, dovnitř se nepodíváme“, je to komponenta. Pokud by si to předání vyžádalo rozhovor o vnitřnostech, hranice je nakreslená na špatném místě - a to je zjištění, ne kreslicí problém, který je třeba obejít.

V praxi to obvykle dopadne na jednu z těchhle možností a to, na kterou, vám řekne, k čemu diagram je.

• Nasaditelná služba. Jeden repozitář, jedna pipeline, jedna pohotovost. Nejčastější odpověď u čehokoli postaveného za poslední dekádu a úroveň, na které se vyplatí držet diagram v repozitáři.
• Knihovna nebo modul. Uvnitř jedné nasaditelné jednotky, když se spor vede o vnitřní strukturu - který balíček smí záviset na kterém. Tady často řekne totéž levněji diagram balíčků.
• Celý systém. Mainframe, CRM, platební poskytovatel. Úroveň pro kontextový diagram, kde jde o to, na čem závisíte, ne jak je to postaveno.

Míchání dvou z těchhle úrovní na jednom diagramu je chyba, která vyrábí ty rozbujelé diagramy komponent, na které si lidé vzpomínají. Obrázek se třemi mikroslužbami, jednou pomocnou knihovnou a „SAP“ jsou tři diagramy položené na sebe a žádný čtenář nepozná, které boxy jsou si rovné.

Nejužitečnější technikou čtení je zakrýt komponentu dlaní. Co zbude, je její smlouva: rozhraní, která k ní byla připojena. Pokud ten seznam umíte podat jinému týmu se slovy „postavte něco, co tomuhle vyhoví“, diagram dělá svou práci. Pokud ne - pokud by výměna komponenty vyžadovala znát věci, které nakreslené nejsou - hranice je na špatném místě, a to se vyplatí vědět dřív, než se o to někdo pokusí.

Druhou technikou je sledovat vyžadovaná rozhraní. Každé z nich je závislost, kterou musí někdo naplnit, a cyklus v tomhle grafu je skutečný architektonický problém, který diagram komponent okamžitě zviditelní.

Obě techniky se snáz vidí použité než popsané. Pět diagramů systémů, na kterých jste pravděpodobně pracovali - sdílený katalog, porty a adaptéry, výměna legacy systému, hostitel zásuvných modulů a cyklus - je rozebráno v příkladech diagramů komponent, každý se sporem, který řeší.

Pět druhů diagramů jsou obdélníky spojené čarami a rozdíl mezi nimi je zcela v tom, čím obdélník je. Vybrat ten špatný je tu nejdražší dostupná chyba, protože diagram bude vypadat v pořádku a odpoví na otázku, kterou nikdo nepoložil.

Nejčastěji se objeví otázka komponentový versus nasazení a rozdělení je po vyslovení čisté: komponenta je logická jednotka a uzel fyzická. Jedna komponenta může běžet na čtyřiceti uzlech; jeden uzel může hostit tucet komponent. Ve chvíli, kdy box na vašem diagramu komponent dostane region, počet instancí nebo název hostitele, přestal být komponentou a diagram se potichu stal dvěma.

Pokud jste se setkali s C4, jeho diagram kontejnerů leží skoro přesně tam, kde diagram komponent na úrovni nasaditelné služby, a jeho vlastní úroveň „komponent“ je o krok hlouběji, než UML obvykle myslí. Slovníky si nesednou, takže na diagram napište, který používáte - ten jeden řádek legendy předejde většině sporů.

Diagramy komponent stárnou dobře, což je neobvyklé. Rozhraní se mění mnohem pomaleji než kód za nimi, takže diagram komponent uložený v repozitáři zůstává pravdivý mnohem déle než diagram tříd téhož systému - a odpovídajícím způsobem víc se vyplatí ho udržovat.

1. Komponenty, které jsou ve skutečnosti třídy. Pokud to nelze věrohodně vyměnit samostatně, není to komponenta. Použijte diagram tříd.
2. Nakreslená jen poskytovaná rozhraní. Vyžadovaná nesou informaci o závislostech, což je ta užitečnější polovina.
3. Šipky mezi komponentami bez rozhraní. Holá šipka říká „nějak závisí“, což je právě to, co má tenhle diagram zpřesnit.
4. Přimíchané nasazení. Servery, regiony a kontejnery patří na diagram nasazení.
5. Rozhraní pojmenovaná podle poskytovatele. ILedger je v pořádku, když je jedna účetní kniha; když můžou být dvě implementace, pojmenujte smlouvu podle schopnosti, ne podle současného dodavatele.