Diagramy przypadków użycia UML jako kod z użyciem PlantUML i VPasCode

Diagram przypadków użycia UML pokazuje, co oferuje system i kto – lub co – z nim oddziałuje. W przepływie pracy diagram jako kod źródłem diagramu jest zwykły tekst: edytuj tekst, wygeneruj diagram i przechowuj źródło obok dokumentacji projektu.

PlantUML obsługuje diagramy przypadków użycia. Edytor VPasCode firmy Visual Paradigm zapewnia edytor i podgląd PlantUML, a także funkcje generowania i edycji diagramów wspomagane przez sztuczną inteligencję.

1. Co przekazuje diagram przypadków użycia

Diagramy przypadków użycia koncentrują się nazakresie systemu i celach użytkowników, a nie na krok po kroku mechanice przepływu pracy. Diagram zazwyczaj zawiera:

• Granica systemu:Prostokąt z nazwą modelowanego systemu.

• Aktora:Rola zewnętrzna wobec systemu, która z nim oddziałuje. Aktorami mogą być osoby, organizacje, urządzenia lub systemy zewnętrzne.

• Przypadek użycia:Możliwość lub cel zapewniany przez system, zazwyczaj przedstawiany jako owal i nazwany frazą czasownikową, np. „Złóż zamówienie”.

• Zależność (asocjacja):Linia pokazująca, że aktor uczestniczy w danym przypadku użycia.

• Zależności między przypadkami użycia:Włączenie, rozszerzenie i uogólnienie.

Aktorzy reprezentują role, a nie konkretne osoby. Zewnętrzna usługa płatności może być aktorem, jeśli oddziałuje z modelowanym systemem.

Diagramy przypadków użycia są przydatne do sprecyzowania zakresu systemu, omawiania wymagań z interesariuszami, identyfikowania zależności zewnętrznych oraz zapewnienia wspólnego przeglądu dla rozwoju i testowania. Łącz je z pisemnymi opisami przypadków użycia, gdy potrzebujesz szczegółów, takich jak warunki wstępne, główne kroki, alternatywne przepływy i wyniki.

2. Zależności na pierwszy rzut oka

• Zależność aktor–przypadek użycia:Zwykła linia wskazująca na interakcję.

• <<include>>:Przypadek użycia zawierający zawsze wykorzystuje zachowanie zawarte. Przerywana strzałka wskazujeod przypadku użycia zawierającego do przypadku użycia zawartego. Na przykład złożenie zamówienia może zawsze obejmować autoryzację płatności.

• <<extend>>:Przypadek użycia rozszerzający dodaje zachowanie do przypadku bazowego w określonym warunku. Przerywana strzałka wskazujeod przypadku użycia rozszerzającego do przypadku użycia bazowego. Na przykład zastosowanie promocji może rozszerzać składanie zamówienia.

• Uogólnienie: Specjalny aktor lub przypadek użycia dziedziczy po bardziej ogólnym. Ciągła linia z pustym trójkątem wskazuje na element ogólny.

Przydatne rozróżnienie: include oznacza wymagane zachowanie; extend oznacza warunkowe dodane zachowanie.

3. Podstawy PlantUML

Diagram PlantUML zaczyna się od @startuml i kończy się na @enduml. Deklaruj aktorów za pomocą actor, przypadków użycia za pomocą usecase oraz granice systemu za pomocą rectangle. Aliasy ułatwiają odwoływanie się do elementów w relacjach.

@startuml
left to right direction

actor Customer

rectangle "Online Store" {
  usecase "Browse products" as Browse
  usecase "Place order" as Place
}

Customer --> Browse
Customer --> Place
@enduml

kierunek od lewej do prawej prosi PlantUML o ułożenie diagramu poziomo. PlantUML może dostosować dokładny układ w miarę zmian diagramu.

4. Przykład: podstawowy sklep internetowy

@startuml
kierunek z lewej do prawej

aktor Klient
aktor Administrator jako Admin

prostokąt "Sklep internetowy" {
  przypadki użycia "Przeglądaj produkty" jako Browse
  przypadki użycia "Złóż zamówienie" jako Place
  przypadki użycia "Śledź przesyłkę" jako Track
  przypadki użycia "Zarządzaj katalogiem" jako Manage
}

Klient --> Browse
Klient --> Place
Klient --> Track
Admin --> Manage
@enduml

Klienci przeglądają, składają zamówienia i śledzą przesyłki. Administrator zarządza katalogiem. Diagram celowo pomija wewnętrzne kroki przetwarzania zamówienia.

5. Przykład: include i extend

Załóżmy, że złożenie zamówienia zawsze wymaga autoryzacji płatności, podczas gdy zastosowanie promocji jest opcjonalne i warunkowe.

@startuml
kierunek z lewej do prawej

aktor Klient

prostokąt "Sklep internetowy" {
  przypadki użycia "Złóż zamówienie" jako Place
  przypadki użycia "Autoryzuj płatność" jako Payment
  przypadki użycia "Zastosuj promocję" jako Promotion
}

Klient --> Place

Place ..> Payment : <<include>>
Promotion ..> Place : <<extend>>
@enduml

Strzałka Place ..> Payment oznacza, że „Złóż zamówienie” zawiera wymaganą zachowanie płatności. Strzałka Promotion ..> Place oznacza, że „Zastosuj promocję” rozszerza „Złóż zamówienie”, gdy spełniony jest jej warunek.

Dokumentuj warunek – na przykład „klient wprowadza poprawny kod promocyjny” – w opisie przypadku użycia lub w notatce.

6. Przykład: uogólnienie aktora i systemy zewnętrzne

Specjalistyczny aktor dziedziczy interakcje z bardziej ogólnego aktora. Usługi zewnętrzne również mogą być aktorami, gdy wchodzą w interakcję z systemem.

@startuml
kierunek z lewej do prawej

aktor "Użytkownik" jako User
aktor "Zarejestrowany klient" jako Customer
aktor "Brama płatności" jako Gateway

Customer --|> User

prostokąt "Sklep internetowy" {
  przypadki użycia "Przeglądaj produkty" jako Browse
  przypadki użycia "Złóż zamówienie" jako Place
  przypadki użycia "Przetwórz płatność" jako Pay
}

User --> Browse
Customer --> Place
Place ..> Pay : <<include>>
Gateway --> Pay
@enduml

„Zarejestrowany klient” jest specjalizacją „Użytkownika” i dziedziczy ogólną interakcję użytkownika. Bramka płatności znajduje się poza granicami Sklepu Internetowego, ale uczestniczy w przypadku użycia płatności.

7. Przykład: uogólnienie przypadku użycia

Uogólnienie może reprezentować specjalistyczne wersje szerszego przypadku użycia. Pusty trójkąt wskazuje w kierunku ogólnego przypadku użycia.

@startuml
kierunek od lewej do prawej

aktor Klient

prostokąt "System płatności" {
  usecase "Wykonaj płatność" jako Płatność
  usecase "Zapłać kartą" jako Karta
  usecase "Zapłać przelewem" jako Przelew
}

Klient --> Karta
Klient --> Przelew

Karta --|> Płatność
Przelew --|> Płatność
@enduml

Użyj tego, gdy specjalistyczne przypadki użycia mają wspólny ogólny cel, ale posiadają istotne różnice. Jeśli różnice stanowią jedynie warunki kroków, to <<rozszerzenie>>relacji lub opis przypadku użycia w formie tekstowej może być bardziej przejrzysty.

8. Praca w VPasCode

Praktyczny przepływ pracy:

1. Zdefiniuj zakres.Zidentyfikuj granice systemu, role aktorów oraz cele, jakie każdy z aktorów chce osiągnąć.

2. Stwórz szkic.Napisz kod PlantUML bezpośrednio lub poproś asystenta AI o wygenerowanie diagramu przypadków użycia.

3. Przejrzyj kod i podgląd.Potwierdź, że aktorzy znajdują się poza granicami systemu, przypadki użycia są wewnątrz, a strzałki wskazują w odpowiednim kierunku.

4. Udoskonal model.Zastąp niejasne nazwy, usuń szczegóły implementacyjne i dodawaj relacje tylko wtedy, gdy odzwierciedlają one rzeczywiste wymagania.

5. Zażądaj ukierunkowanych edycji przez AI.Na przykład: „Dodaj aktora zewnętrznego bramki płatności i pokaż wymaganą interakcję płatności za pomocą relacji include. Pozostałą część pozostaw bez zmian.”

6. Zweryfikuj z interesariuszami.Sprawdź, czy diagram odzwierciedla rzeczywisty zakres systemu i cele użytkowników.

7. Zapisz źródło. Zachowaj .puml tekst wraz z dokumentacją projektu lub w systemie kontroli wersji. Eksportuj obraz, gdy jest to potrzebne do dokumentów lub prezentacji.

Przykładowe polecenie dla asystenta AI

Stwórz diagram przypadków użycia UML w PlantUML dla sklepu internetowego. Uwzględnij granicę systemu, aktorów Klient i Administrator oraz cele: Przeglądaj produkty, Złóż zamówienie, Śledź przesyłkę i Zarządzaj katalogiem. Pokaż autoryzację płatności jako wymagane zachowanie zawarte w przypadku użycia Złóż zamówienie. Pokaż zastosowanie promocji jako warunkowe rozszerzenie przypadku użycia Złóż zamówienie. Zwróć tylko poprawne źródło PlantUML.

Traktuj kod wygenerowany przez AI jako szkic. Przed użyciem sprawdź aktorów, granice, relacje i założenia biznesowe.

9. Typowe błędy

• Modelowanie wewnętrznych komponentów jako aktorów: Aktorzy powinni być zewnętrznymi rolami lub systemami, które wchodzą w interakcję z przedmiotem.

• Nazywanie przypadków użycia jako zadań implementacyjnych: Preferuj „Śledź przesyłkę” zamiast „Wywołaj API śledzenia.”

• Używanie <<include>> do zachowań opcjonalnych: Include reprezentuje zachowanie, które jest wymagane przez bazowy przypadek użycia.

• Odwracanie strzałek relacji: Include wskazuje na włączony przypadek użycia; extend wskazuje na bazowy przypadek użycia.

• Przeładowanie jednego diagramu szczegółami: Użyj diagramu wysokiego poziomu dla zakresu, a następnie oddzielnych diagramów lub tekstu dla szczegółowych scenariuszy.

• Zakładanie, że poprawne wyrenderowanie oznacza poprawność modelu: PlantUML może wyrenderować diagram, który nadal nieprawidłowo przedstawia wymagania.

10. Lista kontrolna przeglądu

Przed udostępnieniem diagramu potwierdź, że:

• Granica systemu jest jasna.

• Każdy aktor jest zewnętrzny i reprezentuje rolę.

• Nazwy przypadków użycia opisują sensowne cele.

• Asocjacje aktorów odzwierciedlają rzeczywiste interakcje.

• Relacje include są wymagane; relacje extend są warunkowe lub w inny sposób uzasadnione.

• Strzałki generalizacji wskazują na ogólnego aktora lub przypadek użycia.

• Diagram pozostaje czytelny w zamierzonym rozmiarze.

• Założenia wygenerowane przez sztuczną inteligencję zostały zweryfikowane z osobami zaznajomionymi z wymaganiami.

Ten post dostępny jest również w Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Portuguese, Ру́сский, Việt Nam and 繁體中文