Czym jest kompozycja#

Kompozycja (composite aggregation) jest silnym rodzajem asocjacji całość–część w UML. Na diagramie klas oznacza się ją wypełnionym rombem przy końcu reprezentującym kompozyt, czyli całość. Wyraża silniejszą odpowiedzialność całości za istnienie i przechowywanie części niż zwykła asocjacja lub agregacja współdzielona.

Kompozycja nie jest po prostu inną nazwą relacji „ma”. Użyj jej, gdy część należy do jednej całości w danym czasie, a ich cykle życia są powiązane w modelowanym kontekście. Jeśli część jest niezależna, współdzielona lub może swobodnie istnieć po usunięciu całości, rozważ asocjację albo inny model.

Notacja i przykład#

Zamówienie jest całością zawierającą od jednej do wielu pozycji zamówienia; każda pozycja należy najwyżej do jednego zamówienia, co oznacza kompozycję.
Kompozycja zamówienia i pozycji z licznościami przy obu końcach.

Wypełniony romb znajduje się przy Zamówieniu, które jest kompozytem. Każde zamówienie w przedstawionym poprawnym stanie ma co najmniej jedną pozycję; każda pozycja należy do dokładnie jednego zamówienia. Liczność 1 przy końcu całości oznacza, że pozycja nie może być jednocześnie częścią kilku zamówień.

Przykład opisuje zatwierdzone zamówienia. Jeśli system dopuszcza pusty szkic, zmień model lub określ, że minimalna liczność dotyczy dopiero stanu złożonego. Nie zmieniaj 1..* na 0..* tylko po to, by odzwierciedlić chwilowy etap tworzenia, bez przemyślenia reguły domenowej.

Własność i cykl życia#

Kompozyt zarządza częścią w granicach tej relacji. Instancja części może należeć w danym momencie do najwyżej jednego kompozytu. Usunięcie kompozytu wiąże się z usunięciem jego części w ramach modelowanej własności; przeniesienie części do innej całości wymaga rozważenia zasad zmiany powiązania i cyklu życia.

To semantyczne zobowiązanie UML, a nie automatyczna gwarancja, że baza danych kaskadowo skasuje rekordy albo że implementacja używa kompozycji obiektowej języka programowania. Szczegóły trwałości, archiwizacji i przenoszenia są decyzjami systemu. Diagram określa oczekiwany model, a implementację należy z nim porównać.

Wybór zależy od pojęć, a nie od wygody technicznej. PozycjaZamówienia często istnieje tylko w kontekście jednego zamówienia, podczas gdy Produkt jest niezależną pozycją katalogową, która może być używana przez wiele zamówień. Dlatego pozycja może być częścią kompozycyjną zamówienia, a produkt pozostaje powiązany z pozycjami zwykłą asocjacją.

Końce i liczności#

Wybierając kompozycję, określ liczności po obu stronach. Przy końcu części zapis mówi, ile części może należeć do jednej całości; przy końcu całości — z iloma całościami część może być związana. Zgodnie z semantyką kompozycji część może należeć najwyżej do jednego kompozytu jednocześnie, choć może nie być przypisana do żadnego w danym momencie, jeśli model dopuszcza taki stan.

Liczności muszą odpowiadać warunkom domenowym. Zamówienie może być chwilowo bez pozycji podczas edycji, ale nie może zostać zatwierdzone, dopóki nie spełni reguły minimalnej liczby. Taką zależność od statusu można opisać ograniczeniem lub oddzielnym stanem, gdy sama liczność nie wystarcza.

Kompozycja a agregacja i asocjacja#

Zwykła asocjacja mówi o strukturalnym powiązaniu instancji. Agregacja współdzielona dodaje słaby sygnał całość–część pustym rombem, ale nie precyzuje silnych zasad własności. Kompozycja używa wypełnionego rombu i nakłada wyraźniejsze ograniczenia dotyczące przynależności części do całości.

Jeśli nie potrafisz uzasadnić, co w modelu oznacza część i w jaki sposób jej istnienie wiąże się z całością, wybierz zwykłą asocjację. Nie używaj kompozycji jako dekoracyjnej wersji linii „ma”.

Testuj decyzję na scenariuszach#

Zadaj pytania:

  • Czy część ma własną tożsamość poza konkretną całością?
  • Czy może być współdzielona równocześnie przez więcej niż jeden kompozyt?
  • Co się z nią dzieje, gdy całość przestaje istnieć?
  • Czy część może zostać przeniesiona do innego kompozytu?
  • Czy istnieją reguły, które wymagają części w określonym stanie całości?
  • Czy odbiorca diagramu potrzebuje informacji o takiej własności?

Przejdź przez tworzenie, zmianę, archiwizację i usuwanie obiektów. Jeśli scenariusze przeczą kompozycji, użyj słabszej relacji i opisz właściwe reguły osobno.

Typowe błędy#

  • Romb po stronie części. Wypełniony romb umieszcza się przy kompozycie.
  • Kompozycja dla każdego „ma”. Silny symbol wymaga reguł całość–część.
  • Brak liczności. Nie wiadomo, ile części może lub musi mieć całość.
  • Współdzielona część bez rozstrzygnięcia. Kompozycyjna część nie należy równocześnie do kilku kompozytów.
  • Automatyczne utożsamienie z kaskadowym kasowaniem. Model i trwałość danych to różne poziomy.
  • Ignorowanie stanów przejściowych. Częściowe tworzenie może wymagać ograniczeń zależnych od statusu.
  • Kompozycja katalogu i produktu bez analizy. Produkt może istnieć niezależnie od zamówienia.
  • Semantyka niewidoczna dla odbiorców. Jeśli symbol jest sporny, objaśnij decyzję lub użyj prostszej asocjacji.

Podsumowanie#

Kompozycja jest silną asocjacją całość–część oznaczaną wypełnionym rombem przy kompozycie. Stosuj ją, gdy model rzeczywiście wymaga powiązania własności, przynależności i cyklu życia części. Uzupełnij symbol licznościami i regułami stanów, a implementację sprawdź względem przyjętej semantyki.