UML diagramy komponentov

Diagram komponentov popisuje systém ako vymeniteľné časti. Komponent v UML nie je hocijaká trieda - je to jednotka s definovanou hranicou, ktorá by sa v princípe dala vymeniť za inú implementáciu tých istých zmlúv bez toho, aby si to okolie všimlo.

V tej definícii je celá hodnota. Diagram vás núti pri každej časti zapísať práve dve veci: čo poskytuje a čo vyžaduje. Tieto dva zoznamy sú zmluvou tej časti so zvyškom systému a sú presne tým, čo naozaj potrebujete pri plánovaní migrácie, odhade prepisu alebo rozhodovaní, či je hranica služby na správnom mieste.

Forma guľôčky a objímky (ball and socket) je kompaktná a väčšina nástrojov ju kreslí predvolene: lízatko trčiace z komponentu je rozhranie, ktoré poskytuje, polovička pohárika je to, ktoré vyžaduje, a guľôčka spočívajúca v objímke sú obe zapojené do seba. Je to tá istá informácia ako šípky vyššie, len na menšom mieste. Použite tú, ktorú vaši čitatelia zvládnu ľahšie; v rámci jedného diagramu buďte konzistentní.

Každá značka, ktorú tento druh diagramu unesie - obe notácie rozhraní, assembly aj delegačné konektory, porty a štyri stereotypy, ktoré sa oplatí písať - je vysvetlená v symboloch diagramu komponentov.

Na tejto otázke uviazne každý prvý diagram komponentov a špecifikácia nepomôže: UML hovorí, že komponent je vymeniteľná jednotka s definovanou zmluvou, a veľkosť necháva úplne na vás. Pre normu je to správna odpoveď a pri tabuli nepoužiteľná, takže tu je pracovné pravidlo.

Komponent je to, čo by ste vedeli vypísať do súťaže. Ak si viete predstaviť, že inému tímu podáte zoznamy poskytovaných a vyžadovaných rozhraní a poviete „postavte toto, dovnútra sa nepozrieme“, je to komponent. Ak by si to odovzdanie vyžiadalo rozhovor o vnútornostiach, hranica je nakreslená na zlom mieste - a to je zistenie, nie kresliaci problém, ktorý treba obísť.

V praxi to zvyčajne dopadne na jednu z týchto možností a to, na ktorú, vám povie, na čo diagram je.

• Nasaditeľná služba. Jeden repozitár, jedna pipeline, jedna pohotovosť. Najčastejšia odpoveď pri čomkoľvek postavenom za posledné desaťročie a úroveň, na ktorej sa oplatí držať diagram v repozitári.
• Knižnica alebo modul. Vnútri jednej nasaditeľnej jednotky, keď sa spor vedie o vnútornú štruktúru - ktorý balík smie závisieť od ktorého. Tu často povie to isté lacnejšie diagram balíkov.
• Celý systém. Mainframe, CRM, platobný poskytovateľ. Úroveň pre kontextový diagram, kde ide o to, od čoho závisíte, nie ako je to postavené.

Miešanie dvoch z týchto úrovní na jednom diagrame je chyba, ktorá vyrába tie rozbujnené diagramy komponentov, na ktoré si ľudia spomínajú. Obrázok s tromi mikroslužbami, jednou pomocnou knižnicou a „SAP“ sú tri diagramy položené na seba a žiadny čitateľ nerozozná, ktoré boxy sú si rovné.

Najužitočnejšou technikou čítania je zakryť komponent dlaňou. Čo zostane, je jeho zmluva: rozhrania, ktoré k nemu boli pripojené. Ak ten zoznam viete podať inému tímu so slovami „postavte niečo, čo tomuto vyhovie“, diagram robí svoju prácu. Ak nie - ak by výmena komponentu vyžadovala vedieť veci, ktoré nakreslené nie sú - hranica je na zlom mieste, a to sa oplatí vedieť skôr, než sa o to niekto pokúsi.

Druhou technikou je sledovať vyžadované rozhrania. Každé z nich je závislosť, ktorú musí niekto naplniť, a cyklus v tomto grafe je skutočný architektonický problém, ktorý diagram komponentov okamžite zviditeľní.

Obe techniky sa ľahšie vidia použité než opísané. Päť diagramov systémov, na ktorých ste pravdepodobne pracovali - zdieľaný katalóg, porty a adaptéry, výmena legacy systému, hostiteľ zásuvných modulov a cyklus - je rozobratých v príkladoch diagramov komponentov, každý so sporom, ktorý rieši.

Päť druhov diagramov sú obdĺžniky spojené čiarami a rozdiel medzi nimi je úplne v tom, čím obdĺžnik je. Vybrať ten nesprávny je tu najdrahšia dostupná chyba, lebo diagram bude vyzerať v poriadku a odpovie na otázku, ktorú nikto nepoložil.

Najčastejšie sa objaví otázka komponentový verzus nasadenia a rozdelenie je po vyslovení čisté: komponent je logická jednotka a uzol fyzická. Jeden komponent môže bežať na štyridsiatich uzloch; jeden uzol môže hostiť tucet komponentov. V okamihu, keď box na vašom diagrame komponentov dostane región, počet inštancií alebo názov hostiteľa, prestal byť komponentom a diagram sa potichu stal dvomi.

Ak ste sa stretli s C4, jeho diagram kontajnerov leží takmer presne tam, kde diagram komponentov na úrovni nasaditeľnej služby, a jeho vlastná úroveň „komponentov“ je o krok hlbšie, než UML zvyčajne myslí. Slovníky si nesadnú, takže na diagram napíšte, ktorý používate - ten jeden riadok legendy predíde väčšine sporov.

Diagramy komponentov starnú dobre, čo je nezvyčajné. Rozhrania sa menia oveľa pomalšie než kód za nimi, takže diagram komponentov uložený v repozitári zostáva pravdivý oveľa dlhšie než diagram tried toho istého systému - a zodpovedajúco viac sa oplatí ho udržiavať.

1. Komponenty, ktoré sú v skutočnosti triedy. Ak sa to nedá vierohodne vymeniť samostatne, nie je to komponent. Použite diagram tried.
2. Nakreslené len poskytované rozhrania. Vyžadované nesú informáciu o závislostiach, čo je tá užitočnejšia polovica.
3. Šípky medzi komponentmi bez rozhrania. Holá šípka hovorí „nejako závisí“, čo je práve to, čo má tento diagram spresniť.
4. Primiešané nasadenie. Servery, regióny a kontajnery patria na diagram nasadenia.
5. Rozhrania pomenované podľa poskytovateľa. ILedger je v poriadku, keď je jedna účtovná kniha; keď môžu byť dve implementácie, pomenujte zmluvu podľa schopnosti, nie podľa súčasného dodávateľa.