Realizacja zamówienia

Kontekst i granica modelu#

Realizacja zamówienia obejmuje działania po przyjęciu zamówienia: kontrolę jego stanu, przygotowanie towarów, przekazanie przesyłki i poinformowanie klienta. Ten przykład modeluje proces sklepu internetowego po złożeniu zamówienia. Nie definiuje polityki zwrotów, księgowania, konkretnej integracji kurierskiej ani gwarancji czasu dostawy.

Właściciel procesu musi uzgodnić, kiedy zamówienie uznaje się za opłacone, czy rezerwacja zapasu powstaje przed czy po autoryzacji, jak długo jest utrzymywana oraz co dzieje się przy częściowej dostępności. Poniższy diagram przedstawia uproszczony wariant: wszystkie pozycje są dostępne, płatność jest zaakceptowana, a następnie kompletacja i przygotowanie dokumentów mogą przebiegać równolegle.

Uczestnicy i dane procesu#

W procesie mogą uczestniczyć klient, system zamówień, magazyn, operator płatności i przewoźnik. W widoku aktywności aktorzy nie muszą być lifelines — można pokazać odpowiedzialności partycjami, jeśli podział pracy jest ważny. W tym uproszczeniu skupiamy się na przepływie, a nie na szczegółowych wywołaniach.

Ważne dane obejmują zamówienie, pozycje, status płatności, stan zapasu, rezerwację, paczkę, dokument przewozowy i numer śledzenia. Przepływ danych warto pokazać osobno od sterowania, jeśli typ albo zawartość obiektu wpływa na następny krok.

Przebieg podstawowy#

1. System odbiera zamówienie do realizacji.
2. Potwierdza, że płatność jest zaakceptowana i wszystkie pozycje można skompletować.
3. Rezerwuje zapas, aby inne zamówienie nie przydzieliło tych samych jednostek.
4. Równolegle przygotowuje listę kompletacyjną i dane wysyłkowe.
5. Magazyn kompletuje i pakuje produkty; system tworzy etykietę przewozową.
6. Po przygotowaniu paczki i dokumentów proces synchronizuje się przed przekazaniem przesyłki.
7. System zapisuje status wysłania i przekazuje klientowi potwierdzenie z informacją o śledzeniu.

Węzeł fork pokazuje prace, które mogą być wykonywane współbieżnie; join czeka na zakończenie obu gałęzi przed wysyłką. Nie oznacza to, że czynności muszą odbywać się na różnych komputerach ani że są zawsze szybsze. Jeśli przygotowanie dokumentów zależy od wyników kompletacji, należy zmienić przepływ i nie modelować ich jako równoległych.

Alternatywy i reguły biznesowe#

Nieopłacone lub odrzucone zamówienie. Proces nie powinien przekazywać go do wysyłki. Może oczekiwać na płatność, wygasnąć lub zostać anulowane — zależnie od polityki sklepu.

Brak części pozycji. Możliwe są: wstrzymanie całości, wysyłka częściowa, zamiana produktu, anulowanie pozycji albo kontakt z klientem. Wybór wymaga decyzji biznesowej; diagram nie powinien ukrywać go pod ogólnym Obsłuż brak.

Błąd kompletacji lub uszkodzony produkt. System może zwolnić rezerwację, zainicjować uzupełnienie zapasu albo powiadomić klienta. Trzeba rozstrzygnąć, czy proces wraca do sprawdzenia dostępności i jak unika pętli bez końca.

Awaria przewoźnika lub błąd etykiety. To inny wariant niż brak produktu. Rozważ ponowienie, wybór innego przewoźnika i idempotencję utworzenia przesyłki, aby retry nie powodował duplikatów.

Model uzupełniający#

Diagram aktywności pokazuje przebieg, ale status zamówienia może wymagać osobnej maszyny stanów: Opłacone, W kompletacji, Spakowane, Wysłane, Dostarczone, Wstrzymane i Anulowane. Zdarzenia i reguły przejść powinny być spójne z aktywnością. Diagram sekwencji może rozwinąć komunikację między usługą zamówień, magazynem i operatorem wysyłki.

Przy modelu klas można powiązać zamówienie z pozycjami, rezerwacjami oraz przesyłką. Trzeba rozstrzygnąć, czy jedna rezerwacja może obejmować kilka magazynów, czy zamówienie może być dzielone na paczki oraz czy numer śledzenia pojawia się przed czy po przekazaniu przewoźnikowi.

Przypadki testowe#

• Płatność zaakceptowana i pełny zapas prowadzą do rezerwacji oraz wysyłki.
• Odmowa płatności zatrzymuje proces przed kompletacją.
• Brak jednego produktu uruchamia uzgodnioną ścieżkę alternatywną.
• Towar jest zarezerwowany najwyżej raz mimo równoczesnych żądań.
• Błąd etykiety nie powoduje oznaczenia paczki jako wysłanej.
• Powtórzenie żądania utworzenia przesyłki nie tworzy niezamierzonych duplikatów.
• Klient otrzymuje numer przesyłki dopiero po jego uzyskaniu.
• Każda ścieżka kończy się statusem pozwalającym ustalić dalszy los zamówienia.

Typowe błędy modelowania#

• Założenie, że złożone zamówienie jest opłacone. Warunek płatności może być częścią procesu.
• Rezerwacja bez uwzględnienia współbieżności. Dwa zamówienia mogą rywalizować o ostatnią sztukę.
• Fork użyty dla alternatywnych wyników. Odmowa i akceptacja to wybór ścieżki, nie równoległość.
• Join pominięty po pracy równoległej. Wysyłka może rozpocząć się przed przygotowaniem dokumentów.
• Jeden ogólny krok dla wyjątków. Brak, uszkodzenie i awaria integracji mają inne skutki.
• Brak idempotencji przy ponowieniach. Błąd sieci może doprowadzić do duplikowania przesyłek.
• Statusy niezgodne między diagramami. Model stanu i aktywność muszą używać tych samych reguł.
• Założenie jednego magazynu i jednej paczki. Wymagania mogą dopuszczać podział wysyłki.

Podsumowanie przykładu#

Przykład pokazuje, jak aktywność może przedstawić kontrolę płatności i dostępności, pracę równoległą oraz moment synchronizacji przed wysyłką. Jest szkieletem do uzgodnienia, nie kompletną specyfikacją sklepu. Rozszerz go o reguły zapasu, częściowej realizacji, anulowania, awarii i ponowień, które rzeczywiście obowiązują w modelowanym procesie.