Wstęp

Poniższy tekst stanowi zbiór zaleceń do realizacji konstrukcji UML wymaganych do mini-projektu 4 (MP4).

 1. Zgodnie z wymaganiami opisanymi w pkt 3. dokumentu wymagań każda konstrukcja powinna mieć osobny przykład biznesowy (nie należy łączyć konstrukcji wymienionych w wymaganiach mini-projektu).

 2. Ograniczenia atrybutu.

  2.1. Ograniczenia dotyczące atrybutów powinny być uwzględane w momemcie inicjalizacji obiektu i zmiany wartości atrybutu (metoda setXXX).

  2.2. W przypadku próby ustawienia niewłaściwej wartości należy podnieść odpowiedni wyjątek (np. java.lang.IllegalArgumentException, lub własny wyjątek).

  2.3. Należy zaprezentować jeden przykład ograniczenia statycznego i jeden przykład ograniczenia dynamicznego.

   2.3.1. Dla ograniczenia dynamicznego należy uwzględnić poprzednią wartość artybutu. ‘Dynamiczność’ może również polegać na sprawdzeniu wartości innego atrybutu, np. klasowego, który wskazuje dopuszczalny zakres wartości.

   2.3.2. Ograniczenia statyczne nie uwzględniają aktualnych wartości danego lub innych atrybutów. Móżna wśród nich wskazać np.:

    2.3.2.1. Ograniczenie zakresu liczby

    2.3.2.2. Ograniczenie ilości znaków

    2.3.2.3. Format napisu sprawdzany wyrażeniem regularnym

 3. Ograniczenie ‘unique’.

  3.1. Dotyczy unikalności wartości atrybutu (bądź kombinacji wielu atrybutów) w obrębie ekstensji klasy.

  3.2. Podobnie jak w przypadku innych ograniczeń atrybutów należy je uwzględnić podczas inicjalizacji obiektu, jak i zmiany atrybutu. Nie należy zakładać, że unikalny atrybut jest niezmienny.

  3.3. Należy zastosować prawidłowy przykład biznesowy. Id obiektu jest słabym przykładem, gdyż nie jest to atrybut biznesowy, lecz techniczny, najczęściej zarządzany przez bazę danych.

  3.4. Istnieją dwa główne sposoby implementacji, z użyciem ekstensji klasy, lub dodatkowej statycznej kolekcji. W ramach realizacji mini-projektu należy wybrać jeden z nich.

  3.5. Implementacja za pomocą ekstensji klasy (rekomendowana):

   3.5.1. Walidacja polega na sprawdzeniu, czy w ekstensji klasy występuje inny obiekt posiadający taką samą wartość danego atrybutu. W takim przypadku należy podnieść wyjątek.

  3.6. Implementacja za pomocą pomocniczej, statycznej kolekcji:

   3.6.1. Należy utworzyć dodatkową, statyczną kolekcję zawierającą wszystkie wartości danego atrybutu.

   3.6.2. Kolekcję tę należy aktualizować przy każdej pomyślnej zmianie atrybutu, pamiętając o usuwaniu nieużywanych wartości.

   3.6.3. Walidacja polega na sprawdzeniu, czy nowa wartość atrybutu już występuje we wspomnianej kolekcji. Jeżeli tak, należy podnieść wyjątek.

 4. Ograniczenie ‘subset’.

  4.1. Dotyczy sytuacji, gdy pomiędzy dwiema klasami występują co najmniej dwie asocjacje, zaś jedna jest podzbiorem drugiej.

  4.2. Należy prawidłowo zaimplementować obie asocjacje. Dotyczy to również stworzenia mechanizmu automatycznej aktualizacji referencji zwrotnych, jak w przypadku ‘zwykłej’ asocjacji. Nazwy referencji powinny odnosić się do roli, jaką pełni dane powiązanie.

  4.3. Podczas tworzenia powiązania będącego podzbiorem należy upewnić się, że takie powiązanie występuje już w powiązaniu będącym nadzbiorem. W przeciwnym wypadku należy podnieść wyjątek.

  4.4. Podczas usuwania powiązania będącego nadzbiorem należy upewnić się, że takie powiązanie nie występuje w powiązaniu będącym podzbiorem. W przeciwnym wypadku należy automatycznie usunąć dane powiązanie z podzbioru, lub podnieść wyjątek.

 4. Ograniczenie ‘ordered’.

  4.1. Dotyczy kolejności obiektów przechowywanych w ekstensji klasy, lub dla asocjacji.

  4.2. Metoda zwracająca kolekcję powinna zwracać typ kolekcji utrzymujący kolejność (List)

  4.3. Można zaimplementować na dwa główne sposoby: dynamicznego sortowania kolekcji przy pobraniu, lub sortowaniu obiektów podczas zmiany zawartości kolekcji. Do realizacji mini-projektu wystarczy implementacja jednego z wymienionych sposobów.

  4.3.1. Dla dynamicznego sortowania należy zaktualizować metodę getXXX, w której zwracana lista będzie uprzednio posortowana za pomocą właściwego komparatora. W tym przypadku typ kolekcji, użyty jako pole obiektu nie ma znaczenia, może być to również Set, który nie utrzymuje kolejności.

  4.3.2. Dla metody polegającej na sortowaniu podczas zmiany należy zastosować odpowiedni typ kolekcji dla pola obiektu (List). Podczas dodawania elementu do kolekcji należy zastosować sortowanie z użyciem odpowiedniego komparatora.

 5. Ograniczenie ‘bag’ / ‘history’.

  5.1. Domyślnie powiązania obiektów w ramach asocjacji są unikalne - w ramach jednej asocjacji para powiązanych obiektów nie może występować więcej niż raz. Oznaczenie asocjacji jako ‘bag’ lub ‘history’ znosi to ograniczenie.

  5.2. To ograniczenie ma praktyczne zastosowanie dla asocjacji typu wiele-do-wiele z atrybutem.

  5.3. W ramach implementacji należy usunąć sprawdzenie unikalności powiązania w konstruktorze klasy pośredniczącej.

 6. Ograniczenie ‘XOR’.

  6.1. Dotyczy sytuacji, gdzie klasa powiązana jest co najmniej dwiema asocjacjami. Dla danego obiektu w danym momencie może istnieć tylko jeden rodzaj powiązania spośród asocjacji oznaczonych jako ‘XOR’.

  6.2. Należy prawidłowo zaimplementować obie asocjacje. Dotyczy to również stworzenia mechanizmu automatycznej aktualizacji referencji zwrotnych, jak w przypadku ‘zwykłej’ asocjacji. Nazwy referencji powinny odnosić się do roli, jaką pełni dane powiązanie.

  6.3. Podczas tworzenia asocjacji należy upewnić się, że nie ma powiązań w żadnej innej asocjacji, które się wykluczają. W takim przypadku należy podnieść wyjątek.

 7. Własne ograniczenie biznesowe.

  7.1. Może dotyczyć asocjacji, lub też atrubutu.

  7.2. W przypadku atrybutu może być to walidacja krzyżowa z innym atrybutem, np. dataDo musi być późniejsza niż dataOd (zastosuj własny przypadek biznesowy w Twoim rozwiązaniu).

  7.3. W przypadku asocjacji walidacja może polegać na sprawdzeniu stanu łączonego obiektu (np. do klubu mogą być zapisani tylko użytkownicy ze statusem VIP) lub innych atrybutów (np. liczba powiązanych książek może być ograniczona pojemnością półki, będącą atrybutem półki)