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.

Sistemul va putea fi accesat, pe baza unui proces de autentificare, și de către clienții care și-au creat un cont de acces care a fost 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ă), respectiv CNP-ul / CUI-ul. Gestiunea acestor solicitări se face doar de către un administrator sau super-administrator. 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 situația curentă a conturilor sale, pentru fiecare în parte afișându-se IBAN-ul, tipul de cont, valuta și soldul la momentul respectiv.

Pentru fiecare cont în parte, clientul poate genera un raport cu tranzacțiile realizate pentru un anumit interval de timp indicat (dată de început, dată de sfârșit), afișându-se și balanța intermediară după fiecare operațiune în parte. De asemenea, se va afișa situația contului la începutul și la sfârșitul perioadei respective (sold inițial și sold final).

Utilizatorul poate transmite către bancă o solicitare pentru realizarea unei tranzacții, indicând contul său din care dorește să realizeze operațiunea respectivă (în situația în care deține mai multe produse de acest tip, în caz contrar acest lucru nefiind necesar) precum și contul către care se va realiza tranzacția, în cadrul aceleiași instituții financiar-bancare (dacă acesta nu este găsit de sistemul informatic, se va genera un mesaj de eroare). Până la momentul în care tranzacția va fi procesată din aplicația desktop de un expert financiar-contabil, suma de bani respectivă va fi retrasă din contul clientului, însă nu va fi transferată propriu-zis, acest fapt realizându-se doar în momentul când operațiunea respectivă este aprobată; în cazul în care tranzacția este respinsă, suma de bani va fi restituită.

Clientul poate solicita și deschiderea sau închiderea unui cont, specificând, după caz, tipul de cont dorit, respectiv codul IBAN al acestuia. După ce operațiunea va fi realizată (în mod automat), rezultatul va putea fi vizualizat în lista de produse deținute. Solicitarea de deschidere a unui cont de debit va fi aprobată dacă respectivul client nu are deține alte conturi de credit cu sold negativ. De asemenea, solicitarea de deschidere a unui cont de credint nu va fi aprobată dacă utilizatorul mai are un alt cont de acest tip. Închiderea unui cont presupune că suma curentă din cadrul acestuia să nu fie negativă.

De asemenea, se va implementa și un sistem de comunicație, prin intermediul căruia clientul poate transmite un mesaj către bancă, care poate avea drept obiect o solicitare pentru suport tehnic, la care vor răspunde administratorii, respectiv pentru obținerea de informații legate de serviciile oferite, la care vor răspunde experții financiar-contabili. Un astfel de mesaj este caracterizat prin expeditor, subiect, dată și oră, tip, conținut și stare (citit sau necitit).

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

Fiecare fereastră a interfeței grafice va fi definită în cadrul unui fișier FXML generat folosind Scene Builder 2.0.

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

Un angajat poate lucra la mai multe sucursale, în zile diferite ale săptâmânii, fapt specificat în cadrul orarului.

Numărul de zile de concediu de odihnă rămase se calculează începând cu data angajării, proporțional cu numărul de zile lucrate în anul respectiv. Un inspector de resurse umane nu poate preciza un concediu de odihnă pentru o perioadă mai mare decât numărul de zile de care dispune angajatul respectiv (numărul de zile de concediu de odihnă rămase), în caz contrar generându-se un mesaj de eroare.

Pentru calculul salariului, se va avea în vedere faptul că un concediu de odihnă este remunerat cu 100% (ca și când angajatul ar fi lucrat), un concediu fără plată cu 0%, iar un concediu medical cu un procent variabil, în funcție de codul de indemnizație (se vor folosi trei valori, la alegerea proprie).

Informațiile furnizate de serviciul la distanță vor fi preluate dintr-o bază de date, în care cursurile vor fi introduse manual (fără a fi necesară o interfață grafică ca intermediar), pentru fiecare dată calendaristică în parte.

În cadrul transferurilor intrabancare, se vor realiza verificările necesare (un cont de debit nu poate avea soldul negativ în urma realizării tranzacției, nu se poate depăși un anumit plafon pentru un tip specific de valută), generându-se mesaje de eroare sugestive în cazul în care nu se pot efectua. Atât sursa cât și destinația transferului pot fi deopotrivă persoane fizice sau persoane juridice.

În cadrul informațiilor legate de jurnalizare, se vor stoca și comisioanele percepute lunar pentru fiecare cont în parte.

Pentru solicitările realizate de client se vor transmite mesaje în mod automat atunci când un expert financiar-contabil le aprobă sau le respinge.

Pentru rapoartele pe care utilizatorul le poate vizualiza legat de operațiunile realizate, tranzacțiile care nu au fost încă analizate de expertul financiar-contabil vor fi marcate ca fiind în așteptare.

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 15.05.2015, 23:55);
• 0,50 p – determinarea profitului operațional al băncii în aplicația desktop, pentru fiecare lună calendaristică în parte, și afișarea lui în interfața expertului financiar contabil; calculul său se obține ca diferență dintre veniturile provenite din comisioane și dobânzi la credite și cheltuielile cu salariile angajaților, acestea fiind defalcate pe sucursale (presupunând că fiecare angajat și fiecare client aparține unei singure sucursale);
• 0,50 p – posibilitatea de a programa din aplicația web o serie de plăți recurente; acestea sunt realizate periodic, la intervale prestabilite de timp (săptămânal, lunar, trimestrial, semestrial, anual), începând cu o anumită dată calendaristică, către un cont bancar, suma de bani fiind fixă; ele vor fi realizate în mod automat cu condiția ca soldul curent (raportat la tipul de cont să o permită), în caz contrar generându-se un mesaj de eroare, marcat în operațiile de jurnalizare și transmis sub formă de mesaj clientului.

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. Sunt obligatorii proiectarea și implementarea bazei de date (complet sau incomplet), respectiv a interfeței grafice.

Tema va trebui încărcată pe site-ul cs.curs.pub.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 baza de date (numele bazei de date fiind Grupa34XCX_NumePrenume) – în rădăcină, sursele aplicaţiei (proiect Eclipse / NetBeans), scripturi ce conţin lansări în execuţie ale aplicației desktop și a serviciului de conversie valutară la distanță, specificând argumentele necesare²⁾ precum şi un README în care să explicaţi funcționalitățile dezvoltate, tehnologiile folosite, problemele întâlnite și modul de soluționare a acestora, eventualele decizii de implementare. Dacă aplicația web este găzduită online, veți indica URL-ul de unde aceasta poate fi accesată. Temele care nu respectă convențiile de nume indicate nu vor fi luate în considerare.

Încărcarea pe site nu este redundantă, 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.