Jak wyodrębniać klasy z wymagań? Poradnik UML

Nie zamieniaj mechanicznie rzeczowników w klasy#

Wyodrębnianie klas z wymagań polega na odkrywaniu pojęć i odpowiedzialności, które model powinien zachować, a nie na przepisywaniu rzeczowników z dokumentu na diagram. Klasa reprezentuje wspólny typ obiektów o istotnych cechach i zachowaniu. W modelu dziedzinowym może opisywać pojęcie problemu, a w modelu projektowym również element rozwiązania technicznego.

Rzeczownik może wskazywać klasę, ale równie dobrze aktora, rolę, atrybut, wartość, zdarzenie, dokument, usługę zewnętrzną albo detal interfejsu. Decyzję podejmuj względem celu modelu i poziomu abstrakcji. Nazwa w wymaganiu jest wskazówką do dalszej analizy, nie automatycznym rozstrzygnięciem.

Przygotuj materiał do analizy#

Zbierz wymagania, przykłady rzeczywistych przypadków, formularze, dokumenty, reguły i scenariusze. Zanim szukasz klas, uzgodnij zakres modelowanego systemu oraz odbiorców. Rozdziel wymagania biznesowe od propozycji implementacji, a niejasności zapisz jako pytania.

Utwórz roboczy słownik terminów. Dla każdego terminu zanotuj definicję używaną przez interesariuszy, przykładowe instancje i ewentualne synonimy. Różne osoby mogą nazywać to samo pojęcie inaczej albo używać jednej nazwy dla różnych rzeczy. Ujednolicenie języka zmniejsza liczbę sztucznych klas i sprzecznych nazw.

Zbieraj kandydatów, ale odkładaj decyzję#

Podkreśl w wymaganiach rzeczowniki i rzeczownikowe frazy. Dodaj też pojęcia wynikające z czasowników, reguł i zdarzeń — ważna koncepcja może nie wystąpić jako jawny rzeczownik. Dla każdego kandydata zapisz zdanie źródłowe i kontekst. Następnie pogrupuj synonimy i zaznacz słowa wieloznaczne.

Przykładowy opis sklepu: „Klient rezerwuje dostępny produkt w zamówieniu. Rezerwacja wygasa po piętnastu minutach, jeśli płatność nie zostanie potwierdzona. System wysyła klientowi potwierdzenie”. Kandydatami mogą być Klient, Produkt, Zamówienie, Rezerwacja, Płatność i Potwierdzenie. Piętnaście minut może stać się wartością ograniczenia, a „system” może być granicą, nie klasą domenową. Dopiero sprawdzenie tożsamości, cyklu życia i reguł pokaże, które kandydatury są typami, a które atrybutami lub zdarzeniami.

Oceń kandydata na klasę#

Zadaj dla każdego pojęcia kilka pytań:

Czy pojęcie ma znaczenie w dziedzinie i pojawia się w regułach, scenariuszach lub danych?
Czy system musi rozróżniać jego poszczególne wystąpienia?
Czy ma własne cechy, zachowanie, stan lub cykl życia?
Czy istnieją reguły odnoszące się do niego jako całości?
Czy jest odrębnym bytem, czy prostą cechą innego obiektu?
Czy zachowanie lub informacje o nim zmieniają się niezależnie?
Czy modelowany poziom wymaga przedstawienia tego pojęcia jako klasy?

Odpowiedzi nie stanowią matematycznego testu. To narzędzie do podejmowania i uzasadniania decyzji. Pojęcie z własną tożsamością, cyklem życia i regułami częściej zasługuje na oddzielną klasę niż pojedyncza etykieta tekstowa.

Odróżnij klasy od atrybutów i wartości#

Wartość jest zwykle cechą innego obiektu, jeśli nie ma własnej tożsamości ani niezależnego cyklu życia. Imię klienta, numer telefonu albo kod pocztowy mogą być atrybutami lub obiektami wartości w zależności od wymagań i walidacji. Adres może być klasą, gdy ma strukturę, jest współdzielony lub podlega własnym regułom; może być zwykłą wartością, gdy jest prostym polem.

Nie każda informacja musi być osobną klasą. Zbyt drobny podział prowadzi do modelu pełnego pustych pojemników na dane. Zbyt szeroka klasa z kolei może łączyć niezależne koncepcje i utrudniać zapis reguł. Decyzja zależy od potrzebnego poziomu szczegółowości.

Typy wyliczeniowe są przydatne dla małego, zamkniętego zbioru wartości, np. StatusZamówienia, jeśli wartości są proste i nie mają własnych cech. Jeżeli warianty mają różne dane lub zachowanie, mogą wymagać bogatszego modelu. Nie traktuj tego jako uniwersalnej reguły bez sprawdzenia zakresu i stabilności wartości.

Rozpoznaj zdarzenia, role i dokumenty#

Zdarzenie oznacza coś, co zaszło w określonym momencie, np. ZłożenieZamówienia albo PotwierdzeniePłatności. Może być osobnym bytem, gdy trzeba przechowywać historię, czas, nadawcę lub korelować zdarzenia. Może też występować jedynie jako komunikat lub przejście stanu. Wybierz formę zgodną z wymaganiami.

Rola wskazuje funkcję obiektu w konkretnym kontekście. Płatnik może być rolą klienta, a Odbiorca — rolą osoby lub organizacji. Jeżeli role mają różne dane lub zasady, modeluj je jawnie; nie twórz klas wyłącznie dlatego, że jeden byt występuje w kilku zdaniach pod różnymi określeniami.

Dokument, raport lub potwierdzenie może być artefaktem generowanym przez system, zapisem historycznym, projekcją danych albo tylko formatem prezentacji. Ustal, czy ma własną tożsamość, jest przechowywany, może być zmieniany i czy podlega regułom. To rozstrzyga o jego miejscu w modelu.

Wyznacz odpowiedzialności, a potem atrybuty i operacje#

Dla każdej zaakceptowanej klasy zapisz, za jakie informacje lub zachowanie odpowiada. Klasa Zamówienie może utrzymywać pozycje i status, natomiast reguła dostępności może należeć do magazynu lub usługi domenowej zależnie od modelowanej architektury. Nie przypisuj wszystkich operacji do jednej klasy tylko dlatego, że „system” wykonuje je w opisie.

Atrybut opisuje właściwość instancji klasy. Dodawaj tylko dane potrzebne do celu modelu, reguł lub scenariuszy. Ustal typ, obowiązkowość, wartości dozwolone i ograniczenia, jeśli są istotne. Nie wnioskuj, że każda wartość z formularza jest trwałym atrybutem domenowym.

Operacje modeluj wtedy, gdy odbiorca potrzebuje zobaczyć zachowanie lub odpowiedzialność klasy. Diagram pojęciowy nie musi zawierać metod technicznych. Wymaganie „system informuje klienta” nie wystarcza samo w sobie, by zdecydować o konkretnej metodzie, klasie powiadomień i architekturze transportu.

Odkryj relacje, liczności i ograniczenia#

Po ustaleniu głównych pojęć sprawdź, które klasy są powiązane oraz co ta relacja znaczy. Formułuj ją słowami po obu stronach, np. „zamówienie zawiera pozycje”, „płatność rozlicza zamówienie”. Jeśli wymagania określają liczbę, zapisz liczności i warunki: czy zamówienie może mieć zero pozycji w trakcie tworzenia, czy po zatwierdzeniu musi mieć co najmniej jedną?

Nie wyciągaj liczności z pojedynczego przykładu. Jedno zamówienie może mieć wiele pozycji, lecz opis mógł pokazywać tylko jedną. Sprawdź zasady powtórzeń, współdzielenia, usuwania, historii i zależności cyklu życia. Agregację i kompozycję stosuj wyłącznie wtedy, gdy semantyka całości i części jest potrzebna oraz uzasadniona.

Model klas powinien odzwierciedlać niezmienniki domeny, czyli warunki, które muszą być prawdziwe dla poprawnego stanu modelu. Ograniczenia można wyrazić licznościami, typami, opisem lub notacją ograniczeń. Nie każda reguła jest czytelna jako sama relacja; czasem wymaga tekstowego objaśnienia albo innego diagramu.

Weryfikuj kandydatów scenariuszami#

Przejdź przez główny scenariusz i wyjątki, śledząc, które obiekty uczestniczą, jakie informacje przechowują, jak zmieniają stan i które reguły muszą być spełnione. Sprawdź także przypadki graniczne, takie jak anulowanie, ponowienie, wygaśnięcie, brak danych i historia zmian — jeśli dotyczą problemu.

Każdą klasę uzasadnij wymaganiem, regułą, scenariuszem lub decyzją o zakresie. Klasę bez uzasadnienia odłóż, usuń albo wyjaśnij w założeniach. Sprawdź, czy każda istotna nazwa z wymagań została zinterpretowana, nawet jeśli nie staje się klasą.

Rozdziel model dziedzinowy i projektowy#

Model dziedzinowy wyjaśnia pojęcia problemu, ich relacje i reguły bez przedwczesnego przywiązania do technologii. Model projektowy może dodawać klasy interfejsu, kontrolery, repozytoria, adaptery, DTO i elementy frameworka. Oba modele mogą być przydatne, ale odpowiadają na inne pytania.

Nie mieszaj ich bez oznaczenia. Jeżeli diagram ma pomóc ekspertom domenowym, techniczne klasy infrastruktury często zaciemniają treść. Jeżeli ma wesprzeć implementację, pominięcie warstw technicznych może być zbyt dużym uproszczeniem. Opisz poziom abstrakcji i odbiorcę.

Typowe błędy#

Rzeczownik równa się klasa. Sprawdź tożsamość, odpowiedzialność, reguły i cel modelu.
Każdy atrybut jako osobny byt. Wyodrębniaj klasę, gdy pojęcie ma własne znaczenie lub zachowanie.
Pominięcie zdarzeń i historii. Ustal, czy system musi pamiętać, że coś zaszło, kiedy i w jakim kontekście.
Mieszanie synonimów. Utrzymuj jeden uzgodniony termin dla tego samego pojęcia.
Używanie klas technicznych w modelu domenowym. Nie zaciemniaj pojęć problemu szczegółami implementacji.
Przypisanie całego zachowania do jednej klasy. Rozdziel odpowiedzialności zgodnie z wiedzą i regułami.
Liczności wywnioskowane z przykładu. Weryfikuj je w wymaganiach i przypadkach brzegowych.
Nadużycie dziedziczenia. Wspólna nazwa lub kilka wspólnych pól nie zawsze uzasadniają hierarchię.
Przedwczesna agregacja lub kompozycja. Najpierw ustal znaczenie i cykl życia części.
Atrybuty bez typów i ograniczeń. Gdy mają znaczenie dla reguł, określ dozwolone wartości.
Model bez śladu uzasadnienia. Powiąż decyzje z wymaganiami, scenariuszami lub jawnymi założeniami.

Lista kontrolna#

Czy zakres i poziom modelu są jasno określone?
Czy każdy kandydat na klasę ma uzasadnienie poza tym, że wystąpił jako rzeczownik?
Czy klasy, atrybuty, wartości, role, zdarzenia i dokumenty zostały rozróżnione?
Czy odpowiedzialności klas wynikają z reguł i scenariuszy?
Czy relacje i liczności są potwierdzone, a nie zgadnięte?
Czy model obsługuje istotne wyjątki i zmiany stanu?
Czy nazwy są spójne ze słownikiem dziedziny?

Wyodrębnianie klas to proces stawiania i sprawdzania hipotez o pojęciach problemu. Dobry wynik jest spójnym modelem, który tłumaczy wymagania i reguły, a nie najdłuższą możliwą listą klas.