Platformy współdzielenia przejazdów takie jak Uber, Lyft i Bolt przełamały urbanistyczną mobilność, łącząc pasażerów z blisko położonymi kierowcami w czasie rzeczywistym. W centrum tego doświadczenia leży złożita, dynamiczna interakcja między wieloma usługami — oddopasowania lokalizacjiiśledzenia w czasie rzeczywistym, dologiki akceptacji kierowcy, powiadomień, iobsługi błędów.

Ten artykuł przedstawiakompletny przypadek badaniaaplikacji do współdzielenia przejazdówprocesu rezerwacji w aplikacji do współdzielenia przejazdów, modelowany za pomocądiagramu UML Diagramu sekwencji. Przejdziemy przez pełny cykl życia żądania przejazdu przez pasażera — od wprowadzenia danych do potwierdzenia — w tymdopasowania kierowcy, obsługi wygaśnięcia czasu oczekiwania, powiadomień asynchronicznych, ilogiki ponownych prób.
Aby ten materiał był praktyczny i od razu użyteczny, przedstawiamypoprawiony, poprawny i gotowy do użycia w środowisku produkcyjnym fragment kodu PlantUMLktóry generuje czysty, zgodny ze standardami diagram sekwencji.
Zarejestrowany pasażer otwiera aplikację mobilną, wpisuje lokalizację wzięcia i destinację, wybiera typ przejazdu (np. ekonomiczny, premium) i żąda przejazdu. System wykonuje następujące czynności:
Szacuje koszt i czas przybyciaużywając routingu w czasie rzeczywistym przezMapsService.
Znajduje dostępnych kierowców w pobliżuw promieniu (z timeoutem).
Wysyła prośby o przejazddo najlepiej dopasowanych kierowców.
Czeka napotwierdzenie lub odrzucenie przez kierowcę (z timeoutem 30 sekund).
Jeśli zaakceptowane:
Przypisuje przejazd.
Informuje zarówno pasażera, jak i kierowcę.
Uruchamia śledzenie w czasie rzeczywistym.
Jeśli żaden kierowca nie zaakceptuje w czasie:
Oznacza prośbę jako nieudaną.
Oferta ponownej próby lub anulowania.
To odzwierciedla rzeczywiste zachowanie aplikacji do współdzielenia przejazdów:dynamiczne dopasowanie, asynchroniczne odpowiedzi, orazodporność na scenariusze braku akceptacji.
| Koncepcja | Rola w tym diagramie |
|---|---|
| Linia życia | Pionowe linie kreskowe dla każdego uczestnika (np. Pasażer, Usługa przejazdu, Kierowca) |
Komunikat synchroniczny (->) |
Bezpośrednie wywołanie (np. RS -> DM: findNearestDrivers) |
Komunikat asynchroniczny (-->) |
Niewymagające blokowania lub odpowiedź (np. NS --> Kierowca: Powiadomienie push) |
| Pasek aktywacji | Pokaż czas trwania przetwarzania (aktywuj / dezaktywuj) |
| Fragment alternatywy | Warunkowy: alt Driver Accepts vs inaczej Timeout/odrzucenie |
| Fragment opcjonalny | Opcjonalne przepływy (np. wybór premium) |
| Fragment pętli | Powtarza wyszukiwanie wśród wielu kierowców (pętla Znajdź dostępnych kierowców) |
| Fragment referencji | Odwołanie do podciągów (np. startTrackingSession) |
Aktora (Pasazer, Kierowca) |
Zewnętrzni użytkownicy inicjujący działania |
Zewnętrzny serwis (<<external>>) |
MapsService, NotificationService |
| Postęp czasu | Z góry na dół — logiczny przebieg czasu |
| Uczestnik | Rola |
|---|---|
Pasazer |
Uczestnik inicjujący żądanie przejazdu |
Aplikacja mobilna |
Interfejs użytkownika front-end obsługujący dane wejściowe i wyświetlanie |
Usługa przejazdu |
Główna usługa zaplecza zarządzająca cyklem życia przejazdu |
Usługa dopasowania kierowców |
Dopasowuje pasażerów do pobliskich kierowców |
Usługa map |
Zewnętrzna usługa do routingu, ceny i szacunkowego czasu przybycia (<<zewnętrzne>>) |
Usługa powiadomień |
Wysyła powiadomienia typu push/SMS/email do kierowcy i pasażera (<<zewnętrzne>>) |
Kierowca |
Uczestnik (aplikacja kierowcy) odpowiadający na żądania przejazdu |
@startuml
title Aplikacja współdzielenia przejazdów - Diagram sekwencji rezerwacji przejazdu
skinparam monochrome true
skinparam shadowing false
skinparam sequenceMessageAlign center
autonumber "<b>[0]"
aktor Pasazer
uczestnik "Aplikacja mobilna" jako App
uczestnik "Usługa przejazdu" jako RS
uczestnik "Usługa dopasowania kierowców" jako DM
uczestnik "Usługa map" jako Maps <<zewnętrzne>>
uczestnik "Usługa powiadomień" jako NS <<zewnętrzne>>
aktor Kierowca
Pasazer -> App: Otwórz aplikację i wprowadź punkt wzięcia/dostarczenia
aktywuj App
App -> RS: requestRide(punktWzięcia, punktDostarczenia, typPrzejazdu)
aktywuj RS
RS -> Maps: calculateFareAndETA(punktWzięcia, punktDostarczenia, typPrzejazdu)
aktywuj Maps
Maps --> RS: szacunekCeny, minutyETA, trasa
dezaktywuj Maps
RS --> App: display(cena, ETA, potwierdź?)
App --> Pasazer: Pokaż cenę i ETA, zapytaj o potwierdzenie
alt Pasażer potwierdza przejazd
Pasazer -> App: confirmRide()
App -> RS: confirmAndMatch()
aktywuj RS
pętla Znajdź dostępnych kierowców (timeout 30s)
RS -> DM: findNearestDrivers(punktWzięcia, typPrzejazdu, maksymalnaOdległość)
aktywuj DM
DM --> RS: listaDostępnychKierowców
dezaktywuj DM
alt Znaleziono kierowców
RS -> NS: sendRideRequestToDriver(idKierowcy, punktWzięcia, cena)
aktywuj NS
NS --> Kierowca: Powiadomienie typu push "Nowe żądanie przejazdu"
NS --> RS: requestSent
alt Kierowca akceptuje
Kierowca -> NS: acceptRide()
NS --> RS: driverResponse(accept)
przerwij Zgodność pomyślna
inaczej Kierowca odmawia lub timeout
notatka po prawej od RS: Kontynuuj do następnego kierowcy lub niepowodzenie
przerwij Brak akceptacji
koniec
RS -> Maps: startTrackingSession(idPrzejazdu)
aktywuj Maps
Maps --> RS: idŚledzenia, aktualizacjeMapy
dezaktywuj Maps
RS -> NS: notifyPassenger("Przydzielono kierowcę", informacjeKierowcy, ETA)
NS --> Pasazer: Powiadomienie typu push "Kierowca w drodze"
RS -> NS: notifyDriver("Przejazd potwierdzony", informacjePasażera)
NS --> Kierowca: Powiadomienie typu push "Przejazd zaakceptowany"
RS --> App: rideMatched(informacjeKierowcy, pojazd, ETA)
App --> Pasazer: Pokaż szczegóły kierowcy i mapę
inaczej Brak dostępnych kierowców
RS --> App: noDrivers("Brak kierowców w pobliżu. Spróbuj ponownie?")
przerwij Brak kierowców
koniec
koniec
alt Zgodność pomyślna
RS --> App: bookingConfirmed(idPrzejazdu)
App --> Pasazer: Pokaż "Przejazd zarezerwowany!" + śledzenie
inaczej Brak akceptacji po próbach
RS --> App: requestFailed("Brak kierowców. Spróbuj ponownie?")
App --> Pasazer: Pokaż błąd i opcję ponownego próby
koniec
dezaktywuj RS
inaczej Pasażer anuluje
App --> Pasazer: Anulowano
koniec
dezaktywuj App
@enduml
✅ Brak return stany — zastąpione przez break i odpowiednie przepływy.
✅ Wszystkie aktywuj/dezaktywuj pary są poprawnie zamknięte.
✅ alt/pętla/opt są poprawnie zagnieżdżone i zakończone.
✅ ref fragmenty są domyślne przez startTrackingSession (może być wyodrębnione jako poddiagram).
✅ <<zewnętrzny>> stereotypy użyte dla przejrzystości.
✅ Spróbuj teraz: Wklej do https://www.plantuml.com/plantuml → Kliknij „Generuj” → Zobacz pełny przepływ renderowany natychmiastowo.
Przejdź do PlantUML Live
Wklej kod → Kliknij „Generuj”
✅ Natychmiastowy wizualny diagram sekwencji
💡 Porada: Dodaj
skinparam backgroundColor #F8F8F8dla czystego białego tła.
Otwórz Visual Paradigm Desktop lub VP Online
Utwórz nowy Diagram sekwencji
Użyj Narzędzia > Importuj > PlantUML → Wklej kod
Automatycznie generuje z liniami życia, komunikatami i paskami aktywacji
Użyj chat.visual-paradigm.com aby zadać pytanie:
„Przeprojektuj ten schemat współdzielenia jazdy na architekturę mikroserwisów: rozdziel RideService, MatchingService, NotificationService i PaymentService. Dodaj opcjonalny krok płatności po dopasowaniu.”
VP AI zrobi:
Podziel RideService na ControllerRide, UsługaRide, UsługaPłatności
Dodaj UsługaPłatności z processPayment() wywołanie
Dodaj <<zewnętrzny>> dla BramaPłatności
Dodaj opc do opcjonalnego ulepszenia do wersji premium
Zaloguj się na online.visual-paradigm.com
Otwórz OpenDocs → Utwórz nową stronę: „Specyfikacja przepływu rezerwacji przejazdu”
Wstaw diagram.
Dodaj:
Wstępne warunki: „Użytkownik musi być zalogowany, GPS włączony”
Warunki końcowe: „Połączenie przejazdu, śledzenie aktywne, kierowca poinformowany”
Wyjątki: „Brak kierowcy akceptującego w ciągu 30 sekund”, „GPS niedostępne”
Linki: Diagram przypadków użycia, diagram klas, maszyna stanów
| Zalety | Wyjaśnienie |
|---|---|
| Szybkie prototypowanie | Twórz UML w sekundach za pomocą PlantUML |
| Ulepszanie z wykorzystaniem AI | Przekształć w mikroserwisy lub architekturę warstwową |
| Zgodność z kontrolą wersji | Przechowuj kod w Git — bez plików binarnych |
| Skalowalny | Rozszerz o typy przejazdów, promocje, przejazdy grupowe |
| Zgodność z różnymi narzędziami | Działa w VS Code, Confluence, GitHub itd. |
Chcesz iść dalej? Oto typowe rozszerzenia:
opt Typ przejazdu: Premium
RS -> Aplikacja: showPremiumOption()
Aplikacja --> RS: selectPremium()
RS -> Mapy: recalculateFareWithSurge()
Mapy --> RS: newFare, updatedEta
koniec
RS -> ServicePłatności: processPayment(idPrzejazdu, kwota)
aktywuj ServicePłatności
ServicePłatności --> RS: sukces, idTransakcji
dezaktywuj ServicePłatności
RS --> Aplikacja: showPaymentConfirmed()
Kierowca -> NS: cancelRide(uzasadnienie)
NS --> RS: driverCanceled
RS -> Aplikacja: notifyPassenger("Kierowca anulował. Szukamy nowego kierowcy...")
Daj mi znać, jeśli chcesz te warianty w postaci pełnego kodu PlantUML!
Proces rezerwacji przejazdu w systemie współdzielenia pojazdów to nie tylko dopasowanie — to o koordynacji w czasie rzeczywistym, komunikacja asynchroniczna, i odporność na niepewność. Modelując to za pomocą diagramów sekwencji UML i wykorzystując PlantUML + narzędzia AI, takie jak Visual Paradigm, zespoły mogą:
Projektuj z jasnością i precyzją
Wykrywaj przypadki graniczne wczesnie (np. brak kierowców, przekroczenie czasu)
Współpracuj między produktami, inżynierią i QA
Dokumentuj przepływy w celu audytów, wdrażania i szkoleń
✅ Zacznij teraz: Wklej kod PlantUML powyżej do PlantUML Live i zobacz, jak twój przepływ współdzielenia pojazdów przybiera życie w ciągu sekund.
Użyj autonumber do śledzenia.
Dodaj hide footbox aby usunąć stopkę.
Dostosuj kolory: skinparam sequenceMessageBackgroundColor #E0F7FA
Eksportuj jako PNG/SVG/PDF do raportów lub prezentacji.
📬 Potrzebujesz pomocy?
Chcesz wersję z diagramy klas, maszyny stanów, lub integracja z backendem Spring Boot/Node.js?
Po prostu zapytaj — wygeneruję dla Ciebie pełny model architektury.
✨ Modeluj z precyzją. Buduj z prędkością. Dostarczaj z pewnością.