Przewodnik po diagramach przypadków użycia PlantUML

Wstęp

Użyj przypadek diagramy zapewniają jasny sposób do opisania jak użytkownicy, zewnętrzne systemy, i inne aktorzy współdziałają z systemem oprogramowania systemu. Pomagają zespołom określać zakres systemu, identyfikować zidentyfikować funkcjonalne wymagania, i komunikować oczekiwane zachowanie przed wdrożeniem zacznie się.

PlantUML czyni korzystanie modelowania przypadków użycia modelowania praktycznym przez a tekstowy składnia która może być przechowywana, przeglądana, wersjonowana, i regenerowana obok projektu dokumentacji lub źródło kod. Z kilku kilkoma poleceniami, możesz zdefiniować aktorów, scenariuszy użycia, systemu, granic systemu, granic, asocjacje, <<include>> zależności, <<extend>> zależności, ogólnienie, uwagi, i układ preferencji.

Ten przewodnik wyjaśnia kluczowe aspekty PlantUML użyj przypadek notacja pokazana w arkuszu referencyjnym i wykazuje jak zastosować ją w realistyczne przykłady. Ono również wprowadza szersze szersze narzędzia przepływ pracy z wykorzystaniem Visual Paradigm UML, wspierane przez AI modeling, i VPasCode. Razem, te narzędzia wspierają cały proces: proces: przekształcanie wymagań w początkowy początkowy modelu, walidacji UML zależności, udoskonalania modelu i utrzymywania końcowego modelu jako czytelny diagram źródło.

Diagram przypadków użycia UML opisuje, jak zewnętrzni użytkownicy lub systemy interagują z systemem. Skupia się on na co system robi, a nie na tym, jak jest zaimplementowany.

PlantUML pozwala tworzyć diagramy przypadków użycia za pomocą prostego notowania tekstowego.

1. Podstawowa struktura PlantUML

Każdy diagram PlantUML zaczyna się od @startuml i kończy się na @enduml.

@startuml

' Treść diagramu znajduje się tutaj

@enduml

Komentarze zaczynają się od apostrofu:

' To jest komentarz

Możesz również używać komentarzy wieloliniowych:

/'
To jest
wielowierszowy komentarz
'/

2. Definiowanie aktorów

Aktor reprezentuje osobę, rolę, organizację, urządzenie lub zewnętrzny system, który oddziałuje z Twoim systemem.

Podstawowy aktor

aktor User

To tworzy aktora w postaci patyczka o nazwie Użytkownik.

Aktor z aliasem

Alias są przydatne, gdy wyświetlana nazwa zawiera spacje lub gdy chcesz użyć krótszego identyfikatora dla relacji.

aktor "Brama płatności" jako payment
aktor "Administrator systemu" jako admin

Następnie możesz odwoływać się do aliasów:

payment --> ProcessPayment
admin --> ManageUsers

Aktor używający innego stylu wizualnego

PlantUML obsługuje kilka stylów aktorów. Domyślny styl zazwyczaj wystarcza, ale możesz użyć aktora w stylu ikony:

skinparam actorStyle awesome

actor Customer

Możesz również użyć aktora w prostym stylu prostokąta:

skinparam actorStyle hollow

actor Customer

Dokładny wygląd zależy od silnika renderowania PlantUML oraz parametrów motywu.

3. Definiowanie przypadków użycia

Przypadek użycia reprezentuje usługę, cel lub funkcję dostarczaną przez system.

Podstawowy przypadek użycia

usecase "Zaloguj się"

PlantUML renderuje to jako elipsę z etykietą Zaloguj się.

Przypadek użycia z aliasem

usecase "Przetwórz płatność kartą kredytową" jako ProcessPayment

Widoczna etykieta to Przetwórz płatność kartą kredytową, podczas gdy ProcessPayment jest używane w relacjach.

aktor Klient
Klient --> ProcessPayment

Wielowierszowe nazwy przypadków użycia

Możesz wstawić przełamanie wiersza używając n:

usecase "Przetwarzanienpłatnościnkartąnkredytową" jako ProcessPayment

Jest to przydatne, gdy diagram zawiera długie etykiety.

4. Granice systemu

Granica systemu grupuje przypadki użycia należące do danego systemu.

rectangle "System zakupów online" {
    usecase "Przeglądanie produktów" jako Browse
    usecase "Kasacja" jako Checkout
}

Prostokąt reprezentuje system, a przypadki użycia wewnątrz niego reprezentują funkcjonalności dostarczane przez ten system.

Możesz również użyć nazwanej aliasu dla granicy:

rectangle "System Zakupów Online" jako OnlineStore {
    usecase "Przeglądaj Produkty" jako Browse
    usecase "Kasacja" jako Checkout
}

Granica systemu jest przydatna przy rozróżnianiu zachowania systemu od zewnętrznych aktorów i usług.

5. Łączenie aktorów i przypadków użycia

Asocjacja pokazuje, że aktor bierze udział w przypadku użycia lub wchodzi z nim w interakcję.

Asocjacja bezkierunkowa

Klient -- Przeglądaj

Tworzy to ciągłą linię bez główki strzałki.

Asocjacja skierowana

Klient --> Przeglądaj

Tworzy to ciągłą linię ze strzałką wskazującą w stronę przypadku użycia.

Obie formy są powszechnie stosowane. Kierunek strzałki należy wybierać konsekwentnie w zależności od komunikacji lub odpowiedzialności, którą chcesz podkreślić.

Asocjacja z etykietą

Klient --> Kasa : start

Etykieta opisuje interakcję.

Klient --> WyświetlZamówienia : wyświetla historię zamówień

Dla bardziej czytelnej układu możesz użyć dłuższej strzałki:

Klient ---> Kasa : rozpoczyna

6. The <<include>> relacja

An włączrelacja reprezentuje zachowanie, które jest zawsze wymagane przez inny przypadek użycia.

Na przykład złożenie zamówienia może zawsze wymagać walidacji płatności:

PlaceOrder ..> ValidatePayment : <<include>>

Kierunek jest ważny:

Podstawowy przypadek użycia ..> Włączony przypadek użycia : <<include>>

Strzałka wskazuje od przypadku użycia, który potrzebuje zachowania, do przypadku użycia, który zapewnia ponownie używalne zachowanie.

Przykład

usecase "Kasacja" jako Kasacja
usecase "Walidacja danych klienta" jako WalidacjaKlienta
usecase "Obliczenie całkowitej wartości zamówienia" jako ObliczenieSumy
usecase "Wykonanie płatności" jako WykonaniePłatności

Kasacja ..> WalidacjaKlienta : <<include>>
Kasacja ..> ObliczenieSumy : <<include>>
Kasacja ..> WykonaniePłatności : <<include>>

Oznacza to:

1. Kasacja zawsze waliduje dane klienta.

2. Kasacja zawsze oblicza całkowitą wartość zamówienia.

3. Kasacja zawsze wykonuje płatność.

Użyj <<include>> gdy włączona zachowanie jest obowiązkowe lub wielokrotnego użytku.

7. The <<extend>> zależność

Zależność extend zależność reprezentuje opcjonalne, warunkowe lub wyjątkowe zachowanie dodane do podstawowego przypadku użycia.

Na przykład zastosowanie rabatu może nastąpić tylko wtedy, gdy klient posiada ważny kupon:

ApplyDiscount ..> Checkout : <<extend>>

Kierunek jest następujący:

Opcjonalny przypadek rozszerzający ..> Podstawowy przypadek : <<extend>>

Strzałka wskazuje z zachowania opcjonalnegodo podstawowego przypadku użycia.

Poprawny przykład

usecase "Kasacja" jako Kasacja
usecase "Zastosuj kupon rabatowy" jako ZastosujKupon

ZastosujKupon ..> Kasacja : <<extend>>

Oznacza to, żeZastosuj kupon rabatowyopcjonalnie rozszerzaZakończ zakup proces.

Porównanie włączenia i rozszerzenia

Przykład:

Checkout ..> ValidatePayment : <<include>>
ApplyDiscount ..> Checkout : <<extend>>

Unikaj odwracania tych relacji, ponieważ kierunek zmienia ich znaczenie.

8. Uogólnienie przypadków użycia

Uogólnienie pokazuje, że jeden przypadek użycia jest specjalną formą innego przypadku użycia.

usecase "Szukaj produktów" jako SearchProducts
usecase "Przeglądaj produkty" jako BrowseProducts

SearchProducts -|> BrowseProducts

Pusty trójkąt wskazuje na bardziej ogólny przypadek użycia.

Oznacza to, że Szukaj produktów jest wyspecjalizowaną wariacją Przeglądaj produkty.

Uogólnienie jest mniej powszechne niż zawiera i rozszerza, więc używaj go tylko wtedy, gdy istnieje rzeczywista relacja rodzic-dziecko między przypadkami użycia.

9. Uogólnienie aktora

Aktorzy mogą również mieć relacje uogólnienia.

aktor Klient
aktor "Klient Premium" jako PremiumCustomer

PremiumCustomer -|> Klient

Oznacza to, że klient premium jest wyspecjalizowanym typem klienta i dziedziczy interakcje ogólnego aktora.

Na przykład:

PremiumCustomer --> ZastosujRabat

10. Notatki i adnotacje

Notatki dodają objaśnienia lub ograniczenia do diagramu.

Notatka dołączona do przypadku użycia

note right of Checkout
  Klient musi podać
  poprawne dane rozliczeniowe.
end note

Inne pozycje obejmują:

note left of Checkout
  Proces skierowany do klienta
end note

note top of Checkout
  Główny przepływ biznesowy
end note

note bottom of Checkout
  Obejmuje przetwarzanie płatności
end note

Składnia krótkiej notatki

notatka po prawej stronie Login : Wymagane uwierzytelnienie użytkownika

Samodzielna notatka z aliasem

notatka "Płatność musi być autoryzowananzanim zostanie potwierdzony zamówienie" jako PaymentNote

Połącz notatkę z elementem za pomocą przerywanej linii:

PaymentNote .. MakePayment

Notatki dotyczące ograniczeń

Notatki są przydatne do dokumentowania warunków:

notatka po prawej stronie ApplyDiscount
  Opcjonalne zachowanie:
  używane tylko wtedy, gdy
  podano ważny kod rabatowy.
koniec notatki

11. Kierunek układu

Domyślnie PlantUML automatycznie wybiera układ. Możesz wpływać na kierunek.

Układ od lewej do prawej

kierunek od lewej do prawej

Jest to często przydatne w diagramach przypadków użycia, ponieważ aktorzy pojawiają się po lewej stronie, a systemy zewnętrzne po prawej.

Układ od góry do dołu

kierunek od góry do dołu

Może to być przydatne dla zwartych diagramów lub procesów zorganizowanych pionowo.

Niewidoczne połączenia układu

Niewidoczne połączenie może wpływać na pozycjonowanie bez wyświetlania widocznej relacji:

Klient -[ukryty]-> Kasa

Jest to przydatne w celu poprawy układu diagramu.

12. Stylizacja diagramu

Usuń cienie

skinparam shadowing false

Użyj prostokątnych pakietów i granic

skinparam packageStyle rectangle

Ustaw kolory

skinparam usecase {
    BackgroundColor #FDFDFD
    BorderColor #333333
}

skinparam actor {
    BorderColor #333333
}

Ustaw kolory strzałek

skinparam ArrowColor #555555

Ustaw domyślny rozmiar czcionki

skinparam defaultFontSize 14

Kompletna sekcja stylizacji może wyglądać następująco:

skinparam shadowing false
skinparam packageStyle rectangle
skinparam actorStyle awesome
skinparam defaultFontSize 14

skinparam usecase {
    BackgroundColor #F9FBFF
    BorderColor #234
}

skinparam ArrowColor #555555

13. Pakiety i grupowanie

Pakiety mogą grupować powiązane przypadki użycia.

package "Funkcje klienta" {
    usecase "Zarejestruj konto" as Register
    usecase "Zaloguj się" as Login
    usecase "Przeglądaj produkty" as Browse
}

package "Funkcje administracyjne" {
    usecase "Zarządzaj produktami" as ManageProducts
    usecase "Generuj raport sprzedaży" as SalesReport
}

Pakiety są przydatne, gdy diagram zawiera wiele przypadków użycia.

Możesz również użyć prostokąta jako grupy:

rectangle "Zarządzanie zamówieniami" {
    usecase "Złóż zamówienie" as PlaceOrder
    usecase "Śledź zamówienie" as TrackOrder
    usecase "Anuluj zamówienie" as CancelOrder
}

14. Systemy zewnętrzne

Zewnętrzne aplikacje lub usługi mogą być reprezentowane jako aktorzy.

aktor "Brama płatności" jako PaymentGateway
aktor "Usługa e-mail" jako EmailService
aktor "Zewnętrzny system CRM" jako CRM

Połącz je z przypadkami użycia systemu:

PaymentGateway --> MakePayment
EmailService --> SendConfirmation
CRM --> SynchronizeCustomer

To wyraźnie oddziela funkcjonalność systemu od usług znajdujących się poza granicami systemu.

15. Kompletny przykład

Poniższy przykład łączy główne notacje z arkusza referencyjnego.

@startuml
title System Zakupów Online - Diagram Przypadków Użycia

kierunek od lewej do prawej

skinparam shadowing false
skinparam packageStyle rectangle
skinparam actorStyle awesome

skinparam usecase {
    BackgroundColor #F9FBFF
    BorderColor #333333
}

skinparam ArrowColor #555555

' Aktorzy
actor Klient as klient
actor "Klient Premium" as premium
actor Administrator jako admin
actor "Brama Płatnościowa" jako payment
actor "Usługa E-mail" jako email

' Generalizacja aktorów
premium -|> klient

' Granica systemu
rectangle "System Zakupów Online" {

    ' Przypadki użycia klienta
    usecase "Zarejestruj Konto" jako Register
    usecase "Zaloguj się" jako Login
    usecase "Przeglądaj Produkty" jako Browse
    usecase "Szukaj Produktów" jako Search
    usecase "Zobacz Szczegóły Produktu" jako ViewProduct
    usecase "Dodaj Produkt do Koszyka" jako AddToCart
    usecase "Zobacz Koszyk Zakupowy" jako ViewCart
    usecase "Zakończ Zakup" jako Checkout
    usecase "Złóż Zamówienie" jako PlaceOrder
    usecase "Śledź Zamówienie" jako TrackOrder
    usecase "Anuluj Zamówienie" jako CancelOrder

    ' Wspólne zachowania włączone
    usecase "Zweryfikuj Dane Klienta" jako ValidateCustomer
    usecase "Oblicz Całkowitą Kwotę Zamówienia" jako CalculateTotal
    usecase "Wykonaj Płatność" jako MakePayment
    usecase "Wyślij Potwierdzenie Zamówienia" jako SendConfirmation

    ' Zachowania opcjonalne
    usecase "Zastosuj Kod Rabatowy" jako ApplyDiscount
    usecase "Zażądaj Zwrotu Środków" jako RequestRefund

    ' Przypadki użycia administracyjne
    usecase "Zarządzaj Produktami" jako ManageProducts
    usecase "Wygeneruj Raport Sprzedaży" jako SalesReport
}

' Asocjacje aktorów
klient --> Register
klient --> Login
klient --> Browse
klient --> Search
klient --> ViewProduct
klient --> AddToCart
klient --> ViewCart
klient --> Checkout
klient --> TrackOrder
klient --> CancelOrder

premium --> ApplyDiscount
premium --> RequestRefund

admin --> ManageProducts
admin --> SalesReport

payment --> MakePayment
email --> SendConfirmation

' Relacje włączenia
Checkout ..> ValidateCustomer : <<include>>
Checkout ..> CalculateTotal : <<include>>
Checkout ..> PlaceOrder : <<include>>

PlaceOrder ..> MakePayment : <<include>>
PlaceOrder ..> SendConfirmation : <<include>>

' Relacje rozszerzenia
ApplyDiscount ..> Checkout : <<extend>>
RequestRefund ..> CancelOrder : <<extend>>

' Generalizacja przypadków użycia
Search -|> Browse

' Notatki
note right of Checkout
    Główny proces zakupowy klienta
end note

note right of ApplyDiscount
    Zachowanie opcjonalne:
    używane tylko wtedy, gdy dostępny jest ważny
    kod rabatowy
end note

note bottom of MakePayment
    Płatność obsługiwana jest przez
    zewnętrzną bramę płatnościową
end note

@enduml

16. Czytanie kompletnego przykładu

Diagram przedstawia następujące informacje:

• Klient może przeglądać produkty, dodawać produkty do koszyka i dokonywać zakupu.

• Klient Premium jest specjalizowaną formą Klient.

• Kasazawsze obejmuje weryfikację klienta, obliczenie całkowitej kwoty i złożenie zamówienia.

• Złóż zamówieniezawsze obejmuje płatność i potwierdzenie.

• Zastosuj kupon rabatowyjest opcjonalne i przedłuża proces kasy.

• Zażądaj zwrotujest opcjonalnym rozszerzeniem anulowania.

• Brama płatności obsługuje przetwarzanie płatności.

• Usługa e-mail wysyła potwierdzenia zamówień.

• Administrator zarządza produktami i generuje raporty.

17. Typowe błędy

Cofaniedołącz

Niepoprawnie:

ValidateCustomer ..> Checkout : <<dołącz>>

Poprawnie:

Checkout ..> ValidateCustomer : <<dołącz>>

Podstawowy scenariusz użycia wskazuje na wymagane zachowanie włączone.

Odwracanierozszerz

Niepoprawnie:

Kasa ..> ZastosujRabat : <<extend>>

Poprawnie:

ApplyDiscount ..> Checkout : <<extend>>

Opcjonalny przypadki użycia rozszerzający wskazuje na bazowy przypadek użycia.

Używając include dla zachowania opcjonalnego

Jeśli zachowanie występuje tylko w określonych warunkach, użyj <<extend>>:

ApplyDiscount ..> Checkout : <<extend>>

Jeśli zawsze się to dzieje, użyj <<include>>:

Checkout ..> ValidateCustomer : <<include>>

Umieszczanie aktorów zewnętrznych wewnątrz granic systemu

Zewnętrzni użytkownicy i usługi powinny zazwyczaj znajdować się poza prostokątem:

aktor Klient

prostokąt "System zakupowy" {
    przypadki użycia "Kasowanie" jako Kasowanie
}

Klient --> Kasowanie

Tworzenie zbyt szczegółowych przypadków użycia

Przypadek użycia powinien opisywać znaczący cel użytkownika, taki jak:

usecase "Złóż zamówienie"

Unikaj zamieniania każdego małego kroku implementacji na osobny przypadek użycia, chyba że jest on wielokrotnie wykorzystywany, opcjonalny lub istotny dla modelu.

18. Minimalny szablon praktyczny

Dla mniejszego diagramu użyj tego szablonu:

@startuml

kierunek od lewej do prawej

aktor User

rectangle "Mój system" {
    usecase "Główny cel użytkownika" jako MainGoal
    usecase "Wymagane wspólne zachowanie" jako SharedBehavior
    usecase "Zachowanie opcjonalne" jako OptionalBehavior
}

User --> MainGoal

MainGoal ..> SharedBehavior : <<include>>
OptionalBehavior ..> MainGoal : <<extend>>

notatka po prawej stronie MainGoal
    Główna funkcja systemu
koniec notatki

@enduml

Ten szablon zawiera podstawową notację:

• Aktor

• Granica systemu

• Scenariusze użycia

• Asocjacja

• Zawiera

• Rozszerza

• Uwaga

• Kierunek układu

Narzędzia: Visual Paradigm UML, AI oraz VPasCode

PlantUML jest idealny do tworzenia diagramów w formie tekstu, ale narzędzia do modelowania wizualnego mogą sprawić, że ten sam przepływ pracy będzie łatwiejszy do przeglądu, dopracowania i udostępnienia. Visual Paradigm oferuje możliwości modelowania UML wraz z modelowaniem wspieranym przez AI oraz środowiskiem pracy VPasCode opartym na tekście. Jego platforma obsługuje standardowe diagramy UML, w tym diagramy scenariuszy użycia, klas, sekwencji, aktywności, komponentów, wdrożenia, maszyn stanów, pakietów i obiektów.

Modelowanie UML w Visual Paradigm

Visual Paradigm można wykorzystać, gdy chcesz tworzyć diagram scenariuszy użycia wizualnie, zamiast ręcznie wpisywać całą składnię. Typowy przepływ pracy wygląda następująco:

1. Utwórz projekt UML.

2. Dodaj diagram scenariuszy użycia.

3. Umieść aktorów i scenariusze użycia na płótnie.

4. Narysuj granicę systemu.

5. Połącz aktorów z przypadkami użycia.

6. Dodaj zawieranie, rozszerzenieoraz relacje uogólnienia.

7. Dodaj notatki i ograniczenia.

8. Ułóż i wyeksportuj gotowy diagram.

Modelowanie wizualne jest szczególnie przydatne, gdy interesariusze potrzebują interaktywnego przeglądu diagramu. Członkowie zespołu mogą badać symbole, omawiać konkretne elementy i wspólnie notować diagramy.

Ręcznie stworzony diagram przypadków użycia może zawierać:

• Aktorzy tacy jak Klient, Administratororaz Brama płatności

• Granica systemu, taka jak System zakupów online

• Scenariusze użycia, takie jak Kasa, Złóż zamówienie, oraz Śledź zamówienie

• <<include>> relacje dla obowiązkowego, wielokrotnego użycia zachowania

• <<extend>> relacje dla opcjonalnego zachowania

• Relacje uogólnienia dla wyspecjalizowanych aktorów lub scenariuszy użycia

Model wizualny powinien zachować te same reguły semantyczne używane w PlantUML:

Checkout ..> ValidatePayment : <<include>>
ApplyDiscount ..> Checkout : <<extend>>
PremiumCustomer -|> Customer

Kluczowa różnica polega na tym, że zmiana narzędzia nie zmienia znaczenia UML. Niezależnie od tego, czy diagram został stworzony ręcznie, wygenerowany przez AI, czy napisany w PlantUML, kierunek relacji musi pozostać poprawny.

Modelowanie wspomagane przez AI

Możliwości AI w Visual Paradigm mogą pomóc przekształcić wymagania sformułowane w języku naturalnym na elementy modelu i diagramy. Platforma opisuje swoje funkcje AI jako zdolne do przekształcania wymagań w diagramy oraz generowania artefaktów związanych z rozwojem oprogramowania na podstawie opisów tekstowych.

Na przykład możesz podać następujące wymaganie:

Stwórz diagram przypadków użycia dla systemu zakupów online.

Aktory:
- Klient
- Klient Premium
- Administrator
- Bramka płatności
- Usługa e-mail

Klient może się zarejestrować, zalogować, przeglądać produkty, dodawać produkty do koszyka,
dokonywać zakupu, śledzić zamówienia i anulować zamówienia.

Proces zakupu musi obejmować weryfikację klienta, obliczenie całkowitej kwoty, płatność
i potwierdzenie zamówienia.

Zastosowanie kuponu rabatowego jest opcjonalne i rozszerza proces zakupu.
Klient Premium jest specjalnym typem Klienta.

Narzędzie wspomagane przez AI może wykorzystać ten opis, aby zaproponować:

• Definicje aktorów

• Nazwy przypadków użycia

• Granice systemu

• Asocjacje

• Włączone przypadki użycia

• Rozszerzone przypadki użycia

• Uogólnienie aktorów

• Notatki opisujące reguły biznesowe

AI jest najbardziej przydatne podczas pierwszego przejścia modelowania. Może szybko wygenerować szkic na podstawie wymagań, zidentyfikować kandydujących aktorów i zasugerować zachowania wielokrotnego użytku. Powstały model powinien nadal być przeglądany przez programistę, analityka lub eksperta dziedzinowego.

Zalecana lista kontrolna przeglądu AI

Po wygenerowaniu diagramu sprawdź:

• Każdy aktor znajduje się poza granicami systemu.

• Każdy przypadek użycia opisuje istotny cel użytkownika lub usługę systemu.

• Obowiązkowe zachowania wielokrotnego użytku wykorzystują<<include>>.

• Opcjonalne lub warunkowe zachowania wykorzystują<<extend>>.

• Strzałkaincludekieruje się od przypadku użycia bazowego do przypadku użycia włączonego.

• StrzałkarozszerzanieStrzałka wskazuje od przypadku użycia rozszerzającego do przypadku użycia bazowego.

• Strzałki uogólnienia wskazują w kierunku bardziej ogólnego aktora lub przypadku użycia.

• Usunięto duplikaty lub zbyt szczegółowe przypadki użycia.

• Nazwy są spójnie wyrażane jako zwroty czasownikowe.

• Diagram jasno komunikuje zakres systemu.

VPasCode: modelowanie za pomocą tekstu

VPasCode zapewnia środowisko pracy do tworzenia diagramów z tekstu w ekosystemie Visual Paradigm. Oficjalna platforma opisuje je jako darmowy online’owy edytor tekstowy do tworzenia diagramów, a także przedstawia je jako sposób na przekształcanie kodu w diagramy.

Dzięki temu VPasCode jest przydatny dla użytkowników, którzy preferują precyzję i powtarzalność diagramów jako kodu, jednocześnie pracując w środowisku modelowania wizualnego.

Diagram przypadków użycia PlantUML można zapisać następująco:

@startuml
tytuł System Zakupów Online

kierunek od lewej do prawej

aktor Klient jako customer
aktor "Klient Premium" jako premium
aktor Administrator jako admin
aktor "Brama Płatnościowa" jako payment
aktor "Usługa E-mailowa" jako email

premium -|> customer

rectangle "System Zakupów Online" {
    usecase "Zarejestruj Konto" jako Register
    usecase "Zaloguj się" jako Login
    usecase "Przeglądaj Produkty" jako Browse
    usecase "Zakończ Zakup" jako Checkout
    usecase "Złóż Zamówienie" jako PlaceOrder
    usecase "Śledź Zamówienie" jako TrackOrder
    usecase "Anuluj Zamówienie" jako CancelOrder

    usecase "Zweryfikuj Dane Klienta" jako ValidateCustomer
    usecase "Oblicz Całkowitą Kwotę Zamówienia" jako CalculateTotal
    usecase "Wykonaj Płatność" jako MakePayment
    usecase "Wyślij Potwierdzenie Zamówienia" jako SendConfirmation

    usecase "Zastosuj Kod Rabatowy" jako ApplyDiscount
    usecase "Zażądaj Zwrotu Środków" jako RequestRefund

    usecase "Zarządzaj Produktami" jako ManageProducts
}

customer --> Register
customer --> Login
customer --> Browse
customer --> Checkout
customer --> TrackOrder
customer --> CancelOrder

premium --> ApplyDiscount
premium --> RequestRefund

admin --> ManageProducts
payment --> MakePayment
email --> SendConfirmation

Checkout ..> ValidateCustomer : <<include>>
Checkout ..> CalculateTotal : <<include>>
Checkout ..> PlaceOrder : <<include>>

PlaceOrder ..> MakePayment : <<include>>
PlaceOrder ..> SendConfirmation : <<include>>

ApplyDiscount ..> Checkout : <<extend>>
RequestRefund ..> CancelOrder : <<extend>>

@enduml

Ten sam model można udoskonalić na kilka sposobów:

• Zmień kierunek układu za pomocą kierunku od lewej do prawej.

• Dodaj notatki w celu wyjaśnienia zasad biznesowych.

• Grupuj przypadki użycia w pakiety.

• Dodaj stylizację za pomocą skinparam.

• Zmień nazwy aliasów bez zmiany widocznych etykiet.

• Utrzymuj źródło diagramu pod kontrolą wersji.

• Generuj diagram ponownie za każdym razem, gdy model się zmienia.

Modelowanie wizualne versus diagram jako kod

Praktyczny połączony przepływ pracy

Produktywny przepływ pracy polega na używaniu każdego narzędzia do zadania, z którym radzi sobie najlepiej:

1. Uchwyć wymagania w języku naturalnym.
   Opisz użytkowników, cele, zakres systemu i reguły biznesowe.

2. Użyj sztucznej inteligencji do stworzenia wstępnego modelu.
   Poproś sztuczną inteligencję o zidentyfikowanie aktorów i przypadków użycia, a następnie wygeneruj pierwszy szkic.

3. Przejrzyj szkic w Visual Paradigm UML.
   Sprawdź, czy model wiernie odzwierciedla domenę i czy diagram jest łatwy do zrozumienia.

4. Eksportuj lub przepisz model w PlantUML.
   Używaj aliasów, spójnych nazw i jawnego składni relacji.

5. Utrzymuj źródło w VPasCode lub systemie kontroli wersji.
   Przechowuj plik.pumlrazem z dokumentacją projektu lub kodem źródłowym.

6. Zweryfikuj semantykę UML.
   Zwróć szczególną uwagę nainclude, extend, oraz kierunek uogólnienia.

7. Opublikuj końcowy diagram.
   Eksportuj go jako obraz lub dokument do celów wymagań, architektury, przeglądów projektu i dokumentacji.

Wskazówka do generowania diagramu przypadków użycia PlantUML

Poniższa wskazówka może być użyta z asystentem modelowania AI:

Wygeneruj diagram przypadków użycia PlantUML dla systemu zakupów online.

Użyj układu od lewej do prawej i umieść wszystkie przypadki użycia systemu wewnątrz
prostokąta o nazwie "System Zakupów Online".

Aktory:
- Klient
- Klient Premium
- Administrator
- Bramka płatności
- Usługa e-mail

Przypadki użycia klienta:
- Zarejestruj konto
- Zaloguj się
- Przeglądaj produkty
- Dodaj produkt do koszyka
- Złóż zamówienie
- Śledź zamówienie
- Anuluj zamówienie

Złożenie zamówienia musi zawierać:
- Zweryfikuj dane klienta
- Oblicz całkowitą wartość zamówienia
- Złóż zamówienie

Złożenie zamówienia musi zawierać:
- Dokonaj płatności
- Wyślij potwierdzenie zamówienia

Opcjonalne zachowania:
- Zastosuj kupon rabatowy extends Złóż zamówienie
- Zażądaj zwrotu extends Anuluj zamówienie

Klient Premium jest specjalizacją Klienta.

Użyj standardowego składni PlantUML i uwzględnij:
- Aliasy aktorów
- Aliasy przypadków użycia
- Granica systemu
- Asocjacje aktorów
- Relacje <<include>>
- Relacje <<extend>>
- Uogólnienie aktorów
- Co najmniej jeden komentarz wyjaśniający

Upewnij się, że strzałki include wskazują od bazowego przypadku użycia do włączonego przypadku użycia,
a strzałki extend wskazują od opcjonalnego rozszerzającego przypadku użycia do bazowego przypadku użycia.

Kluczowy wniosek

Visual Paradigm UML jest idealnie dostosowany do interaktywnego modelowania i przeglądu; sztuczna inteligencja może przyspieszyć przejście od wymagań do pierwszego szkicu, a VPasCode z PlantUML zapewnia powtarzalny, tekstowy przepływ pracy. Używane razem, wspierają pełny cykl życia modelowania: opisanie wymagań, wygenerowanie szkicu, walidację UML, udoskonalenie źródła oraz opublikowanie diagramu, który można łatwo utrzymywać.

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