Cel i założenia#

To studium przypadku pokazuje, jak połączyć kilka widoków UML dla sklepu internetowego: model pojęciowy, cele użytkowników oraz przepływ złożenia i realizacji zamówienia. Nie opisuje kompletnego produktu ani gotowej architektury wdrożeniowej. Zakres obejmuje katalog, koszyk, zamówienie, zapas, płatność i wysyłkę.

Przyjmujemy, że klient może składać zamówienie z dostępnych produktów, płaci przez zewnętrznego operatora, a sklep po pozytywnym wyniku rezerwuje zapas i przygotowuje przesyłkę. Zamówienie może zostać odrzucone z powodu walidacji, braku produktu lub nieudanej płatności. Konkretne reguły cen, podatków, dostaw, zwrotów i ochrony danych wymagają osobnego uzgodnienia.

Kluczowe założenie: koszyk jest roboczym wyborem, a zamówienie jest zapisanym żądaniem zakupu. Samo dodanie produktu do koszyka nie gwarantuje ceny ani dostępności, chyba że system jawnie rezerwuje je w tej fazie.

Aktorzy i cele#

Klient przegląda katalog, zarządza koszykiem, składa zamówienie, płaci i sprawdza status. Operator sklepu zarządza ofertą i obsługuje wyjątki. Operator płatności autoryzuje lub odrzuca operację. Przewoźnik odbiera dane przesyłki i zwraca informacje o jej statusie. Te systemy zewnętrzne są aktorami względem modelu sklepu, jeśli granicę wyznaczono na sklepie.

Diagram przypadków użycia powinien skupić się na celach, takich jak Złożyć zamówienie, Opłacić zamówienie, Śledzić przesyłkę, Zarządzać katalogiem. „Kliknąć przycisk Kup” jest szczegółem interfejsu, a nie celem biznesowym. Szczegółowe kroki i alternatywy należy opisać w scenariuszu lub innym diagramie.

Model pojęciowy#

Model klas poniżej pokazuje relacje między najważniejszymi pojęciami:

Model sklepu łączy klienta z zamówieniami, zamówienie kompozycyjnie zawiera pozycje i może mieć płatności oraz przesyłki, a pozycja wskazuje produkt katalogowy.
Uproszczony model klas kluczowych pojęć sklepu internetowego.

W tym uproszczeniu klient ma najwyżej jeden aktywny koszyk, ale może mieć wiele historycznych zamówień. Zamówienie zawiera pozycje, z których każda wskazuje produkt. W jednej chwili produkt może pojawić się w wielu pozycjach różnych zamówień. Relacja zamówienia do płatności jest wielokrotna, bo mogą istnieć próby, częściowe płatności lub zwroty; konkretny model musi określić, które operacje są osobnymi rekordami.

Pozycja zamówienia powinna zwykle zachować dane handlowe obowiązujące w chwili zakupu, np. nazwę i cenę jednostkową, zamiast polegać wyłącznie na później zmienionym produkcie katalogowym. Diagram celowo nie pokazuje wszystkich atrybutów, statusów, kuponów, podatków ani wariantów produktu.

Główny przepływ zamówienia#

Proces zamówienia prowadzi od złożenia do walidacji i sprawdzenia zapasu; przy dostępnych produktach rezerwuje towar, obsługuje płatność, przygotowuje wysyłkę i potwierdza zamówienie, a przy błędzie zatrzymuje lub anuluje proces.
Przebieg od złożenia zamówienia do potwierdzenia wysyłki z wybranymi wariantami.

„Nieznany wynik” płatności nie jest równoznaczny z odmową. Jeśli połączenie z operatorem zostanie przerwane, system może nie wiedzieć, czy środki zostały pobrane. Nie powinien bez sprawdzenia ponawiać obciążenia ani wysyłać towaru. Szczegóły obsługi timeoutu, identyfikatorów idempotencji i uzgadniania transakcji należą do osobnego modelu płatności.

Węzeł „Zatrzymaj zamówienie do decyzji” celowo pozostawia otwartą regułę: sklep może zaoferować zamiennik, częściową wysyłkę lub anulowanie. Diagram produkcyjny musi ten wybór rozwinąć, jeśli taki wariant należy do zakresu.

Statusy i spójność#

Zamówienie, płatność, zapas i przesyłka mają odrębne cykle życia. Przykładowo zamówienie może być Oczekujące na płatność, Opłacone, W realizacji, Wysłane, Dostarczone, Anulowane. Płatność ma własne stany, takie jak Oczekująca, Potwierdzona, Odrzucona, Nieznana, Zwrócona. Przesyłka może oczekiwać na nadanie, być w drodze lub zostać doręczona.

Nie redukuj wszystkich tych pojęć do jednego statusu zamówienia. Zamówienie może być opłacone, lecz jeszcze nieskompletowane; przesyłka może być doręczona, a reklamacja nadal otwarta. Zdefiniuj, które zdarzenia aktualizują statusy i jak postąpić, gdy częściowy zapis się nie powiedzie.

Warianty wymagające osobnego modelowania#

  • Częściowa dostępność: czy klient może zaakceptować wysyłkę częściową lub zamiennik?
  • Zmiana ceny: czy cena jest ponownie sprawdzana przed płatnością i jak system informuje o zmianie?
  • Timeout operatora: jak odczytać ostateczny wynik bez podwójnego obciążenia?
  • Wiele paczek: jak zamówienie łączy się z przesyłkami z różnych magazynów?
  • Anulowanie: do którego momentu można anulować i jak zwalnia się rezerwację?
  • Zwrot i reklamacja: jak po dostawie skorygować płatność, zapas i status?
  • Równoczesne zakupy: jak zapobiec sprzedaży większej liczby sztuk niż dostępna?
  • Gość bez konta: jakie informacje i czynności są dostępne bez rejestracji?

Nie zakładaj jednej odpowiedzi dla każdego sklepu. Wymagania powinny określić reguły i właściciela decyzji.

Przypadki testowe#

  • Poprawne zamówienie i płatność prowadzą do realizacji i potwierdzenia wysyłki.
  • Niepoprawne dane zatrzymują proces przed rezerwacją.
  • Brak zapasu nie uruchamia płatności bez uzgodnionej polityki.
  • Odrzucona płatność nie powoduje wysłania towaru.
  • Timeout płatności nie jest automatycznie traktowany jako sukces ani odmowa.
  • Równoczesne zamówienia nie zużywają zapasu ponad stan.
  • Ponowienie żądania nie tworzy drugiego zamówienia lub obciążenia.
  • Zmiana danych produktu nie zmienia historycznej ceny pozycji zamówienia.
  • Błąd utworzenia przesyłki pozostawia zamówienie w stanie możliwym do wznowienia.
  • Każda ścieżka błędna ma widoczny rezultat i odpowiedzialność za dalsze działanie.

Typowe błędy#

  • Koszyk utożsamiony z zamówieniem. Koszyk może być tymczasowy i nie oznacza zobowiązania.
  • Produkt katalogowy jako jedyne źródło historii ceny. Dane pozycji mogą wymagać migawki z chwili zakupu.
  • Jeden status dla wielu cykli życia. Płatność, zamówienie i przesyłka są różnymi obiektami.
  • Założenie, że płatność jest synchroniczna. Wynik może być opóźniony lub nieznany.
  • Brak rezerwacji lub kontroli zapasu. Równoczesne zamówienia mogą przekroczyć dostępność.
  • Zbyt wczesne potwierdzenie wysyłki. Numer przesyłki nie istnieje, dopóki nie zostanie utworzony.
  • Pominięcie anulowania i zwrotu. To ważne ścieżki zmieniające status i zasoby.
  • Zbyt wiele detali na jednej planszy. Podziel strukturę, przepływ i komunikację na odpowiednie widoki.
  • Niespójność relacji między diagramami. Nazwy, liczności i zdarzenia powinny opisywać ten sam model.

Co studium pokazuje, a czego nie#

Studium łączy model pojęciowy ze scenariuszem realizacji zamówienia i wskazuje osobne cykle życia płatności, zapasu oraz przesyłki. Diagramy są punktami wyjścia do uzgodnienia zakresu, testów i szczegółowego projektu.

Nie opisują pełnego e-commerce, prawnych wymagań sprzedaży, podatków, bezpieczeństwa ani wdrożenia. Przed użyciem w rzeczywistym projekcie zastąp przykładowe założenia zatwierdzonymi regułami biznesowymi i wymaganiami technicznymi.