Jak przejść od opisu problemu do modelu?

Zacznij od pytania, na które model ma odpowiedzieć#

Przejście od opisu problemu do modelu UML zaczyna się od określenia celu, a nie od rysowania diagramu. Najpierw ustal, jaką decyzję model ma wesprzeć, kto będzie go czytał i jaki fragment rzeczywistości opisuje. Dopiero potem wybierz pojęcia, relacje, zachowania i diagramy potrzebne do odpowiedzi na to pytanie.

Model jest uproszczoną reprezentacją systemu lub problemu zbudowaną w określonym celu. Nie musi zawierać wszystkiego, co wiadomo o rzeczywistym świecie ani przewidywać każdej możliwej sytuacji. Dobre uproszczenie zachowuje szczegóły ważne dla celu i pomija resztę jawnie, zamiast tworzyć pozornie kompletny, lecz nieczytelny rysunek.

Przykładowe cele różnią się: omówienie zakresu systemu z interesariuszem wymaga pokazania funkcji i aktorów; projektowanie struktury wymaga typów i relacji; analiza współpracy usług wymaga przepływu komunikatów; przygotowanie testów może wymagać warunków, wyjątków i stanów. Jeden model nie musi odpowiadać na wszystkie te pytania.

Ustal kontekst i granice#

Opis problemu często miesza potrzeby użytkowników, zachowanie istniejącej organizacji, ograniczenia techniczne, propozycje rozwiązań i wyjątki. Rozdziel te informacje. Zapisz:

• kto lub co ma problem i czego potrzebuje;
• jaki system lub proces jest przedmiotem modelowania;
• co należy do systemu, a co pozostaje jego otoczeniem;
• jakie zdarzenie uruchamia analizowany scenariusz;
• jaki rezultat ma być osiągnięty;
• które ograniczenia są obowiązujące, a które są dopiero propozycjami;
• co jest poza zakresem bieżącego modelu.

Granica systemu powinna być czytelna dla odbiorców. „System” może oznaczać aplikację, organizację, usługę, proces albo ich część. Jeśli różni rozmówcy używają tej nazwy inaczej, uzgodnij definicję przed modelowaniem. Możesz zaznaczyć granicę na diagramie przypadków użycia lub opisać ją w założeniach modelu.

Rozbij opis na sprawdzalne stwierdzenia#

Nie modeluj bezpośrednio długiego akapitu. Podziel go na stwierdzenia: kto wykonuje działanie, na jakich danych, w jakich warunkach, jaki stan się zmienia i co może pójść nie tak. Dla procesów zapisz kroki i warianty. Dla opisu domeny wyodrębnij pojęcia, ich cechy, relacje i reguły. Dla wymagań oddziel to, co system musi robić, od jakościowych ograniczeń, takich jak dostępność czy czas odpowiedzi.

Przykładowy opis: „Klient składa zamówienie. Sklep sprawdza dostępność. Jeśli produkt jest dostępny, rezerwuje go na piętnaście minut i prosi o płatność; w przeciwnym razie informuje o braku. Po udanej płatności potwierdza zamówienie.” Można z niego wydzielić aktora, zamówienie, produkt, rezerwację, dostępność, płatność oraz scenariusz warunkowy. Sam tekst nie rozstrzyga jeszcze, czy rezerwacja jest osobnym obiektem, jaki jest dokładny moment rozpoczęcia limitu ani jak obsłużyć spóźnioną płatność. Te kwestie wymagają doprecyzowania.

Zapisz niejasności jako pytania, zamiast zamieniać domysł w pozorny fakt. Przyjmij tymczasowe założenie tylko wtedy, gdy możesz je nazwać, uzasadnić i sprawdzić z właściwą osobą.

Rozpoznaj elementy i relacje#

W analizie tekstu pomocne są rzeczowniki, czasowniki i warunki, ale nie przekształcaj mechanicznie każdego rzeczownika w klasę ani każdego czasownika w metodę. Rzeczownik może oznaczać aktora, dokument, rolę, wartość, zdarzenie, system zewnętrzny lub pojęcie nieistotne dla modelu. Czasownik może opisywać zachowanie użytkownika, regułę biznesową, zdarzenie, stan albo szczegół techniczny.

Dla każdego kandydata zadaj pytania:

• Czy to pojęcie należy do problemu, który model ma objaśnić?
• Czy ma własną tożsamość, właściwości lub cykl życia?
• Czy jest rolą pełnioną przez osobę lub system?
• Czy jest informacją, wartością czy zdarzeniem?
• Czy występuje relacja, którą trzeba zachować, i jakie obowiązują jej reguły?
• Czy nazwa opisuje pojęcie domenowe, czy wyłącznie szczegół implementacyjny?

Na tym etapie utrzymuj listę pojęć i relacji, a niekoniecznie gotowy diagram klas. Oznacz terminy niejednoznaczne i uzgodnij słownik z zespołem. To ogranicza późniejsze rozbieżności między diagramami.

Wybierz perspektywę i diagram#

Diagram dobiera się do pytania, nie do wygody autora ani do tego, że dany typ jest najbardziej znany. Przykładowo:

Na początek wybierz jeden główny diagram. Dodaj kolejny, gdy odpowiada na inne istotne pytanie lub wyjaśnia szczegół, którego nie da się czytelnie pokazać na pierwszym. Nie próbuj umieszczać całego systemu na jednej planszy.

Buduj model iteracyjnie#

Utwórz pierwszy, celowo niepełny szkic. Umieść w nim tylko elementy potrzebne do opisania głównego scenariusza. Następnie przejdź przez model z osobą znającą problem i sprawdź, czy rozumie nazwy, granice, relacje oraz warunki.

Model rozwijaj w krótkich iteracjach:

1. Opisz cel, odbiorców i zakres.
2. Wydziel pojęcia, role, zdarzenia, reguły oraz pytania bez odpowiedzi.
3. Wybierz diagram, który najlepiej odpowiada na główne pytanie.
4. Narysuj podstawowy przebieg lub strukturę bez przedwczesnych szczegółów.
5. Porównaj go z opisem problemu i sprawdź przykłady oraz wyjątki.
6. Popraw nazwy, granice i semantykę; udokumentuj założenia.
7. Dodaj następny widok tylko wtedy, gdy wnosi nową informację.

To nie jest ścisła sekwencja faz. Analiza modelu może ujawnić brakujące wymaganie, a szczegół diagramu może skłonić do zmiany zakresu. Cofnięcie się i poprawienie wcześniejszych decyzji jest częścią modelowania.

Sprawdzaj model na konkretnych scenariuszach#

Przejdź przez co najmniej jeden typowy przypadek i istotne warianty: sukces, odmowę, błąd, brak danych, powtórzenie lub upływ terminu, jeśli dotyczą problemu. Sprawdź, czy model pozwala wskazać uczestników, warunki, kolejność, rezultat i odpowiedzialność za decyzje.

Weryfikuj zgodność z opisem źródłowym. Każdy element powinien mieć uzasadnienie w celu modelu lub jawnym założeniu. Z drugiej strony istotne wymaganie nie powinno znikać tylko dlatego, że trudno je narysować. Model ma wspierać rozmowę, ale nie może zastępować tekstu wymagania, testu ani decyzji biznesowej.

Jeśli używasz kilku diagramów, porównaj wspólne elementy: nazwy klas i uczestników, zakres odpowiedzialności, stany, warunki i wyniki. Różne widoki mogą abstrahować od innych szczegółów, ale nie powinny opisywać sprzecznych zachowań bez wyjaśnienia.

Kiedy model jest wystarczający#

Model jest wystarczający, gdy odpowiada na uzgodnione pytanie, odbiorcy potrafią odtworzyć istotny scenariusz lub strukturę, a ważne założenia i niewiadome są jawne. Nie oznacza to, że model jest kompletny dla każdego możliwego celu. Wystarczalność ocenia się względem konkretnej decyzji, analizy lub dokumentacji.

Zatrzymaj rozwijanie widoku, jeśli kolejne elementy nie zmieniają interpretacji i nie wspierają celu. Wróć do modelu, gdy zmieni się zakres, pojawi się nowy wymóg albo model przestanie tłumaczyć rzeczywiste zachowanie.

Typowe błędy#

• Rysowanie przed uzgodnieniem celu. Powstaje diagram, który nie odpowiada na konkretne pytanie.
• Automatyczne zamienianie rzeczowników w klasy. Lista słów nie jest modelem domeny.
• Mieszanie problemu z rozwiązaniem technicznym. Szczegóły frameworka mogą odwracać uwagę od reguł biznesowych.
• Brak jawnej granicy. Odbiorcy inaczej rozumieją, co należy do modelowanego systemu.
• Dopowiadanie niejasnych wymagań. Założenie powinno być oznaczone, a nie ukryte w diagramie.
• Pokazywanie wszystkiego naraz. Nadmiar szczegółów utrudnia wykrycie ważnych relacji.
• Pomijanie scenariuszy błędnych. Model sukcesu może nie ujawniać kluczowych wymagań.
• Traktowanie poprawnej składni jako poprawności modelu. Diagram może się wyrenderować, a mimo to zawierać sprzeczne lub nieuzasadnione informacje.
• Niespójne nazewnictwo. To samo pojęcie pod różnymi nazwami wygląda jak kilka różnych elementów.
• Uznanie modelu za cel sam w sobie. Model ma pomagać analizować, projektować, wyjaśniać lub weryfikować system.

Podsumowanie procesu#

Przejdź od problemu do modelu przez określenie celu i zakresu, rozłożenie opisu na stwierdzenia, rozpoznanie pojęć oraz reguł, wybór właściwej perspektywy i iteracyjne sprawdzanie modelu na scenariuszach. Diagram jest użytecznym widokiem modelu, ale decyzje o tym, co pokazać, wynikają z problemu i potrzeb odbiorców.