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ść.
Czym 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 elementy. Te relacje zwiększają moduowość, zmniejszają nadmiarowość i poprawiają czytelność diagramów.

-
Relacja Include (<<include>>): Reprezentuje zachowanie wymagane, 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ą ZawierajZwiązek Zawieraj jest używany 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: Włączony przypadek użycia jest zawsze wykonywany, gdy wykonywany jest przypadek podstawowy.
-
Ponownie użyteczny: Włączony przypadek użycia to samodzielna, spójna funkcja, którą mogą wykorzystywać wiele przypadków podstawowych.
-
Uproszcza diagramy: Wyodrębniając wspólne kroki, przypadek podstawowy pozostaje zwięzły i skupiony.
-
Kierunek: Strzałka wskazuje od przypadku podstawowego do przypadku włączanego, co oznacza, że przypadek podstawowy zależy od przypadku włączanego.
Oznaczenie
-
Przerywana strzałka oznaczona jako<<zawieraj>> łączy przypadek podstawowy z przypadkiem włączanym.
Przykład 1: System internetowego sklepowania
Rozważmy system internetowego sklepowania, w którym klient możeZłożyć zamówienielubAnulować zamówienie. Oba przypadki użycia wymagają od klientaZalogować się do systemu.
-
Przypadki podstawowe: 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 biblioteki 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>>----> [Weryfikuj użytkownika]
[Zwróć książkę] ----<<include>>----> [Weryfikuj 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 używanej ponownie.
-
Gdy uwzględniony przypadek użycia ma sens samodzielnie (np. Zaloguj się lub Weryfikuj 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 rozszerzający przypadek użycia z podstawowym przypadkiem użycia, często z notatką określającą warunek lub punkt rozszerzenia.
Przykład 1: System bankomatu
W systemie bankomatu podstawowym przypadkiem użycia jestWypłata gotówki. Dodatkowe zachowanie, Drukowanie paragonu, może wystąpić, jeśli użytkownik poprosi o paragon.
-
Podstawowy przypadek użycia: Wypłata gotówki
-
Rozszerzający przypadek użycia: Drukowanie paragonu
-
Warunek: Użytkownik decyduje się na drukowanie 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 do kierowania ich użyciem:
|
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: Weryfikuje 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 weryfikacji 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 ze sobą.
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. Nadmierna liczba przypadków zawartych 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 schemat jest trudny do odczytania.
-
Rozwiązanie: Używaj tych relacji tylko wtedy, gdy zmniejszają nadmiarowość lub poprawiają czytelność.
-
-
Nieokreślone warunki rozszerzania:
-
Pułapka: Nie określanie 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 włączenia, który jest używany tylko przez jeden przypadek podstawowy.
-
Rozwiązanie: Upewnij się, że przypadek użycia do włączenia jest reużywalny lub znacznie upraszcza 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 wykorzystywanie poprzez wyodrębnianie wymaganych, współdzielonych zachowań, podczas gdyRozszerz relacja utrzymuje podstawowe przypadki użycia skupione poprzez modelowanie opcjonalnych lub warunkowych zachowań. 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 przewodnik 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.