Czym jest liczność#

Liczność (multiplicity) określa, ile wartości może wystąpić na danym końcu relacji. Na diagramie klas zapisuje się ją przy końcu asocjacji, którego dotyczy. Jest to ograniczenie modelu: mówi, jakie liczby powiązań są dopuszczalne dla każdego obiektu po przeciwnej stronie. W języku polskim spotyka się też określenia „krotność” i „liczebność”; w tym artykule używamy nazwy liczność.

Rozważmy klienta i jego zamówienia. Przy końcu Zamowienie zapis 0..* oznacza, że jeden klient może być powiązany z zerem, jednym albo wieloma zamówieniami. Przy końcu Klient zapis 1 oznacza, że każde zamówienie jest związane z dokładnie jednym klientem.

Klient może mieć zero lub wiele zamówień, a każde Zamowienie należy do dokładnie jednego Klienta.
Liczności przy końcach asocjacji opisują dopuszczalne liczby powiązanych obiektów.

Czytaj wartości przy końcach, patrząc z perspektywy pojedynczego obiektu po stronie przeciwnej. 0..* przy Zamowienie odpowiada na pytanie: „ile zamówień może być powiązanych z jednym klientem?”. 1 przy Klient odpowiada na pytanie: „ilu klientów może być przypisanych do jednego zamówienia?”. Kierunek czytania łatwo pomylić, dlatego warto wypowiedzieć oba ograniczenia pełnym zdaniem.

Zapis zakresów#

Najczęstsze zapisy to:

  • 1 — dokładnie jedna wartość;
  • 0..1 — zero albo jedna wartość, czyli opcjonalna;
  • 0..* — dowolna liczba, w tym zero;
  • 1..* — co najmniej jedna;
  • 2..5 — od dwóch do pięciu włącznie;
  • * — nieograniczona górna granica, stosowana w notacji zakresu jako skrót dla braku określonego maksimum.

Zakres a..b obejmuje dolną i górną granicę. Zapis 0..* nie oznacza, że liczba obiektów musi być duża; dopuszcza także brak powiązań. Dla wartości wielokrotnych można podać więcej niż jeden zakres, na przykład 1..3, 5, jeśli model dopuszcza od jednej do trzech wartości albo dokładnie pięć. Takie nieregularne ograniczenia bywają trudniejsze do zrozumienia niż prosta reguła biznesowa, więc należy je objaśnić.

UML dopuszcza również wyrażenia liczności, których wartość może być obliczana z kontekstu modelu. Jeśli odbiorca nie potrafi odczytać wyrażenia bez niejawnej wiedzy, dopisz jego znaczenie lub zapisz ograniczenie w bardziej czytelny sposób. Nie używaj znaku * w znaczeniu „typowy przypadek to wiele”; jest to granica nieokreślona, a nie prognoza liczby.

Liczność a liczba obiektów w przykładowych danych#

Liczność opisuje dozwolone modele lub stan systemu, nie bieżący wynik zapytania. Jeśli linia mówi 0..* zamówień, klient może mieć zero zamówień, ale może też mieć dowolną liczbę. Zrzut bazy zawierający aktualnie trzy zamówienia nie zmienia tego ograniczenia.

Liczność nie jest też automatycznie liczbą wierszy tabeli. Relacyjna baza danych może wymagać kluczy obcych, tabel łącznikowych i ograniczeń, aby wymusić część reguł. Wygenerowany kod może reprezentować relację jako kolekcję, referencję lub inaczej — zależy to od technologii. Model ma wyrazić regułę domenową niezależnie od tej implementacji.

Liczność na różnych relacjach#

W asocjacji liczności przy jej końcach opisują liczbę instancji, które mogą być powiązane. W kompozycji oraz agregacji końcowa liczność nadal ogranicza liczbę części przypisanych do całości, a semantyka własności wynika dodatkowo z rodzaju agregacji. W przypadku zależności liczność nie jest zwykle głównym sposobem opisu relacji, bo zależność nie przedstawia strukturalnych powiązań instancji.

W asocjacji n-arnej, łączącej więcej niż dwa klasyfikatory, odczyt jest bardziej złożony: liczność przy końcu określa liczbę instancji tego klasyfikatora, które mogą uczestniczyć w jednym zestawie powiązania, gdy wartości na pozostałych końcach są ustalone. Jeżeli taki przypadek jest istotny, pokaż konkretny przykład, ponieważ intuicja z asocjacji binarnej może nie wystarczyć.

Jak ustalić właściwą liczność#

Formułuj regułę domenową dla pojedynczego obiektu po drugiej stronie, a następnie przełóż ją na zakres. Dla przykładu:

  1. Czy zamówienie może istnieć przed przypisaniem klienta? Jeśli nie, koniec Klient ma dolną granicę 1.
  2. Czy zamówienie może mieć kilku klientów? Jeśli nie, górna granica to 1.
  3. Czy klient może nie mieć jeszcze żadnych zamówień? Jeśli tak, koniec Zamowienie zaczyna się od 0.
  4. Czy system wyznacza maksymalną liczbę zamówień klienta? Jeśli nie, górna granica może być *.

Sprawdź regułę na brzegowych przykładach: zero elementów, dokładnie jeden, maksymalna liczba oraz stan tuż poza zakresem. Jeśli biznes wymaga limitu, takiego jak najwyżej pięć aktywnych rezerwacji, wskaż, czy ograniczenie dotyczy wszystkich instancji, konkretnego stanu czy tylko danego kontekstu. Zwykły zapis liczności przy relacji może nie wyrażać warunku warunkowego lub zależnego od czasu.

Częste błędy#

  • Czytanie liczności po niewłaściwej stronie. Wypowiedz osobno, ile obiektów z jednego końca przypada na pojedynczy obiekt drugiego końca.
  • 0..* odczytane jako „co najmniej jeden”. Jeśli relacja jest obowiązkowa, minimalna liczba musi wynosić 1.
  • 1 potraktowane jako „jeden lub więcej”. Dokładnie jeden zapisuje się jako 1; co najmniej jeden jako 1..*.
  • Pominięcie liczności. Wartość domyślna w UML nie zawsze jest tym, co autor miał na myśli; jawny zapis jest czytelniejszy w materiale dydaktycznym i przy regułach domenowych.
  • Przeniesienie liczby z przykładowych danych do modelu. To, że obecnie klient ma trzy zamówienia, nie uzasadnia zakresu 3.
  • Mylenie liczności z ograniczeniem implementacyjnym. Limit techniczny lub rozmiar strony wyników nie musi być regułą modelowanej domeny.
  • Ukrycie warunku w zbyt prostym zakresie. Jeśli liczba zależy od statusu, roli albo czasu, dopisz ograniczenie lub użyj osobnego modelu.

Podsumowanie#

Liczność określa minimalną i maksymalną liczbę wartości przy końcu relacji. Zapis 0..* pozwala na brak lub dowolnie wiele powiązań, a 1 oznacza dokładnie jedno. Odczytuj każdy koniec z perspektywy pojedynczego obiektu po przeciwnej stronie i sprawdzaj zakres na konkretnych przypadkach brzegowych.