Czym jest zależność#
Zależność (dependency) to skierowana relacja między elementami modelu, która mówi, że jeden element — klient — wymaga innego elementu — dostawcy — do swojej specyfikacji lub implementacji. Zmiana dostawcy może więc wymagać sprawdzenia albo zmiany klienta. Zależność wskazuje powiązanie istotne dla modelu, ale sama nie opisuje szczegółowo jego postaci, czasu trwania ani sposobu wykonania.
W UML zależność może łączyć różne elementy modelu, nie tylko klasy. Można jej użyć między pakietami, komponentami, przypadkami użycia i innymi elementami, jeśli ogólna informacja o wymaganiu jednego elementu przez drugi jest tym, co chcemy przekazać. Gdy znamy dokładniejszą relację, należy rozważyć bardziej precyzyjny rodzaj zamiast pozostawiać nieokreśloną zależność.
Notacja i kierunek#
Zależność przedstawia się przerywaną linią zakończoną otwartym grotem strzałki. Strzałka biegnie od klienta do dostawcy: RaportZamowien korzysta z RepozytoriumZamowien, więc to raport jest klientem, a repozytorium dostawcą.
Diagram pokazuje, że logika generowania raportu wymaga kontraktu repozytorium. Nie przesądza, czy repozytorium jest polem klasy, parametrem metody, usługą zdalną czy zależnością przekazaną w inny sposób. Taki szczegół trzeba modelować osobno, jeśli jest ważny dla odbiorcy.
Klient, dostawca i wpływ zmiany#
Nazwy „klient” i „dostawca” opisują role w relacji, a nie role użytkowników ani kierunek przepływu danych. Klient potrzebuje dostawcy; dostawca dostarcza element, którego definicja lub implementacja jest klientowi potrzebna. Strzałka nie musi oznaczać, że klient w każdej chwili wywołuje dostawcę. Może przedstawiać zależność na poziomie projektu, kompilacji, specyfikacji lub architektury.
Jeżeli interfejs dostawcy zmieni nazwę operacji, parametry albo wymagane zachowanie, klient może wymagać aktualizacji. Diagram nie stwierdza jednak, że każda zmiana dostawcy na pewno zepsuje klienta; sygnalizuje możliwy wpływ, który należy przeanalizować. Nie opisuje też automatycznie siły, częstotliwości ani kosztu tego wpływu.
Etykiety i rodzaje zależności#
Podstawową zależność można opisać stereotypem, aby doprecyzować jej znaczenie w przyjętej notacji lub dziedzinie. Nazwa stereotypu pojawia się w cudzysłowie kątowym przy relacji, na przykład «use», «import» albo «trace», jeśli dany wariant i jego znaczenie odpowiadają modelowi. Stereotyp nie jest ozdobną etykietą: powinien wskazywać konkretną, zrozumiałą semantykę. Specjalizowane relacje UML, takie jak realizacja, mają własne reguły i notację; nie należy zastępować ich ogólną zależnością tylko dlatego, że obie są zależnościami w szerszym sensie.
Można również podpisać relację zwykłą nazwą, ale jeśli etykieta jest potrzebna do zrozumienia diagramu, sprawdź, czy nie opisuje ona przypadkiem bardziej precyzyjnej relacji. W przypadku zależności między pakietami jej kierunek nadal oznacza, że klient wymaga dostawcy; nie myl go z kierunkiem przepływu danych czy wywołania w konkretnym scenariuszu.
Zależność a inne relacje#
- Asocjacja opisuje strukturalne powiązanie instancji klasy, często takie, które modeluje trwałą znajomość obiektów. Zależność może być krótkotrwała i nie mówi sama, że obiekt klienta przechowuje referencję do dostawcy.
- Realizacja wyraża spełnienie specyfikacji, na przykład przez klasę realizującą interfejs. Jej zapis ma przerywaną linię i pusty trójkąt, więc różni się od zwykłej zależności z otwartym grotem.
- Generalizacja określa relację typu ogólnego i szczegółowego. Nie jest korzystaniem z dostawcy.
- Komunikat na diagramie interakcji pokazuje wymianę w konkretnym przebiegu. Zależność statyczna nie zastępuje komunikatu ani nie podaje kolejności zdarzeń.
Wybór relacji powinien wynikać z pytania, na które odpowiada diagram. Jeśli chcemy pokazać, że klasa posiada kolekcję obiektów drugiej klasy, zwykła zależność jest zbyt ogólna. Jeśli wystarczy wskazać, że pakiet wymaga definicji innego pakietu, szczegółowa asocjacja może z kolei sugerować strukturę, której nie zamierzamy stwierdzić.
Kiedy używać zależności#
Zależność przydaje się, gdy trzeba pokazać, że element wymaga innego elementu, ale nie chcemy ani nie możemy określić tej relacji jako strukturalnej asocjacji lub innej bardziej konkretnej relacji. Może być użyteczna na wczesnym etapie projektu, przy zależnościach między pakietami i komponentami lub przy wskazywaniu wpływu zmian.
Nie rysuj strzałki dla każdej technicznej interakcji w kodzie. Diagram z gęstą siecią oczywistych zależności będzie trudny do odczytania. Pokazuj te relacje, które odpowiadają celowi diagramu; grupuj elementy na właściwym poziomie i podpisuj nietypowe zależności.
Typowe błędy#
- Odwrócony kierunek. Grot wskazuje dostawcę, od którego klient zależy.
- Mylenie z przepływem danych. Zależność określa wymaganie między elementami, nie kierunek przesyłania danych w czasie wykonania.
- Zakładanie trwałego pola. Sama zależność nie mówi, że klient przechowuje dostawcę jako atrybut.
- Nadużywanie relacji ogólnej. Gdy wiadomo, że chodzi o realizację, asocjację lub inną konkretną relację, pokaż jej właściwy rodzaj.
- Niejasna etykieta. Stereotyp powinien mieć uzgodnione znaczenie; przypadkowy tekst nie czyni relacji precyzyjniejszą.
- Przesadne wnioskowanie o skutkach zmiany. Zależność wskazuje możliwy wpływ, a nie gwarantowaną awarię.
Podsumowanie#
Zależność UML pokazuje, że klient wymaga dostawcy do swojej specyfikacji lub implementacji. Przerywana strzałka biegnie od klienta do dostawcy. Jest relacją ogólną, przydatną wtedy, gdy nie opisujemy bardziej konkretnego powiązania; nie oznacza sama struktury obiektów, wywołania ani przepływu danych.