4. Arhitektura i dizajn sustava
Ovim poglavljem opisana je arhitektura aplikacije za prijavu i pracenje vremenskih nepogoda DisasterMaster. Odabrani stil arhitekture je mikroservis zbog potrebe za skalabilnosti i neovisnim razvojem kljucnih funkcionalnosti. Na frontendu koristen je Reach.js, dok se za implementaciju backenda koristi Srping Boot. Koristeni su i sigurnosni potokoli koji su navedeni kasnije.
Spring Boot arhitektura prati slojni dizajn s nekoliko glavnih komponenti: Controller layer (upravlja HTTP zahtjevima), Service layer (poslovna logika koja implementira razne funkcionalnosti), Repository Layer (upravlja pristupom podatcima i njihovom pohranom), Model layer (definira podatkovne objekte)
- Stil arhitekture: Arhitektura mikroservisa pogodna je razvoj aplikacije jer omogucava implementiranje svake funkcionalnosti kao zasebnog servisa. Ovo omogućava prilagođeno skaliranje specifičnih dijelova sustava ovisno o opterećenju, kao što je povećanje resursa za prijave nepogoda tijekom krize. Nadalje svaki servis moze biti razvijen, implementiran i testiran odvojeno, sto omogucava brzu reakciju na korisnicke zahtjeve. Uz model mikroservisa, arhitektura sadrzi i neke elemente slojevite arhitekture:
- Klijentski sloj: prikazije korisnicko sucelje kroz koje korisnici komuniciraju s aplikacijom (Reach.js)
- Sloj servisa: implementira sve funkcionalnosti aplikacije kao sto su prijava nepogode, obavijesti i statistika (Spring Boot, REST API)
- Sloj integracije: olaksava komunikaciju izmedu mikroservisa. Korištenjem API gatewaya osigurava se pouzdanost i otpornost sustava, čak i pri povećanom opterećenju. (Amazon API Gateway, HTTP)
- Sloj podataka: omogucava pohranu i obradu podataka te brzu obradu informacija (PostgreSQL, AWS S3)
- Sloj infrastrukture i sigurnosti: upravljanje autentifikacijom, enkripcija i zastita podataka (OAuth 2.0, JWT za provjeru identiteta korisnika)
- Sloj obavijesti: osigurava slanje obavijesti putem razlicitih kanala (u nasem slucaju maila) kako bi se promptno informirali korisnici (Mail Server, STMP, HTTPS)
-
Mrezni protokoli: Za komunikaciju izmedu klijenta i posluzitelja koristiti ce se HTTP/HTTPS implementirani u Spring Bootu. Prijenos podataka izmedu front i backenda u JSON formatu odvijet ce se putem REST API-ja. OAuth omogucava sigurnu prijavu u sustav putem tokena uz koji ce se koristiti i JWT. Sto se tice protokola slanja obavijesti integriran ce biti STMP koristeci Spring Email Starter.
-
Globalni upravljacki tok:
- Početna interakcija: Korisnik (npr. građanin, vlast) pristupa aplikaciji, registrira se ili se prijavljuje.
- Unos podataka: Korisnik prijavljuje nepogodu ili traži informacije.
- Obrada podataka: Podaci se pohranjuju u bazu podataka i analiziraju.
- Obavijesti i akcije: Ako je prijava odobrena, obavijesti se šalju korisnicima putem maila.
- Povratna informacija: Korisnik dobiva potvrdu ili povratnu informaciju o statusu prijave ili akciji.
Odabir mikroservisne arhitekture temelji se na nekoliko kljucnih cimbenika: fleksibilnost, skalabilnost i odrzivost. Mikroservisi omogućuju podjelu aplikacije na manje, samostalne jedinice koje se mogu razvijati, testirati i implementirati neovisno, što olakšava održavanje i unapređivanje aplikacije. Također, mikroservisna arhitektura omogućuje horizontalnu skalabilnost jer je moguće skalirati pojedine servise prema potrebi, čime se povećava efikasnost u upravljanju resursima.
Principi oblikovananja kao sto je povecanje kohezije i smanjenje povezanosti, pomogli su u stvaranju mikroservisa koji komuniciraju putem jasno definiranih API-ja i protokola cime se smanjila meduovisnost i povecala fleksibilnost unutar sustava.
Kao alternativu razmatrali smo klijent-posluzitelj arhitekturu koja je jednostavna za implementaciju, ali postavlja ogranicenja kada je rijec o skalabilnosti i fleksibilnosti. Klijent-posluzitelj arhitektura je prikladna za manje sustave, dok mikroservisna pruza bolje rjesnje za vece, dinamicne aplikacije poput DisasterMastera.
- Korisnicko sucelje implementirano React.jsom korisniku omogucava komunikaciju s ostatkom aplikacije (mikroservisa) putem API gatewaya
- Mikroservisi su manji moduli spicificnih funkcionalnosti:
- upravljanje korisnicima, prijava nepogoda, primanje/slanje obavijesti, pregled informacija o resursima, generiranje izvjestaja, interaktivna mapa
- Baza podataka je PostgreSQL ---- Dodajem kasnije kad deployamo aplikaciju
- Datotecni sustav ---- Dodajem kasnije kad deployamo aplikaciju
U arhitekturi aplikacije koristeci MVC framework u Spring Bootu te React.js za frontend, aplikacija sadrzi tri glavna sloja:
- Frontend (View): Implementiran u React.js, frontend pruža korisničko sučelje koje komunicira s backendom putem HTTP zahtjeva. Frontend koristi REST API kako bi dobio podatke, prikazao ih i omogućio interakcije korisnika, kao što su prijava nepogoda ili ažuriranje profila.
- Kontroler (Controller): U Spring Boot-u kontroleri obrađuju zahtjeve iz frontenda. Svaki zahtjev se prima putem API endpointa, a kontroler zatim poziva odgovarajuće servise (poslovnu logiku) kako bi obradio podatke. Nakon obrade, kontroler vraća odgovor natrag na frontend.
- Poslovna logika i model (Service i Model): Sloj poslovne logike obuhvaća servise koji obrađuju zahtjeve iz kontrolera, izvršavajući poslovne operacije kao što su validacija podataka, autentifikacija ili manipulacija podacima. Model predstavlja strukture podataka koje se koriste unutar aplikacije i pohranjuju u bazi podataka. Svaki model preslikava strukture baze podataka pomoću JPA ili drugih ORM alata.
- Baza podataka (Repository Layer): Pomoću JPA ili drugih ORM tehnologija, Spring Boot omogućava komunikaciju s bazom podataka. Repozitoriji komuniciraju s poslovnom logikom, a svaki model podataka može biti povezan s jedinstvenom bazom podataka ako koristimo arhitekturu mikrousluga.
Dijagram mvc arhitekture u spring bootu:
| Atribut | Tip podatka | Opis varijable |
|---|---|---|
| locationId | DOUBLE | identifikator lokacije za prijave, PK |
| name | STRING | ime grada, ulice, mjesta prijave |
| latitude | DOUBLE | Jedinstveni identifikator lokacije |
| longitude | DOUBLE | Jedinstveni identifikator lokacije |
| address | STRING | vlastiti atribut lokacije |
| city | STRING | vlastiti atribut lokacije |
| zipCode | INT | vlastiti atribut lokacije |
| Atribut | Tip podatka | Opis varijable |
|---|---|---|
| photoId | DOUBLE | identifikator fotografije priložene uz prijavu, PK |
| reportId | DOUBLE | identifikator prijave uz koju je vezana fotografija, FK |
| photoURL | STRING | identifikator fotografije |
| uploadedAt | DATETIME | vlastiti atribut, vrijeme prijave fotografije |
| userId | DOUBLE | identifikator korisnika koji prijavljuje nepogodu, FK |
| Atribut | Tip podatka | Opis varijable |
|---|---|---|
| reportId | DOUBLE | Jedinstveni identifikator prijave nepogode, PK |
| userId | DOUBLE | identifikator korisnika koji prijavljuje nepogodu , FK, PK |
| disasterType | STRING | vlastiti atribut, vrsta tipa nepogode |
| status | BOOLEAN | vlastiti atribut, status prijave (odbijena ili prihvaćena) |
| locationId | DOUBLE | identifikator lokacije vezane uz prijavu, FK |
| descriptionOfDisaster | STRING | vlastiti atribut, tekstualni opis prijave |
| createdAt | DATETIME | vlastiti atribut, vrijeme prijave nepogode |
| photoId | DOUBLE | identifikator fotografije priložene uz prijavu, FK |
| Atribut | Tip podatka | Opis varijable |
|---|---|---|
| informationId | INT | Jedinstveni identifikator objave o informacijama, PK |
| userId | DOUBLE | identifikator korisnika koji objavljuje informacije, FK |
| informationType | STRING | vlastiti atribut vrste tipa informacije (sklonište, resurs) |
| createdAt | DATETIME | vlastiti atribut vremena objave informacije |
| locationId | DOUBLE | identifikator lokacije vezane uz objavu informacije |
| descriptionOfInformation | STRING | vlastiti atribut, tekstualni opis informacije |
| Atribut | Tip podatka | Opis varijable |
|---|---|---|
| userId | DOUBLE | Jedinstveni identifikator korisnika, FK, PK |
| orgName | STRING | vlastiti atribut imena humanitarne organizacije |
| Atribut | Tip podatka | Opis varijable |
|---|---|---|
| userId | DOUBLE | Jedinstveni identifikator korisnika, FK, PK |
| firstName | STRING | vlastiti atribut, ime korisnika |
| lastName | STRING | vlastiti atribut, prezime korisnika |
| isAnonymous | BOOLEAN | vlastiti atribut, status anonimnosti korisnika (je li korisnik ulogiran u aplikaciju ili ne) |
| Atribut | Tip podatka | Opis varijable |
|---|---|---|
| userId | DOUBLE | Jedinstveni identifikator korisnika, PK |
| roleId | INT | identifikator tipa uloge korisnika |
| password | STRING | vlastiti atribut šifra korisničkog računa |
| STRING | vlastiti atribut, email korisnika (koji koristi za prijavu u aplikaciju) | |
| roleId | INT | FK, PK |
| Atribut | Tip podatka | Opis varijable |
|---|---|---|
| userId | DOUBLE | Jedinstveni identifikator korisnika, PK, FK |
| govName | STRING | vlastiti atribut imena nadležnog tijela |
| Atribut | Tip podatka | Opis varijable |
|---|---|---|
| roleId | INT | jedinstvani identifikator uloge korisnika, PK |
| rolename | STRING | vlastiti atribut imena uloge korisnika |
Stanja dijagrama su: Neaktivna, Odabir vrste napogode, Aktivna/ispunjavanje forme (Odabir lokacije, Opis prijave, Prilog fotografije), Prijava dodana, Zavrsno stanje (prijava dodana je zavrsno stanje prijave nepogode)
Korisniku se klikom na gumb 'Add new weather reports' prikazuje lista nepogodi
Klikom na odredenu vrstu nepogode prikazuje se forma za prijavu
Ispunjavanjem svih elemenata forme i klikom na gumb 'submit' prijava se sprema te prikazuje na mapi pocetne stranice
Klikom na gumb 'cancel' u bilo kojem trenutku korisnika se vraca na pocetnu stranicu, te njegova prijava nije spremljena
Dijagram aktivnosti prikazuje tok akcija tijekom procesa prijave nove nepogode
Akori su: Korisnik, Disaster Master web aplikacija i baza podataka
Na pocetni cvor se nadovezuje na klik gumba za prijavu nove nepogode cime zapocinje proces prijave nepogode
Zavrsni cvor se nadovezuje na prikaz pocetne stranice cime zavrsava proces prijave nepogode (i u slucaju submita i u slucaju canclea)
Dijagram aktivnosti prikazuje proces prihvacanja/odbijanja prijava korisnika od strane vlasti
Aktori su: Korisnik (governmnet), Disaster Master web aplikacija, baza podataka
Proces zapicnje tablicnim prikazom svih prijava korisniku s ulogom government
Proces zavrsava ili zavrsetkom procesa toka kod prihvacanja prijave (prijava samo ostaje u bazi i prikazana na mapi) ili zavrsnim cvorom nakon brisanja prijave