Studium przypadku: Diagram przypadków użycia dla platformy dostaw jedzenia

Modelowanie rzeczywistych wymagań za pomocą UML – Przewodnik praktyczny

---

1. Wprowadzenie

W nowoczesnej inżynierii oprogramowania diagramy przypadków użycia są podstawowym narzędziem do zapisywania wymagań funkcyjnych z perspektywy użytkownika. Niniejsze studium przypadku przedstawia szczegółową analizę realistycznego diagramu przypadków użycia dla platforma dostaw jedzenia, używając składni PlantUML jako języka modelowania. Celem jest pokazanie nie tylko jakie elementy są używane w diagramie, ale także dlaczego są one wybrane — podkreślając praktyczne decyzje modelowania, zasady, oraz typowe pułapki.

To studium przypadku służy zarówno początkującym uczącym się UML i praktykom doskonalącym swoje metody modelowania. Rozbija każdy element diagramu, wyjaśnia jego cel i omawia konsekwencje w świecie rzeczywistym.

---

2. Przegląd systemu

 platforma dostaw jedzeniato cyfrowy rynek łączący:

• Klienci (osoby zamawiające jedzenie),

• Restauracje (dostawcy posiłków),

• Kierowcy (personel dostawczy),

• Zewnętrzne bramki płatności (systemy zewnętrzne obsługujące transakcje).

Platforma umożliwia użytkownikom przeglądanie restauracji, składanie zamówień, śledzenie dostaw, zarządzanie płatnościami oraz stosowanie promocji. System integruje się z zewnętrznymi usługami, takimi jak procesory płatności, i nie obsługuje logiki płatności wewnętrznie.

Kod PlantUML:

@startuml
skinparam monochrome true
skinparam shadowing false

kierunek od lewej do prawej

‘ Wszystkie aktorzy są definiowane poza prostokątem
aktor Klient
aktor „Zarejestrowany klient” jako RegKlient
aktor „Personel restauracji” jako Restauracja
aktor Kierowca
aktor „Procesor płatności” jako PaymentGW

prostokąt „Platforma dostawy jedzenia” {

(Przeglądaj restauracje)
(Złóż zamówienie)
(Sledź zamówienie)
(Zarządzaj menu)
(Przyjmij / Przygotuj zamówienie)
(Dostarcz zamówienie)
(Przetwórz płatność)
(Wydaj zwrot)
(Zastosuj kod promocyjny)
(Użyj portfela)
(Płatność kartą)
(Płatność portfelem cyfrowym)

‘ Powiązania – strzałki przechodzą przez granicę
Klient –> (Przeglądaj restauracje)
Zarejestrowany klient –> (Złóż zamówienie)
Zarejestrowany klient –> (Śledź zamówienie)

Restauracja –> (Zarządzaj menu)
Restauracja –> (Przyjmij / Przygotuj zamówienie)

Kurier –> (Dostarcz zamówienie)

PaymentGW –> (Przetwarzaj płatność)
PaymentGW –> (Wydaj zwrot)

‘ include
(Złóż zamówienie) ..> (Przetwarzaj płatność) : <<include>>

‘ extend
(Złóż zamówienie) <.. (Zastosuj kod promocyjny) : <<extend>>
(Przetwarzaj płatność) <.. (Użyj portfela) : <<extend>>

‘ generalizacja
(Przetwarzaj płatność) <|– (Płatność kartą)
(Przetwarzaj płatność) <|– (Płatność portfelem cyfrowym)
}

‘ Generalizacja aktora (również poza granicą)
Klient <|– Zarejestrowany klient

notatka po prawej stronie PaymentGW
Zewnętrzny gateway płatności
(Stripe, PayPal, Adyen, …)
koniec notatki

notatka pod (Zastosuj kod promocyjny)
Opcjonalne – tylko gdy wprowadzono ważny kod
notatka końcowa

@enduml

✅ Kluczowa obserwacja: Diagram skupia się na interakcje zewnętrzne — pokazuje, co system robi dla swoich użytkowników i systemów, a nie jak jest zaimplementowany.

---

3. Elementy diagramu: szczegółowe omówienie z praktycznym znaczeniem

Poniżej znajduje się kompleksowe omówienie każdego elementu UML użytego na diagramie, wraz z interpretacją z rzeczywistego świata i uzasadnieniem modelowania.

#	Element	Oznaczenie	Znaczenie i cel	Decyzja modelowania / Uwaga
1	Granica systemu	prostokąt "Platforma dostaw jedzenia"	Określa zakres systemu, który jest modelowany. Wszystkie przypadki użycia wewnątrz są częścią tego systemu.	Nazwa jest zwięzła, ale precyzyjna. W kontekście przedsiębiorstw mogą być używane dłuższe nazwy (np. „System zarządzania zamówieniami klientów”).
2	Główny aktor ludzki	aktor Klient, aktor Kierowca	Reprezentuje rolę zewnętrznaktóre inicjują lub uczestniczą w przypadkach użycia.	Nazwy są proste i intuicyjne. Unika niepotrzebnych stereotypów takich jak <<osoba>>chyba że wymagane jest dla dużych modeli.
3	Aktor z aliasem	aktor "Personel Restauracji" jako Restauracja	Zezwala na skrócenie długiej, opisowej nazwy aktora w celu lepszej czytelności połączeń.	Bardzo skuteczne, gdy nazwy aktorów zawierają spacje lub są szczegółowe. Zmniejsza zamieszanie i poprawia czytelność.
4	Aktory zewnętrznych systemów	aktor "Przetwornik płatności" jako PaymentGW	Modeluje systemy zewnętrznez którymi platforma się komunikuje.	Brak stereotypu «system»jest używany — akceptowalny w lekkich diagramach. Jednak dodanie «system»może wyjaśnić intencję w złożonych systemach.
5	Uogólnienie aktora	`Klient <	— ZarejestrowanyKlient`	Wskazuje, że zarejestrowany klientjest wersją specjalną klient gościnny.
6	Zwykła asocjacja	Klient --> (Przeglądaj restauracje)	Pokazuje, że aktorinicjujelubuczestniczy wprzypadku użycia.	Linia ciągła = komunikacja. Kierunek jest sugerowany od aktora do przypadku użycia (strzałka nie jest potrzebna).
7	Relacja «include»	(Złóż zamówienie) ..> (Przetwórz płatność) : <<include>>	Przetwórz płatnośćjestzawsze wymaganepodczas składania zamówienia.	Strzałka wskazujeod zawierającego → zawarte. To jest krytyczne:Złóż zamówienie zawiera Przetwórz płatnośćjako krok wymagany.
8	Relacja «extend»	(Złóż zamówienie) <.. (Zastosuj kod promocyjny) : <<extend>>	Zastosowanie kodu promocyjnego jestopcjonalnei ma miejsce tylko w określonych warunkach.	Strzałka wskazujeod rozszerzenia → podstawy. Podstawowy przypadek użycia (Złóż zamówienie) może być rozszerzony warunkowo.
9	Uogólnienie przypadku użycia	`(Przetwarzanie płatności) <	— (Płatność kartą)<br>(Przetwarzanie płatności) <	— (Płatność portfelim cyfrowym)`
10	Uwaga	uwaga po prawej stronie PaymentGW uwaga na dole (Zastosuj kod promocyjny)	Zapewnia wyjaśnienie kontekstowe dotyczące implementacji lub zasad biznesowych.	Uwagi są niedoużywane, ale niesamowicie wartościowe. Zapobiegają nieporozumieniom (np. wyjaśniając, że PaymentGW jest zewnętrzny).
11	Aktory poza granicą	Wszystkie aktor deklaracje poprzedzają prostokąt	Podkreśla, że żaden aktor nie jest częścią systemu — jasne oddzielenie odpowiedzialności.	Jeden z dwóch standardowych układów. Wskazany, gdy aktorów jest dużo lub są zewnętrzne.
12	Kierunek diagramu	kierunek od lewej do prawej	Ulepsza układ, gdy na lewej stronie znajduje się wiele aktorów.	Ułatwia czytanie. Szczególnie skuteczne przy 4–8 aktorach. Alternatywa: układ od góry do dołu dla mniejszej liczby aktorów.

---

4. Kluczowe decyzje modelowania i ich uzasadnienie

✅ Dlaczego aktorzy znajdują się poza granicą systemu

• Najlepsza praktyka: Aktorzy reprezentują rolepozasystemem.

• Dlaczego to ma znaczenie: Zapobiega zamieszaniu między składnikami systemu a obiektami zewnętrznymi.

• Przykład: Kierowcanie jest modułem platformy — to rola zewnętrzna, która z nią współpracuje.

📌 Porada: Jeśli wszyscy aktorzy byli wewnątrz granicy, oznaczałoby to, że system je obejmuje — co jest mylące.

---

✅ Dlaczego używaćKlient <|-- ZarejestrowanyKlientzamiast powtarzania połączeń

• Bez uogólnienia należałoby narysować:

  Klient --> (Przeglądaj restauracje)
  ZarejestrowanyKlient --> (Przeglądaj restauracje)
  ZarejestrowanyKlient --> (Zamów jedzenie)
  

• Z uogólnieniem wystarczy:

  Klient <|-- ZarejestrowanyKlient
  Klient --> (Przeglądaj restauracje)
  ZarejestrowanyKlient --> (Zamów jedzenie)
  

• Wynik: Czystszy, łatwiejszy w utrzymaniu diagram.

📌 Najlepsza praktyka: Używaj generalizacji aktora, gdy specjalizowany aktor dziedziczy wszystkie zachowania bardziej ogólnego.

---

✅ Dlaczego <<include>> i <<extend>> są używane poprawnie

Relacja	Cel	Kierunek	Przykład
<<include>>	Obowiązkowy podprzepływ	Od w tym → zawarte	Złóż zamówienie musi zawierać Przetwórz płatność
<<extend>>	Opcjonalne rozszerzenie	Od rozszerzenie → bazowy	Zastosuj kod promocyjny rozszerza Złóż zamówienietylko jeśli kod jest ważny

❗ Powszechny błąd: Odwracanie kierunku strzałki. Zawsze pamiętaj:

• zawiera: Bazowy ..> Zawarty

• rozszerzać: Rozszerzenie <.. Bazowy

---

✅ Dlaczego Przetwarzanie płatnościma uogólnienia

• Płatność kartą i Płatność z portfela cyfrowegosąspecjalizowane formyformyPrzetwarzanie płatności.

• Pokazuje to, że platforma obsługujewiele metod płatności, ale wszystkie one podlegają temu samemu podstawowemu przepływowi.

• Uogólnienie pozwala nawspólne zachowanie i przyszła rozszerzalność.

📌 Przypadek użycia: Dodanie nowej metody płatności (np. Apple Pay) byłoby po prostu kolejnym uogólnieniem Przetwarzanie płatności.

---

5. Interpretacje z rzeczywistego świata i odpowiedzi na pytania

Ten diagram to nie tylko pomoc wizualna — odpowiada na kluczowe pytania biznesowe i techniczne:

Pytanie	Odpowiedź z diagramu
Kto są głównymi użytkownikami?	Klienci, Zarejestrowani klienci, Personel restauracji, Kierowcy, Brama płatności
Czy niezarejestrowani użytkownicy mogą składać zamówienia?	❌ Nie — tylko ZarejestrowanyKlient może Złożyć zamówienie. Klient może tylko Przeglądaj restauracje.
Czy płatność jest zawsze wymagana?	✅ Tak — Złożyć zamówienie zawiera Przetwarzanie płatności. Wymagane.
Czy klienci mogą stosować kody promocyjne?	✅ Tak — ale tylko opcjonalnie poprzez <<rozszerz>>. Tylko wtedy, gdy zostanie wprowadzony ważny kod.
Jakie metody płatności są obsługiwane?	Karta i portfel cyfrowy (poprzez uogólnienie). System zewnętrzny obsługuje rzeczywiste przetwarzanie.
Kto obsługuje płatność?	Zewnętrzny PaymentGW — nie jest częścią platformy.
Czy restauracje mogą zarządzać swoimi menu?	✅ Tak — Restauracja aktor współdziała z Zarządzaj menu i Zaakceptuj / Przygotuj zamówienie.

✅ Wartość biznesowa: Diagram jasno przekazuje co system robi, kto go używa, i jakie zachowania są wymagane w porównaniu do opcjonalnych.

---

6. Pokazane są typowe zasady modelowania

Diagram ilustruje kilka najlepsze praktyki w modelowaniu przypadków użycia UML:

Zasada	Sposób zastosowania
Używaj nazw przypadków użycia skierowanych na cele	Złóż zamówienie, Śledź zamówienie, Zastosuj kod promocyjny — wszystkie zaczynają się od czasownika i opisują cel użytkownika.
Zachowaj czytelność diagramu	Tylko 10 przypadków użycia jest pokazanych — idealne dla większości dziedzin biznesowych (zalecane 5–12).
Zewnętrzne systemy jako aktorzy	PaymentGW jest modelowany jako aktor, a nie jako przypadek użycia. Poprawnie rozdziela obowiązki.
Używaj notatek do wyjaśnienia niejasności	Notatki wyjaśniają, że PaymentGW jest zewnętrzny, a kod promocyjny jest opcjonalny — kluczowe do uniknięcia nieporozumień.
Używaj uogólnienia aktora, aby zmniejszyć zamieszanie	`Klient <
Użyj include i extendpoprawnie	Jasna różnica między zachowaniem wymaganym a opcjonalnym.

📌 Ostrzeżenie: Wiele schematów błędnie wykorzystuje<<extend>>aby oznaczać „opcjonalne”, nie rozumiejącwarunkowego charakterurozszerzeń. Ten schemat unika tego błędu.

---

7. Potencjalne ulepszenia i krytyka

Choć schemat jest dobry, otokonstruktywne sugestiena jego doskonalenie:

🔧 1. Dodaj stereotypy dla jasności

aktor "Payment Processor" jako PaymentGW <<system>>

• Dlaczego: Umożliwia jasne określenie, że jest to system zewnętrzny, a nie rola ludzka.

• Zalety: Zmniejsza niejasności, szczególnie w dużych modelach.

🔧 2. UjednolijZastosuj kod promocyjny warunek rozszerzenia

Obecnie:

notatka na dole (Zastosuj kod promocyjny)
  Opcjonalne – tylko gdy wprowadzony jest ważny kod
koniec notatki

• Lepsze: Użyjnotacji warunkowejlubochrona w <<rozszerz>> strzałka:

(Zamówienie) <.. (Zastosuj kod promocyjny) : <<rozszerz>> [poprawny kod promocyjny]

• Dlaczego: Bardziej precyzyjne niż notatka — bezpośrednio łączy rozszerzenie z warunkiem.

🔧 3. Rozważ dodanie Zobacz historię zamówień Przypadek użycia

• Obecnie brakuje, ale prawdopodobnie jest ważne zarówno dla klientów, jak i restauracji.

• Może zostać dodane jako ZarejestrowanyKlient przypadek użycia.

🔧 4. Grupuj powiązane przypadki użycia (opcjonalnie)

W przypadku większych diagramów grupuj przypadki użycia w pakiety:

package "Zarządzanie zamówieniami" {
    (Zamówienie)
    (Śledzenie zamówienia)
    (Zastosuj kod promocyjny)
}
package "Płatności" {
    (Przetwarzanie płatności)
    (Użyj portfela)
    (Płatność kartą)
    (Płatność portfelem cyfrowym)
}

• Zalety: Poprawia skalowalność i czytelność.

---

8. Co dalej?

Ten przykład pokazuje, jak dobrze zorganizowany diagram przypadków użycia może jasno i zwięźle oddać złożoną logikę biznesową. Aby pogłębić swoje zrozumienie, oto zalecane kolejne kroki:

🔄 Opcja 1: Widok skupiony na restauracji

Zamodeluj ten sam obszar z perspektywy restauracji:

• Skup się na Zarządzaj menu, Przyjmij / Przygotuj zamówienie, Zobacz zamówienia, Zaktualizuj status.

• Pokaż Restauracja jako główny aktor.

• Uwzględnij Klient jako aktor pomocniczy (np. Klient wysyła zamówienie → Restauracja je otrzymuje).

✅ Zalety: Ujawnia różne cele systemu i role aktorów.

🔄 Opcja 2: Dodaj więcej punktów rozszerzenia

Ulepsz Złóż zamówienie z:

• Zastosuj kupon (jeśli kod promocyjny jest nieprawidłowy → <<rozszerz>> z komunikatem o błędzie)

• Poproś o specjalne instrukcje (dowolne)

• Zaplanuj zamówienie (dla przyszłej dostawy)

🔄 Opcja 3: Porównaj zawierać vs rozszerzać z przykładami

Przypadek użycia	<<zawiera>>	<<rozszerz>>
Złóż zamówienie → Przetwarzanie płatności	✅ Obowiązkowe	❌ Nie jest opcjonalne
Złóż zamówienie → Zastosuj kod promocyjny	❌ Nie jest obowiązkowe	✅ Warunkowe
Zaloguj się → Weryfikacja tożsamości	✅ Zawsze wymagane	❌ Niewłaściwe
Zakończ zakup → Zastosuj rabat	✅ Zawsze	✅ Tylko jeśli istnieje rabat

📌 Zasada ogólna:

• Użyj <<zawiera>> gdy zachowanie musi się zdarzyć.

• Użyj <<rozszerza>> gdy zachowanie może się zdarzyć w określonych warunkach.

🔄 Opcja 4: Konwersja do diagramów sekwencji lub działania

Do głębszej analizy:

• Diagram sekwencji: Pokaż przepływ Złóż zamówienie → Przetwórz płatność → Dostarcz zamówienie z wiadomościami między aktorami i systemem.

• Diagram aktywności: Zamodeluj punkty decyzyjne w Przetwórz płatność (np. kartę odrzucono → ponów lub przełącz się na portfel).

---

9. Wnioski

Ten przykład pokazuje, że dokładnie opracowany diagram przypadków użycia jest znacznie więcej niż tylko wizualny szkic — to narzędzie strategicznego komunikowania które:

• Precyzuje zakres systemu,

• Zapisuje zasady biznesowe,

• Kieruje rozwojem,

• Zapobiega nieporozumieniom.

Diagram Platforma dostaw jedzenia jest silnym przykłademsilnego przykładu takich jak:

• Poprawne użycie notacji UML,

• Odpowiednie decyzje modelowania,

• Jasne rozdzielenie odpowiedzialności,

• Skuteczne wykorzystanie notatek i uogólnień.

Przykładując zasady przedstawione tutaj — nazewnictwo skierowane na cele, poprawne użycie include/rozszerzyć, generalizacja aktora, i strategiczne wykorzystanie notatek— możesz tworzyć diagramy przypadków użycia, które są jednocześniedokładneiwykonalne.

---

✅ Ostateczne wnioski

Zasada	Zastosowana tutaj?	Dlaczego to ma znaczenie
Używaj nazw przypadków użycia skierowanych na cele	✅ Tak	Poprawia jasność i skupia się na użytkowniku
Zachowaj rozmiar diagramu możliwie mały	✅ Tak (10 przypadków użycia)	Zapobiega przeciążeniu poznawczemu
Zewnętrzne systemy jako aktorzy	✅ Tak	Poprawne rozdzielenie obowiązków
Używaj notatek do uzyskania kontekstu	✅ Tak	Zapobiega nieporozumieniom
Używaj generalizacji, aby zmniejszyć nadmiarowość	✅ Tak	Robi diagram skalowalnym i łatwym w utrzymaniu
Poprawny <<włącz>> i <<rozszerz>> kierunek	✅ Tak	Gwarantuje dokładne modelowanie zachowań

---