Cel i zakres#

Studium modeluje wypłatę gotówki w bankomacie: wprowadzenie karty i PIN-u, wybór kwoty, weryfikację oraz autoryzację, a następnie próbę wydania gotówki. Najważniejsze jest rozdzielenie decyzji banku od fizycznego wydania banknotów przez urządzenie.

Model jest edukacyjny. Nie opisuje rzeczywistych protokołów płatniczych, szyfrowania PIN-u, certyfikacji urządzeń, rozliczeń międzybankowych ani szczegółowych wymogów prawnych. W rzeczywistym systemie bezpieczeństwo i procedury awaryjne wymagają specjalistycznego projektu.

Aktorzy i odpowiedzialności#

Klient inicjuje wypłatę i odbiera kartę oraz gotówkę. Bankomat obsługuje interakcję i urządzenia peryferyjne. System autoryzacyjny banku weryfikuje konto, limit i dostępne środki. Dyspenser wydaje gotówkę i zgłasza wynik operacji. Rejestr transakcji zapisuje zdarzenia dla rozliczeń i późniejszego wyjaśniania niezgodności.

Ważne granice: bankomat może nie mieć bezpośredniej wiedzy o wszystkich regułach rachunku; system bankowy nie może sam potwierdzić, że fizyczne banknoty wypadły z dyspensera; klient nie powinien otrzymać potwierdzenia sukcesu tylko dlatego, że autoryzacja została zaakceptowana.

Główny przebieg#

  1. Klient wkłada kartę i podaje PIN.
  2. Bankomat przekazuje żądanie weryfikacji do systemu autoryzacyjnego.
  3. Klient wybiera kwotę, a system sprawdza środki, limity i reguły.
  4. Po autoryzacji bankomat wydaje gotówkę.
  5. Urządzenie zgłasza, ile faktycznie wydało, i zapisuje wynik.
  6. System bankowy finalizuje lub odpowiednio koryguje transakcję.
  7. Bankomat drukuje potwierdzenie, zwraca kartę i kończy sesję.
Klient żąda wypłaty; bankomat weryfikuje kartę i PIN, prosi system bankowy o autoryzację, a następnie wydaje gotówkę i zapisuje wynik albo obsługuje odmowę lub błąd dyspensera.
Uproszczona interakcja wypłaty z rozdzieleniem autoryzacji i wydania gotówki.

Sekwencja upraszcza rzeczywiste uzgadnianie transakcji. Jeśli system bankowy autoryzował kwotę, lecz dyspenser wydał tylko część lub nic, trzeba zapisać incydent i uruchomić procedurę wyjaśnienia albo korekty. Nie wolno utożsamiać „autoryzowano” z „klient otrzymał gotówkę”. Dokładny protokół zależy od systemu i nie jest określony w UML.

Karta, PIN i odmowa#

Niepoprawny PIN, zablokowana karta, przekroczony limit, brak środków, przekroczenie limitu urządzenia i niedostępność systemu to różne przyczyny. Z punktu widzenia interfejsu mogą wymagać odmiennych komunikatów, ale szczegóły nie powinny ujawniać informacji, których klient nie powinien poznać. Model powinien również określić, kiedy bankomat zatrzymuje lub zwraca kartę zgodnie z zatwierdzonymi regułami.

Model bezpieczeństwa powinien obejmować ochronę danych uwierzytelniających i kanału komunikacji, limity prób, monitoring, rejestr audytowy oraz obsługę manipulacji urządzeniem. Przykładowy diagram nie jest projektem zabezpieczeń i nie należy implementować na jego podstawie obsługi sekretów.

Stany sesji bankomatu#

Sesja może przechodzić przez stany Oczekuje, KartaWłożona, Uwierzytelnianie, WybórOperacji, OczekujeNaAutoryzację, WydawanieGotówki, RejestrowanieWyniku i Zakończona. Zdarzenia timeoutu, anulowania i błędu urządzenia mogą kończyć lub przerywać sesję.

Sesja użytkownika i transakcja rachunku to różne cykle. Sesja może zostać zakończona, podczas gdy uzgadnianie transakcji pozostaje otwarte. Rejestr transakcji powinien zachować identyfikator, wynik urządzenia i powiązanie z autoryzacją.

Przypadki testowe#

  • Niepoprawna karta lub PIN nie prowadzą do wypłaty.
  • Odrzucona autoryzacja nie uruchamia dyspensera.
  • Poprawna autoryzacja i pełne wydanie prowadzą do potwierdzenia.
  • Awaria dyspensera po autoryzacji zapisuje incydent i uruchamia uzgodnienie.
  • Częściowe wydanie nie jest traktowane jako pełna wypłata.
  • Ponowione żądanie po utracie odpowiedzi nie powoduje drugiego wydania.
  • Awaria sieci nie pozostawia wyniku bez możliwości późniejszego ustalenia.
  • Timeout kończy sesję zgodnie z regułami i chroni dane wprowadzone przez klienta.

Typowe błędy#

  • Autoryzacja utożsamiona z wydaniem gotówki. To osobne kroki i osobne dowody.
  • Brak ścieżki częściowego wydania. Fizyczne urządzenie może nie dostarczyć żądanej kwoty.
  • Brak identyfikatora transakcji. Utrudnia uzgodnienie po awarii.
  • Założenie, że timeout oznacza odmowę. Wynik może być nieznany po stronie urządzenia lub sieci.
  • Pomijanie zwrotu albo zatrzymania karty. Zdefiniuj te zachowania dla danego urządzenia.
  • Modelowanie wrażliwych danych wprost. Nie zapisuj PIN-u ani sekretów jako zwykłych atrybutów lub logów.
  • Brak obsługi idempotencji i ponowień. Retry nie może powodować kolejnego wydania.
  • Mylenie sesji z rozliczeniem. Interakcja z klientem może się skończyć przed zamknięciem incydentu.

Co przykład pokazuje, a czego nie#

Model pokazuje uczestników wypłaty, rozdziela autoryzację od wydania banknotów i uwzględnia odmowę oraz niepełny wynik urządzenia. Ułatwia identyfikację odpowiedzialności i scenariuszy awaryjnych.

Nie jest specyfikacją bankową, projektem kryptograficznym ani procedurą rozliczeń. Rzeczywista implementacja wymaga zatwierdzonych standardów, wymagań bezpieczeństwa, dokumentacji urządzeń i testów integracyjnych.