Diagram jako wspólna powierzchnia rozmowy#

Warsztat UML ma pomóc uczestnikom wspólnie zrozumieć cele, przebiegi, reguły, granice i zależności. Rysunek jest narzędziem do myślenia i uzgadniania, a nie egzaminem z symboli. Moderator może rysować na żywo, pytać o znaczenie każdej relacji i zapisywać niewiadome zamiast samemu dopowiadać odpowiedzi.

Nie musisz tworzyć diagramu do każdego warsztatu. Jeśli problem lepiej rozwiązuje mapa procesu, prototyp, tabela lub rozmowa, użyj właściwego narzędzia. UML jest wartościowy, gdy notacja ujawnia ważną strukturę lub zachowanie.

Przygotuj cel, uczestników i zakres#

Przed spotkaniem określ jedno pytanie lub decyzję, którą grupa ma rozstrzygnąć. Zaproś osoby znające proces, system, dane i ograniczenia oraz osobę uprawnioną do zatwierdzania decyzji. Podaj granicę modelowanego systemu i kontekst zmiany.

Wybierz prosty diagram startowy, jeśli pozwala oszczędzić czas, ale oznacz go jako hipotezę. Przygotuj neutralne pytania, a nie gotowe odpowiedzi. Jeśli uczestnicy nie rozumieją symboli, krótko wyjaśnij potrzebną notację i kontynuuj rozmowę o problemie.

Prowadź od celu do modelu#

  1. Poproś uczestników o opisanie celu lub problemu własnymi słowami.
  2. Ustal granicę, role, ważne pojęcia i systemy współpracujące.
  3. Zapytaj o scenariusz typowy oraz o odmowę, błąd, wyjątek i przypadek brzegowy.
  4. Wybierz diagram odpowiadający rozmowie: przypadki użycia, aktywność, klasy, stany lub sekwencję.
  5. Rysuj elementy, gdy grupa uzgodni ich znaczenie; nazywaj relacje pełnymi zdaniami.
  6. Zaznacz niepewności, konflikty interpretacji i osoby odpowiedzialne za decyzję.
  7. Podsumuj, co jest uzgodnione, co pozostaje otwarte i jakie działania wynikają ze spotkania.

Moderator nie powinien przeskakiwać do projektowania implementacji, zanim uczestnicy uzgodnią problem i reguły. Jeśli rozmowa schodzi w szczegóły, zapisz je jako pytanie do osobnego spotkania albo wyznacz zakres, który wymaga decyzji technicznej.

Wybór diagramu podczas spotkania#

Diagram przypadków użycia pomaga nazwać aktorów i cele. Aktywność pokazuje przebieg czynności, odpowiedzialność i rozgałęzienia. Klasy pomagają uzgodnić pojęcia, relacje i liczności. Stany są dobre do rozstrzygnięcia, jakie działania są dozwolone na kolejnych etapach. Sekwencja ujawnia kolejność komunikacji z systemami zewnętrznymi.

Jeśli pytanie zmienia się w trakcie spotkania, zmień widok albo rozpocznij drugi diagram. Nie próbuj wyjaśniać wszystkich aspektów jednym rysunkiem. Wspólne nazwy i krótki opis pomagają połączyć widoki później.

Pytania, które pomagają odkryć braki#

  • Kto inicjuje ten przebieg i jaki cel chce osiągnąć?
  • Co musi być prawdą, zanim proces się zacznie?
  • Co jest wynikiem, który użytkownik może zaobserwować?
  • Co jeśli warunek nie jest spełniony albo zależny system nie odpowie?
  • Czy czynność powtarza się, może zostać anulowana lub wykonać równolegle?
  • Kto odpowiada za krok i czy jest to część modelowanego systemu?
  • Jakie dane lub pojęcia zmieniają się w tym przebiegu?
  • Czy uczestnicy używają tej samej nazwy w tym samym znaczeniu?

Weryfikuj model na konkretnym przykładzie. Poproś inną osobę, aby opisała go bez pomocy moderatora. Jeśli nie potrafi, sprawdź nazwy, kierunki, liczności i brakujące warunki.

Konflikty i otwarte decyzje#

Uczestnicy mogą mieć różne opisy procesu, bo mówią o różnych środowiskach, rolach lub wyjątkach. Nie zacieraj konfliktu przez narysowanie kompromisowej strzałki. Zapisz warianty, źródła informacji i właściciela decyzji; w razie potrzeby utwórz osobne diagramy stanu obecnego i docelowego.

Rozróżnij fakt obserwowany, wymaganie, założenie i propozycję. Odnotuj decyzje oraz ich konsekwencje poza samym diagramem. Rysunek nie zapisuje automatycznie uzasadnienia ani tego, kto zatwierdził zachowanie.

Po warsztacie#

Przepisz szkic do źródłowego formatu lub narzędzia, dodaj zakres i kontekst, a następnie udostępnij uczestnikom do potwierdzenia. Zamień ustalenia na wymagania, kryteria akceptacji, zadania i otwarte pytania. Nie uznawaj braku sprzeciwu za formalną akceptację, jeśli proces projektu wymaga zatwierdzenia.

Właściciel diagramu powinien aktualizować go, gdy zmienią się uzgodnione reguły. Szkic warsztatowy może być archiwalnym wynikiem spotkania, a dokumentacja systemu — osobnym widokiem utrzymywanym przez zespół.

Typowe błędy#

  • Warsztat zamieniony w wykład UML. Ucz i rysuj tylko notację potrzebną do rozmowy.
  • Moderator projektuje za uczestników. Zadawaj pytania i ujawniaj założenia.
  • Brak celu spotkania. Zdefiniuj decyzję lub pytanie przed rysowaniem.
  • Sukces jako jedyny scenariusz. Zapytaj o wyjątki, błędy i przypadki graniczne.
  • Konflikt zamalowany na diagramie. Zapisz rozbieżności i właścicieli decyzji.
  • Szkic uznany za zatwierdzony model. Potwierdź status i źródło prawdy.
  • Brak działań po spotkaniu. Przekształć model w wymagania i decyzje.

Podsumowanie#

Używaj UML podczas warsztatu jako wspólnego języka do odkrywania i uzgadniania zachowania. Zacznij od celu, dobierz prosty diagram, sprawdź go na przypadkach i zapisuj niepewności jawnie. Po spotkaniu potwierdź ustalenia i określ, kto utrzymuje model.