diff --git a/.gitignore b/.gitignore new file mode 100644 index 00000000..1d672593 --- /dev/null +++ b/.gitignore @@ -0,0 +1,308 @@ +## Core latex/pdflatex auxiliary files: +*.aux +*.lof +*.log +*.lot +*.fls +*.out +*.toc +*.fmt +*.fot +*.cb +*.cb2 +.*.lb + +## Intermediate documents: +*.dvi +*.xdv +*-converted-to.* +# these rules might exclude image files for figures etc. +# *.ps +# *.eps +# *.pdf + +## Generated if empty string is given at "Please type another file name for output:" +.pdf + +## Bibliography auxiliary files (bibtex/biblatex/biber): +*.bbl +*.bbl-SAVE-ERROR +*.bcf +*.bcf-SAVE-ERROR +*.blg +*-blx.aux +*-blx.bib +*.run.xml + +## Build tool auxiliary files: +*.fdb_latexmk +*.synctex +*.synctex(busy) +*.synctex.gz +*.synctex.gz(busy) +*.pdfsync +*.rubbercache +rubber.cache + +## Build tool directories for auxiliary files +# latexrun +latex.out/ + +## Auxiliary and intermediate files from other packages: +# algorithms +*.alg +*.loa + +# achemso +acs-*.bib + +# amsthm +*.thm + +# beamer +*.nav +*.pre +*.snm +*.vrb + +# changes +*.soc + +# comment +*.cut + +# cprotect +*.cpt + +# elsarticle (documentclass of Elsevier journals) +*.spl + +# endnotes +*.ent + +# fixme +*.lox + +# feynmf/feynmp +*.mf +*.mp +*.t[1-9] +*.t[1-9][0-9] +*.tfm + +#(r)(e)ledmac/(r)(e)ledpar +*.end +*.?end +*.[1-9] +*.[1-9][0-9] +*.[1-9][0-9][0-9] +*.[1-9]R +*.[1-9][0-9]R +*.[1-9][0-9][0-9]R +*.eledsec[1-9] +*.eledsec[1-9]R +*.eledsec[1-9][0-9] +*.eledsec[1-9][0-9]R +*.eledsec[1-9][0-9][0-9] +*.eledsec[1-9][0-9][0-9]R + +# glossaries +*.acn +*.acr +*.glg +*.glo +*.gls +*.glsdefs +*.lzo +*.lzs +*.slg +*.slo +*.sls + +# uncomment this for glossaries-extra (will ignore makeindex's style files!) +# *.ist + +# gnuplot +*.gnuplot +*.table + +# gnuplottex +*-gnuplottex-* + +# gregoriotex +*.gaux +*.glog +*.gtex + +# htlatex +*.4ct +*.4tc +*.idv +*.lg +*.trc +*.xref + +# hypdoc +*.hd + +# hyperref +*.brf + +# knitr +*-concordance.tex +# TODO Uncomment the next line if you use knitr and want to ignore its generated tikz files +# *.tikz +*-tikzDictionary + +# listings +*.lol + +# luatexja-ruby +*.ltjruby + +# makeidx +*.idx +*.ilg +*.ind + +# minitoc +*.maf +*.mlf +*.mlt +*.mtc[0-9]* +*.slf[0-9]* +*.slt[0-9]* +*.stc[0-9]* + +# minted +_minted* +*.pyg + +# morewrites +*.mw + +# newpax +*.newpax + +# nomencl +*.nlg +*.nlo +*.nls + +# pax +*.pax + +# pdfpcnotes +*.pdfpc + +# sagetex +*.sagetex.sage +*.sagetex.py +*.sagetex.scmd + +# scrwfile +*.wrt + +# svg +svg-inkscape/ + +# sympy +*.sout +*.sympy +sympy-plots-for-*.tex/ + +# pdfcomment +*.upa +*.upb + +# pythontex +*.pytxcode +pythontex-files-*/ + +# tcolorbox +*.listing + +# thmtools +*.loe + +# TikZ & PGF +*.dpth +*.md5 +*.auxlock + +# titletoc +*.ptc + +# todonotes +*.tdo + +# vhistory +*.hst +*.ver + +# easy-todo +*.lod + +# xcolor +*.xcp + +# xmpincl +*.xmpi + +# xindy +*.xdy + +# xypic precompiled matrices and outlines +*.xyc +*.xyd + +# endfloat +*.ttt +*.fff + +# Latexian +TSWLatexianTemp* + +## Editors: +# WinEdt +*.bak +*.sav + +# Texpad +.texpadtmp + +# LyX +*.lyx~ + +# Kile +*.backup + +# gummi +.*.swp + +# KBibTeX +*~[0-9]* + +# TeXnicCenter +*.tps + +# auto folder when using emacs and auctex +./auto/* +*.el + +# expex forward references with \gathertags +*-tags.tex + +# standalone packages +*.sta + +# Makeindex log files +*.lpz + +# xwatermark package +*.xwm + +# REVTeX puts footnotes in the bibliography by default, unless the nofootinbib +# option is specified. Footnotes are the stored in a file with suffix Notes.bib. +# Uncomment the next line to have this generated file ignored. +#*Notes.bib \ No newline at end of file diff --git a/.vscode/extensions.json b/.vscode/extensions.json new file mode 100644 index 00000000..ca9e6a0c --- /dev/null +++ b/.vscode/extensions.json @@ -0,0 +1,5 @@ +{ + "recommendations": [ + "hediet.vscode-drawio" + ] +} \ No newline at end of file diff --git a/report/draft/AIS Wymagania funkcjonalne.md b/report/draft/AIS Wymagania funkcjonalne.md new file mode 100644 index 00000000..7d055a4e --- /dev/null +++ b/report/draft/AIS Wymagania funkcjonalne.md @@ -0,0 +1,270 @@ +[https://github.com/Artur-Romaniuk/ais](https://github.com/Artur-Romaniuk/ais) +[https://www.overleaf.com/project/67e843e5c78b52b01a88211a](https://www.overleaf.com/project/67e843e5c78b52b01a88211a) + +System e-Toll do zbierania danych na temat ruchu pojazdów po polskich drogach i naliczania należności za przejazdy. + +Rezultatem projektu powinien być dokument PDF, zawierający następujące elementy: + +1. Wymagania funkcjonalne. + * pogrupowana lista wymagań + * zidentyfikować jeden kluczowy proces biznesowy i szczegółowo ten proces zdefiniować. Definicja procesu to po prostu: + * cel procesu + * stan początkowy + * stan końcowy + * kroki procesu, z uwzględnieniem sytuacji wyjątkowych. +2. Wymagania niefunkcjonalne. + * geograficzna skala działania + * liczba obsługiwanych klientów + * liczba obsługiwanych zdarzeń biznesowych w określonym czasie (na godzinę/dziennie/miesięcznie etc.) + * wymagania wydajnościowe + * wymagania niezawodnościowe + * wymagania bezpieczeństwa + * .... +3. Projekt systemu w postaci modelu C4 (https://c4model.com/) + * wystarczą 3 pierwsze poziomy : context, containers, components, nie wymagam poziomu code + * diagram dynamiczny(dynamic diagram) realizujący opisany w wymaganiach proces biznesowy + * diagram wdrożenia (deploymen diagram) +4. Dyskusja zastosowanych wzorców i/lub taktyk architektonicznych \- w celu wyboru odpowiednich rozwiązań należy się odwołać do wymagań funkcjonalnych i niefunkcjonalnych. +5. Decyzje architektoniczne w postaci modelu MAD 2.0 + +# Wymagania funkcjonalne + +\# Wymagania funkcjonalne dla Systemu e-Toll + +\#\# Kluczowy proces biznesowy: Naliczanie i pobieranie opłat za przejazd + +\#\#\# 1\. Cel procesu + +1) Wykrywanie pojazdów na płatnych odcinkach dróg +2) Naliczanie należności zgodnie z taryfami +3) Pobieranie opłat od użytkowników + +\#\#\# 2\. Stan początkowy +Pojazd niezarejestrowany w systemie jako znajdujący się na płatnym odcinku drogi, z kontem użytkownika posiadającym określony stan środków (prepaid) lub limitem kredytowym (postpaid). + +\#\#\# 3\. Stan końcowy +Prawidłowo naliczona i pobrana opłata za przejazd, zaksięgowana w systemie finansowym, z wygenerowanym potwierdzeniem dla użytkownika oraz aktualizacją stanu konta. + +\#\#\# 4\. Kroki procesu +1\. Identyfikacja pojazdu wjeżdżającego na płatny odcinek (poprzez urządzenie OBU, aplikację mobilną lub kamery ANPR) \[Dla redundancji, im więcej systemów tym większa szansa na identyfikację) +2\. Zebranie danych o pojeździe (kategoria, klasa emisji spalin, masa) +3\. Rozpoczęcie śledzenia przejazdu i rejestracja czasu wjazdu +4\. Monitorowanie trasy przejazdu przez punkty kontrolne +5\. Identyfikacja zjazdu z płatnego odcinka +6\. Obliczenie należności na podstawie przebytej trasy i charakterystyki pojazdu +7\. Weryfikacja dostępności środków na koncie użytkownika +8\. Pobranie opłaty z konta użytkownika +9\. Wygenerowanie potwierdzenia transakcji +10\. Aktualizacja salda konta użytkownika + +\*\*Obsługa sytuacji wyjątkowych:\*\* +\- Jeśli identyfikacja pojazdu nie jest możliwa: uruchomienie procedury rejestracji incydentu z dokumentacją wizualną (zdjęcia niezidentyfikowanego pojazdu) +\- W przypadku niewystarczających środków na koncie: + +1) Zablokowanie konta do momentu zapłacenia +2) W przypadku braku zapłaty w określonym czasie, uruchomienie procedury windykacyjnej + +\- Przy awarii urządzenia OBU: automatyczne przełączenie na identyfikację przez system kamer ANPR +\- W razie przerwy w komunikacji: lokalne buforowanie danych i synchronizacja po przywróceniu łączności +\- Jeśli zidentyfikowano omijanie bramek: + +1. Poinformowanie użytkownika +2. uruchomienie procedury kontrolnej +3. naliczenie kary + +\#\# Wymagania funkcjonalne + +1\. \*\*System rejestracji użytkowników\*\* \- System musi umożliwiać rejestrację nowych użytkowników z weryfikacją tożsamości, zbieraniem danych o pojazdach (w tym masa, klasa emisji, kategoria) oraz wyborem metody płatności (prepaid lub postpaid). + +2\. \*\*Moduł geolokalizacji pojazdów\*\* \- System musi określać pozycję pojazdów z dokładnością do 10 metrów, wykorzystując dane GPS z urządzeń OBU lub aplikacji mobilnej, aktualizowane nie rzadziej niż co 30 sekund podczas przejazdu. + +3\. \*\*System rozpoznawania tablic rejestracyjnych (ANPR)\*\* \- System musi identyfikować pojazdy poprzez kamery ANPR z dokładnością co najmniej 98% w różnych warunkach pogodowych i oświetleniowych, jako dopełnienie jeśli wszystkie systemy działają poprawnie lub alternatywa dla urządzeń OBU w razie awarii.. + +4\. \*\*Elastyczny system taryfowy\*\* \- System musi obsługiwać zróżnicowane taryfy opłat w zależności od: typu pojazdu, masy całkowitej, klasy emisji spalin, pory dnia, dnia tygodnia oraz stopnia zatłoczenia drogi. + +5\. \*\*Moduł rozliczeń i płatności\*\* \- System musi obsługiwać różne metody płatności (karty płatnicze, przelewy, płatności mobilne, blik) z możliwością automatycznego doładowania konta prepaid oraz wystawiania faktur elektronicznych zgodnych z przepisami prawa. + +6\. \*\*System powiadomień dla użytkowników\*\* \- System musi wysyłać automatyczne powiadomienia do użytkowników (aplikacja, mail \+ sms) o: niskim stanie konta, zbliżającym się terminie płatności, dokonanych transakcjach oraz zmianach w taryfach i regulaminie. + +7\. \*\*Moduł raportowania i analityki\*\* \- System musi generować raporty dotyczące natężenia ruchu, generowanych przychodów, incydentów oraz efektywności egzekwowania opłat, z możliwością eksportu danych w formatach CSV i PDF. + +8\. \*\*System wykrywania naruszeń\*\* \- System musi identyfikować próby obejścia opłat (np. manipulacja urządzeniem OBU, podawanie fałszywych danych o pojeździe) i automatycznie uruchamiać procedury weryfikacyjne. + +9\. \*\*Portal samoobsługowy dla użytkowników\*\* \- System musi udostępniać portal internetowy oraz aplikację mobilną umożliwiającą użytkownikom zarządzanie kontem, przeglądanie historii przejazdów i opłat, generowanie raportów oraz aktualizację danych pojazdu. + +10\. System musi umożliwiać ręczną korektę naliczonej opłaty przez operatora w przypadku zgłoszenia błędu przez użytkownika. Zakładając, że system źle naliczył opłatę np. Użytkownik został obciążony za trasę, której nie przejechał lub przypisano niewłaściwą kategorię pojazdu. Użytkownik zgłasza błąd do obsługi systemu. W takim przypadku operator musi mieć możliwość ręcznej korekty naliczonej opłaty np. Anulowanie opłaty, zmniejszenie jej lub ponowne przeliczenie, jeżeli zgłoszenie użytkownika okaże się zasadne. Zasadność zgłoszenia musi być weryfikowalna poprzez fizyczne zdjęcia pojazdu + +# Wymagania niefunkcjonalne + +1\. \*\*Wydajność systemu\*\* \- System musi obsługiwać jednoczesne przetwarzanie danych z co [najmniej 200,000 pojazdów w godzinach szczytu](https://forsal.pl/transport/drogi/artykuly/8295957,najbardziej-obciazone-drogi-w-polsce-s8-s2-a4-s86-mapa.html), z czasem odpowiedzi dla transakcji poniżej 1s oraz przetwarzaniem danych geolokalizacyjnych w czasie rzeczywistym. + +2\. \*\*Dostępność systemu\*\* \- System musi zapewniać dostępność na poziomie 99,9% (maksymalny czas niedostępności: \~9 godzin rocznie), z planowanymi oknami serwisowymi w godzinach nocnych (1:00-4:00) i z odpowiednim wyprzedzeniem komunikowanym użytkownikom. + +3\. \*\*Bezpieczeństwo danych\*\* \- System musi zapewniać: + +1) Szyfrowanie danych w spoczynku i podczas transmisji (minimum AES-256) +2) Zgodność z normą ISO/IEC 27001 +3) Wielopoziomową autoryzację użytkowników (hasło \+ kod sms) +4) Pełną zgodność z RODO, włączając automatyczne mechanizmy anonimizacji danych historycznych starszych niż 5 lat. + +4\. \*\*Skalowalność\*\* \- System musi posiadać architekturę umożliwiającą skalowanie w celu [obsługi wzrostu liczby użytkowników o 30% rocznie bez pogorszenia wydajności](https://kpmg.com/pl/pl/home/media/press-releases/2024/02/liczba-rejestracji-nowych-samochodow-osobowych-wzrosla-o-13-2-procent-w-2023-roku.html#:~:text=sztuk.-,Liczba%20rejestracji%20nowych%20samochod%C3%B3w%20osobowych%20w%20Polsce%20w%202023%20roku,szt.&text=W%202023%20roku%20w%20Polsce,wi%C4%99cej%20ni%C5%BC%20w%202022%20roku.), z automatycznym zwiększeniem zasobów w odpowiedzi na zwiększone obciążenie w ciągu dnia. + +5\. \*\*Niezawodność i odporność na awarie\*\* \- System musi zawierać rozwiązania wysokiej dostępności z nadmiarowością komponentów krytycznych, automatycznym przełączaniem awaryjnym poniżej 10 sekund oraz mechanizmem ciągłej replikacji danych między geograficznie odległymi centrami danych, zapewniając RPO (Recovery Point Objective) poniżej 5 minut i RTO (Recovery Time Objective) poniżej 30 minut. + +6\. \*\*Interoperacyjność\*\* \- System musi obsługiwać standardy interoperacyjności z europejskimi systemami elektronicznego poboru opłat (zgodnie z dyrektywą EETS), zapewniając pełną wymianę danych poprzez standardowe API (REST/SOAP) z minimum 99,5% dostępnością interfejsów integracyjnych. + +7\. \*\*Użyteczność i dostępność interfejsów\*\* \- Interfejsy użytkownika (portal i aplikacja mobilna) muszą spełniać standardy WCAG 2.1 na poziomie AA, obsługiwać minimum 5 języków (polski, angielski, niemiecki, ukraiński, rosyjski), zapewniać responsywność na urządzeniach mobilnych oraz wykazywać wskaźnik satysfakcji użytkowników (CSAT) na poziomie minimum 85%. + +8\. \*\*Audytowanie i śledzenie aktywności\*\* \- System musi rejestrować wszystkie operacje w niezmienialne logi z zachowaniem zgodności z wymogami prawnymi dotyczącymi dowodów elektronicznych, umożliwiać niemodyfikowalny ślad audytu dla wszystkich transakcji finansowych oraz zapewniać przechowywanie logów przez minimum 5 lat z możliwością szybkiego wyszukiwania. + +9\. \*\*Efektywność zarządzania danymi\*\* \- System musi umożliwiać archiwizację i zarządzanie cyklem życia danych zgodnie z polityką retencji, zapewniać kompresję danych historycznych na poziomie minimum 80% oraz optymalizację zapytań do bazy danych z czasem odpowiedzi poniżej 10 sekund dla 90% zapytań raportowych. + +10\. \*\*Utrzymywalność i modyfikowalność\*\* \- System musi być zaprojektowany z wykorzystaniem architektury modułowej i mikroserwisowej, umożliwiającej niezależną aktualizację poszczególnych komponentów bez przerywania działania całości systemu, z automatycznymi testami regresji pokrywającymi minimum 90% kodu oraz pełną dokumentacją techniczną aktualizowaną przy każdej **dużej** (takiej która sprawia że system nie jest kompatybilny z poprzednią wersją) zmianie. + +11\. \*\*System integracji z zewnętrznymi bazami danych\*\* \- System musi komunikować się z zewnętrznymi bazami danych (np. CEPiK, rejestry pojazdów innych krajów) w celu weryfikacji danych pojazdów oraz wymiany informacji o użytkownikach z zagranicznymi systemami poboru opłat. + +12\. Zgodność prawna i regulacyjna \- System musi spełniać wszystkie obowiązujące przepisy prawa krajowego oraz unijnego dotyczące elektronicznego poboru opłat. Ustawę o drogach publicznych, dyrektywę [EETS](https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX%3A32019L0520), przepisy podatkowe oraz przepisy dotyczące ochrony konkurencji i konsumentów. + +13\. Czas wdrożenia poprawek krytycznych \- w przypadku wykrycia krytycznego błędu (np. Uniemożliwiającego naliczenie opłaty lub przetwarzanie przejazdów) poprawka musi zostać wdrożona w ciągu maksymalnie 24 godzin od momentu potwierdzenia błędu. + +14\. Transparentność naliczanych opłat \- system musi umożliwiać użytkownikom końcowym wgląd w szczegółowe informacje dotyczące każdej naliczonej opłaty. Czas przejazdu, odcinki dróg, taryfy oraz podstawy naliczenia. + +15\. Elastyczność taryf \- system musi obsługiwać dynamiczne taryfy drogowe (np. Zmienne w zależności od natężenia ruchu czy poziomu emisji pojazdu) z możliwoścą wdrażania nowych taryf bez konieczności przerywania działania systemu. + +16\. Personalizacja powiadomień dla użytkowników \- system musi umożliwić użytkownikom wybór otrzymywania powiadomień np. (sms, e-mail, powiadomienie push w aplikacji) z opcją definiowania progów powiadomień (np. Przekroczenie salda, opłata powyżej X zł etc.) + +Decyzje architektoniczne: + +1\. Podział na warstwy +![][image1] + +* Warstwa prezentacji: trzy różne aplikacje klienckie — aplikacja webowa, mobilna i aplikacja na urządzenia embedded. +* Warstwa logiki biznesowej: centralna aplikacja serwerowa (serverApp), w której znajdują się komponenty takie jak UserService, PaymentService, PositionService itd. +* Warstwa dostępu do danych: komponenty UserRepository, PaymentRepository. +* Warstwa danych: baza danych Oracle z mechanizmem failover. + +Decyzja: Rozdzielenie odpowiedzialności na warstwy zwiększa modularność i ułatwia zarządzanie kodem oraz jego testowanie. + +Alternatywa: Architektura mikroserwisowa +Zalety alternatywy: + +* Lepsza skalowalność poszczególnych komponentów +* Możliwość niezależnego wdrażania i rozwijania usług +* Lepsza odporność na awarie (awaria jednego serwisu ≠ awaria całego systemu) + +Wady alternatywy: + +* Większa złożoność wdrożeniowa (DevOps, CI/CD, monitoring) +* Konieczność rozwiązywania problemów związanych z komunikacją między serwisami +* Trudniejsze debugowanie i testowanie end-to-end + +2\. Modularność i komponenty (Component-based Design) +![][image2] + +* Serwerowa aplikacja została podzielona na komponenty pełniące konkretne role (SigninController, TollController, MainComponent, itd.). +* Każdy komponent ma jasno zdefiniowaną odpowiedzialność, zgodnie z zasadą Single Responsibility Principle. + +Decyzja: Wprowadzenie komponentów umożliwia łatwe rozszerzanie i testowanie poszczególnych fragmentów systemu. + +Alternatywa: Monolityczna aplikacja serwerowa +Zalety alternatywy: + +* Prostsza implementacja i wdrożenie +* Mniejsza liczba zależności i konfiguracji +* Mniej złożone środowisko developerskie + +Wady alternatywy: + +* Trudniejsza skalowalność i refaktoryzacja +* Każda zmiana wymaga redeploy całej aplikacji +* Trudniejsze testowanie izolowanych funkcji + +3\. Wielokanałowy dostęp (Multi-Platform Clients) +![][image3] + +* Użytkownicy mogą korzystać z systemu za pomocą aplikacji mobilnej, webowej lub urządzeń embedded. + +Decyzja: Umożliwienie różnym grupom użytkowników (np. administratorzy vs kierowcy) dostępu do funkcji systemu w najbardziej dogodny sposób. + +Alternatywa: Tylko aplikacja mobilna (np. PWA lub natywna) +Zalety alternatywy: + +* Uproszczony interfejs użytkownika +* Jedna platforma do utrzymania +* Lepsze dopasowanie do kontekstu użytkownika (kierowcy) + +Wady alternatywy: + +* Brak wygodnego interfejsu dla administratorów lub analityków +* Mniejsza elastyczność użytkowania +* Trudności z dostępem do systemu z urządzeń stacjonarnych + +4\. Rozdzielenie ról i uprawnień +![][image4] +Administrator ma dostęp tylko przez aplikację webową. +Kierowca może korzystać z trzech różnych interfejsów — w zależności od potrzeb. +Decyzja: Jasny podział ról zwiększa bezpieczeństwo i ergonomię systemu. + +Alternatywa: Jeden zunifikowany interfejs z uprawnieniami na poziomie konta +Zalety alternatywy: + +* Mniejsze zróżnicowanie UI +* Mniej kodu i testów związanych z różnymi platformami + +Wady alternatywy: + +* Mniejsza przejrzystość +* Możliwość przypadkowego ujawnienia funkcji nieprzeznaczonych dla danego typu użytkownika + +5\. Integracja z zewnętrznymi systemami +![][image5] +System płatności (systemPlatnosci) oraz system archiwizacji danych (archiwum) są zewnętrznymi systemami zintegrowanymi z systemem e-Toll. +Decyzja: Wydzielenie tych odpowiedzialności do zewnętrznych systemów pozwala na lepsze skalowanie oraz wykorzystanie istniejących rozwiązań. +Alternatywa: Wszystko w ramach jednej aplikacji (np. własny moduł płatności i archiwizacji) +Zalety alternatywy: + +* Większa kontrola nad logiką +* Mniejsze zależności zewnętrzne + +Wady alternatywy: + +* Większe ryzyko błędów w obszarach regulowanych prawnie (np. płatności) +* Większe koszty utrzymania i certyfikacji +* Brak skalowalności i elastyczności + +6\. Wysoka dostępność i odporność na awarie +![][image6] +Baza danych jest replikowana (primary–secondary). +Oddzielne deployment node'y dla różnych typów urządzeń oraz dla aplikacji serwerowej i bazy danych. +Failover serwera bazy danych — Oracle \- Secondary. +Decyzja: Architektura uwzględnia mechanizmy zapewniające ciągłość działania systemu nawet w przypadku awarii. +Alternatywa: Deployment w chmurze +Zalety alternatywy: + +* Duża skalowalność +* Bezpieczeństwo i redundancja + +Wady alternatywy: + +* Wyższe koszty +* Przetwarzanie danych przez inne podmioty + +7\. Wybór technologii wdrożeniowych +![][image7] +System hostowany na serwerach z Ubuntu 24.04 LTS. +Serwer aplikacji oparty o Apache Tomcat 8.x. +Baza danych Oracle 12c. +Decyzja: Użycie sprawdzonych technologii o długoterminowym wsparciu i wysokiej wydajności. +Alternatywa: Cloud-native stack – np. AWS/GCP +Zalety alternatywy: + +* Automatyczne skalowanie, monitoring, CI/CD +* Niższe koszty utrzymania fizycznej infrastruktury +* Łatwiejsze zarządzanie kontenerami i usługami + +Wady alternatywy: + +* Uzależnienie od chmury (vendor lock-in) +* Potrzeba opanowania nowych technologii +* Potencjalne wyższe koszty początkowe + diff --git a/report/draft/AIS Wymagania funkcjonalne.odt b/report/draft/AIS Wymagania funkcjonalne.odt new file mode 100644 index 00000000..58cc8835 Binary files /dev/null and b/report/draft/AIS Wymagania funkcjonalne.odt differ diff --git a/report/draft/AIS Wymagania funkcjonalne.pdf b/report/draft/AIS Wymagania funkcjonalne.pdf new file mode 100644 index 00000000..f77cc3b9 Binary files /dev/null and b/report/draft/AIS Wymagania funkcjonalne.pdf differ diff --git a/report/draft/mad2ais-1.drawio b/report/draft/mad2ais-1.drawio new file mode 100644 index 00000000..54e8035a --- /dev/null +++ b/report/draft/mad2ais-1.drawio @@ -0,0 +1,886 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/report/draft/markdown_images.md b/report/draft/markdown_images.md new file mode 100644 index 00000000..8e6979f6 --- /dev/null +++ b/report/draft/markdown_images.md @@ -0,0 +1,13 @@ +[image1]: + +[image2]: + +[image3]: + +[image4]: + +[image5]: + +[image6]: + +[image7]: \ No newline at end of file diff --git a/report/final/images/c4/component_server_app.png b/report/final/images/c4/component_server_app.png new file mode 100644 index 00000000..285fb111 Binary files /dev/null and b/report/final/images/c4/component_server_app.png differ diff --git a/report/final/images/c4/deployment.png b/report/final/images/c4/deployment.png new file mode 100644 index 00000000..0cd76901 Binary files /dev/null and b/report/final/images/c4/deployment.png differ diff --git a/report/final/images/c4/etoll.png b/report/final/images/c4/etoll.png new file mode 100644 index 00000000..cff584b9 Binary files /dev/null and b/report/final/images/c4/etoll.png differ diff --git a/report/final/images/c4/etool_glebiej.png b/report/final/images/c4/etool_glebiej.png new file mode 100644 index 00000000..4e2bb24e Binary files /dev/null and b/report/final/images/c4/etool_glebiej.png differ diff --git a/report/final/images/dostep_do_systemu.png b/report/final/images/dostep_do_systemu.png new file mode 100644 index 00000000..e745060b Binary files /dev/null and b/report/final/images/dostep_do_systemu.png differ diff --git a/report/final/images/organizacja_aplikacji_serwerowej.png b/report/final/images/organizacja_aplikacji_serwerowej.png new file mode 100644 index 00000000..da920127 Binary files /dev/null and b/report/final/images/organizacja_aplikacji_serwerowej.png differ diff --git a/report/final/images/realizacja_obslugi_platnosci_i_archiwizacji_danych.png b/report/final/images/realizacja_obslugi_platnosci_i_archiwizacji_danych.png new file mode 100644 index 00000000..b044a412 Binary files /dev/null and b/report/final/images/realizacja_obslugi_platnosci_i_archiwizacji_danych.png differ diff --git a/report/final/images/uprawnienia_dla_uzytkownikow.png b/report/final/images/uprawnienia_dla_uzytkownikow.png new file mode 100644 index 00000000..c1e7bb56 Binary files /dev/null and b/report/final/images/uprawnienia_dla_uzytkownikow.png differ diff --git a/report/final/images/wybor_architektury.png b/report/final/images/wybor_architektury.png new file mode 100644 index 00000000..08321545 Binary files /dev/null and b/report/final/images/wybor_architektury.png differ diff --git a/report/final/images/wybor_technologii_wdrozeniowej.png b/report/final/images/wybor_technologii_wdrozeniowej.png new file mode 100644 index 00000000..213b12d6 Binary files /dev/null and b/report/final/images/wybor_technologii_wdrozeniowej.png differ diff --git a/report/final/images/zapewnienie_dostepnosci_i_odpornosci_na_awarie.png b/report/final/images/zapewnienie_dostepnosci_i_odpornosci_na_awarie.png new file mode 100644 index 00000000..da44efdd Binary files /dev/null and b/report/final/images/zapewnienie_dostepnosci_i_odpornosci_na_awarie.png differ diff --git a/report/final/ver1/main.tex b/report/final/ver1/main.tex new file mode 100644 index 00000000..b3be20c6 --- /dev/null +++ b/report/final/ver1/main.tex @@ -0,0 +1,236 @@ +\documentclass[a4paper,12pt]{article} + +% Packages +\usepackage{amsmath, amssymb, amsthm} % For math symbols and theorems +\usepackage{graphicx} % For including images +\usepackage{hyperref} % For hyperlinks +\usepackage{geometry} % Page layout +\usepackage{fancyhdr} % Header and footer +\usepackage{listings} % Code listings +\usepackage{xcolor} % Colors for code +\usepackage{biblatex} % References +\usepackage{float} % Dodaj na początku dokumentu +\usepackage{polski} % Obsługa języka polskiego +\addbibresource{references.bib} + +% Page Setup +\geometry{margin=1in} +\pagestyle{fancy} +\fancyhf{} +\rhead{\thepage} +\lhead{Small Documentation} +\renewcommand{\headrulewidth}{0.4pt} + +% Code Formatting +\lstset{ + language=Python, + basicstyle=\ttfamily\small, + keywordstyle=\color{blue}, + commentstyle=\color{gray}, + stringstyle=\color{red}, + breaklines=true, + frame=single +} + +% Theorem, Definition, and Example Styles +\theoremstyle{definition} +\newtheorem{definition}{Definition} +\newtheorem{theorem}{Theorem} +\newtheorem{example}{Example} + +\begin{document} + +% Title Page +\title{AIS \\ Projekt} +\author{Jakub Woźniak 318745 \\ Filip Budzyński 319021 \\} +\date{\small \today} +\maketitle + +\begin{abstract} +Projekt opiera sie... +\end{abstract} + +\tableofcontents +\newpage + +\section{Wymagania funkcjonalne} + +\subsection{Pogrupowana lista wymagań} + +\begin{itemize} + \item \textbf{Rejestracja i zarządzanie kontem} + \begin{itemize} + \item Rejestracja konta użytkownika (indywidualnego lub firmowego) + \item Dodawanie pojazdów i przypisywanie urządzeń lokalizacyjnych + \item Zarządzanie danymi użytkownika + \end{itemize} + + \item \textbf{Monitoring pojazdów} + \begin{itemize} + \item Odbieranie danych GPS w czasie rzeczywistym + \item Identyfikacja płatnych odcinków + \item Obsługa przerw w sygnale + \end{itemize} + + \item \textbf{Naliczanie opłat} + \begin{itemize} + \item Analiza przejazdu i naliczanie opłaty + \item Uwzględnianie kategorii pojazdu, pory dnia, długości trasy + \item Obsługa taryf i zniżek + \end{itemize} + + \item \textbf{Płatności i fakturowanie} + \begin{itemize} + \item Doładowanie konta + \item Historia opłat i przejazdów + \item Generowanie faktur + \end{itemize} + + \item \textbf{Obsługa wyjątków} + \begin{itemize} + \item Brak sygnału GPS – interpolacja pozycji + \item Brak środków – powiadomienie i odroczenie płatności + \item Korekta błędnych danych, reklamacje + \end{itemize} +\end{itemize} + +\subsection{Kluczowy proces biznesowy: Naliczanie opłaty} + +\begin{itemize} + \item \textbf{Cel:} Naliczenie opłaty za przejazd przez płatny odcinek drogi + \item \textbf{Stan początkowy:} System odbiera dane GPS pojazdu + \item \textbf{Stan końcowy:} Opłata naliczona i zarejestrowana + \item \textbf{Kroki:} + \begin{enumerate} + \item Odbiór danych GPS + \item Detekcja wjazdu/zjazdu z odcinka + \item Obliczenie opłaty + \item Sprawdzenie środków: + \begin{itemize} + \item Jeśli są: pobranie opłaty + \item Jeśli brak: zapis zobowiązania, notyfikacja + \end{itemize} + \item Zapis transakcji + \item Wystawienie e-faktury + \end{enumerate} +\end{itemize} + +\section{Wymagania niefunkcjonalne} + +\begin{itemize} + \item \textbf{Skala działania:} Polska, z możliwością rozszerzenia na UE + \item \textbf{Liczba klientów:} do 7 milionów aktywnych użytkowników + \item \textbf{Zdarzenia biznesowe:} + \begin{itemize} + \item 5 mln przejazdów dziennie + \item 200 tys. opłat/h + \item 10 tys. zapytań/min + \end{itemize} + \item \textbf{Wydajność:} <1s latencji, \textless 200 ms API + \item \textbf{Niezawodność:} SLA 99.95\%, redundancja + \item \textbf{Bezpieczeństwo:} + \begin{itemize} + \item TLS, MFA, role + \item Szyfrowanie danych lokalizacyjnych + \item Zgodność z RODO + \end{itemize} +\end{itemize} + +\section{Model C4} + +\begin{itemize} + \item \textbf{Poziom 1:} Kontekst – użytkownicy, systemy zewnętrzne, urządzenia + \item \textbf{Poziom 2:} Kontenery – frontend, backend, baza, billing + \item \textbf{Poziom 3:} Komponenty – mikroserwisy: płatności, GPS, billing, notyfikacje +\end{itemize} + +\section{Diagramy} + +\begin{itemize} + \item \textbf{Diagram dynamiczny:} Proces naliczania opłaty + \item \textbf{Diagram wdrożenia:} Kubernetes, CDN, bazy danych, load balancer +\end{itemize} + +\section{Zastosowane wzorce i taktyki} + +\begin{itemize} + \item CQRS – oddzielenie zapisu i odczytu + \item Event-Driven Architecture – system oparty na zdarzeniach + \item Saga Pattern – do obsługi błędów i retry + \item Service Mesh – np. Istio + \item Cache Aside – Redis dla odczytów + \item Sharding danych lokalizacyjnych +\end{itemize} + +\section{Model MAD 2.0 – decyzje architektoniczne} + +\begin{tabular}{|p{4cm}|p{4cm}|p{7cm}|} +\hline +\textbf{Decyzja} & \textbf{Alternatywy} & \textbf{Uzasadnienie} \\ +\hline +Architektura mikroserwisowa & Monolit & Skalowalność i niezależny rozwój komponentów \\ +\hline +TimescaleDB & MongoDB, Cassandra & Dane czasowo-lokalizacyjne w zoptymalizowany sposób \\ +\hline +gRPC do komunikacji & REST & Wydajność, binarny format, mniejsze opóźnienia \\ +\hline +Kafka jako event broker & RabbitMQ & Lepsza wydajność dla dużych wolumenów danych \\ +\hline +Kubernetes & VM & Skalowalność, automatyzacja, dostępność \\ +\hline +\end{tabular} + +% =============== +% MODELE MAD 2.0 +% =============== +\begin{figure}[h] + \centering \includegraphics[width=0.8\textwidth]{mad/mad2-wybor-architektury.png} + \caption{Model MAD 2.0 dla decyzji wyboru architektury systemu.} + \label{fig:csr} +\end{figure} + +\begin{figure}[h] + \centering \includegraphics[width=0.8\textwidth]{mad/mad2-organizacja-aplikacji-serwerowej.png} + \caption{Model MAD 2.0 dla decyzji organizacji aplikacji serwerowej.} + \label{fig:csr} +\end{figure} + +\begin{figure}[h] + \centering \includegraphics[width=0.8\textwidth]{mad/mad2-dostep-do-systemu.png} + \caption{Model MAD 2.0 dla decyzji dostępu do systemu.} + \label{fig:csr} +\end{figure} + +\begin{figure}[h] + \centering \includegraphics[width=0.8\textwidth]{mad/mad2-uprawniania-uzytkownikow.png} + \caption{Model MAD 2.0 dla decyzji o uprawnianiach dla użytkowników.} + \label{fig:csr} +\end{figure} + +\begin{figure}[h] + \centering \includegraphics[width=0.8\textwidth]{mad/mad2-obsluga-platnosci-archiwizacja-danych.png} + \caption{Model MAD 2.0 dla decyzji o realizacji obsługi płatności i archiwizacji danych.} + \label{fig:csr} +\end{figure} + +\begin{figure}[h] + \centering \includegraphics[width=0.8\textwidth]{mad/mad2-zapewnienie-dostepnosci.png} + \caption{Model MAD 2.0 dla decyzji zapewnienia dostępności i odporności na awarie.} + \label{fig:csr} +\end{figure} + +\begin{figure}[h] + \centering \includegraphics[width=0.8\textwidth]{mad/mad2-wybor-tech-wdrozeniowej.png} + \caption{Model MAD 2.0 dla decyzji wyboru technologii wdrożeniowej.} + \label{fig:csr} +\end{figure} + + + + +\end{document} + + +\printbibliography + +\end{document} diff --git a/report/final/ver2/etoll.pdf b/report/final/ver2/etoll.pdf new file mode 100644 index 00000000..04c5c032 Binary files /dev/null and b/report/final/ver2/etoll.pdf differ diff --git a/report/final/ver2/etoll.tex b/report/final/ver2/etoll.tex new file mode 100644 index 00000000..2924d53d --- /dev/null +++ b/report/final/ver2/etoll.tex @@ -0,0 +1,398 @@ +\documentclass[12pt]{article} +\usepackage[left=0.75in,right=0.75in,bottom=0.75in]{geometry} +\usepackage[polish]{babel} +\usepackage[utf8]{inputenc} +\usepackage{hyperref} +\usepackage{graphicx} +\usepackage{enumitem} +\usepackage{url} +\usepackage{listings} +\usepackage{booktabs} +\usepackage{multirow} +\usepackage{float} +\usepackage{titlesec} +\usepackage{xcolor} +\graphicspath{ {../images/} } + +% Configure hyperlinks +\hypersetup{ + colorlinks=true, + linkcolor=blue, + filecolor=magenta, + urlcolor=blue, + pdftitle={System e-Toll - Dokumentacja}, + pdfauthor={}, + pdfsubject={Wymagania funkcjonalne i niefunkcjonalne systemu e-Toll}, + pdfkeywords={e-Toll, wymagania, architektura, system} +} + +\title{System e-Toll \\ +\large Dokumentacja systemu do zbierania danych na temat ruchu pojazdów\\po polskich drogach i naliczania należności za przejazdy} +\author{Dawid Budzyński, Filip Budzyński \\ Artur Romaniuk, Krzysztof Rudnicki, Jakub Woźniak} +\date{\today} + +\begin{document} + +\maketitle + +\section{Wymagania funkcjonalne} + +\subsection{Kluczowy proces biznesowy: Naliczanie i pobieranie opłat za przejazd} + +\subsubsection{Cel procesu} +\begin{enumerate} + \item Wykrywanie pojazdów na płatnych odcinkach dróg + \item Naliczanie należności zgodnie z taryfami + \item Pobieranie opłat od użytkowników +\end{enumerate} + +\subsubsection{Stan początkowy} +Pojazd niezarejestrowany w systemie jako znajdujący się na płatnym odcinku drogi, z kontem użytkownika posiadającym określony stan środków (prepaid) lub limitem kredytowym (postpaid). + +\subsubsection{Stan końcowy} +Prawidłowo naliczona i pobrana opłata za przejazd, zaksięgowana w systemie finansowym, z wygenerowanym potwierdzeniem dla użytkownika oraz aktualizacją stanu konta. + +\subsubsection{Kroki procesu} +\begin{enumerate} + \item Identyfikacja pojazdu wjeżdżającego na płatny odcinek (poprzez urządzenie OBU, aplikację mobilną lub kamery ANPR) [Dla redundancji, im więcej systemów tym większa szansa na identyfikację] + \item Zebranie danych o pojeździe (kategoria, klasa emisji spalin, masa) + \item Rozpoczęcie śledzenia przejazdu i rejestracja czasu wjazdu + \item Monitorowanie trasy przejazdu przez punkty kontrolne + \item Identyfikacja zjazdu z płatnego odcinka + \item Obliczenie należności na podstawie przebytej trasy i charakterystyki pojazdu + \item Weryfikacja dostępności środków na koncie użytkownika + \item Pobranie opłaty z konta użytkownika + \item Wygenerowanie potwierdzenia transakcji + \item Aktualizacja salda konta użytkownika +\end{enumerate} + +\paragraph{Obsługa sytuacji wyjątkowych:} +\begin{itemize} + \item Jeśli identyfikacja pojazdu nie jest możliwa: uruchomienie procedury rejestracji incydentu z dokumentacją wizualną (zdjęcia niezidentyfikowanego pojazdu) + + \item W przypadku niewystarczających środków na koncie: + \begin{enumerate} + \item Zablokowanie konta do momentu zapłacenia + \item W przypadku braku zapłaty w określonym czasie, uruchomienie procedury windykacyjnej + \end{enumerate} + + \item Przy awarii urządzenia OBU: automatyczne przełączenie na identyfikację przez system kamer ANPR + + \item W razie przerwy w komunikacji: lokalne buforowanie danych i synchronizacja po przywróceniu łączności + + \item Jeśli zidentyfikowano omijanie bramek: + \begin{enumerate} + \item Poinformowanie użytkownika + \item Uruchomienie procedury kontrolnej + \item Naliczenie kary + \end{enumerate} +\end{itemize} + +\subsection{Lista wymagań funkcjonalnych} + +\begin{enumerate} + \item \textbf{System rejestracji użytkowników} - System musi umożliwiać rejestrację nowych użytkowników z weryfikacją tożsamości, zbieraniem danych o pojazdach (w tym masa, klasa emisji, kategoria) oraz wyborem metody płatności (prepaid lub postpaid). + + \item \textbf{Moduł geolokalizacji pojazdów} - System musi określać pozycję pojazdów z dokładnością do 10 metrów, wykorzystując dane GPS z urządzeń OBU lub aplikacji mobilnej, aktualizowane nie rzadziej niż co 30 sekund podczas przejazdu. + + \item \textbf{System rozpoznawania tablic rejestracyjnych (ANPR)} - System musi identyfikować pojazdy poprzez kamery ANPR z dokładnością co najmniej 98\% w różnych warunkach pogodowych i oświetleniowych, jako dopełnienie jeśli wszystkie systemy działają poprawnie lub alternatywa dla urządzeń OBU w razie awarii. + + \item \textbf{Elastyczny system taryfowy} - System musi obsługiwać zróżnicowane taryfy opłat w zależności od: typu pojazdu, masy całkowitej, klasy emisji spalin, pory dnia, dnia tygodnia oraz stopnia zatłoczenia drogi. + + \item \textbf{Moduł rozliczeń i płatności} - System musi obsługiwać różne metody płatności (karty płatnicze, przelewy, płatności mobilne, blik) z możliwością automatycznego doładowania konta prepaid oraz wystawiania faktur elektronicznych zgodnych z przepisami prawa. + + \item \textbf{System powiadomień dla użytkowników} - System musi wysyłać automatyczne powiadomienia do użytkowników (aplikacja, mail + sms) o: niskim stanie konta, zbliżającym się terminie płatności, dokonanych transakcjach oraz zmianach w taryfach i regulaminie. + + \item \textbf{Moduł raportowania i analityki} - System musi generować raporty dotyczące natężenia ruchu, generowanych przychodów, incydentów oraz efektywności egzekwowania opłat, z możliwością eksportu danych w formatach CSV i PDF. + + \item \textbf{System wykrywania naruszeń} - System musi identyfikować próby obejścia opłat (np. manipulacja urządzeniem OBU, podawanie fałszywych danych o pojeździe) i automatycznie uruchamiać procedury weryfikacyjne. + + \item \textbf{Portal samoobsługowy dla użytkowników} - System musi udostępniać portal internetowy oraz aplikację mobilną umożliwiającą użytkownikom zarządzanie kontem, przeglądanie historii przejazdów i opłat, generowanie raportów oraz aktualizację danych pojazdu. + + \item \textbf{System korekty opłat} - System musi umożliwiać ręczną korektę naliczonej opłaty przez operatora w przypadku zgłoszenia błędu przez użytkownika. Zakładając, że system źle naliczył opłatę np. Użytkownik został obciążony za trasę, której nie przejechał lub przypisano niewłaściwą kategorię pojazdu. Użytkownik zgłasza błąd do obsługi systemu. W takim przypadku operator musi mieć możliwość ręcznej korekty naliczonej opłaty np. Anulowanie opłaty, zmniejszenie jej lub ponowne przeliczenie, jeżeli zgłoszenie użytkownika okaże się zasadne. Zasadność zgłoszenia musi być weryfikowalna poprzez fizyczne zdjęcia pojazdu. +\end{enumerate} + +\section{Wymagania niefunkcjonalne} + +\begin{enumerate} + \item \textbf{Wydajność systemu} - System musi obsługiwać jednoczesne przetwarzanie danych z co najmniej 200,000 pojazdów w godzinach szczytu\footnote{\url{https://forsal.pl/transport/drogi/artykuly/8295957,najbardziej-obciazone-drogi-w-polsce-s8-s2-a4-s86-mapa.html}}, z czasem odpowiedzi dla transakcji poniżej 1s oraz przetwarzaniem danych geolokalizacyjnych w czasie rzeczywistym. + + \item \textbf{Dostępność systemu} - System musi zapewniać dostępność na poziomie 99,9\% (maksymalny czas niedostępności: $\sim$9 godzin rocznie), z planowanymi oknami serwisowymi w godzinach nocnych (1:00-4:00) i z odpowiednim wyprzedzeniem komunikowanym użytkownikom. + + \item \textbf{Bezpieczeństwo danych} - System musi zapewniać: + \begin{enumerate} + \item Szyfrowanie danych w spoczynku i podczas transmisji (minimum AES-256) + \item Zgodność z normą ISO/IEC 27001 + \item Wielopoziomową autoryzację użytkowników (hasło + kod sms) + \item Pełną zgodność z RODO, włączając automatyczne mechanizmy anonimizacji danych historycznych starszych niż 5 lat. + \end{enumerate} + + \item \textbf{Skalowalność} - System musi posiadać architekturę umożliwiającą skalowanie w celu obsługi wzrostu liczby użytkowników o 30\% rocznie bez pogorszenia wydajności\footnote{\url{https://kpmg.com/pl/pl/home/media/press-releases/2024/02/liczba-rejestracji-nowych-samochodow-osobowych-wzrosla-o-13-2-procent-w-2023-roku.html}}, z automatycznym zwiększeniem zasobów w odpowiedzi na zwiększone obciążenie w ciągu dnia. + + \item \textbf{Niezawodność i odporność na awarie} - System musi zawierać rozwiązania wysokiej dostępności z nadmiarowością komponentów krytycznych, automatycznym przełączaniem awaryjnym poniżej 10 sekund oraz mechanizmem ciągłej replikacji danych między geograficznie odległymi centrami danych, zapewniając RPO (Recovery Point Objective) poniżej 5 minut i RTO (Recovery Time Objective) poniżej 30 minut. + + \item \textbf{Interoperacyjność} - System musi obsługiwać standardy interoperacyjności z europejskimi systemami elektronicznego poboru opłat (zgodnie z dyrektywą EETS\footnote{\url{https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX\%3A32019L0520}}), zapewniając pełną wymianę danych poprzez standardowe API (REST/SOAP) z minimum 99,5\% dostępnością interfejsów integracyjnych. + + \item \textbf{Użyteczność i dostępność interfejsów} - Interfejsy użytkownika (portal i aplikacja mobilna) muszą spełniać standardy WCAG 2.1 na poziomie AA, obsługiwać minimum 5 języków (polski, angielski, niemiecki, ukraiński, rosyjski), zapewniać responsywność na urządzeniach mobilnych oraz wykazywać wskaźnik satysfakcji użytkowników (CSAT) na poziomie minimum 85\%. + + \item \textbf{Audytowanie i śledzenie aktywności} - System musi rejestrować wszystkie operacje w niezmienialne logi z zachowaniem zgodności z wymogami prawnymi dotyczącymi dowodów elektronicznych, umożliwiać niemodyfikowalny ślad audytu dla wszystkich transakcji finansowych oraz zapewniać przechowywanie logów przez minimum 5 lat z możliwością szybkiego wyszukiwania. + + \item \textbf{Efektywność zarządzania danymi} - System musi umożliwiać archiwizację i zarządzanie cyklem życia danych zgodnie z polityką retencji, zapewniać kompresję danych historycznych na poziomie minimum 80\% oraz optymalizację zapytań do bazy danych z czasem odpowiedzi poniżej 10 sekund dla 90\% zapytań raportowych. + + \item \textbf{Utrzymywalność i modyfikowalność} - System musi być zaprojektowany z wykorzystaniem architektury modułowej i mikroserwisowej, umożliwiającej niezależną aktualizację poszczególnych komponentów bez przerywania działania całości systemu, z automatycznymi testami regresji pokrywającymi minimum 90\% kodu oraz pełną dokumentacją techniczną aktualizowaną przy każdej \textbf{dużej} (takiej która sprawia że system nie jest kompatybilny z poprzednią wersją) zmianie. + + \item \textbf{System integracji z zewnętrznymi bazami danych} - System musi komunikować się z zewnętrznymi bazami danych (np. CEPiK, rejestry pojazdów innych krajów) w celu weryfikacji danych pojazdów oraz wymiany informacji o użytkownikach z zagranicznymi systemami poboru opłat. + + \item \textbf{Zgodność prawna i regulacyjna} - System musi spełniać wszystkie obowiązujące przepisy prawa krajowego oraz unijnego dotyczące elektronicznego poboru opłat. Ustawę o drogach publicznych, dyrektywę EETS, przepisy podatkowe oraz przepisy dotyczące ochrony konkurencji i konsumentów. + + \item \textbf{Czas wdrożenia poprawek krytycznych} - w przypadku wykrycia krytycznego błędu (np. Uniemożliwiającego naliczenie opłaty lub przetwarzanie przejazdów) poprawka musi zostać wdrożona w ciągu maksymalnie 24 godzin od momentu potwierdzenia błędu. + + \item \textbf{Transparentność naliczanych opłat} - system musi umożliwiać użytkownikom końcowym wgląd w szczegółowe informacje dotyczące każdej naliczonej opłaty. Czas przejazdu, odcinki dróg, taryfy oraz podstawy naliczenia. + + \item \textbf{Elastyczność taryf} - system musi obsługiwać dynamiczne taryfy drogowe (np. Zmienne w zależności od natężenia ruchu czy poziomu emisji pojazdu) z możliwoścą wdrażania nowych taryf bez konieczności przerywania działania systemu. + + \item \textbf{Personalizacja powiadomień dla użytkowników} - system musi umożliwić użytkownikom wybór otrzymywania powiadomień np. (sms, e-mail, powiadomienie push w aplikacji) z opcją definiowania progów powiadomień (np. Przekroczenie salda, opłata powyżej X zł etc.) +\end{enumerate} + +\section{Decyzje architektoniczne} + +\subsection{Podział na warstwy} +\begin{figure}[H] +\centering +\includegraphics[width=0.8\textwidth]{wybor_architektury.png} +\caption{Diagram podziału na warstwy} +\label{fig:layers} +\end{figure} + +\begin{itemize} +\item Warstwa prezentacji: trzy różne aplikacje klienckie — aplikacja webowa, mobilna i aplikacja na urządzenia embedded. +\item Warstwa logiki biznesowej: centralna aplikacja serwerowa (serverApp), w której znajdują się komponenty takie jak UserService, PaymentService, PositionService itd. +\item Warstwa dostępu do danych: komponenty UserRepository, PaymentRepository. +\item Warstwa danych: baza danych Oracle z mechanizmem failover. +\end{itemize} + +\textbf{Decyzja:} Rozdzielenie odpowiedzialności na warstwy zwiększa modularność i ułatwia zarządzanie kodem oraz jego testowanie. + +\textbf{Alternatywa:} Architektura mikroserwisowa + +\textbf{Zalety alternatywy:} +\begin{itemize} +\item Lepsza skalowalność poszczególnych komponentów +\item Możliwość niezależnego wdrażania i rozwijania usług +\item Lepsza odporność na awarie (awaria jednego serwisu $\neq$ awaria całego systemu) +\end{itemize} + +\textbf{Wady alternatywy:} +\begin{itemize} +\item Większa złożoność wdrożeniowa (DevOps, CI/CD, monitoring) +\item Konieczność rozwiązywania problemów związanych z komunikacją między serwisami +\item Trudniejsze debugowanie i testowanie end-to-end +\end{itemize} + +\subsection{Modularność i komponenty (Component-based Design)} +\begin{figure}[H] +\centering +\includegraphics[width=0.8\textwidth]{organizacja_aplikacji_serwerowej.png} +\caption{Diagram komponentów} +\label{fig:components} +\end{figure} + +\begin{itemize} +\item Serwerowa aplikacja została podzielona na komponenty pełniące konkretne role (SigninController, TollController, MainComponent, itd.). +\item Każdy komponent ma jasno zdefiniowaną odpowiedzialność, zgodnie z zasadą Single Responsibility Principle. +\end{itemize} + +\textbf{Decyzja:} Wprowadzenie komponentów umożliwia łatwe rozszerzanie i testowanie poszczególnych fragmentów systemu. + +\textbf{Alternatywa:} Monolityczna aplikacja serwerowa + +\textbf{Zalety alternatywy:} +\begin{itemize} +\item Prostsza implementacja i wdrożenie +\item Mniejsza liczba zależności i konfiguracji +\item Mniej złożone środowisko developerskie +\end{itemize} + +\textbf{Wady alternatywy:} +\begin{itemize} +\item Trudniejsza skalowalność i refaktoryzacja +\item Każda zmiana wymaga redeploy całej aplikacji +\item Trudniejsze testowanie izolowanych funkcji +\end{itemize} + +\subsection{Wielokanałowy dostęp (Multi-Platform Clients)} +\begin{figure}[H] +\centering +\includegraphics[width=0.8\textwidth]{dostep_do_systemu.png} +\caption{Diagram wielokanałowego dostępu} +\label{fig:multichannel} +\end{figure} + +\begin{itemize} +\item Użytkownicy mogą korzystać z systemu za pomocą aplikacji mobilnej, webowej lub urządzeń embedded. +\end{itemize} + +\textbf{Decyzja:} Umożliwienie różnym grupom użytkowników (np. administratorzy vs kierowcy) dostępu do funkcji systemu w najbardziej dogodny sposób. + +\textbf{Alternatywa:} Tylko aplikacja mobilna (np. PWA lub natywna) + +\textbf{Zalety alternatywy:} +\begin{itemize} +\item Uproszczony interfejs użytkownika +\item Jedna platforma do utrzymania +\item Lepsze dopasowanie do kontekstu użytkownika (kierowcy) +\end{itemize} + +\textbf{Wady alternatywy:} +\begin{itemize} +\item Brak wygodnego interfejsu dla administratorów lub analityków +\item Mniejsza elastyczność użytkowania +\item Trudności z dostępem do systemu z urządzeń stacjonarnych +\end{itemize} + +\subsection{Rozdzielenie ról i uprawnień} +\begin{figure}[H] +\centering +\includegraphics[width=0.8\textwidth]{uprawnienia_dla_uzytkownikow.png} +\caption{Diagram ról i uprawnień} +\label{fig:roles} +\end{figure} + +\begin{itemize} +\item Administrator ma dostęp tylko przez aplikację webową. +\item Kierowca może korzystać z trzech różnych interfejsów — w zależności od potrzeb. +\end{itemize} + +\textbf{Decyzja:} Jasny podział ról zwiększa bezpieczeństwo i ergonomię systemu. + +\textbf{Alternatywa:} Jeden zunifikowany interfejs z uprawnieniami na poziomie konta + +\textbf{Zalety alternatywy:} +\begin{itemize} +\item Mniejsze zróżnicowanie UI +\item Mniej kodu i testów związanych z różnymi platformami +\end{itemize} + +\textbf{Wady alternatywy:} +\begin{itemize} +\item Mniejsza przejrzystość +\item Możliwość przypadkowego ujawnienia funkcji nieprzeznaczonych dla danego typu użytkownika +\end{itemize} + +\subsection{Integracja z zewnętrznymi systemami} +\begin{figure}[H] +\centering +\includegraphics[width=0.8\textwidth]{realizacja_obslugi_platnosci_i_archiwizacji_danych.png} +\caption{Diagram integracji z systemami zewnętrznymi} +\label{fig:integration} +\end{figure} + +\begin{itemize} +\item System płatności (systemPlatnosci) oraz system archiwizacji danych (archiwum) są zewnętrznymi systemami zintegrowanymi z systemem e-Toll. +\end{itemize} + +\textbf{Decyzja:} Wydzielenie tych odpowiedzialności do zewnętrznych systemów pozwala na lepsze skalowanie oraz wykorzystanie istniejących rozwiązań. + +\textbf{Alternatywa:} Wszystko w ramach jednej aplikacji (np. własny moduł płatności i archiwizacji) + +\textbf{Zalety alternatywy:} +\begin{itemize} +\item Większa kontrola nad logiką +\item Mniejsze zależności zewnętrzne +\end{itemize} + +\textbf{Wady alternatywy:} +\begin{itemize} +\item Większe ryzyko błędów w obszarach regulowanych prawnie (np. płatności) +\item Większe koszty utrzymania i certyfikacji +\item Brak skalowalności i elastyczności +\end{itemize} + +\subsection{Wysoka dostępność i odporność na awarie} +\begin{figure}[H] +\centering +\includegraphics[width=0.8\textwidth]{zapewnienie_dostepnosci_i_odpornosci_na_awarie.png} +\caption{Diagram wysokiej dostępności} +\label{fig:high-availability} +\end{figure} + +\begin{itemize} +\item Baza danych jest replikowana (primary–secondary). +\item Oddzielne deployment node'y dla różnych typów urządzeń oraz dla aplikacji serwerowej i bazy danych. +\item Failover serwera bazy danych — Oracle - Secondary. +\end{itemize} + +\textbf{Decyzja:} Architektura uwzględnia mechanizmy zapewniające ciągłość działania systemu nawet w przypadku awarii. + +\textbf{Alternatywa:} Deployment w chmurze + +\textbf{Zalety alternatywy:} +\begin{itemize} +\item Duża skalowalność +\item Bezpieczeństwo i redundancja +\end{itemize} + +\textbf{Wady alternatywy:} +\begin{itemize} +\item Wyższe koszty +\item Przetwarzanie danych przez inne podmioty +\end{itemize} + +\subsection{Wybór technologii wdrożeniowych} +\begin{figure}[H] +\centering +\includegraphics[width=0.8\textwidth]{wybor_technologii_wdrozeniowej.png} +\caption{Diagram technologii wdrożeniowych} +\label{fig:deployment-tech} +\end{figure} + +\begin{itemize} +\item System hostowany na serwerach z Ubuntu 24.04 LTS. +\item Serwer aplikacji oparty o Apache Tomcat 8.x. +\item Baza danych Oracle 12c. +\end{itemize} + +\textbf{Decyzja:} Użycie sprawdzonych technologii o długoterminowym wsparciu i wysokiej wydajności. + +\textbf{Alternatywa:} Cloud-native stack – np. AWS/GCP + +\textbf{Zalety alternatywy:} +\begin{itemize} +\item Automatyczne skalowanie, monitoring, CI/CD +\item Niższe koszty utrzymania fizycznej infrastruktury +\item Łatwiejsze zarządzanie kontenerami i usługami +\end{itemize} + +\textbf{Wady alternatywy:} +\begin{itemize} +\item Uzależnienie od chmury (vendor lock-in) +\item Potrzeba opanowania nowych technologii +\item Potencjalne wyższe koszty początkowe +\end{itemize} + +\section{Projekt systemu w postaci modelu C4} + \begin{figure}[H] + \centering + \includegraphics[width=1\textwidth]{c4/etoll.png} + \caption{Poziom context} + \label{fig:deployment-tech} + \end{figure} + \begin{figure}[H] + \centering + \includegraphics[width=1\textwidth]{c4/component_server_app.png} + \caption{Poziom component} + \label{fig:deployment-tech} + \end{figure} + \begin{figure}[H] + \centering + \includegraphics[width=1\textwidth]{c4/etool_glebiej.png} + \caption{Diagram dynamiczny} + \label{fig:deployment-tech} + \end{figure} + \begin{figure}[H] + \centering + \includegraphics[width=1\textwidth]{c4/deployment.png} + \caption{Diagram technologii wdrożeniowych} + \label{fig:deployment-tech} + \end{figure} +\end{document} diff --git a/strukturizrz/.structurizr/1/images/ComponentMobileApp-thumbnail.png b/strukturizrz/.structurizr/1/images/ComponentMobileApp-thumbnail.png deleted file mode 100644 index 5eb11fd7..00000000 Binary files a/strukturizrz/.structurizr/1/images/ComponentMobileApp-thumbnail.png and /dev/null differ diff --git a/strukturizrz/.structurizr/1/images/ComponentServerApp-thumbnail.png b/strukturizrz/.structurizr/1/images/ComponentServerApp-thumbnail.png deleted file mode 100644 index 15d6f3db..00000000 Binary files a/strukturizrz/.structurizr/1/images/ComponentServerApp-thumbnail.png and /dev/null differ diff --git a/strukturizrz/.structurizr/1/images/ComponentWebApp-thumbnail.png b/strukturizrz/.structurizr/1/images/ComponentWebApp-thumbnail.png deleted file mode 100644 index 3bed7854..00000000 Binary files a/strukturizrz/.structurizr/1/images/ComponentWebApp-thumbnail.png and /dev/null differ diff --git a/strukturizrz/.structurizr/1/images/Container-thumbnail.png b/strukturizrz/.structurizr/1/images/Container-thumbnail.png deleted file mode 100644 index c74d4809..00000000 Binary files a/strukturizrz/.structurizr/1/images/Container-thumbnail.png and /dev/null differ diff --git a/strukturizrz/.structurizr/1/images/Deployment-001-thumbnail.png b/strukturizrz/.structurizr/1/images/Deployment-001-thumbnail.png deleted file mode 100644 index c72e8f01..00000000 Binary files a/strukturizrz/.structurizr/1/images/Deployment-001-thumbnail.png and /dev/null differ diff --git a/strukturizrz/.structurizr/1/images/Diagram1-thumbnail.png b/strukturizrz/.structurizr/1/images/Diagram1-thumbnail.png deleted file mode 100644 index bfdb8f5e..00000000 Binary files a/strukturizrz/.structurizr/1/images/Diagram1-thumbnail.png and /dev/null differ diff --git a/strukturizrz/.structurizr/1/images/Diagram2-thumbnail.png b/strukturizrz/.structurizr/1/images/Diagram2-thumbnail.png deleted file mode 100644 index 35e6876c..00000000 Binary files a/strukturizrz/.structurizr/1/images/Diagram2-thumbnail.png and /dev/null differ diff --git a/strukturizrz/.structurizr/1/images/SystemContext-thumbnail.png b/strukturizrz/.structurizr/1/images/SystemContext-thumbnail.png deleted file mode 100644 index f328b3ca..00000000 Binary files a/strukturizrz/.structurizr/1/images/SystemContext-thumbnail.png and /dev/null differ diff --git a/strukturizrz/.structurizr/1/images/thumbnail.png b/strukturizrz/.structurizr/1/images/thumbnail.png deleted file mode 100644 index f328b3ca..00000000 Binary files a/strukturizrz/.structurizr/1/images/thumbnail.png and /dev/null differ