Najważniejsze kryterium#
Wybierz asocjację, gdy modelujesz strukturalne powiązanie między instancjami klasyfikatorów — na przykład zamówienie jest przypisane do klienta. Wybierz zależność, gdy jeden element modelu wymaga innego do swojej specyfikacji lub implementacji, ale nie chcesz stwierdzać trwałego powiązania instancji. Asocjacja opisuje relację obiektów; zależność — relację wymagania między elementami modelu.
Asocjacja pokazuje, że każde zamówienie jest powiązane z klientem, a klient może mieć wiele zamówień. Przerywana zależność pokazuje, że generator raportu wymaga repozytorium; nie mówi, czy obiekt repozytorium jest przechowywany w polu, przekazywany jako argument czy uzyskiwany przez inny mechanizm.
Co mówi asocjacja#
Asocjacja łączy klasyfikatory i opisuje możliwe powiązania ich instancji. Może mieć końce nazwane rolami, liczności, ograniczenia, nawigowalność, kwalifikatory lub właściwości agregacji. Diagram klas może dzięki temu wyrazić, ile obiektów jest powiązanych i z której strony można do nich dotrzeć.
Asocjacja jest odpowiednia, gdy relacja jest częścią struktury modelowanych obiektów lub domenowej wiedzy. Nie musi być odwzorowana na pojedyncze pole kodu: dostęp może zapewniać kolekcja, indeks, repozytorium lub mechanizm trwałości. Istotne jest znaczenie relacji, nie konkretna implementacja.
Co mówi zależność#
Zależność jest skierowana: klient potrzebuje dostawcy, a zmiana dostawcy może wpłynąć na klienta. Jej podstawowy zapis to przerywana strzałka od klienta do dostawcy. Może łączyć różne elementy modelu, na przykład pakiety, komponenty czy klasy, i bywa używana, gdy wiemy, że występuje wymaganie, ale nie określamy strukturalnego powiązania instancji.
Zależność może być doprecyzowana stereotypem, jeśli istnieje właściwa semantyka, albo zastąpiona relacją bardziej konkretną. Sama nie podaje liczności instancji ani nie gwarantuje, że klient w trakcie każdego wykonania wywoła dostawcę.
Czy użycie klasy zawsze oznacza asocjację?#
Nie. Jeżeli typ występuje jako parametr operacji lub lokalna wartość i nie jest trwałą częścią struktury obiektu, zwykła zależność może wystarczyć. Jeżeli instancje są ze sobą powiązane jako część domeny i ta więź ma być widoczna w modelu, użyj asocjacji. Sama obecność nazwy typu w sygnaturze nie rozstrzyga, który widok jest właściwy.
Projekt klasy może wykorzystywać asocjację w celu modelowania referencji, ale w diagramie analitycznym ważniejsza może być relacja pojęć niezależna od kodu. Zdecyduj, czy diagram odpowiada na pytanie o strukturę domeny, czy o zależności implementacyjne.
Nawigowalność nie zmienia asocjacji w zależność#
Jednokierunkowa asocjacja wciąż może być strukturalną asocjacją; strzałka nawigowalności wskazuje, z której strony dostępne są powiązane instancje. Nie należy zastępować każdej jednokierunkowej asocjacji przerywaną zależnością. Kierunek grotu oraz rodzaj linii kodują inne informacje.
Podobnie asocjacja może być dwukierunkowa, a dependency skierowana od klienta do dostawcy. Nie wybieraj relacji na podstawie liczby grotów, tylko na podstawie semantyki modelu.
Szybki test wyboru#
- Czy chcesz powiedzieć, że instancje mogą być ze sobą powiązane jako elementy struktury? Rozważ asocjację.
- Czy relacja powinna mieć liczność, role końców albo regułę nawigowania? Wskaż asocjację.
- Czy jeden element wymaga definicji lub implementacji innego, ale nie modelujesz powiązania instancji? Rozważ zależność.
- Czy możesz nazwać bardziej konkretną relację — realizację, generalizację, import, wdrożenie? Użyj jej, jeśli odpowiada znaczeniu.
- Czy rysunek nadal wymaga wyjaśnienia? Dopisz krótką konwencję zamiast mnożyć niejasne strzałki.
Typowe błędy#
- Jedna linia dla wszystkich relacji. Asocjacja i dependency mają inną notację oraz znaczenie.
- Każde użycie klasy zamienione w trwałe powiązanie. Parametr metody nie zawsze oznacza asocjację.
- Jednokierunkowa asocjacja nazwana zależnością. Nawigowalność i rodzaj relacji to odrębne cechy.
- Liczność dopisana do dependency jako reguła instancji. Zależność nie jest strukturalnym końcem asocjacji.
- Przerywana strzałka od dostawcy do klienta. Kierunek zależności prowadzi od klienta do dostawcy.
- Relacja ogólna tam, gdzie znana jest konkretna. Użyj precyzyjnej relacji, jeśli jej semantyka jest potrzebna.
Podsumowanie#
Asocjacja modeluje strukturalne powiązania instancji i może określać ich liczność oraz nawigowalność. Zależność pokazuje, że klient wymaga dostawcy do specyfikacji lub implementacji. Rozróżniaj je na podstawie tego, co chcesz stwierdzić o modelu, a nie na podstawie samego kierunku użycia w kodzie.