Traktuj diagramy jako widoki jednego modelu#

Różne diagramy UML łączy się przez wspólne elementy, nazwy, zachowania, relacje i wymagania, które opisują z różnych perspektyw. Diagram przypadków użycia pokazuje cele aktorów, diagram aktywności — przepływ, diagram sekwencji — wymianę komunikatów, a diagram klas — strukturę typów. Każdy widok odpowiada na inne pytanie; razem mogą objaśniać ten sam system.

UML definiuje język modelowania i relacje między elementami modelu. Nie oznacza to, że każdy rysunek musi zawierać wszystkie informacje ani że diagramy są automatycznie spójne tylko dlatego, że używają tych samych nazw. Spójność wymaga świadomego utrzymania wspólnych założeń i sprawdzania, czy zachowania nie przeczą sobie nawzajem.

Zacznij od potrzebnego zestawu pytań#

Nie twórz diagramu „do kompletu”. Zapisz pytania, na które odbiorca potrzebuje odpowiedzi, a potem wybierz widok dla każdego z nich. Jeden diagram może wystarczyć. Dodaj następny, gdy przedstawia istotny aspekt, którego pierwszy nie pokazuje czytelnie.

Przykładowy przepływ do analizy:

  • przypadek użycia określa, że klient może złożyć zamówienie;
  • aktywność rozpisuje decyzje i przebieg od złożenia do potwierdzenia;
  • sekwencja pokazuje interakcję interfejsu, usługi zamówień, bazy danych i bramki płatności;
  • diagram klas wyjaśnia Zamówienie, Pozycję i Płatność;
  • maszyna stanów dokumentuje dozwolone stany zamówienia.

To przykładowy sposób podziału informacji, nie obowiązkowa kolejność ani wymóg posiadania pięciu diagramów.

Ustal wspólne źródło nazw i pojęć#

Utrzymuj słownik terminów, identyfikatory elementów lub centralny model, jeśli narzędzie i proces to umożliwiają. Uzgodnij nazwy aktorów, klas, komponentów, stanów i zdarzeń. Synonimy używaj wtedy, gdy rzeczywiście oznaczają inne pojęcia; jeśli są aliasami dla odbiorców, objaśnij je.

To samo słowo może mieć różne znaczenie zależnie od kontekstu, a ta sama klasa może pojawić się na kilku diagramach. Sprawdź, czy jest to ten sam element modelu, czy dwa podobnie nazwane elementy. Jeśli narzędzie utrzymuje repozytorium modelu, ponowne użycie elementu jest bezpieczniejsze niż ręczne kopiowanie, ale nadal wymaga kontroli kontekstu i poziomu abstrakcji.

Łącz wymagania z zachowaniem i strukturą#

Przypadek użycia lub wymaganie funkcjonalne powinno dać się powiązać z opisem scenariusza, aktywnością lub interakcją, która je rozwija. Zachowanie odwołuje się do uczestników i pojęć występujących w modelu strukturalnym. Wymaganie dotyczące czasu odpowiedzi może łączyć się z ograniczeniem na diagramie czasowym i testem, który je sprawdza.

Śledzenie wymagań (traceability) zapisuje relacje między źródłem potrzeby, elementami modelu, decyzją projektową i weryfikacją. Można je utrzymywać w narzędziu modelującym, rejestrze, tabeli lub metadanych, zależnie od skali projektu. Nie każda strzałka UML jest relacją śledzenia — nie nadużywaj zależności, by wyrazić dowolny związek dokumentacyjny.

Sprawdzaj zgodność między widokami#

Wykonaj przegląd przekrojowy. Nazwy stanów w sekwencji powinny zgadzać się z maszyną stanów lub wymagać jawnego wyjaśnienia. Komunikat zarezerwuj nie powinien prowadzić do liczności niemożliwej w diagramie klas. Aktor z przypadku użycia powinien rzeczywiście należeć do granicy i scenariusza, który go opisuje.

Kontroluj szczególnie:

  • zgodność nazw i definicji elementów;
  • zakres systemu oraz role elementów zewnętrznych;
  • kierunek komunikatów i zależności;
  • kolejność oraz warunki scenariuszy;
  • dozwolone stany i zdarzenia;
  • liczności, ograniczenia i warunki wstępne;
  • powiązanie z wymaganiami i testami;
  • poziom abstrakcji i założenia widoków.

Nie wszystkie widoki muszą pokazywać wszystkie fakty. Pominięcie detalu jest poprawne, jeśli wynika z celu diagramu i nie zmienia jego interpretacji. Sprzeczność to inny przypadek: dwa widoki nie powinny przypisywać tej samej sytuacji niezgodnych reguł bez zaznaczenia zakresu lub wersji.

Minimalizuj dublowanie informacji#

Jeśli ten sam scenariusz jest szczegółowo opisany w kilku miejscach, ustal źródło prawdy dla każdej informacji. Diagram sekwencji może pokazywać komunikaty, a przypadek użycia — cel i warianty; nie trzeba kopiować wszystkich strzałek do tekstu wymagania. Można użyć identyfikatora scenariusza, nazwy przypadku użycia lub odwołania utrzymywanego w metadanych.

Duplikacja zwiększa ryzyko, że po zmianie jednego rysunku pozostałe pozostaną stare. Z kolei nadmierne odchudzanie może pozbawić odbiorców potrzebnego kontekstu. Wybierz podział, w którym każda informacja ma czytelne miejsce, a powiązania są łatwe do sprawdzenia.

Wersjonuj wspólne decyzje#

Model zmienia się razem z wymaganiami. Zapisuj istotne założenia, decyzje i wersje zakresu. Jeśli dwa diagramy celowo pokazują różne stany systemu — np. przed i po migracji — oznacz tę różnicę. Utrzymuj ślad zmiany: które wymagania i widoki trzeba przejrzeć po zmianie elementu.

W pracy zespołowej warto ustalić właściciela modelu lub procesu akceptacji, konwencje nazw i sposób zgłaszania niezgodności. Nie oznacza to, że jeden autor musi edytować wszystkie diagramy; oznacza, że ktoś pilnuje spójności wspólnego języka.

Typowe błędy#

  • Diagramy tworzone bez wspólnego celu. Zestaw nie odpowiada na potrzeby odbiorców.
  • Kopiowanie elementów zamiast ich ponownego użycia. Pojawiają się różne nazwy lub definicje tej samej klasy.
  • Wymuszone odwzorowanie jeden do jednego. Nie każdy krok aktywności musi być osobną metodą ani każda klasa linią życia.
  • Sprzeczne warunki i liczności. Widoki mogą ujawnić niezgodności, które trzeba rozstrzygnąć.
  • Zbyt wiele diagramów. Powielanie szczegółów obniża czytelność i zwiększa koszt utrzymania.
  • Brak relacji do źródła wymagania. Nie wiadomo, dlaczego element modelu istnieje.
  • Dowolne używanie zależności. Strzałka modelująca jeden rodzaj relacji nie zastępuje wszystkich powiązań dokumentacyjnych.
  • Ukrywanie zakresu i wersji. Różnice między diagramami mogą wynikać z nieoznaczonych założeń.
  • Zakładanie automatycznej spójności. Wspólny plik lub narzędzie nie zastępuje przeglądu semantycznego.
  • Ręczna synchronizacja bez właściciela. Zmiana elementu nie uruchamia sprawdzenia powiązanych widoków.

Lista kontrolna#

  • Czy każdy diagram odpowiada na konkretne pytanie?
  • Czy wspólne elementy zachowują nazwy, definicje i zakres?
  • Czy wiadomo, które wymagania uzasadniają modelowane zachowanie?
  • Czy istotne reguły są zgodne między strukturą, zachowaniem i stanami?
  • Czy pominięcia są świadome, a różnice zakresu jawne?
  • Czy każdy szczegół ma właściwe miejsce i nie jest niepotrzebnie kopiowany?
  • Czy wiadomo, jak zaktualizować powiązane diagramy po zmianie?

Spójny model powstaje wtedy, gdy diagramy uzupełniają się, a wspólne decyzje można prześledzić i zweryfikować. Nie chodzi o maksymalną liczbę rysunków, lecz o taki zestaw perspektyw, który objaśnia system bez sprzeczności i nadmiarowego powtarzania informacji.