Język modelowania zintegrowanego (UML)Diagramy przypadków użycia to potężne narzędzia do modelowania wymagań funkcyjnych systemu. Ilustrują, jak aktorzy (użytkownicy lub zewnętrzne systemy) współdziałają z systemem poprzez przypadki użycia, które reprezentują konkretne funkcjonalności. Dwie kluczowe relacje na diagramach przypadków użycia—Include i Extend— pomagają zarządzać złożonością poprzez strukturyzowanie i modularizację zachowań. Ten samouczek zawiera szczegółowe wyjaśnienie tych relacji, ich celów, cech oraz zastosowań praktycznych, wraz z przykładami zapewniającymi jasność.
W diagramach przypadków użycia UML, Include i Extendrelacje Include i Extend pozwalają na rozkładanie złożonych przypadków użycia na mniejsze, ponownie używalne lub opcjonalne komponenty. Te relacje zwiększają moduowość, zmniejszają nadmiarowość i poprawiają czytelność diagramów.

Relacja Include (<<include>>): Reprezentuje zachowanie obowiązkowe, które zawsze jest wykonywane jako część podstawowego przypadku użycia. Wyodrębnia wspólną funkcjonalność współdzieloną przez wiele przypadków użycia w postaci komponentu ponownie używalnego.
Relacja Extend (<<extend>>): Reprezentuje opcjonalne lub warunkowe zachowanie, które rozszerza podstawowy przypadek użycia w określonych warunkach, pozostawiając podstawowy przypadek użycia skupiony na jego podstawowej funkcjonalności.
Obie relacje wykorzystują kreskowane strzałki do łączenia przypadków użycia, z etykietami wskazującymi<<include>> lub <<extend>>. Kierunek strzałki jest kluczowy, ponieważ odzwierciedla zależność między przypadkami użycia.
Za pomocą ZałączRelacja załącz jest używana do wyodrębnienia wspólnego, obowiązkowego zachowania z wielu przypadków użycia do jednego, ponownie użytecznego przypadku użycia. Umożliwia to ponowne wykorzystanie i upraszcza podstawowe przypadki użycia, unikając powtarzającej się funkcjonalności.
Obowiązkowy: Przypadek użycia załączony jest zawsze wykonywany, gdy wykonywany jest przypadek użycia podstawowy.
Ponownie użyteczny: Przypadek użycia załączony jest samodzielna, spójna funkcja, którą mogą wykorzystywać wiele przypadków użycia podstawowych.
Uproszcza diagramy: Wyodrębniając wspólne kroki, przypadek użycia podstawowy pozostaje zwięzły i skupiony.
Kierunek: Strzałka wskazuje od przypadku użycia podstawowego do przypadku użycia załączonego, co oznacza, że przypadek użycia podstawowy zależy od przypadku użycia załączonego.
Przerywana strzałka oznaczona jako<<załącz>> łączy przypadek użycia podstawowego z przypadkiem użycia załączonym.
Rozważmy system sklepowy internetowy, w którym klient możeZłożyć zamówienielubAnulować zamówienie. Oba przypadki użycia wymagają od klientaZalogować się do systemu.
Podstawowe przypadki użycia: Złożyć zamówienie, Anuluj zamówienie
Włączony przypadek użycia: Zaloguj się
Wyjaśnienie: Zalogowanie się jest obowiązkowym krokiem zarówno przy składaniu, jak i anulowaniu zamówienia. Zamiast powtarzać funkcjonalność logowania w obu przypadkach użycia, została ona wyodrębniona do osobnego Zaloguj się przypadku użycia, który jest włączany przez oba.
Reprezentacja diagramu:
[Złóż zamówienie] ----<<włącz>>----> [Zaloguj się]
[Anuluj zamówienie] ----<<włącz>>----> [Zaloguj się]
W systemie bibliotecznym użytkownik może Wypożyczyć książkę lub Zwrócić książkę. Obie procedury wymagają Weryfikacja użytkownika.
Podstawowe przypadki użycia: Wypożyczyć książkę, Zwrócić książkę
Włączony przypadek użycia: Weryfikacja użytkownika
Wyjaśnienie: Weryfikacja tożsamości użytkownika (np. sprawdzenie jego karty bibliotecznej) jest obowiązkowym krokiem zarówno przy wypożyczaniu, jak i zwracaniu książki. Weryfikacja użytkownika przypadku użycia jest uwzględniony, aby uniknąć nadmiarowości.
Reprezentacja diagramu:
[Wypożycz książkę] ----<<include>>----> [Weryfikacja użytkownika]
[Oddaj książkę] ----<<include>>----> [Weryfikacja użytkownika]
Gdy wiele przypadków użycia dzieli wspólny, obowiązkowy krok.
Gdy chcesz uprościć opisy przypadków użycia poprzez wyodrębnienie funkcjonalności powtarzalnej.
Gdy uwzględniony przypadek użycia ma sens samodzielnie (np. Zaloguj się lub Weryfikacja użytkownikamoże być rozumiane jako funkcje samodzielne).
Relacja Rozszerzrelacja jest używana do modelowania opcjonalnego lub warunkowego zachowania, które jest wykonywane tylko w określonych warunkach. Pozwala przypadkowi podstawowemu zachować skupienie na swojej podstawowej funkcjonalności, jednocześnie dodając opcjonalne zachowanie w sposób modułowy.
Opcjonalne/Warunkowe: Przypadek użycia rozszerzający jest wykonywany tylko wtedy, gdy spełnione są określone warunki.
Zależny: Przypadek użycia rozszerzający nie ma sensu samodzielnie i zależy od przypadku podstawowego.
Punkty rozszerzania: Przypadek podstawowy może definiować konkretne punkty, w których może być wstawione zachowanie rozszerzające.
Kierunek: Strzałka wskazuje od przypadku rozszerzającego do przypadku podstawowego, co oznacza, że przypadek rozszerzający dodaje zachowanie do przypadku podstawowego.
Przerywana strzałka oznaczona jako<<extend>> łączy przypadki użycia rozszerzające z przypadkiem użycia podstawowym, często z notatką określającą warunek lub punkt rozszerzenia.
W systemie bankomatu przypadkiem użycia podstawowym jestWypłata gotówki. Dodatkowe zachowanie, Drukowanie paragonu, może wystąpić, jeśli użytkownik poprosi o paragon.
Przypadek użycia podstawowy: Wypłata gotówki
Przypadek użycia rozszerzający: Drukowanie paragonu
Warunek: Użytkownik decyduje się na wydrukowanie paragonu po wypłacie gotówki.
Wyjaśnienie: Drukowanie paragonu nie jest obowiązkowe i następuje tylko wtedy, gdy użytkownik jawnie o to poprosi. Przypadek użycia Drukowanie paragonu rozszerza Wypłata gotówki w punkcie rozszerzenia „Użytkownik prosi o paragon.”
Reprezentacja diagramu:
[Drukowanie paragonu] ----<<extend>>----> [Wypłata gotówki]rn(Uwaga: Warunek = Użytkownik prosi o paragon)
Na platformie kursów online użytkownik możeUczęszczać na test. Dodatkowe zachowanie, Poprosić o podpowiedź, występuje, gdy użytkownik ma trudności z pytaniem.
Podstawowy przypadek użycia: Ucz się quizu
Przypadek użycia rozszerzający: Poproś o podpowiedź
Warunek: Użytkownik prosi o podpowiedź podczas quizu.
Wyjaśnienie: Prośba o podpowiedź jest opcjonalna i zależy od potrzeb użytkownika. Przypadek Poproś o podpowiedź przypadek użycia rozszerza Ucz się quizu w punkcie rozszerzenia „Użytkownik potrzebuje pomocy.”
Reprezentacja diagramu:
[Poproś o podpowiedź] ----<<extend>>----> [Ucz się quizu]
(Uwaga: Warunek = Użytkownik potrzebuje pomocy)
Gdy zachowanie jest opcjonalne lub zależy od określonych warunków.
Gdy chcesz zachować podstawowy przypadek użycia skupiony na jego podstawowej funkcjonalności.
Gdy przypadek użycia rozszerzający nie ma sensu bez podstawowego przypadku użycia (np. Drukuj paragon jest bez sensu bez Wypłać gotówkę).
Poniższa tabela podsumowuje różnice między Include i Rozszerz relacje, aby kierować ich używaniem:
|
Kryteria |
Zawieraj (<<zawieraj>>) |
Rozszerz (<<rozszerz>>) |
|---|---|---|
|
Czy zachowanie jest obowiązkowe? |
Tak, zawsze wykonywane jako część podstawowego przypadku użycia |
Nie, wykonywane tylko w określonych warunkach |
|
Czy zachowanie może istnieć samodzielnie? |
Tak, jest to spójna, ponownie używalna funkcja |
Nie, zależy od podstawowego przypadku użycia |
|
Czy występuje w wielu przypadkach użycia? |
Tak, współdzielone między wieloma przypadkami użycia |
Zazwyczaj specyficzne dla jednego przypadku użycia |
|
Cel |
Wspieraj ponowne wykorzystanie i upraszczaj podstawowy przypadek użycia |
Dodawaj opcjonalne lub wyjątkowe zachowanie w sposób modułowy |
|
Kierunek strzałki |
Podstawowy → Włączony przypadek użycia |
Rozszerzający → Podstawowy przypadek użycia |
Zastosujmy obie relacje w systemie zarządzania restauracją, aby ilustrować ich zastosowanie w rzeczywistym scenariuszu.
System restauracyjny pozwala klientom naZamawianie jedzenia i Zarezerwuj stół. System obsługuje również dodatkowe zachowania, takie jak Zapłać rachunek i Zażądaj jedzenia na wynos.
Zamów jedzenie: Klient zamawia jedzenie z menu.
Zarezerwuj stół: Klient rezerwuje stół na posiłek.
Zautoryzuj klienta: Potwierdza tożsamość klienta (np. za pomocą konta lojalnościowego).
Zapłać rachunek: Klient płaci za zamówienie (obowiązkowe dla Zamów jedzenie).
Zażądaj jedzenia na wynos: Opcjonalna prośba o opakowanie zamówienia na wynos.
Zawiera: Oba Zamów jedzenie i Zarezerwuj stół wymagają Zautoryzuj klienta w celu potwierdzenia tożsamości klienta.Zamów jedzenie obejmuje również Zapłać rachunek ponieważ płatność jest obowiązkowa po złożeniu zamówienia.
Rozszerz: Zamów jedzenie może być rozszerzony przezZażądaj jedzenia na wynos jeśli klient decyduje się zabrać jedzenie na wynos.
[Zamów jedzenie] ----<<zawiera>>----> [Zautoryzuj klienta]
[Zamów jedzenie] ----<<zawiera>>----> [Zapłać rachunek]
[Zarezerwuj stół] ----<<zawiera>>----> [Zautoryzuj klienta]
[Zażądaj jedzenia na wynos] ----<<rozszerza>>----> [Zamów jedzenie]
(Uwaga: Warunek = Klient prosi o jedzenie na wynos)
Zautoryzuj klienta jest zawarte w obuZamów jedzenie iZarezerwuj stół ponieważ jest to obowiązkowy krok umożliwiający dostęp do systemu.
Zapłać rachunek jest zawarte wZamów jedzenie ponieważ płatność jest wymagana do zakończenia zamówienia.
Zażądaj jedzenia na wynos rozszerzaZamów jedzenie ponieważ jest to zachowanie opcjonalne, które ma miejsce tylko wtedy, gdy klient prosi o jedzenie na wynos.
Używaj Include oszczędnie: Wyodrębniaj zachowanie do przypadku użycia zawartego tylko wtedy, gdy jest wspólne dla wielu przypadków użycia lub znacznie upraszcza podstawowy przypadek użycia. Nadmierne używanie include może spowodować zaniechany diagram.
Określ jasne punkty rozszerzania dla Extend: Określ warunki lub punkty w podstawowym przypadku użycia, w których ma zastosowanie rozszerzane zachowanie, aby uniknąć niejasności.
Trzymaj przypadki użycia skupione: Upewnij się, że podstawowy przypadek użycia pozostaje prosty i skupiony na swoim głównym celu, używającZawieraj do kroków wymaganych iRozszerz do opcjonalnych.
Weryfikuj możliwości ponownego wykorzystania dla Zawieraj: Przypadek użycia zawarty powinien mieć sens i być wykorzystywany ponownie w różnych kontekstach.
Unikaj nadmiernego skomplikowania diagramów: UżywajZawieraj iRozszerz tylko wtedy, gdy dodają jasność. Złożone relacje mogą wprowadzać w błąd stakeholderów.
Pomylenie Zawieraj z Rozszerz:
Pułapka: UżywanieZawieraj do zachowania opcjonalnego lubRozszerz do zachowania wymaganego.
Rozwiązanie: Zawsze sprawdź, czy zachowanie jest wymagane (użyjZawieraj) lub warunkowe (użyjRozszerz).
Zbyt częste używanie relacji:
Pułapka: Tworzenie zbyt wielu Zawieraj lub Rozszerz relacji, co sprawia, że diagram jest trudny do odczytania.
Rozwiązanie: Używaj tych relacji tylko wtedy, gdy zmniejszają nadmiarowość lub poprawiają czytelność.
Nieprecyzyjne warunki rozszerzenia:
Pułapka: Nie określając warunku dla relacji Rozszerz relacji, co prowadzi do zamieszania.
Rozwiązanie: Zawsze dodawaj notatkę lub opis warunku lub punktu rozszerzenia.
Włączanie niereużywalnego zachowania:
Pułapka: Tworzenie przypadku użycia dołączanego, który jest używany tylko przez jeden przypadek podstawowy.
Rozwiązanie: Upewnij się, że przypadki użycia dołączane są reużywalne lub znacznie upraszczają przypadek podstawowy.
Relacje Zawieraj i Rozszerz relacje w diagramach przypadków użycia UML są kluczowe do zarządzania złożonością i zapewniania modułowości. Relacja Zawieraj relacja promuje ponowne wykorzystanie poprzez wyodrębnianie wymaganych, współdzielonych zachowań, podczas gdyRozszerz relacja utrzymuje podstawowe przypadki użycia skupione, modelując zachowania opcjonalne lub warunkowe. Zrozumienie ich celów, cech i najlepszych praktyk pozwala stworzyć jasne, utrzymywalne i skuteczne diagramy przypadków użycia, które przekazują funkcjonalność systemu stakeholderom.