Obiectivul temelor de casă este reprezentat de implementarea unui sistem informatic performant şi scalabil pentru gestiunea resurselor unei întreprinderi de dimensiuni mari. Pentru tema de recuperare, organizaţia pentru care se va proiecta şi dezvolta acest pachet de programe este o companie prin intermediul căreia pot fi achiziționate bilete la diverse reprezentații artistice, oferite de instituții diferite (teatre, cinematografe).

Această aplicație ERP va conține mai multe module accesate de clienții :

• o aplicație desktop fără interfață grafică (în linie de comandă) prin intermediul căreia clienții pot obține informații cu privire la reprezentațiile artistice, putând să rezerve locuri, respectiv să achiziționeze bilete;
• o aplicație web va oferi utilizatorilor de tip clienți aceleași funcționalități, odată ce accesul lor este confirmat.

Toate modulele vor accesa un sistem de gestiune pentru baze de date pentru a asigura persistența operațiilor care sunt realizate în cadrul lor.

După rezolvarea temei de casă, studentul va fi capabil să:

• proiecteze o bază de date cu mai multe tabele normalizate, între care există relaţii de dependenţă, gestionând informaţiile din cadrul acesteia prin intermediul unei aplicaţii;
• distribuie pe componente ale aplicației diferite funcționalități, modelând comunicația între acestea;
• realizeze o aplicaţie web (formată din mai multe pagini, între care există legături) care implementează o funcţionalitate complexă.

Cunoştinţele necesare pentru rezolvarea temei de casă sunt:

• programarea în limbajul Java;
• manipularea bazelor de date folosind MySQL;
• folosirea API-ului Java DataBase Connectivity SAU o implementare Java Persistence API (de preferat, Hibernate) pentru accesarea programatică a informațiilor stocate în baza de date;
• utilizarea, la alegere, a unei dintre tehnologiile RMI sau JAX-WS pentru apelarea unor metode aparţinând unor obiecte existente într-o altă maşină virtuală, a căror definiţie se consideră cunoscută;
• folosirea tehnologiilor Java Servlets / JavaServer Pages și Node.JS pentru dezvoltarea unei aplicaţii web.

Se doreşte implementarea unui sistem informatic destinat gestiunii activităţilor dintr-o organizație prin intermediul căreia pot fi interogate serviciile mai multor instituții culturale, care oferă reprezentații artistice, în scopul rezervării de locuri și achiziționării de bilete la acestea.

Fiecare instituție culturală este caracterizată prin denumire, adresă, tip și descriere. O instituție are un anumit repertoriu, desemnat prin mai multe reprezentații. O reprezentație este caracterizată prin denumire, distribuție (actori), scenograf, regizor și producător precum și durata, exprimată în minute (cu sau fără pauză), pretul unui bilet. De asemenea, o instituție culturală dispune de mai multe săli de spectacole, pentru fiecare existând o anumită capacitate, distribuită pe mai multe rânduri (se definește pentru fiecare locație atât numărul de rânduri, cât și numărul de locuri - considerat constant pentru fiecare rând). Se va defini și programul instituției culturale, prin care se asociază o reprezentație la o sală de spectacole, la o anumită dată calendaristică și o anumită oră. Fiecare instituție culturală va dispune de propria bază de date, prin care se vor reține aceste informații.

Se va implementa o aplicație desktop, folosită de clienții care doresc să rezerve locuri sau să achiziționeze bilete la aceste reprezentații artistice. În funcție de solicitări, aceasta va accesa, la distanță, sistemele fiecărei instituții artistice în parte. Conexiunea se va realiza prin intermediul tehnologiei RMI SAU JAX-WS (la alegere).

Totodată, clienții vor putea accesa, prin intermediul unei aplicații web, sistemul propriu al fiecărei instituții artistice (disponibil la adrese diferite), funcționalitățile oferite fiind identice (diferită fiind doar baza de date la care se realizează conexiunea). Aceeași aplicație web va fi implementată folosind atât folosind Java Servlets / JavaServer Pages împreună cu un server Apache Tomcat sau GlassFish cât și Node.JS. Ulterior implementării, vor fi comparate performanțele aplicațiilor web.

Ambele aplicații vor fi integrate prin folosirea unei baze de date unice, implementată în cadrul unui SGBD MySQL.

Un spectator poate obține informații cu privire la reprezentațiile artistice ale instituțiilor culturale, realizând rezervări pentru acestea și achiziționând bilete prin intermediul unui agent de intermediere a comunicației. Acesta are rolul de a facilita interacțiunea dintre clienți și astfel de companii, responsabile cu organizarea spectacolelor. El poate fi interogat pentru a se obține lista organizațiilor culturale, lista reprezentațiilor împreună cu data la care acestea sunt programate și numărul de locuri disponibile, pentru a rezerva locurile disponibile pentru anumite perioade de timp (respectiv pentru a anula rezervarea), precum și pentru a achiziționa bilete.

1. O instituție culturală va interacționa doar cu agentul de intermediere a comunicației. Accesul la metodele expuse va fi permis doar în situația în care între aceste entități este stabilită o legătură, în acest sens fiind implementat un meniu în mod text în cadrul componentei companiei organizatoare de spectacole prin care vor fi accesate funcționalitățile de înregistrare, respectiv de deînregistrare de la nivelul agentului de intermediere.

Funcționalitățile pe care le expune un către agentul de intermediere sunt:

a) metoda getCulturalInstitutionInfo() oferă informații cu privire la producător:

• parametri: -;
• valoare întoarsă: un obiect de tip CulturalInstitution care conține datele prin care o comapanie culturală este identificată: denumire, adresă, tip și descriere.

public CulturalInformation getCulturalInstitutionInfo();

b) metoda getRepresentationList() furnizează lista de reprezentații existente în repertoriul organizației culturale, pentru care există măcar o programare:

• parametri: -;
• valoare întoarsă: o listă de obiecte de tip Representation, caracterizat prin denumire, distribuție (actori), scenograf, regizor, producător, durata, data și sala la care este programat, prețul unui bilet precum și numărul de locuri disponibile, toate aceste informații fiind gestionate prin intermediul unei baze de date dedicate pentru fiecare instituție culturală în parte:

public List<Representation> getRepresentationList();

c) metoda makeReservation() realizează o rezervare pentru un spectacol:

• parametri: un identificator unic, pe baza căruia rezervarea va putea fi referită la nivelul furnizorului, un obiect de tip Representation reprezentând spectacolul la care se dorește să se realizeze rezervarea și o valoare întreagă, reprezentând numărul de locuri care se dorește a fi ocupat;
• valoare întoarsă: o valoare de tip adevărat / fals, care indică posibilitatea realizării rezervării respective.

public boolean makeReservation(int reservationId, Representation representation, int numberOfSeats);

d) metoda cancelReservation() anulează o rezervare prealabilă:

• parametru de intrare: un identificator unic prin intermediul căruia este referită rezervarea respectivă;
• valoare întoarsă: o valoare de tip adevărat / fals după cum operația a fost realizată cu succes, respectiv cu eșec.

public boolean cancelReservation(int reservationId);

e) metoda buyTicket() este corespunzătoare operației de achiziționare a unui bilet la o reprezentație, pe baza unei rezervări:

• parametru de intrare: un identificator unic prin intermediul căruia este referită rezervarea respectivă;
• valoare întoarsă: o valoare de tip adevărat / fals după cum operația a fost realizată cu succes, respectiv cu eșec.

public boolean buyTicket(int reservationId);

2. Un agent de intermediere facilitează comunicația dintre un compania organizatoare de spectacole și clienți, expunând către fiecare dintre acestea anumite funcționalități:

CĂTRE INSTITUȚIA CULTURALĂ

a) metoda registerCulturalInstitution() permite înregistrarea unei instituții culturale la agentul de intermediere; doar în cazul în care instituția culturală este înregistrată la agentul de intermediere, aceasta poate fi interogată cu privire la reprezentațiile pe care le are în repertoriu; metoda are ca semnătură:

• parametri: un obiect de tip CulturalInstitution conținând informațiile prin care compania organizatoare de spectacole este identificată;
• valoarea întoarsă: un identificator prin care organizația culturală este referită în mod unic la nivelul agentului de intermediere.

public int registerCulturalInstitution(CulturalInstitution culturalInstitution);

b) metoda unregisterCulturalInstitution() permite deînregistrarea unei instituții culturale de la agentul de intermediere; în acest moment, toate informațiile stocate la nivelul agentului de intermediere cu privire la respectiva companie organizatoare de spectacole sunt eliminate; metoda are semnătura:

• parametru: identificatorul unic prin care organizația culturală este referită de agentul de intermediere;
• valoarea întoarsă: o valoare de tip adevărat / fals, care indică dacă operația a fost realizată cu succes, respectiv cu eșec.

public boolean unregisterCulturalInstitution(int registrationId);

CĂTRE CLIENȚI

a) metoda getCulturalInstitutionList() furnizează o listă cu instituțiile culturale care pot fi accesate la un moment dat:

• parametri: -;
• valoare întoarsă: o listă de obiecte de tip CulturalInformation, conținând informațiile prin care o companie organizatoare de spectacole este identificată.

public List<CulturalInformation> getCulturalInformationList();

b) metoda getRepresentations() determină lista tuturor reprezentațiilor existente în repertoriu pentru care există măcar o programare, pentru fiecare organizație culturală în parte:

• parametri: -;
• valoare întoarsă: un obiect de tip Map având drept cheie un obiect de tip CulturalInstitution iar ca valoare o listă de obiecte de tip Representation reprezentând spectacolele oferite de instituția culturală.

public Map<CulturalInstitution, List<Representation>> getRepresentations();

c) metoda makeReservation() realizează o rezervare, la nivelul unei instituții culturale, pentru un anumit spectacol:

• parametri: un obiect de tip CulturalInstitution, conținând informațiile prin care organizația culturală este identificată, un obiect de tip Representation cu semnificația reprezentației respective precum și numărul de locuri care se dorește a fi rezervate;
• valoare întoarsă: un identificator unic (atât la nivelul agentului de intermediere cât și la nivelul companiei organizatoare de spectacole) prin care rezervarea va putea fi referită sau -1 în situația în care rezervarea nu a putut fi realizată (spectacolul nu este oferit de organizația culturală respectivă sau numărul de locuri solicitate este incompatibil cu numărul de locuri disponibile).

public int makeReservation(CulturalInstitution culturalInstitution, Representation representation, int numberOfSeats);

d) metoda cancelReservation() anulează o rezervare prealabilă:

• parametru: un identificator unic, prin care rezervarea este referită atât la nivelul agentului de intermediere cât și la nivelul instituției culturale;
• valoare întoarsă: o valoare de tip adevărat / fals după cum operația a fost realizată cu succes, respectiv cu eșec.

public boolean cancelReservation(int reservationId);

e) metoda buyTicket() realizează achiziționarea unui bilet pe baza unei rezervări:

• parametru de intrare: un identificator unic prin intermediul căruia este referită rezervarea respectivă;
• valoare întoarsă: o valoare de tip adevărat / fals după cum operația a fost realizată cu succes, respectiv cu eșec.

public boolean buyTicket(int reservationId);

3. Un client accesează operațiile pe care le oferă agentul de intermediere a comunicației cu organizațiile culturale pentru a obține informații cu privire la repertoriul acestora, pentru a rezerva locuri la spectacolele pe care acestea le organizează respectiv pentru a achiziționa bilete.

Modul de operare la nivelul clientului implică obținerea listei de instituții culturale și a reprezentațiilor pe care acestea le oferă, selectarea unui spectacol pentru care se solicită realizarea unei rezervări urmată de achiziția unui bilet pe baza acesteia. Toate aceste funcționalități, oferite de către agentul de intermediere, vor fi disponibile prin intermediul unui meniu în mod text.

Arhitectura sistemului informatic va fi prin urmare formată din trei componente care comunică între ele, dintre care una (agentul de intermediere a comunicației) expune funcționalități de tip server atât către componenta de tip instituție culturală cât și către componenta de tip client. În această situație, se va asigura faptul că pentru fiecare entitate vor fi accesibile doar metodele specifice, fără a se expune și operațiile aferente altor aplicații.

Pentru fiecare instituție culturală se va implementa și o aplicație web (folosind două tehnologii diferite: Java Servlets & JavaServer Pages și Node.JS), aceasta putând fi accesată, pe baza unui proces de autentificare, de către clienții care și-au creat un cont de acces aprobat. Informațiile care trebuie transmise pentru obținerea permisiunii de a folosi aplicația web sunt: credențialele dorite (nume de utilizator și parolă), CNP-ul, codul IBAN și o sumă de bani disponibilă în contul aferent, inițial. Gestiunea acestor solicitări se face doar de către un utilizator de tip administrator, preexistent în baza de date (nu trebuie gestionat programatic). Doar după ce acesta a acordat drepturile necesare, aplicația va putea fi utilizată corespunzător de către clienți.

Un client poate vizualiza lista cu reprezentațiile oferite de instituția culturală respectivă, pentru fiecare spectacol afișându-se toate informațiile caracteristice: denumire, distribuție (actori), scenograf, regizor, producător, durată și preț. Această listă poate fi filtrată în funcție de un actor care se găsește în distribuție, de anumite limite (minimă și maximă) pentru durată, respectiv pentru preț. De asemenea, lista poate fi ordonată alfabetic după denumirea spectacolului precum și în funcție de durată sau ae preț. De asemenea, clientului i se va afișa programul curent al companiei organizatoare de reprezentații, grupată pe săli de spectacole: pentru fiecare zi vor fi afișate manifestările culturale respective, ordonate după ora de începere, precizându-se și numărul de locuri disponibile precum și prețul unui bilet.

Clientul are posibilitatea de a-și defini un coș de cumpărături, format dintr-un număr de 1 sau mai multe bilete achiziționate pentru 1 sau mai multe spectacole. În momentul în care coșul de cumpărături este complet, acesta poate fi finalizat, ceea ce implică actualizarea numărului de locuri disponibile pentru spectacolele completate și a sumei de bani disponibile în contul clientului. În situația în care numărul de locuri solicitate pentru o anumită reprezentație nu corespunde numărului de locuri disponibile, se va genera un mesaj de eroare.

Se va defini și o secțiune în care clientul are acces la datele personale, pe care le poate modifica în orice moment. De asemenea, clientul va putea avea acces la istoricul coșurilor de cumpărături pe care le-a finalizat cu succes.

De asemenea, se va implementa și un sistem de comunicație, prin intermediul căruia clientul poate gestiona (citi, scrie) mesaje către reprezentații instituțiilor culturale, care poate avea drept obiect o solicitare pentru informații referitoare la un spectacol, la care vor răspunde administratorii. Un astfel de mesaj este caracterizat prin expeditor, subiect, dată și oră, tip, conținut și stare (citit sau necitit).

Este necesar să se implementeze și operația de deautentificare prin care se revine la pagina principală a aplicației web.

NU este permină folosirea altor tehnologii decât a celor specificate enunţ. Definiţiile metodelor apelabile la distanţă sunt descrise în pseudocod. Acestea pot fi modificate la nivelul parametrilor sau rezultatelor întoarse, păstrându-se însă funcţionalitatea lor.

Popularea bazei de date cu informații trebuie să fie corespunzătoare pentru a putea ilustra funcționalitățile implementate.

Pentru o instituție culturală, datele specifice (denumirea, adresa, tipul și descrierea) vor fi precizate sub formă de parametri în linia de comandă în momentul lansării sale în execuție.

Perioada pentru care o rezervare este menținută se măsoară în număr de zile calendaristice și se exprimă sub formă de constantă la nivelul codului sursă.

Metodele de la nivelul agentului de intermediere vor accesa funcționalitățile cu acceeași denumire de la nivelul companiilor organizatoare de spectacole, în unele situații fiind necesară parcurgerea întregii liste a instituțiilor culturale care pot fi accesate la un moment dat. Într-un astfel de model, în care componentele sunt strâns cuplate, toate operațiile sunt sincrone (se blochează până se transmite un rezultat de la metoda invocată). Accesul la resursele care pot fi referite de mai multe fire de execuție concomitent trebuie să se realizeze sincronizat.

Semnăturile metodelor accesibile la distanță pot suferi modificări în funcție de necesități, cu respectarea funcționalității descrise.

În cazul aplicației desktop, nu este necesar să se implementeze o interfață grafică pentru testarea aplicațiilor, fiind suficient un meniu în mod text care să permită introducerea unui număr de opțiuni corespunzător numărului de metode pe care o componentă le poate accesa la distanță.

În cazul aplicației web, nu se va ține cont de interfața grafică a paginilor Internet, accentul punându-se pe funcționalitatea acestora. Pot fi preluate șabloane pentru foile de stil sau pentru proiectarea aspectului disponibile pe Internet, fără ca acest lucru să intre sub incidența regulilor legate de frauda academică.

Pentru gestiunea informațiilor stocate în baza de date se poate utiliza fie JDBC (Java DataBase Connectivity), fie JPA (Java Persistence API) cu orice implementare a acesteia (Hibernate, Eclipse Link).

Criteriile în funcție de care va fi realizată comparația dintre soluțiile oferite de Java Enterprise Edition / Node.JS pentru dezvoltarea de aplicații web trebuie să fie minim trei, la alegere (memoria utilizată - sistemul de colectare a memoriei, ușurința în dezvoltare - facilități oferite pentru programatori, integrarea cu diferite sisteme de operare / navigatoare, funcționalități oferite / posibilitatea de accesare a diferitelor informații din antetele HTTP sau legate de platforma pe care rulează aplicația web, posibilitatea de gestiune a informațiilor dintr-un sistem de gestiune pentru baze de date, ușurința în depanarea aplicației web, posibilitatea de integrare a unor biblioteci, formatele în care pot fi transferate datele).

Orice specificaţie care nu este menţionată mai sus reprezintă decizie de implementare. Puteţi considera orice simplificare în condiţiile în care enunţul nu precizează altfel.

BONUS. Se pot obţine punctaje suplimentare, astfel:

• 0,50 p – predarea temei cu două săptămâni mai devreme (înainte de 11.05.2016, 23:55);
• 0,50 p – modificarea sistemului de rezervare de locuri / achiziție de bilete în cadrul aplicației desktop, astfel încât acesta să se realizeze pe baza unei locații (unui interval de locații) specifice în sală, caracterizată prin rând și loc; se vor defini categorii de locații, fiecare dintre acestea având asociat un preț specific;
• 0,50 p - implementarea unui sistem de recomandări, în cazul aplicației web: în situația în care pentru un utilizator a realizat achiziții anterioare de bilete la reprezentații culturale, i se pot face anumite sugestii cu privire la spectacolele pe care le poate viziona, folosind un algoritm propriu (posibile criterii fiind: spectacole cu aceeași distribuție / scenograf / regizor / producator, care au program in aceeași sală, în aceeași zi a săptămânii și la aceeași oră sau alte criterii);

Tema va fi realizată individual şi va fi prezentată înainte de examenul de restanță, la o dată care va fi anunțată ulterior. Neprezentarea temei de casă sau un rezultat nesatisfăcător al prezentării (necunoașterea funcționalității aplicației / codului sursă, imposibilitatea de a răspunde la întrebări) atrag după sine anularea punctajului corespunzător acesteia. În cadrul prezentării veţi specifica succint funcţionalităţile pe care le-aţi dezvoltat şi veţi răspunde la întrebări cu privire la modul de implementare al acestora.

Sunt punctate și implementări parțiale, în sensul că anumite module nu au fost abordate deloc. Este obligatorie proiectarea și implementarea bazei de date (complet sau incomplet).

Tema va trebui transmisă sub forma unui mesaj la adresa de poștă electronică aipi2015@andreirosucojocaru.ro sub forma unei arhive de tip .zip (având denumirea Grupa34XCX_NumePrenume_TemaRecuperare.zip) care să conţină script-ul pentru crearea şi popularea tabelelor din bazele de date (numele bazelor de date fiind Grupa34XCX_NumePrenume_InstitutieCulturala pentru fiecare companie organizatoare de spectacole respectiv Grupa34XCX_NumePrenume_AgentIntermediere pentru agentul de intermediere) – în rădăcina, sursele aplicaţiilor (proiecte Eclipse / NetBeans), configurațiile de rulare (parametrii java.rmi.server.codebase, java.rmi.server.hostname, java.security.policy) - dacă se optează pentru JAX-WS, vor trebui indicate locațiile la care vor fi publicate serviciile web - specifice aplicației desktop, precum şi un README în care să explicaţi funcționalitățile dezvoltate, problemele întâlnite și modul de soluționare a acestora. În cazul în care aplicaţia web este găzduită online, veţi indica URL-ul de unde aceasta poate fi accesată. Subiectul utilizat va fi [TemaRecuperare][Grupa34XCX][NumePrenume]. Temele care nu respectă convențiile de nume indicate nu vor fi luate în considerare. Prezentarea se poate face numai după ce tema a fost predată sub această formă.

Temele vor fi comparate prin aplicaţii specializate pentru a se depista eventualele fraude. În această situaţie, întreg punctajul pe parcursul semestrului va fi anulat, studenţii implicaţi (atât originalul, cât şi copia / copiile) fiind obligaţi să repete disciplina – cu taxă – în anul universitar următor.