Uproszczenie dużych diagramów przypadków użycia za pomocą relacji include

Wprowadzenie

W inżynierii oprogramowania diagramy przypadków użycia pomagają wizualizować interakcje między użytkownikami (aktorami) a systemem w celu zapisania jego wymagań funkcyjnych. W miarę jak systemy rosną, diagramy przypadków użycia mogą stać się trudne w obsłudze, wypełnione powtarzającymi się lub skomplikowanymi zachowaniami, które zakłócają zrozumienie podstawowej funkcjonalności systemu. Relacja include w UML rozwiązuje ten problem, pozwalając na wyodrębnienie wspólnych zachowań w ponownie używalnych, modułowych przypadkach użycia. Niniejszy artykuł omawia, jak relacje include upraszczają diagramy przypadków użycia, ich kluczowe korzyści oraz praktyczne przykłady ilustrujące ich użyteczność.

Co to jest relacja include?

Relacja include w UML określa, że podstawowy przypadek użycia zawiera zachowanie innego przypadku użycia, zwanego przypadkiem dołączonym. Przypadek dołączony reprezentuje sekwencję działań, która jest zawsze wykonywana jako część przepływu podstawowego przypadku użycia. Wizualnie relacja ta jest przedstawiona jako przerywana strzałka z otwartym zakończeniem wskazująca od podstawowego przypadku użycia do przypadku dołączonego, oznaczona stereotypem «include».

Relacja include jest podobna do wywołania podprogramu w programowaniu: podstawowy przypadek użycia „wywołuje” przypadek dołączony w celu wykonania określonego zadania, wspierając modelowanie strukturalne i hierarchiczne. Wyodrębniając wspólne lub skomplikowane zachowania w osobnych przypadkach użycia, relacje include zmniejszają powtarzalność, poprawiają przejrzystość i ułatwiają utrzymanie modelu.

Zalety relacji include

Relacje include oferują kilka zalet podczas modelowania dużych i skomplikowanych systemów:

1. Odzyskiwanie wspólnych zachowań: Funkcjonalność wspólna dla wielu przypadków użycia może być zamknięta w jednym przypadku dołączonym, eliminując nadmiarowość.

2. Uproszczenie skomplikowanych przypadków użycia: Duże przypadki użycia mogą być podzielone na mniejsze, łatwiejsze w zarządzaniu moduły, co sprawia, że diagram jest mniej zatłoczony.

3. Wymuszone wykonywanie: Przypadek dołączony jest zawsze wykonywany jako część podstawowego przypadku użycia, zapewniając kompletność bez przeciążania głównego przepływu szczegółami.

4. Poprawiona przejrzystość i utrzymywalność: Oddzielając obowiązki, podstawowy przypadek użycia skupia się na swoim unikalnym zachowaniu, podczas gdy przypadki dołączone obsługują ponownie używalne sekwencje, upraszczając aktualizacje.

5. Modelowanie strukturalne: Relacje include wspierają projektowanie hierarchiczne, podobne do podprogramów, co ułatwia zrozumienie i rozwój systemu.

Przykłady relacji include

Aby pokazać moc relacji include, rozważmy kilka praktycznych przykładów w różnych dziedzinach.

Przykład 1: System e-handlu

Rozważmy platformę e-handlu, w której użytkownicy mogą przeglądać produkty, dodawać przedmioty do koszyka i dokonywać zakupu. Wiele przypadków użycia, takich jak „Kup produkt”, „Zarezerwuj przedmiot” i „Podaruj przedmiot”, wymaga uwierzytelnienia użytkownika przed kontynuacją.

• Podstawowe przypadki użycia: „Kup produkt”, „Zarezerwuj przedmiot”, „Podaruj przedmiot”

• Dołączony przypadek użycia: „Zautoryzuj użytkownika”

Zamiast powtarzać kroki uwierzytelniania w każdym przypadku użycia, wyodrębniamy je w jednym przypadku użycia „Zautoryzuj użytkownika”. Ten dołączony przypadek użycia obsługuje zadania takie jak żądanie danych logowania i ich weryfikacja. Diagram przypadków użycia przedstawiłby:

• Punktowana strzałka od „Kup produkt” do „Zautoryzuj użytkownika” oznaczona jako „include”.

• Podobne strzałki od „Zarezerwuj przedmiot” i „Podaruj przedmiot” do „Zautoryzuj użytkownika”.

Ten podejście zmniejsza nadmiarowość, ponieważ logika uwierzytelniania jest zdefiniowana tylko raz i wykorzystywana w wielu przypadkach użycia, co utrzymuje diagram czysty i łatwy w utrzymaniu.

Przykład 2: System bankowy

W systemie bankowym klienci mogą wykonywać działania takie jak „Wypłać gotówkę”, „Wpłać pieniądze” i „Przelej środki”. Każdy z tych przypadków użycia wymaga weryfikacji konta klienta przed kontynuacją.

• Podstawowe przypadki użycia: „Wypłać gotówkę”, „Wpłać pieniądze”, „Przelej środki”

• Dołączony przypadek użycia: „Weryfikuj konto”

Przypadek użycia „Weryfikuj konto” sprawdza stan konta, saldok i uprawnienia. Poprzez dołączenie tego przypadku użycia do każdego z podstawowych przypadków użycia, diagram unika powtarzania logiki weryfikacji. Wizualna reprezentacja zawiera punktowane strzałki oznaczone jako „include” od każdego podstawowego przypadku użycia do „Weryfikuj konto”. Ta modularizacja upraszcza diagram i zapewnia spójne stosowanie weryfikacji konta.

Przykład 3: System zarządzania biblioteką

W systemie bibliotecznym użytkownicy mogą „Wypożyczyć książkę”, „Zwrócić książkę” lub „Zarezerwować książkę”. Każde z tych działań wymaga sprawdzenia dostępności książki.

• Podstawowe przypadki użycia: „Wypożyczyć książkę”, „Zwrócić książkę”, „Zarezerwować książkę”

• Dołączony przypadek użycia: „Sprawdź dostępność książki”

Przypadek użycia „Sprawdź dostępność książki” potwierdza, czy książka jest na stanie i nie jest zarezerwowana. Poprzez dołączenie tego przypadku użycia do podstawowych przypadków użycia, diagram pozostaje przejrzysty, a aktualizacje logiki sprawdzania dostępności (np. zintegrowanie nowego systemu inwentarzowego) wymagają zmian tylko w jednym miejscu.

Przykład 4: System zarządzania szpitalem

W systemie zarządzania szpitalem pacjenci mogą „Zaplanować wizytę”, „Anulować wizytę” lub „Przeprowadzić rezerwację wizyty”. Każdy z tych przypadków użycia wymaga weryfikacji tożsamości pacjenta.

• Podstawowe przypadki użycia: „Zaplanuj wizytę”, „Anuluj wizytę”, „Przeprowadź rezerwację wizyty”

• Dołączony przypadek użycia: „Weryfikuj tożsamość pacjenta”

Przypadek użycia „Weryfikuj tożsamość pacjenta” obsługuje zadania takie jak sprawdzenie numeru tożsamości pacjenta lub danych ubezpieczeniowych. Dołączenie tego przypadku użycia do podstawowych przypadków użycia zapewnia spójne wykonywanie weryfikacji tożsamości bez powtarzania kroków w diagramie. Punktowane strzałki oznaczone jako „include” łączą każdy podstawowy przypadek użycia z „Weryfikuj tożsamość pacjenta”, co zwiększa przejrzystość.

Przykład 5: Platforma e-learningowa

W platformie e-learningowym studenci mogą „Przeprowadzić test”, „Złożyć zadanie” lub „Zobaczyć oceny”. Każde z tych działań wymaga zalogowania się do systemu.

• Podstawowe przypadki użycia: „Przeprowadzić test”, „Złożyć zadanie”, „Zobaczyć oceny”

• Włączony przypadek użycia: „Zaloguj się”

Przypadek użycia „Zaloguj się” zawiera kroki uwierzytelniania użytkownika. Włączając go do przypadków użycia podstawowych, diagram unika powtarzania kroków logowania, co ułatwia jego zrozumienie i utrzymanie. Wizualna reprezentacja pokazuje przerywane strzałki oznaczone „«include»” wychodzące z każdego przypadku użycia podstawowego do „Zaloguj się”.

Wizualna reprezentacja w UML

W diagramach przypadków użycia UML relacja include jest przedstawiona następująco:

• Strzałka przerywana z otwartym zakończeniem strzałkiwskazuje od przypadku użycia podstawowego do przypadku użycia włączonego.

• Strzałka jest oznaczona stereotypem «include».

Na przykład w przykładzie zakupów online:

• Kup produkt → «include» → Zautoryzuj użytkownika

• Diagram jasno pokazuje, że „Zautoryzuj użytkownika” jest obowiązkową częścią przepływu „Kup produkt”.

Ta konwencja wizualna zapewnia, że zainteresowane strony mogą szybko zrozumieć relacje między przypadkami użycia i ich zależnościami.

Porównanie z relacjami extend

Warto zauważyć różnicę międzyinclude i extendrelacjami, aby uniknąć pomyłek:

• Include: Włączony przypadek użycia jestzawsze wykonywane jako część podstawowego przypadku użycia (obowiązkowe).

• Rozszerz: przypadki użycia rozszerzające toopcjonalne i wykonywane tylko w określonych warunkach.

Na przykład w systemie e-commerce „Zaloguj użytkownika” jest uwzględniony, ponieważ jest obowiązkowy, ale przypadek użycia, taki jak „Zastosuj kod rabatowy”, może być relacją rozszerzającą, ponieważ jest opcjonalny i zależy od tego, czy użytkownik ma ważny kod.

Najlepsze praktyki dotyczące używania relacji include

Aby maksymalnie wykorzystać korzyści z relacji include, rozważ następujące kwestie:

1. Identyfikuj wspólne zachowania: Szukaj sekwencji działań powtarzających się w wielu przypadkach użycia, takich jak uwierzytelnianie, walidacja lub rejestrowanie.

2. Zachowaj skupienie przypadków użycia uwzględnionych: Upewnij się, że przypadki użycia uwzględnione zawierają konkretne, ponownie używalne zachowania, a nie całe procesy.

3. Zrównowaguj modułowość i prostotę: Unikaj nadmiernej fragmentacji przypadków użycia, ponieważ zbyt wiele przypadków użycia uwzględnionych może utrudnić zrozumienie diagramu.

4. Używaj jasnych zasad nazewnictwa: Nadaj przypadkom użycia uwzględnionym nazwy odzwierciedlające ich cel (np. „Zaloguj użytkownika” zamiast „Proces logowania”), aby ułatwić czytanie.

5. Weryfikuj wymagane wykonywanie: Potwierdź, że przypadek użycia uwzględniony jest zawsze wymagany; w przeciwnym razie rozważ relację rozszerzającą.

Podsumowanie korzyści

Poniższa tabela podsumowuje kluczowe korzyści z relacji include:

Wnioski

Relacje include są fundamentem skutecznego modelowania przypadków użycia w UML, umożliwiając ponowne wykorzystanie i modularizację wspólnych, obowiązkowych zachowań. Przenosząc wspólne funkcje do dołączonych przypadków użycia, programiści mogą tworzyć czystsze, łatwiejsze w utrzymaniu diagramy, które są łatwiejsze do zrozumienia i aktualizacji. Przykłady przedstawione — od zakupów online po zarządzanie szpitalami — ilustrują zróżnicowanie stosowania relacji include w różnych dziedzinach. Wykorzystując ten mechanizm, zespoły mogą modelować złożone systemy z większą przejrzystością i efektywnością, co w końcu poprawia jakość ich projektów oprogramowania.

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 i 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 opisy przypadków 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.