Veb aplikacija za upravljanje objedinjenim kartama za muzeje

Aplikacija treba da omogući kupcima, koji se registruju i prijavljuju na aplikaciju da elektronskim putem, preko Interneta, mogu da kupe karte za muzeje u objedinjenoj ponudi. Sistem plaćanja platnim karticama ne treba implementirati u ovom rešenju, već treba simulirati njegovo funkcionisanje, tako što bi plaćanje bilo odbijeno ako detalji kartice nisu neispravni (loš broj kartice, istekla kartice ili je kontrolni broj kartice paran) ili prihvaćeni ako su detalji kartice ispravni (ispravan broj kartice, datum isteka u budućnosti i kontrolni broj kartice je neparan). Kupci mogu da pregledaju katalog ponuda za muzejske obilaske. Aplikacija treba za svaki muzej da pruži osnovne podatke (naziv, adresu, kratak i detaljan opis, fotografiju i radno vreme za svaki dan u nedelji). Za svaki muzej postoje ponuđene ulaznice. Muzeji mogu imati najmanje jednu ulaznicu u ponudi (redovnu ulaznicu), ali mogu imati i više tipova ulaznica, zavisno od toga šta obuhvata ulaznica u smislu obilaska ili da li je ulaznica definisana za tačno određeno vreme ulaska u muzej (skip-line ulaznica, npr. za 9.00, za 9.30, za 10.00 itd). Svaka ulaznica ima svoju redovnu cenu i povlašćenu (sniženu) cenu ako je deo objedinjene ulaznice. Kupci mogu da u korpu za kupovinu da dodaju jednu ili više ulaznica iz ponude različitih muzeja, kao i broj posetilaca (npr. za kupovinu za grupu). Kada žele da izvrše kupovinu, ako je objedinjena korpa ulaznica za jednu osobu, ne za grupu, onda treba da unesu ime i prezime osobe koja će koristiti ulaznicu; ili ime i prezime odgovornog lica ako je u pitanju grupna (tj. ulaznice u objedinjenoj korpi su za više posetilaca), kao i broj telefona za kontakt i adresu elektronske pošte za dostavu izveštaja o naplati. Prilikom potvrde kupovine, izvršiti simulaciju naplate platnom karticom kao što je opisano u početku ovog projektnog zahteva. Ako je kupovina bila neuspešna, na adresu elektronske pošte poslati poruku sa obaveštenjem o tome da nije izvršena naplata. Ako je kupovina bila uspešna, formirati objedinjenu ulaznicu koja ima svoj jedinstveni kôd, datum kupovine i ime posetioca ili odgovornog lica (u slučaju grupe), kao i popis svih tipova ulaznica i muzeja koje objedinjena ulaznica obuhvata, sa podatkom o broju posetilaca ako je ulaznica grupna. Kupci mogu da vide spisak svojih kupljenih objedinjenih ulaznica i mogu da izvezu PDF za štampu koji sadrži sve navedene podatke i bar kôd objedinjene ulaznice prikazan u gornjem desnom delu A4 papira, širine polovine raspoloživog prostora papira, kada se oduzmu margine. Ostale elemente PDF A4 dokumenta sa detaljima objedinjene ulaznice samostalno rasporediti i osmisliti istraživanjem primera iz prakse. Administrator sistema može da ima uvid u sve kupljene ulaznice, kao i pregled uplaćenih sredstava po danima, mesecima i u opsegu datuma, kao i po pojedinačnim muzejima. Grafički interfejs veb aplikacije treba da bude realizovan sa responsive dizajnom, tako da bude prilagodljiv različitim rezolucijama ekrana (npr. za mobilne telefone i Desktop računare).


Tehnička ograničenja
- Aplikacija mora da bude realizovana na Node.js platformi korišćenjem Express biblioteke. Aplikacija mora da bude podeljena u dve nezavisne celine: back-end veb servis (API) i front-end (GUI aplikacija). Sav kôd aplikacije treba da bude organizovan u jednom Git spremištu u okviru korisničkog naloga za ovaj projekat, sa podelom kao u primeru zadatka sa vežbi.
- Baza podataka mora da bude relaciona i treba koristiti MySQL ili MariaDB sistem za upravljanje bazama podataka (RDBMS) i u spremištu back-end dela aplikacije mora da bude dostupan SQL dump strukture baze podataka, eventualno sa inicijalnim podacima, potrebnim za demonstraciju rada projekta.
- Back-end i front-end delovi projekta moraju da budi pisani na TypeScript jeziku, prevedeni TypeScript prevodiocem na adekvatan JavaScript. Back-end deo aplikacije, preveden na JavaScript iz izvornog TypeScript koda se pokreće kao Node.js aplikacija, a front-end deo se statički servira sa rute statičkih resursa back-end dela aplikacije i izvršava se na strani klijenta. Za postupak provere identiteta korisnika koji upućuje zahteve back-end delu aplikacije može da se koristi mehanizam sesija ili JWT (JSON Web Tokena), po slobodnom izboru.
- Sav generisani HTML kôd koji proizvodi front-end deo aplikacije mora da bude 100% validan, tj. da prođe proveru W3C Validatorom (dopuštena su upozorenja - Warning, ali ne i greške - Error). Grafički korisnički interfejs se generiše na strani klijenta (client side rendering), korišćenjem React biblioteke, dok podatke doprema asinhrono iz back-end dela aplikacije (iz API-ja). Nije neophodno baviti se izradom posebnog dizajna grafičkog interfejsa aplikacije, već je moguće koristiti CSS biblioteke kao što je Bootstrap CSS biblioteka. Front-end deo aplikacije treba da bude realizovan tako da se prilagođava različitim veličinama ekrana (responsive design).
- Potrebno je obezbediti proveru podataka koji se od korisnika iz front-end dela upućuju back-end delu aplikacije. Moguća su tri sloja zaštite i to: (1) JavaScript validacija vrednosti na front-end-u; (2) Provera korišćenjem adekvatnih testova ili regularnih izraza na strani servera u back-end-u (moguće je i korišćenjem izričitih šema - Schema za validaciju ili drugim pristupima) i (3) provera na nivou baze podataka korišćenjem okidača nad samim tabelama baze podataka.
- Neophodno je napisati prateću projektnu dokumentaciju o izradi aplikacije koja sadrži (1) model baze podataka sa detaljnim opisom svih tabela, njihovih polja i relacija; (2) dijagram baze podataka; (3) dijagram organizacije delova sistema, gde se vidi veza između baze, back-end, front-end i korisnika sa opisom smera kretanja informacija; (4) popis svih aktivnosti koje su podržane kroz aplikaciju za sve uloge korisnika aplikacije prikazane u obliku Use-Case dijagrama; kao i (5) sve ostale elemente dokumentacije predviđene uputstvom za izradu dokumentacije po ISO standardu.
- Izrada oba dela aplikacije (projekata) i promene kodova datoteka tih projekata moraju da bude praćene korišćenjem alata za verziranje koda Git, a kompletan kôd aplikacije bude dostupan na javnom Git spremištu, npr. na besplatnim GitHub ili Bitbucket servisima, jedno spremište za back-end projekat i jedno za front-end projekat. Ne može ceo projekat da bude otpremljen u samo nekoliko masovnih Git commit-a, već mora da bude pokazano da je projekat realizovan u kontinuitetu, da su korišćene grane (branching), da je bilo paralelnog rada u više grana koje su spojene (merging) sa ili bez konflikata (conflict resolution).

Morate da budete prijavljeni na aplikaciju da biste izvršili rezervaciju. Prijava