Czym jest pakiet#

Pakiet (package) grupuje elementy modelu i może tworzyć przestrzeń nazw (namespace), w której nazwy tych elementów są rozpoznawane. Może zawierać klasy, interfejsy, przypadki użycia, inne pakiety i inne elementy dopuszczone przez UML. Pakiet nie jest sam z siebie folderem systemu plików ani modułem wykonywalnym, choć w konkretnym projekcie może zostać na nie odwzorowany.

Diagram pakietów pokazuje organizację modelu i zależności między grupami elementów. Pozwala przedstawić strukturę na wyższym poziomie niż diagram klas: zamiast wszystkich klas widać granice obszarów, przestrzenie nazw oraz to, które pakiety korzystają z innych.

Pakiet Zamowienia importuje pakiet Platnosci, a pakiet Aplikacja zależy od pakietu Zamowienia.
Pakiety grupują elementy modelu i pokazują zależności między ich przestrzeniami nazw.

Zamowienia importuje elementy z pakietu Platnosci, a Aplikacja zależy od pakietu Zamowienia. Etykiety wyjaśniają relacje, lecz uproszczony rysunek nie pokazuje konkretnych importowanych klas ani widoczności każdego elementu.

Przestrzeń nazw i kwalifikowanie nazw#

Elementy w pakiecie należą do jego przestrzeni nazw. Gdy dwa pakiety zawierają elementy o tej samej prostej nazwie, pełna nazwa może być kwalifikowana ścieżką pakietów, na przykład Platnosci::Transakcja i Zamowienia::Transakcja. Import może umożliwić używanie nazwy elementu bez pełnego kwalifikatora w kontekście pakietu importującego, jeśli element jest widoczny.

Pakiet pomaga uniknąć kolizji nazw i organizować duży model. Widoczność elementów oraz importy mają znaczenie: samo umieszczenie klasy w pakiecie nie czyni jej automatycznie publiczną dla wszystkich innych pakietów. W diagramie można pokazać zawartość pakietu, lecz nie trzeba wyświetlać wszystkich członków, jeśli celem jest tylko struktura zależności.

Import pakietu#

Import pakietu (package import) udostępnia widoczne elementy pakietu docelowego w przestrzeni nazw pakietu źródłowego bez wpływania na przestrzeń nazw celu. Strzałka relacji prowadzi od pakietu importującego do importowanego. Oznaczenie «import» wyjaśnia, że nie chodzi o dowolną zależność, lecz o import elementów.

Import jest relacją modelu, nie instrukcją do kompilatora konkretnego języka. Jego odwzorowanie na import, using, moduły lub inne konstrukcje zależy od platformy. Nie zakładaj również, że import oznacza skopiowanie elementów ani przeniesienie ich własności.

Import elementu#

Model może importować także pojedynczy element do przestrzeni nazw pakietu. Ma to sens, gdy potrzebny jest tylko konkretny klasyfikator zamiast całego zestawu elementów pakietu. W złożonych modelach rozróżnienie importu pakietu i importu elementu pozwala ograniczyć ekspozycję nazw. W zwykłym diagramie przeglądowym często wystarczy zależność z odpowiednim stereotypem i opis tego, co jest importowane.

Łączenie pakietów#

Package merge («merge») to relacja, w której zawartość pakietu docelowego jest scalana z pakietem źródłowym zgodnie z regułami dopasowywania elementów, a definicje elementów mogą być rozszerzane lub łączone. Nie jest to synonim importu ani zwykłego grupowania. Mechanizm jest bardziej zaawansowany i bywa stosowany w modelowaniu rodzin systemów lub rozszerzaniu modelu bazowego.

Nie używaj «merge» jako skrótu dla „te pakiety są podobne” albo „jeden korzysta z drugiego”. Jeśli potrzebujesz wyrazić widoczność elementów, rozważ import; jeśli jedynie zależność architektoniczną, użyj odpowiedniej zależności. Szczegóły package merge powinny być opisane w modelu, bo prosty rysunek nie wyjaśnia reguł łączenia elementów.

Pakiet zagnieżdżony i organizacja modelu#

Pakiet może zawierać inny pakiet, tworząc hierarchię przestrzeni nazw. Zagnieżdżenie nie oznacza automatycznie zależności ani dziedziczenia. Wybierz podział według spójności pojęć, odpowiedzialności i stabilnych granic, a nie tylko według przypadkowego układu katalogów.

Zbyt płytka struktura utrudnia odnalezienie elementów; zbyt głęboka tworzy długie nazwy i sztywne powiązania. Pakiety mogą porządkować model logiczny, ale nie przesądzają, jak kod będzie fizycznie rozmieszczony. Jeśli odwzorowanie ma być zgodne z modułami wdrożeniowymi, zdefiniuj tę regułę osobno.

Zależności między pakietami#

Zależność między pakietami sugeruje, że definicje jednego obszaru wymagają elementów innego. Zmiany w dostawcy mogą wpłynąć na klienta. Gęsta sieć zależności utrudnia zmianę modelu i może wskazywać, że granice pakietów są źle dobrane lub odpowiedzialności są zbyt ściśle związane.

Strzałki powinny być skierowane od klienta do dostawcy. Nie przedstawiaj każdej asocjacji klasowej jako osobnej zależności pakietów, jeśli diagram przestanie być czytelny. Wybierz poziom abstrakcji, który odpowiada pytaniu architektonicznemu.

Typowe błędy#

  • Pakiet utożsamiony z katalogiem. To przede wszystkim element organizacji modelu i przestrzeń nazw.
  • Import odwrócony. Relacja biegnie od pakietu importującego do importowanego.
  • Import uznany za kopiowanie. Import udostępnia nazwy w kontekście, nie przenosi własności elementów.
  • «merge» użyte jako ogólna zależność. Package merge ma odrębne znaczenie łączenia definicji.
  • Zagnieżdżenie uznane za zależność. Zawieranie pakietu i korzystanie z niego to osobne relacje.
  • Każdy element pokazany na diagramie. W przeglądzie architektury ukryj szczegóły, które nie wspierają celu.
  • Założenie odwzorowania na system plików. Konkretne mapowanie projektu trzeba ustalić osobno.

Podsumowanie#

Pakiet grupuje elementy modelu i tworzy przestrzeń nazw, a diagram pakietów pokazuje ich organizację i zależności. Import udostępnia widoczne nazwy bez kopiowania elementów; «merge» ma odrębną semantykę łączenia definicji. Zagnieżdżenie, zależność i import odpowiadają na różne pytania i nie powinny być stosowane zamiennie.