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ść.
Co to są relacje Include i Extend?
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.
Relacja Include (<<include>>)
Cel
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.
Cechy
-
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.
Oznaczenie
-
Przerywana strzałka oznaczona jako<<załącz>> łączy przypadek użycia podstawowego z przypadkiem użycia załączonym.
Przykład 1: System sklepowy internetowy
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ę]
Przykład 2: System zarządzania biblioteką
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]
Kiedy stosować
-
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 rozszerzania (<<extend>>)
Cel
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.
Cechy
-
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.
Oznaczenie
-
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.
Przykład 1: System bankomatu
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)
Przykład 2: Platforma kursów online
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)
Kiedy stosować
-
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ę).
Kluczowe różnice między Include i Extend
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 |
Praktyczny przykład: System zarządzania restauracją
Zastosujmy obie relacje w systemie zarządzania restauracją, aby ilustrować ich zastosowanie w rzeczywistym scenariuszu.
Scenariusz
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.
Przypadki użycia
-
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.
Związki
-
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.
Reprezentacja diagramu
[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)
Wyjaśnienie
-
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.
Najlepsze praktyki dotyczące używania Include i Extend
-
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.
Typowe pułapki i jak im zapobiegać
-
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.
-
Wnioski
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.
Odnośnik
- Dokumentowanie szczegółów przypadków użycia w Visual Paradigm
Przewodnik, jak edytować i przeglądać szczegóły przypadków użycia w Visual Paradigm. - Jak rysować diagram przypadków użycia? – Visual Paradigm
Krok po kroku instrukcje tworzenia diagramów przypadków użycia UML za pomocą Visual Paradigm. - Co to jest diagram przypadków użycia? – Visual Paradigm
Omówienie diagramów przypadków użycia i ich roli w modelowaniu zachowań systemu. - Diagram przypadków użycia w Visual Paradigm
Szczegółowe wyjaśnienie elementów diagramu przypadków użycia oraz sposób dokumentowania zdarzeń przypadków użycia. - Przewodnik po notacjach diagramu przypadków użycia – Visual Paradigm
Kompletny przewodnik po notacjach diagramów przypadków użycia UML obsługiwanych w Visual Paradigm. - Kompletny przewodnik tworzenia diagramów przypadków użycia za pomocą Visual Paradigm
Szczegółowy tutorial dotyczący identyfikowania aktorów, definiowania przypadków użycia i modelowania relacji w Visual Paradigm. - Opis przypadku użycia w Visual Paradigm dla UML – Angelfire
Wyjaśnia opis przypadku użycia, planowanie, rozwojowe rozważania i generowanie dokumentacji w Visual Paradigm. - Rozszyfrowywanie modeli przypadków użycia: łączenie szczegółów tekstowych z wizualnym zrozumieniem
Omawia, jak łączyć szczegółowe informacje tekstowe o przypadkach użycia z diagramami wizualnymi w Visual Paradigm. - Diagram przypadków użycia – narzędzie modelowania UML – Visual Paradigm
Oficjalna strona Visual Paradigm przedstawiająca funkcje i obsługę notacji diagramów przypadków użycia.