Diagram komponentów

Czym jest diagram komponentów#

Diagram komponentów (component diagram) przedstawia organizację modularnych części systemu i zależności między nimi. Pomaga zobaczyć, jakie większe elementy składają się na rozwiązanie, jakie usługi udostępniają i z jakich kontraktów korzystają. Jest diagramem strukturalnym: opisuje układ elementów, a nie kolejność wykonania scenariusza.

Komponent jest jednostką modelowania, którą można traktować jako część systemu o określonej odpowiedzialności i widocznych punktach współpracy. Jego implementacja może obejmować wiele klas, pakietów, artefaktów albo innych elementów. Z tego powodu diagram komponentów zwykle operuje na wyższym poziomie abstrakcji niż diagram klas. Konkretne znaczenie „komponentu” zależy od celu modelu: może chodzić o moduł aplikacji, usługę, bibliotekę, podsystem lub część systemu wbudowanego.

Diagram nie jest automatycznie diagramem wdrożenia. Może pokazać logiczne moduły bez określenia serwerów czy urządzeń. Gdy pytanie dotyczy tego, na jakim węźle działa dana część, jak jest rozmieszczona w środowisku albo przez jakie połączenie sieciowe komunikuje się z inną częścią, przydatny jest diagram wdrożenia.

Kiedy używać diagramu komponentów#

Diagram komponentów warto wybrać, gdy trzeba wyjaśnić granice modułów, kontrakty między zespołami, zależności architektoniczne lub miejsce elementu zewnętrznego w systemie. Może wspierać:

• omawianie podziału systemu na moduły i usług;
• pokazywanie odpowiedzialności i interfejsów między modułami;
• analizę kierunków zależności oraz ryzyka sprzężenia;
• dokumentowanie integracji z zewnętrznymi systemami;
• śledzenie, które elementy realizują wymagane funkcje lub inne elementy modelu;
• wyjaśnianie, jak większe części są złożone z mniejszych komponentów.

Nie jest dobrym wyborem, jeśli trzeba szczegółowo pokazać atrybuty klas, instancje danych, kolejność komunikatów albo fizyczne rozmieszczenie na infrastrukturze. Dopasuj diagram do pytania, zamiast próbować użyć go jako kompletnej dokumentacji architektury.

Podstawowe elementy#

Komponent#

Komponent jest przedstawiany jako prostokąt z nazwą i oznaczeniem «component» albo ikoną komponentu. W modelu może mieć interfejsy udostępniane, interfejsy wymagane, porty, właściwości oraz relacje z innymi elementami. W uproszczonym widoku nie trzeba pokazywać każdego szczegółu.

Nazwa powinna określać odpowiedzialność lub rozpoznawalną część systemu, np. Katalog produktów albo Obsługa zamówień. Nazwy technologiczne, takie jak SpringBootApp, mogą być przydatne na diagramie implementacyjnym, ale nie muszą wyjaśniać podziału odpowiedzialności odbiorcy biznesowemu.

W UML komponent może reprezentować moduł o wymiennej lub enkapsulowanej implementacji, ale sam symbol nie gwarantuje niezależnego wdrażania, osobnego procesu ani osobnego serwera. Te właściwości trzeba opisać lub pokazać w odpowiednim modelu.

Interfejs udostępniany#

Interfejs udostępniany (provided interface) opisuje kontrakt, którego usługi komponent oferuje innym elementom. W notacji „lizaka” jest rysowany jako małe kółko połączone z komponentem. Można też przedstawić interfejs jako osobny element stereotypowany «interface» i połączyć go z komponentem relacją realizacji.

Udostępniony kontrakt nie pokazuje z definicji wewnętrznego sposobu działania ani wszystkich klas implementacji. Może obejmować operacje, sygnały lub inne elementy kontraktu właściwe dla modelowanego przypadku. Nazwa interfejsu powinna mówić, jaką usługę otrzymuje klient, a nie tylko powtarzać nazwę implementacji.

Interfejs wymagany#

Interfejs wymagany (required interface) określa usługi lub kontrakt, których komponent potrzebuje od otoczenia. W klasycznej notacji można go pokazać jako półokrągłe gniazdo („socket”). Gdy wymagany kontrakt zostaje połączony z odpowiednim interfejsem udostępnianym, powstaje łącznik montażowy (assembly connector): element architektury może wtedy korzystać z usługi oferowanej przez drugi komponent.

W uproszczonych narzędziowych diagramach często przedstawia się wymaganie jako zależność od interfejsu albo komponentu dostawcy. Taki skrót bywa czytelny, ale powinien być opisany tak, aby nie mylić go z pełną notacją gniazda i łącznika. Nie każda strzałka między komponentami jest łącznikiem montażowym.

Port#

Port jest określonym punktem interakcji komponentu z jego otoczeniem. Może grupować interfejsy udostępniane i wymagane oraz wskazywać, którędy odbywa się współpraca. Port jest przydatny, gdy komponent ma wiele wyraźnych wejść i wyjść, gdy kontrakt zależy od punktu interakcji albo gdy modelujemy wnętrze komponentu.

Nie należy dodawać portu do każdego komponentu tylko dlatego, że element ten występuje w pełnej notacji UML. Jeśli komponent ma jedną prostą zależność i rysunek jest czytelny bez portów, ich pominięcie może być właściwym uproszczeniem.

Zależności i realizacja#

Zależność pokazuje, że jeden element wykorzystuje lub w inny sposób zależy od drugiego. W diagramie komponentów może wskazywać, że komponent klienta potrzebuje kontraktu dostawcy. Trzeba odróżnić zależność od jawnego połączenia interfejsów.

Realizacja wskazuje, że komponent albo inny element modelu realizuje kontrakt lub specyfikację. W UML jest zwykle rysowana linią przerywaną z pustym trójkątem skierowanym ku elementowi realizowanemu. Nie oznacza ona tego samego, co zależność: jedna mówi o spełnianiu kontraktu, druga o użyciu lub zależności.

Przykład: moduły sklepu internetowego#

Diagram pokazuje komponenty logiczne aplikacji sklepowej i kontrakty, z których korzystają. Katalog udostępnia interfejs wyszukiwania produktów. Moduł zamówień realizuje kontrakt obsługi zamówień, korzysta z katalogu i wymaga usługi płatniczej, którą dostarcza zewnętrzna bramka.

W tym uproszczeniu interfejsy są oddzielnymi elementami powiązanymi z komponentami, które je udostępniają. Przerywane zależności pokazują użycie kontraktów. Diagram nie rysuje półokrągłych gniazd wymaganych interfejsów ani łączników montażowych w ich pełnej notacji, dlatego etykiety „korzysta” i „wymaga” dopowiadają intencję modelu. To widok do nauki zależności, nie kompletna specyfikacja interfejsów.

Rysunek nie określa, czy aplikacja, katalog i obsługa zamówień są jednym procesem, osobnymi usługami, kontenerami czy wdrażanymi niezależnie modułami. Nie wyznacza też protokołu, adresów sieciowych, liczby instancji ani zachowania przy błędzie płatności. Jeśli te informacje są celem, dodaj odrębny widok lub model wdrożenia i zachowania.

Jak czytać diagram komponentów#

1. Ustal granicę systemu i odróżnij elementy wewnętrzne od zewnętrznych.
2. Odczytaj nazwy komponentów jako większe części o określonych odpowiedzialnościach.
3. Sprawdź, które interfejsy są udostępniane, a które wymagane.
4. Prześledź połączenia kontraktów i zależności od klienta do dostawcy.
5. Rozróżnij realizację interfejsu od korzystania z niego.
6. Sprawdź, czy symbole oznaczają pełną notację UML, czy lokalny skrót przyjęty w diagramie.
7. Zidentyfikuj pominięte informacje: implementację, szczegóły komunikacji, wdrożenie i zachowanie.

Strzałki na diagramie zależności pokazują kierunek od elementu zależnego do dostawcy, ale trzeba zweryfikować, jaki dokładnie rodzaj relacji przedstawia konkretne połączenie. Linia ciągła, przerywana, realizacja i assembly connector nie są wymienne.

Jak tworzyć diagram komponentów#

1. Wybierz poziom i zakres#

Zdecyduj, czy modelujesz moduły aplikacji, usługi, biblioteki, podsystemy czy komponenty urządzenia. Ustal, czy diagram opisuje stan obecny, projekt docelowy, czy wariant rozważany. Nie mieszaj ich bez jawnego oznaczenia.

2. Wydziel odpowiedzialności#

Wybierz komponenty na podstawie odpowiedzialności, kontraktów i potrzebnej granicy. Nie twórz komponentu dla każdego pakietu lub katalogu w repozytorium, jeśli nie służy to pytaniu. Jeden komponent może obejmować wiele klas, a wiele mniejszych elementów może wspólnie realizować większy komponent.

3. Zdefiniuj kontrakty#

Zapisz, jakie usługi element udostępnia i czego sam wymaga. Interfejsy nazwij od oferowanej możliwości, np. Wyszukiwanie produktów, a nie od technicznego adaptera, który aktualnie je implementuje. Jeśli interfejs jest istotny dla integracji, pokaż operacje lub osobno opisz jego szczegóły.

4. Narysuj zależności i połączenia#

Wskaż klienta zależności i jej dostawcę. Kiedy ważne jest połączenie wymaganego i udostępnianego interfejsu, użyj właściwej notacji łącznika montażowego. Rozdziel zależności od relacji realizacji. Oznacz elementy zewnętrzne, jeżeli granica systemu ma znaczenie.

5. Zweryfikuj granice i odbiorcę#

Sprawdź, czy diagram pomaga odpowiedzieć na pytanie o architekturę, czytelnie rozróżnia interfejsy i komponenty oraz nie sugeruje niewykazanych właściwości wdrożenia. Osoba spoza zespołu powinna potrafić wskazać, kto z czego korzysta i gdzie kończy się odpowiedzialność systemu.

Diagram komponentów a inne diagramy#

Granice między tymi widokami wynikają z celu i poziomu szczegółowości. Komponent może być dalej opisany diagramem klas, wdrożony na węźle z diagramu wdrożenia i uczestniczyć w scenariuszu opisanym diagramem sekwencji. Zachowuj spójne nazwy, żeby powiązać te widoki.

Typowe błędy#

• Utożsamianie komponentu z serwerem lub procesem. Symbol komponentu opisuje element modularny, nie jego lokalizację ani sposób uruchomienia.
• Pokazywanie każdej klasy jako komponentu. Diagram traci wtedy poziom abstrakcji; do klas służy właściwy diagram.
• Mieszanie interfejsu z jego implementacją. Oddziel kontrakt od komponentu, który go realizuje lub udostępnia.
• Nieodróżnianie interfejsu wymaganego i udostępnianego. Opisz, kto dostarcza usługę, a kto jej potrzebuje.
• Używanie dowolnej strzałki jako łącznika. Zależność, realizacja i assembly connector mają różne znaczenie.
• Mylenie logiki komponentów z wdrożeniem. Do serwerów, urządzeń, artefaktów i rozmieszczenia użyj diagramu wdrożenia.
• Niejasne granice systemu. Oznacz systemy zewnętrzne i odpowiedzialność modelowanego rozwiązania.
• Nadmierna szczegółowość. Pokaż te interfejsy i zależności, które wspierają cel, a resztę przenieś do powiązanych diagramów.
• Przedstawianie zależności implementacyjnych jako faktu o domenie. Ujawnij perspektywę: logiczną, projektową czy wynikającą z kodu.

Co diagram komponentów pokazuje, a czego nie#

Diagram komponentów pokazuje logiczny podział na większe elementy, ich kontrakty i wybrane zależności. Pomaga wyjaśnić architekturę modularną oraz miejsca integracji. Może też wspierać planowanie granic odpowiedzialności i śledzenie realizacji elementów modelu.

Nie określa sam z siebie algorytmów, kolejności komunikatów, pełnych sygnatur kontraktów, szczegółów implementacji ani fizycznego rozmieszczenia. Informacje te wymagają dodatkowych diagramów i opisów. Używaj diagramu komponentów jako jednego widoku architektury, którego znaczenie określono przez zakres, odbiorcę i przyjęty poziom szczegółowości.