Najkrótsza reguła wyboru#
Użyj «include», gdy przypadek bazowy zawsze włącza wydzielone zachowanie w odpowiednim przebiegu. Użyj «extend», gdy dodatkowe zachowanie dołącza się do przypadku bazowego tylko w określonych warunkach, a przypadek bazowy pozostaje zrozumiały bez rozszerzenia. Jeśli chodzi po prostu o kolejny krok scenariusza, często nie potrzeba żadnej z tych relacji — wystarczy tekstowy opis przebiegu.
Przypadek Złóż zamówienie zawsze obejmuje sprawdzenie dostępności. Dodaj kupon rozszerza go tylko wtedy, gdy klient poda kod i rozszerzenie ma zastosowanie. Strzałki są skierowane inaczej: include biegnie od przypadku bazowego do dołączanego, a extend — od rozszerzającego do bazowego.
Różnice w skrócie#
| Cecha | «include» | «extend» |
|---|---|---|
| Rola | Włącza zachowanie do bazowego przypadku | Dodaje zachowanie rozszerzające do bazowego |
| Kiedy występuje | Zawsze w przebiegu, który realizuje bazowy przypadek | Warunkowo, w określonym punkcie rozszerzenia |
| Samodzielność przypadku bazowego | Obejmuje dołączane zachowanie jako część realizacji | Powinien zachować sens bez rozszerzenia |
| Kierunek strzałki | Bazowy → dołączany | Rozszerzający → bazowy |
| Typowe użycie | Wspólny lub obowiązkowy fragment zachowania | Opcjonalny wariant, dodatkowa reguła lub warunek |
Słowa „obowiązkowy” i „opcjonalny” są użytecznymi skrótami, ale zawsze interpretuj relację w kontekście przebiegu przypadku bazowego. Include nie znaczy, że niezależny aktor uruchamia dołączany przypadek osobno. Extend nie oznacza, że cały przypadek rozszerzający jest zawsze wykonywany.
Kiedy wydzielić zachowanie przez include#
Wydziel wspólny fragment, jeśli kilka przypadków użycia naprawdę korzysta z tego samego zachowania i jego osobny opis poprawia czytelność lub spójność. Przykładem może być uwierzytelnienie wymagane przez kilka operacji, o ile w każdym kontekście ma tę samą semantykę. Strzałka prowadzi z każdego przypadku bazowego do wspólnego przypadku dołączanego.
Nie wydzielaj fragmentu wyłącznie dlatego, że dwie listy kroków zawierają podobne zdanie. Jeśli fragment różni się warunkami, wynikami albo znaczeniem, wspólny przypadek może wprowadzać fałszywe założenie. Jeśli krok ma tylko jednego odbiorcę i nie zyskuje samodzielnego opisu, prościej pozostawić go w scenariuszu.
Kiedy rozszerzyć przez extend#
Użyj extend, gdy podstawowy cel jest kompletny bez dodatkowego przebiegu, ale czasem zachowanie zostaje uzupełnione. Rozszerzenie powinno mieć jasno określony warunek i miejsce włączenia; punkt rozszerzenia może być nazwany w przypadku bazowym. Przykładem jest „Zażądaj zatwierdzenia” jako rozszerzenie „Zmień zamówienie”, gdy zmiana przekracza ustalony próg.
Wyjątek nie zawsze powinien być osobnym przypadkiem extend. Jeśli stanowi zwykły wariant lub błąd obsługi w scenariuszu, opis tekstowy albo diagram aktywności może być czytelniejszy. Stosuj extend, gdy osobny przypadek ma znaczenie dla modelu, może być analizowany niezależnie lub wnosi czytelną strukturę.
Sprawdź kierunek strzałki#
W obu relacjach strzałka jest przerywana i ma otwarty grot, więc sama geometria nie rozróżnia znaczenia — decyduje stereotyp i kierunek. Dla include zapytaj: „który przypadek włącza zachowanie?”; dla extend: „który przypadek dodaje zachowanie do bazowego?”. Najlepiej odczytać etykietę wraz ze strzałką jako zdanie.
Przykład poprawny: Złóż zamówienie —«include»→ Sprawdź dostępność. Przykład poprawny: Dodaj kupon —«extend»→ Złóż zamówienie. Odwrócenie którejkolwiek strzałki zmienia model i łatwo prowadzi do błędnej interpretacji.
Pytania decyzyjne#
- Czy wydzielane zachowanie wykonuje się w każdym przebiegu przypadku bazowego? Jeśli tak, rozważ include.
- Czy podstawowy przypadek jest kompletny bez dodatkowego zachowania, które występuje tylko pod warunkiem? Jeśli tak, rozważ extend.
- Czy fragment ma znaczenie i odpowiedzialność na tyle odrębne, że warto go nazwać osobnym przypadkiem?
- Czy scenariusz tekstowy opisuje go prościej i bez utraty ważnej struktury?
- Czy warunek i punkt włączenia rozszerzenia są zrozumiałe dla odbiorców?
Odpowiedzi powinny wynikać z wymagań, a nie z chęci użycia wszystkich symboli UML. Diagram bez include i extend może być poprawny; są to narzędzia strukturyzowania modelu, a nie obowiązkowy zestaw.
Typowe błędy#
- Kierunek strzałki zamieniony. Include: bazowy wskazuje dołączany; extend: rozszerzający wskazuje bazowy.
- Extend użyty jako obowiązkowy krok. Jeśli zachowanie zawsze jest włączane, rozważ include lub zwykły krok scenariusza.
- Include użyty dla opcjonalnej funkcji. Sama możliwość wywołania nie oznacza, że zachowanie zawsze należy do bazowego przebiegu.
- Warunek rozszerzenia niewidoczny. Opisz, kiedy dodatkowy przebieg się włącza.
- Każdy krok zamieniony w elipsę. Zbyt drobna dekompozycja utrudnia rozmowę o celach.
- Nazwy kroków zamiast celów. Przypadek powinien wnosić sensowną wartość z perspektywy uczestnika.
- Mechaniczne współdzielenie podobnych fragmentów. Najpierw sprawdź, czy ich semantyka naprawdę jest identyczna.
Podsumowanie#
«include» oznacza zachowanie włączane do bazowego przypadku, a «extend» — warunkowe uzupełnienie przypadku bazowego, który ma sens samodzielnie. Include biegnie od bazowego do dołączanego, extend od rozszerzającego do bazowego. Gdy dodatkowa relacja nie poprawia modelu, opisz krok w scenariuszu.