Czym jest nawigowalność#
Nawigowalność (navigability) końca asocjacji opisuje, czy model pozwala przejść od instancji jednego klasyfikatora do powiązanych instancji drugiego. W diagramie klas wskazuje więc możliwość dostępu przez relację w określonym kierunku. Asocjacja może być nawigowalna w jednym kierunku albo w obu; nawigowalność nie musi być symetryczna.
Przykładowo obiekt zamówienia może udostępniać swojego klienta, podczas gdy obiekt klienta nie musi przechowywać ani udostępniać kolekcji wszystkich zamówień. To dwa różne kierunki dostępu, mimo że dotyczą jednego powiązania między klasami.
Strzałka na końcu po stronie Klient przedstawia nawigowalność w tym kierunku: od Zamowienie do Klient. Brak strzałki przy Zamowienie nie powinien być automatycznie odczytywany jako zakaz dostępu w każdej implementacji — trzeba wiedzieć, czy model przyjął konwencję, w której brak oznacza nienawigowalność, czy pozostawił własność końca nieokreśloną. W diagramach dydaktycznych warto podać tę konwencję.
Kierunek to nie kierunek przepływu#
Nawigowalność nie oznacza kierunku przepływu danych, wywołań ani czasu. Pokazuje, z którego obiektu model umożliwia dotarcie do obiektu po drugiej stronie przez daną asocjację. Wywołania metod mogą przebiegać w innym kierunku lub obie strony mogą komunikować się przez inne mechanizmy.
Podobnie nie jest to po prostu strzałka „od klasy nadrzędnej do podrzędnej”. Asocjacja wiąże instancje, a nawigowalność określa dostępność jej końca. Nie myl jej z grotem generalizacji, realizacji ani zależności — te symbole mają inną geometrię i znaczenie.
Zapis na diagramie#
Nawigowalny koniec asocjacji można oznaczyć otwartym grotem skierowanym do tego końca. W modelowaniu spotyka się też jawne oznaczenie końca nienawigowalnego, na przykład krzyżykiem, albo brak grotu. Konwencje narzędzi i praktyk diagramowania różnią się, a nieoznaczony koniec może w niektórych kontekstach znaczyć „nieokreślony”, nie zaś jednoznaczne „nienawigowalny”. Dlatego nie buduj interpretacji wyłącznie na intuicji czy wizualnym zwyczaju.
UML rozróżnia, czy koniec asocjacji jest nawigowalny oraz kto jest jego właścicielem w modelu. Własność i nawigowalność są związane z modelowaniem końca, ale nie należy traktować ich jako synonimów. Narzędzie może prezentować szczegóły modelu inaczej niż uproszczony diagram, a czytelny rysunek może pomijać część informacji o własności.
Związek z implementacją#
W projektowaniu obiektowym asocjacja nawigowalna w stronę Klient może zostać odwzorowana jako referencja klienta w obiekcie Zamowienie. Nawigowalność w obie strony może sugerować referencje lub mechanizm dostępu w obu klasach. To jednak decyzja implementacyjna, a nie nakaz UML: rzeczywisty kod może używać zapytania, indeksu, repozytorium, identyfikatora lub innego mechanizmu.
Ograniczenie nawigowalności może pomóc ograniczyć zależności i odpowiedzialność za utrzymywanie spójności. Nie gwarantuje jednak mniejszego sprzężenia ani lepszej architektury samo przez się. Jeśli użytkownik potrzebuje wyszukiwać zamówienia klienta, model może realizować to zapytaniem nawet wtedy, gdy nie ma bezpośredniej nawigacji z obiektu klienta.
Jak zdecydować, który kierunek pokazać#
Najpierw określ, jakie pytanie ma rozstrzygnąć diagram. Jeśli opisuje dostępne referencje w projekcie klas, zaznacz tylko kierunki istotne dla tego projektu i zachowaj spójną konwencję. Jeśli diagram ma opisywać pojęcia domenowe, a implementacja dostępu nie jest znana, nie przedstawiaj technicznego ograniczenia jako faktu biznesowego.
Warto zadać sobie trzy pytania: z jakiego obiektu użytkownik modelu ma móc dotrzeć do drugiego; czy chodzi o stałą strukturę, czy tylko możliwość wyszukania; oraz czy brak strzałki ma znaczenie, czy pozostaje nieokreślony. Odpowiedzi umieść w modelu albo krótkim objaśnieniu, jeśli sama notacja nie wystarcza.
Częste nieporozumienia#
- Strzałka wskazuje przepływ informacji. W asocjacji wskazuje nawigowalny koniec, nie sam przepływ danych.
- Każda asocjacja jest dwukierunkowa. Kierunki nawigacji mogą być niezależne.
- Brak strzałki zawsze znaczy „nie można przejść”. Zależy to od jawności modelu i przyjętej konwencji; nieokreśloność nie jest zakazem.
- Nawigowalność nakazuje pole w kodzie. UML modeluje możliwość dostępu, ale sposób implementacji zależy od technologii.
- Nawigowalność określa liczność. Liczność jest osobnym ograniczeniem przy końcu asocjacji.
- Nawigowalność i własność końca są tym samym. To odrębne własności modelu, choć mogą być powiązane w sposobie reprezentacji.
Podsumowanie#
Nawigowalność mówi, w którym kierunku można dotrzeć do powiązanych instancji przez asocjację. Można ją określać niezależnie dla obu końców, a strzałka wskazuje nawigowalny koniec. Nie opisuje przepływu danych i nie przesądza o konkretnym polu w kodzie; niejednoznaczny brak oznaczenia warto objaśnić.