Posted inUnified Modeling Language Use Case Modeling

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 includew 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 includew UML określa, że podstawowy przypadek użycia zawiera zachowanie innego przypadku użycia, zwanego przypadkiem include. Przypadek include reprezentuje sekwencję działań, która jest zawsze wykonywanajako część przepływu podstawowego przypadku użycia. Wizualnie relacja ta jest przedstawiona jako przerywana strzałka z otwartym zakończeniemwskazująca od podstawowego przypadku użycia do przypadku include, oznaczona stereotypem «include».

Relacja include jest podobna do wywołania podprogramu w programowaniu: podstawowy przypadek użycia „wywołuje” przypadek include w celu wykonania określonego zadania, wspierając modelowanie strukturalne i hierarchiczne. Wyodrębnienie wspólnych lub skomplikowanych zachowań w osobnych przypadkach użycia pozwala zmniejszyć powtarzalność, poprawić przejrzystość i ułatwić utrzymanie.

Zalety relacji include

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

  1. Odzyskiwanie wspólnych zachowań: Współdzielona funkcjonalność w wielu przypadkach użycia może być zamknięta w jednym przypadku include, eliminując nadmiarowość.

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

  3. Wymuszone wykonywanie: Przypadek include 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ść: Oddzielenie odpowiedzialności pozwala podstawowemu przypadkowi użycia skupić się na swoim unikalnym zachowaniu, podczas gdy przypadki include 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 sklepu internetowego

Rozważmy platformę internetowego sklepu, 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 „Zregaluj 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 do jednego 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 w czystej i utrzymywalnej formie.

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) muszą zostać dokonane tylko w jednym miejscu.

Przykład 4: System zarządzania szpitalem

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

  • Podstawowe przypadki użycia: „Zaplanuj wizytę”, „Anuluj wizytę”, „Przeprowadź ponowne planowanie 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. Włą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 «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»” od 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 nadmiernego rozdrabniania 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:

Korzyść

Wyjaśnienie

Odzyskiwanie wspólnych zachowań

Wyodrębnia wspólne funkcje, aby uniknąć powtarzania się w przypadkach użycia

Uproszczenie skomplikowanych przypadków użycia

Rozdziela duże przypadki użycia na mniejsze, łatwiejsze do zarządzania części

Wymagane wykonywanie

Przypadek użycia uwzględniony jest zawsze częścią podstawowego przypadku użycia, zapewniając jego kompletność

Modułowość i przejrzystość

Oddziela obowiązki, poprawia czytelność i utrzymywalność

Modelowanie strukturalne

Podobne do wywoływania podprogramów, wspierające projektowanie hierarchiczne

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 do utrzymania 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