Studium przypadku: Diagram przypadków użycia dla platformy dostaw żywności

Modelowanie wymagań ze świata rzeczywistego przy użyciu UML – Praktyczny przewodnik

1. Wstęp

We współczesnej inżynierii oprogramowania,diagramy przypadków użyciasą podstawowym narzędziem do przechwytywania wymagań funkcjonalnych z perspektywy użytkownika. Niniejsze studium przypadku przedstawia szczegółową analizęrealistycznego diagramu przypadków użyciadladostaw żywności, wykorzystującskładnię PlantUML jako język modelowania. Celem jest wykazanie nie tylkojakich elementów jest używanych w diagramie, ale takżedlaczego zostały wybrane — podkreślającpraktyczne decyzje modelowania, konwencje orazczęste pułapki.

Niniejsze studium przypadku służy zarównopoczątkującym uczącym się UML jak ipraktykom doskonalącym swoje praktyki modelowaniaRozkłada każdy element diagramu na czynniki pierwsze, wyjaśnia jego cel i omawia implikacje ze świata rzeczywistego.

2. Przegląd systemu

Platformadostaw żywności to cyfrowa platforma rynkowa łącząca:

• Klientów(osoby zamawiające jedzenie),
• Restauracji(dostawcy posiłków),
• Kierowców(personel dostawczy),
• Zewnętrznych Bram Płatności(systemy stron trzecich 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

left to right direction

' Wszyscy aktorzy są zdefiniowani poza prostokątem
actor Klient
actor "Zarejestrowany Klient" jako RegKlient
actor "Personel Restauracji" jako Restauracja
actor Kierowca
actor "Procesor Płatności" jako BramkaPłat

rectangle "Platforma Dostaw Jedzenia" {

(Przeglądaj Restauracje)
(Złóż Zamówienie)
(Śledź Zamówienie)
(Zarządzaj Menu)
(Akceptuj / Przygotuj Zamówienie)
(Dostarcz Zamówienie)
(Przetwórz Płatność)
(Wydaj Zwrot)
(Zastosuj Kod Promocyjny)
(Użyj Portfela)
(Płatność Kartą)
(Płatność Cyfrowym Portfelem)

' Asocjacje – strzałki przekraczają granicę
Klient --> (Przeglądaj Restauracje)
RegKlient --> (Złóż Zamówienie)
RegKlient --> (Śledź Zamówienie)

Restauracja --> (Zarządzaj Menu)
Restauracja --> (Akceptuj / Przygotuj Zamówienie)

Kierowca --> (Dostarcz Zamówienie)

BramkaPłat --> (Przetwórz Płatność)
BramkaPłat --> (Wydaj Zwrot)

' include
(Złóż Zamówienie) ..> (Przetwórz Płatność) : <<include>>

' extend
(Złóż Zamówienie) <.. (Zastosuj Kod Promocyjny) : <<extend>>
(Przetwórz Płatność) <.. (Użyj Portfela) : <<extend>>

' generalizacja
(Przetwórz Płatność) <|-- (Płatność Kartą)
(Przetwórz Płatność) <|-- (Płatność Cyfrowym Portfelem)
}

' Generalizacja aktorów (również poza)
Klient <|-- RegKlient

note right of BramkaPłat
Zewnętrzna bramka płatności
(Stripe, PayPal, Adyen, ...)
end note

note bottom of (Zastosuj Kod Promocyjny)
Opcjonalne – tylko przy wprowadzeniu poprawnego kodu
end note

@enduml

✅ Kluczowa uwaga: Diagram koncentruje się na interakcjach zewnętrznych — pokazuje, co system robidla swoich użytkowników i systemów, a nie jak jest zaimplementowany.

3. Elementy diagramu: Szczegółowa analiza z praktycznym znaczeniem

Poniżej znajduje się kompleksowe omówienie każdego elementu UML użytego w diagramie wraz z interpretacją z życia wziętą i uzasadnieniem modelowania.

4. Kluczowe decyzje modelowania i ich uzasadnienie

✅ Dlaczego aktorzy są poza granicą systemu

• Najlepsza praktyka: Aktorzy reprezentują role pozasystemu.
• Dlaczego to ma znaczenie: Zapobiega pomyłce między komponentami systemu a podmiotami zewnętrznymi.
• Przykład: Kierowca nie jest modułem platformy — są to role zewnętrzne z nią współpracujące.

📌 Wskazówka: Gdyby wszyscy aktorzy znajdowali się wewnątrz granicy, oznaczałoby to, że system ich obejmuje — co wprowadza w błąd.

✅ Dlaczego stosować Klient <|-- KlientZarejestrowany zamiast duplikować połączenia

• Bez uogólnienia musiałbyś narysować:
  PlantUML
  
  
  Edytuj PlantUML w VPasCode
  

  PlantUML Edit PlantUML in VPasCode

  Klient --> (Przeglądaj restauracje)
  KlientZarejestrowany --> (Przeglądaj restauracje)
  KlientZarejestrowany --> (Złóż zamówienie)
  

  Edit PlantUML in VPasCode

  
  
  Edytuj PlantUML w VPasCode
  
• Przy użyciu uogólnienia wystarczy:
  PlantUML
  
  
  Edytuj PlantUML w VPasCode
  

  PlantUML Edit PlantUML in VPasCode

  Klient <|-- KlientZarejestrowany
  Klient --> (Przeglądaj restauracje)
  KlientZarejestrowany --> (Złóż zamówienie)
  

  Edit PlantUML in VPasCode

  
  
  Edytuj PlantUML w VPasCode
  
• Wynik: Czystszy, łatwiejszy w utrzymaniu diagram.

📌 Najlepsza praktyka: Stosuj uogólnienie aktorów, gdy wyspecjalizowany aktor dziedziczy wszystkie zachowania aktora bardziej ogólnego.

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

❗ Pospolity błąd: Odwrócenie kierunku strzałki. Zawsze pamiętaj:

• włączyć: Baza ..> Włączony
• rozszerz: Rozszerzenie <.. Podstawa

✅ Dlaczego Przetwarzanie płatności ma uogólnienia

• Płatność kartą i Płatność portfelem cyfrowym są specjalistycznymi formami Przetwarzanie płatności.
• To pokazuje, że platforma obsługuje wiele metod płatności, ale wszystkie podążają tym samym podstawowym przepływem.
• Uogólnienie umożliwia wspólne zachowanie i przyszłą rozszerzalność.

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

5. Interpretacje z życia wzięte i odpowiedzi na pytania

Ten diagram nie jest tylko pomocą wizualną — odpowiada na kluczowe pytania biznesowe i techniczne:

✅ Wartość biznesowa: Diagram jasno komunikuje co robi system, kto go używa, oraz jakie zachowania są obowiązkowe, a jakie opcjonalne.

6. Zastosowane wspólne wytyczne modelowania

Diagram ilustruje kilka najlepszych praktyk w modelowaniu przypadków użycia UML:

📌 Ostrzeżenie: Wiele diagramów błędnie wykorzystuje <<extend>> w znaczeniu „opcjonalny” bez zrozumienia warunkowego charakteru rozszerzeń. Ten diagram unika tego błędu.

7. Potencjalne ulepszenia i krytyka

Mimo że diagram jest solidny, oto konstruktywne sugestie do dopracowania:

🔧 1. Dodaj stereotypy dla jasności

actor "Payment Processor" as PaymentGW <<system>>

• Dlaczego: Wyraźnie wskazuje, że jest to system zewnętrzny, a nie rola ludzka.
• Korzyść: Zmniejsza niejednoznaczność, szczególnie w dużych modelach.

🔧 2. Ujawnij Zastosuj kod promocyjnyWarunek rozszerzenia

Obecnie:

note bottom of (Apply Promo Code)
  Optional – only when a valid code is entered
end note

• Lepiej: Użyj notacji warunku lub warunku strażniczego w <<extend>> strzałce:

(Złóż zamówienie) <.. (Zastosuj kod promocyjny) : <<extend>> [ważny kod promocyjny]

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

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

• Obecnie brakujące, ale prawdopodobnie ważne zarówno dla klientów, jak i restauracji.
• Można dodać jako Zarejestrowany klient przypadku użycia.

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

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

package "Zarządzanie zamówieniami" {
    (Złóż zamówienie)
    (Śledź zamówienie)
    (Zastosuj kod promocyjny)
}
package "Płatności" {
    (Przetwórz płatność)
    (Użyj portfela)
    (Płatność kartą)
    (Płatność cyfrowym portfelem)
}

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

8. Co dalej?

Ten przypadek badawczy pokazał, jak dobrze ustrukturyzowany diagram przypadków użyciamoże w sposób jasny i zwięzły oddać złożoną logikę biznesową. Aby pogłębić swoją wiedzę, oto sugerowane kolejne kroki:

🔄 Opcja 1: Widok skoncentrowany 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łównego aktora.
• Dołącz Klient jako aktora drugorzędnego (np. Klient wysyła zamówienie → Restauracja je otrzymuje).

✅ Korzyść: Ujawnia różne cele systemu i role aktorów.

🔄 Opcja 2: Dodaj więcej punktów rozszerzeń

Ulepsz Złóż zamówienie z:

• Zastosuj kupon (jeśli kod promocyjny jest nieprawidłowy → <<rozszerz>> z komunikatem błędu)
• Poproś o specjalne instrukcje (opcjonalne)
• Zaplanuj zamówienie (na przyszłą dostawę)

🔄 Opcja 3: Porównaj uwzględnij vs rozszerz z przykładami

📌 Zasada ogólna:

• Użyj <<include>> gdy zachowanie musi nastąpić.
• Użyj <<extend>> gdy zachowanie może nastąpić pod pewnymi warunkami.

🔄 Opcja 4: Przekształć na diagramy sekwencji lub aktywności

Do głębszej analizy:

• Diagram sekwencji: Pokaż przepływ Złóż zamówienie → Przetwórz płatność → Dostarcz zamówieniez wiadomościami między aktorami a systemem.
• Diagram aktywności: Modeluj punkty decyzyjne wPrzetwórz płatność (np. karta odrzucona → ponów próbę lub przełącz się na portfel).

9. Podsumowanie

Ten przypadek badawczy pokazuje, żestarannie opracowany diagram przypadków użyciato znacznie więcej niż wizualny szkic — tostrategiczne narzędzie komunikacjiktóre:

• Ujasnia zakres systemu,
• Uchwyta reguły biznesowe,
• Kieruje rozwojem,
• Zapobiega nieporozumieniom.

DiagramPlatformy Dostaw Żywnościjestmocnym przykłademczego:

• Właściwe użycie notacji UML,
• Zdrowe decyzje modelowania,
• Jasne oddzielenie obowiązków,
• Skuteczne użycie notatek i uogólnień.

Przestrzegając zasad przedstawionych tutaj —nazewnictwo zorientowane na cele, prawidłowe użyciezawiera/rozszerza, uogólnienie aktora, a także strategiczne wykorzystanie notatek — możesz tworzyć diagramy przypadków użycia, które są zarówno dokładne i działalne.

✅ Podsumowanie