PROIECTAREA UNEI ARHITECTURI PENTRU APLICA ȚII WEB [607397]

Universitatea "Politehnica" din București
Facultatea de Electronică, Telecomunicații și Tehnologia Informației

PROIECTAREA UNEI ARHITECTURI PENTRU APLICA ȚII WEB
CE FOLOSESC MODELUL DE BAZE DE DATE RELA ȚIONAL
CAT ȘI CEL NON -RELA ȚIONAL

Proiect de diplomă
prezentat ca cerință parțială pentru obținerea titlului de
Inginer în domeniul Calculatoare și Tehnologia Informației
programul de studii de licență Inginer ia Informației

Condu cător științific Absolvent
Ș.L.Dr.Ing. Valentin PUPEZESCU Alina -Elena LUNGU

Bucure ști
2018

Anexa 6

Copyright © 2018 , Lungu Alina -Elena

Toate drepturile rezervate

Autorul acordă UPB dreptul de a reproduce și de a distribui public copii pe h ârtie sau electronice
ale acestei lucrări, în formă integrală sau parțială.

CUPRINS
LISTA FIGURILOR ………………………….. ………………………….. ………………………….. ………………………….. ……. 11
LISTA ACRONIMELOR ………………………….. ………………………….. ………………………….. …………………………. 13
INTRODUCER E ………………………….. ………………………….. ………………………….. ………………………….. …………. 15
MOTIVAȚIA TEMEI ………………………….. ………………………….. ………………………….. ………………………….. . 15
OBIECTIVELE PROIECTULUI DE DIPLOMĂ ………………………….. ………………………….. …………………. 15
CONTRIBUȚII PERSONALE ………………………….. ………………………….. ………………………….. ……………….. 16
CAPITOLUL 1. NOȚIUNI TEORETICE GENERALE ………………………….. ………………………….. ………… 17
1.1 BAZE DE DATE RELAȚIONALE ………………………….. ………………………….. ………………………….. 17
1.2 BAZE DE DATE NON -RELAȚIONALE ………………………….. ………………………….. …………………. 18
CAPITOLUL 2. TEHNOLOGII UTILIZATE ………………………….. ………………………….. ……………………… 21
2.1 INTERNETUL ………………………….. ………………………….. ………………………….. ………………………….. 21
2.1.1 PROTOCOL UL DE COMUNICARE HTTP ………………………….. ………………………….. ………. 21
2.1.2 MODELUL CLIENT -SERVER ………………………….. ………………………….. ………………………… 22
2.1.3 XML, JSON ………………………….. ………………………….. ………………………….. ……………………….. 22
2.2 LIMBAJE DE PROGRAMARE ………………………….. ………………………….. ………………………….. ….. 23
2.2.1 C#, .NET FRAMEWORK ………………………….. ………………………….. ………………………….. ……. 24
2.2.2 TYPESCRIPT, ANGULAR ………………………….. ………………………….. ………………………….. …. 24
2.2.3 HTML, CSS ………………………….. ………………………….. ………………………….. ……………………….. 24
2.3 SISTEME DE GESTIUNE A BAZELOR DE DATE ………………………….. ………………………….. …. 25
2.3.1 MICROSOFT SQL SERVER ………………………….. ………………………….. ………………………….. . 25
2.3.2 MONGODB ………………………….. ………………………….. ………………………….. ………………………. 25
CAPITOLUL 3. PREZENTAREA APLICAȚIEI ………………………….. ………………………….. …………………. 27
3.1 STRUCTURA APLICAȚIEI ………………………….. ………………………….. ………………………….. ………. 27
3.1.1 BAZE DE DATE ………………………….. ………………………….. ………………………….. ………………… 27
3.1.2 SECURITATE ………………………….. ………………………….. ………………………….. ……………………. 28
3.2 FUNCȚIONAREA APLICAȚIEI ………………………….. ………………………….. ………………………….. … 28
3.2.1 PAGINI PROFESOR ………………………….. ………………………….. ………………………….. ………….. 30
3.2.2 PAGINI STUDENT ………………………….. ………………………….. ………………………….. ……………. 32
3.2.3 PAGINI SECR ETAR ………………………….. ………………………….. ………………………….. ………….. 33
3.2.4 PAGINI ADMINISTRATOR ………………………….. ………………………….. ………………………….. .. 36
CAPITOLUL 4. TESTAREA PERFORMANȚELOR ………………………….. ………………………….. …………… 38
CONCLUZII ………………………….. ………………………….. ………………………….. ………………………….. ……………….. 41
BIBLIOGRAFIE ………………………….. ………………………….. ………………………….. ………………………….. …………. 43

ANEXE ………………………….. ………………………….. ………………………….. ………………………….. ……………………… 45
Anexa 1. Exam.cs ………………………….. ………………………….. ………………………….. ………………………….. …. 45
Anexa 2. UniversityService.cs (parțial – metode de CRUD pentru Subject) ………………………….. ……….. 46
Anexa 3. UniversityController.cs (parțial – metode de CRUD pent ru Subject) ………………………….. ……. 48
Anexa 4. EnrollmentUI.cs ………………………….. ………………………….. ………………………….. ………………….. 49
Anexa 5. professor -grades.component.html (componenta ProfessorGrades) ………………………….. …… 51
Anexa 6. professor -grades.component.ts (componenta ProfessorGrades) ………………………….. ………. 53
Anexa 7. Univ ersityService.cs (parțial – metodele de testare a performanței) ………………………….. …… 54
Anexa 8. ArchiveService.cs ………………………….. ………………………….. ………………………….. ………………… 55
Anexa 9. MongoDB – interogare pentru a obține mediile valorilor de test ………………………….. ……….. 55
Anexa 10. AttendanceUI.cs ………………………….. ………………………….. ………………………….. ……………… 56

11
LISTA FIGURILOR
Figura 1.1: Exemplu de entit ăți stocate într-o bază de date non -relațional ă sub form ă de documente …….. 19
Figura 2.1 : Func ționarea unui web browser ………………………….. ………………………….. ………………………….. … 21
Figura 2.2 : JSON forma colec ției de perechi atribute -valori ………………………….. ………………………….. ……….. 23
Figura 2.3 : JSON forma listei ordonate de valori ………………………….. ………………………….. ………………………. 23
Figura 3.1 : Schema bazei de date relaționale – university ………………………….. ………………………….. ………….. 27
Figura 3.2 : Pagina de autentificare ………………………….. ………………………….. ………………………….. ……………. 29
Figura 3.3 : Pagina "Date personale", pentru utilizator de tip "profesor" ………………………….. …………………. 30
Figura 3.4 : Pagina "Catalog", specific ă tipului de utilizator "profesor" ………………………….. ……………………. 30
Figura 3. 5 : Pagina "Statistici", specific ă tipului de utilizator "profesor" ………………………….. …………………… 31
Figura 3.6 : Pagina "Situație școlară", specifică tipului de uti lizator "student" ………………………….. ………….. 32
Figura 3.7 : Pagina "Student", specifică tipului de utilizator "secretar" ………………………….. ……………………. 33
Figura 3. 8 : Pagina "Înscrieri", specifică tipului de utilizator "secretar" ………………………….. …………………….. 33
Figura 3.9 : Pagina "Înscrieri", secțiunea "Modifică înscriere" ………………………….. ………………………….. …….. 34
Figura 3.1 0 : Pagina "Discipline", specifică tipului de utilizator "secretar" ………………………….. ………………… 34
Figura 3.1 1 : Pagina "Discipline", secț iunea "Adaug ă disciplin ă" ………………………….. ………………………….. … 35
Figura 3.1 2 : Pagina "Utilizatori", specifică tipului de utilizator "administrator", secțiunea "Studenți" …….. 36
Figura 3.13: Pagina "Utilizatori", secțiunea "Studenți", secțiunea "Adaugă student" ………………………….. …. 37
Figura 4 .1 : Măsurători pentru func ția "GetAttendancesForStudent" ………………………….. ………………………. 38
Figura 4 .2 : Măsurători pentru funcția "GetAttendances ForProfessor" ………………………….. …………………….. 39
Figura 4 .3 : Măsurători pentru funcția "GetCurrentEnrollments" ………………………….. ………………………….. … 39

12

13
LISTA ACRONIMELOR
TCP/IP – Transmission Control Protocol/Internet Protocol
WWW – World Wide Web
VoIP – Voice Over IP
FTP – File Transfer Protocol
URI – Uniform Resource Identifiers
URL – Uniform Resource Locator
ISP – Internet Service Provider
HTTP – Hypertext Transfer Protocol
RPC – Remote Procedure Call
RDA – Remote Data Access
QMP – Queued Message Processing
HTML – Hypertext Markup Language
ODC – Open Database Connection
DOM – Document Object Model
CSS – Cascading Style Sheet
API – Application Programming Interfaces
SQL – Structured Query Language
ORM – Object -Relat ional Mapping
RAM – Random Access Memory
CPU – Central Processing Unit
CLI – Command Line Interface
CRUD – Create Read Update Delete
LINQ – Language -Integrated Query

14

15
INTRODUCERE
MOTIVAȚIA TEMEI
Bazele de date sunt folosite în orice sistem informatic pentr u stocare a și prelucrare a
ulterioară a datelor . Alegerea sistemului de gesti une a bazelor de date folosit este printre prime le
decizii care trebuie luate când se realizează o aplicație. Î n func ție de specificul aplica ției, baza de
date aleasă poate fi relațional ă sau non -relațional ă. Fiecar e din tre aceste tipuri are avantaje ș i
dezavantaje caracteristice.
Alegerea unui model de baze de date este o decizie foarte importantă, întrucâ t aceasta poate
face diferența î ntre o func ționare corec tă și rapid ă și o func ționare deficitar ă a sistemului. În cazul
unei alegeri gre șite, pot exista probleme de duplicare a datelor și de performan ță. Consecin țele unei
decizii gre șite pot fi pierderea informa țiilor, blocare a sistemului din lips ă de scala bilitate sau chiar
la refacerea aplica ției. Costurile asociate sunt at ât de natur ă material ă, cât și de timp.
Într-un sistem care gestioneaz ă datele unei universit ăți, este nevoie at ât de propriet ăți
caracte ristice unei baze de date rela țional e (integritatea datelor, accesa re rapid ă a datelor asociate
dată de agreg ările dintre tabele), c ât și propriet ăți găsite la modelul non -relațional (scalabilitatea ,
pentru a manipula cantit ăți mari de date, în contiun ă creștere). O arhitectur ă optim ă pentru un astfel
de sistem încorporează atât o baz ă de date rela țional ă (SQL) c ât și una non -relațional ă (NoSQL).
Într-o facultate, entit ăți precum Student, Profesor, Departamen t, Serie, Disciplină , An Școlar
au o structur ă bine definit ă și au între ele asocieri care fac informa țiile ușor de accesat dac ă sunt
transpuse într-un sistem rela țional . Existența altor e ntități precum Înscriere An Școlar (leg ătura între
Student, Serie și An Școlar ) și Curs (legatur ă între Înscriere An Școlar și Disciplina ) crește
semnificativ însă cantitatea de informa ție, prin exist ența conceptul ui de An Școlar.
Pentru un model relaț ional, acest lucru poate duce la probleme de performan ță cauzate de
agreg ările prea multor tabele. Consider ând faptul c ă datele cel mai des folosite sunt cele din anul
curent, sol uția ar fi stocarea datelor din aceste tabele într-o baz ă de date de tip non -relațional.
Astfel, acestea pot fi accesate la nevoie, pentru realizarea de statistici și pentru eventuale verific ări
procedurale, f ără să afecteze performan ța aplica ției în realizarea sarcinilor uzuale.
OBIECTIVELE PROIECTULUI DE DIPLOMĂ
Obiectivele acestei lucr ări sunt p roiectarea și testarea performan țelor unui sistem hibrid care
folose ște at ât modelul de date rela țional c ât și cel non -relațional, în scopul gestion ării datelor
specifice unei universit ăți. Aceast ă aplica ție a fost gandit ă ca un înlocuitor pentru o serie de
proceduri și sisteme folosite în prezent cu acest scop.
Unul dintre ele este site -ul " https://studenti.pub.ro ", unde studen ții își văd notele. Pe acest
site nu au însă acces și profesorii , ei trebuie s ă predea notele studen ților din anul curent la
secretariat în format fizic, urm ând ca secretarii s ă se ocupe mai departe de trecerea notelor în
catalog . Acest pas poate fi eliminat, iar în aplica ție profesorii vor pune notele în mod direct, av ând
la dispozi ție lista studen ților. Acest lucru va permite studen ților s ă vadă nu doar disciplina și nota,
cât și profesorul care a predat -o și emailul acestuia, pentru a -i semnala direct eventual e
neconcordan țe. Secretarul va avea sarcina de a realiza în aplica ție asocierile Disciplina -Profesor –
Serie în fiecare an.

16
O func ționalitate nou ă este vizualizarea de grafice statistice: fiecare profesor are
posibilitatea de a vedea performan ța seriilor la care a predat, la diferite discipline .
Primul capitol con ține prezentarea introductiv ă a aplica ției, motiva ția temei alese si
contribuțiile personale .
Capitolul 2 con ține no țiunile teoretice despre conceptele de baz ă ale modelelor de baze de
date folosite, precum și avantaje și dejavantaje ale acestora.
Capitolul 3 descrie tehno logiile folosite în realizarea aplica ției.
Capitolul 4 prezint ă structura aplica ției (baze de date, securitatea în aplicaț ie), precum și
funcționarea acesteia.
Capitolu 5 arat ă rezultatul unor teste de performan ță asupra bazelor de date .
CONTRIBUȚII PERSONALE
Am realizat această aplica ție in totalitate, folosindu -mă de cunoș tințele acumulate în
perioada facultații și de func ționali tațile oferite de tehnologiile: ASP .NET Framework ș i Angular
CLI și MongoDB .
Am proiectat schema (Figura 3.1) și am folosit metodologia Model First din cadrul Entity
Framework pentru a crea baza de date SQL (univer sity), luâ nd în considerare cazurile de folosire și
nevoile tipurilor de utilizatori. De asemenea , am creat modelul pentru baza de date NoSQL
(archive) , care s ă includ ă doar informaț iile relevan te modelului universitate, î ntr-o structura mai
compact ă decât cea conținut ă în baza de date SQL (Anexa 1) .
Am creat la nivel de server clasele și metodele care permit realizarea operațiilor necesare de
creare, afișare, modificare și ștergere (Anexa 2 , Anexa 3 ). În acest scop, am creat și clasele folosite
ca modelele de legatur ă între client și server, folosind concepte de programare orientată pe
obiect (Anexa 4) .
La nivel de clien t, am generat structurile de fiș iere (controllere, servicii și modele), din linia
de comandă Angular CLI, apoi am creat paginile web pentru afișarea datelor (Anexa 5) , precum ș i
funcțiile care manipulează aceste pagin i și prelucrează informaț iile venite de la server (Anexa 6) .
Am folosit limbajul LINQ pentru crearea de interog ări ale bazei de date în aplica ție, în
cadrul metodelor de pe partea de server . Am descoperit astfel echivalentul în acest limbaj al unor
sintaxe deja cunoscute în SQL (Anexa 7) .
Pentru a putea determina cum este influențată performanța aplicației de cantitatea de date și
de tipul de sistem de gestiune a bazelor de date folosit, am avut nevoie să stochez și să compar
timpii de execuție ai diverselor funcții utilizate . În acest scop a fost proiectată, creată ș i folosită o
colecție n ouă în baza de date NoSQL, numit ă "performance _tests ". Aceasta conține sub forma
specifică de documente un set de înregistrări care pastrează numele funcției folosite, a tipului de
bază de date interogat, precum și timpul de execuție al funcției (Anexa 7, Anexa 8) .
Am învățat să folosesc linia de coman dă p entru a trimite interogări la o baz ă de date
MongoDB , cu scopul de a obține valori pe care să le reprezint într -un grafic . Astfel, am extras
valori numerice prelucrate prin intermediul unui "pipeline de agregare " (aggregation pipeline),
obținând medii ale valorilor de timpi pentru trei dintre cele mai relevante funcții din aplicație,
pentru fiecare creștere anual ă a bazei de date (Anexa 9) .
Cu scopul de a testa performanț ele aplica ției, am creat funcții care genere ază cantit ăți mari
de date și le inserea ză în bazele de date. Am realizat de asemenea și metode de legatură între
modelele de SQL și modelul de MongoDB, pentru a putea face cu usurin ță arhivarea datelor dintr -o
bază de date în cealalt ă(Anexa 10) .

17
CAPITOLUL 1. NOȚIUNI TEORETICE GENERALE
O baz ă de date este o colecți e organizat ă de date, depozitată și accesat ă electronic. De obicei
datele sunt organizate în modele abstracte inspirate din realitate care s ă permit ă procesarea
informa țiilor.
Un sistem de gestiune a bazei de date este un software cu care interac ționeaz ă userii și
serviciile web. Un astfel de s istem este conceput pentru a suporta definirea, crearea, apelarea,
actualizarea și administrarea bazelor de date. Fiecare sistem are prop riul format pentru stocarea
bazei de date, comunicarea între acestea fiind posibil ă prin diferite interfe țe de programare pentru
aplica ții (API) precum SQL, ODBC, JDBC, etc.
De obicei sistemele de gestiune a bazelor de date sunt clasificate în funcție de mo delul de
date pe care îl suport ă. Dintre acestea, cele mai des int âlnite sunt cele rela ționale și nerela ționale.
1.1 BAZE DE DATE RELAȚIONALE
Baza de date rela țional ă reprezint ă o implementare de baz ă de date ce are la baza modelul
relațional de reprezentare a datelor. Acestea sunt repre zentate în seturi de date grupate prin diferite
relații.
Bazele de date rela ționale suport ă diferite tipuri de constr ângeri care ajut ă menți nerea
integrit ății datelor [1]:
• Constr ângere de unicitate care asigură unicitatea tuturor valorilor dintr -o coloană;
• Constrângeri de chei str ăine care ajut ă la crearea unei rela ții între 2 tabele. De obicei o cheie
străină refer ă o cheie principal ă sau unic ă a unei alte tabele. De asemenea, aceasta asigur ă
integritatea referin țelor, nepermi țând stergerea anumitor date care sunt referen țiate;
Majoritatea bazelor de date rela ționale sup ortă SQL ca limbaj de interogare. Instruc țiunile
de interogare de obicei descriu rezultatul dorit f ără vreo men țiune asupra e tapelor de execu ție pentru
obținerea acestuia. Si stemul decide ulterior care este cea mai bun ă abordare pentru datele cerute.
Deși aceast ă abordare difer ă față de una procedural ă, exist ă suport și pentru rutine și functii
procedurale care pot fi declarate, stocate și apelate pentru o abordare mixt ă [1].
Din punct de vedere al performan ței, bazele de date folosesc inde cși pentru a optimiza
timpul de r ăspuns la interog ări. Inde cșii primari, folosi ți de c ătre cheile primare, defines c ordinea de
stocare a datelor pe disk. Inde cșii secundari sunt folosi ți pentru a oferi diverse combina ții de
aranjare a datelor pentru a facilita interog ări mai rapide evit ând reordonarea datelor pe disk [1].
Una din cele mai com une tipuri de aplica ții care folosesc bazele de date sunt OLTP -urile (
Online Transaction Processing ) . Aceste sisteme asigur ă înregistrarea tutur or interac țiunilor care au
loc într-o organizație sau un business. Tranzacția reprezintă un eveniment sau o interac țiune care
are loc în cadrul unei organiza ții. Aceasta se poate rezuma la un set de instruc țiuni care trebuie
effectuate asupra bazei de date pentru a confirma procesul [1].
Tranzac țiile au cateva propie tăți definite în 1983 de c ătre Andreas Reuter și Theo Härder
care asigu ră integritatea datelor sub acronimul ACID:
• Atomicitatea – deși este compus ă din mai multe instruc țiuni, o tranzac ție este considerat ă o
singur ă schimbare. Aceasta fie este procesat ă cu succes și înregistrat ă în baza de date sau
eșuează, iar baza r ămâne neschimbat ă[1].
• Consisten ța – o tranzac ție poate tranzi ționa o baz ă de date dintr -o stare valid ă numai într-o
altă stare valid ă. În orice moment de timp toate regulile predefinte în baza de date trebuie

18
respectate ( constr ângeri, trigere, cascade, șamd). Acest lucru previne coruperea datelor , dar
nu garanteaz ă corectitudinea tranzac ției în sine[1].
• Izolare – tranzac țiile sunt de obicei executate concomit ent. Din acest motiv izolarea este
important ă pentru a asigura c ă toate schimb ările care se efectueaz ă pe baz ă sunt valide și
executate ca și cum tranzac țiile ar fi fost procesate secven țial[1].
• Durabilitate – aceasta garanteaz ă persistența modific ărilor indifferent de diverse scenarii
negative care pot avea loc precum c ăderi de tensiune [1].
Deși bazele d e date rela ționale int ăresc integritatea referen țiala a datelor, scalarea acesteia poate
provoca probleme la implementare. Scalarea pe orizontala implic ă extinderea tabelelor cu coloane
noi, e xtragerea coloanelor în tabele noi, ștergerea coloanelor sau a tabelelor și poate duce la
inconsisten țe în datele stocate dac ă nu este implementat ă correct. Scalarea pe vertical ă, stocarea în
tabele a milioane de date, poate fi rezolvat ă doar prin îmbunata țiri hardware p ână la un punct sau
crearea unui sistem de shard ing [1].
1.2 BAZE DE DATE NON -RELAȚIONALE
O bază de date non -relațional ă este o baz ă de date care nu folose ște metodele clasice de
tabele și coloane. Aceste baze de date folosesc un model de pastrare a datelor specializat pentru
cerintele tipurilor de date care trebuie stocate , fiind optimizate fiecare pentru anumite situatii [2].
Ele sunt denumite și baze de date NoSQL, deoarece nu folosesc limbajul SQL pentru
interogare, ci alte limbaje de programare și sintaxe pen tru a interoga baza de date. Deși majoritatea
suportă și sintaxa SQL, modul în care instruc țiunile sunt executate diferă de modul în care ar
executa un SGBD o interogare clasic ă [2].
Principalele cat egorii de baze de date non -relaționale, după tipul de date stocate sunt[2]:
• sub formă de documente
• sub formă de coloane
• sub formă de perechi cheie/valoare
• sub formă de grafuri
• sub formă de serii de timpi
• sub formă de obiecte binare
• sub formă de indecș i externi
Baza de date care stochează informațiile sub fomă de documente ("document data store")
foloseș te în acest scop stru ctura de JSON. Entitatea de bază , numit ă în acest caz document, este
formată dintr -un set de c âmpuri de text, cu ni ște valori asociate. Valorile pot fi sub form ă de text,
număr, dat ă calendaristic ă, listă sau obiect, informaț ia fiind stocat ă ca simplu text sau criptat e sub
formă de XML, YAML, JSON sau BSON [2].
În mod normal, un document con ține toate informa țiile despre o entitate, informa ții care
într-o baza de date rela țional ă s-ar întinde pe mai multe tabele. Un avantaj al bazelor de date de tip
document este flexibilitatea structurii , ceea ce înseamn ă că nu este obligatoriu ca toate documentele
să aibă structura ini țială. Acest lucru permite o adaptare rapid ă la schimb ări în logica de business a
aplica țiilor care implementeaza acest tip de baze de date [2].
În aplica ție, un document po ate fi ob ținut folosind cheia acestuia, un identificator unic, cel
mai adesea o valoare hash. Aceasta poate fi atribuit ă de baza de da te la crearea documentului, sau ,
în unele cazuri, se poate specifica unul din atributele documentului, care va fi folosit ca și cheie.
Majoritatea bazelor de date de acest tip implementeaz ă și indexarea datelor [2].

19
Un alt avantaj al acestui tip de baze de date (tip document) este capacitatea de a modifica
valorile atributelor dintr -un document f ără a suprascrie intreg documentul . Acest lucru face ca
opera țiile de citire și scriere pe mai multe atribute ale aceluiaș i document s ă fie atomice [2].

Figura 1.1: Exemplu de entităț i sto cate într-o bază de date non -relațional ă sub form ă de documente
Sursa: [2]
Spre d eosebire de bazele de date relaț ionale, modelul non -relațional folose ște o arhitectur ă
de stocare diferit ă, neav ând o schem ă fixă a bazei de date. Acestea fie nu sus țin deloc, fie limiteaz ă
tranzac țiile, și nu includ în general indec și secundari din motive de scalabilitate. Pe de alt ă parte , la
bazele de date nerela ționale apar concepte precum replicare și sharding [2].
Replicarea este procedeul prin care o bază de date păstrează și sincronizează acela și set de
date pe mai multe servere sub formă de set replică ("replica set") . În acest fel sunt create mai multe
copii ale informa țiilor, exist ând o redundan ță a datelor ce face s ă creasc ă siguran ța informa țiilor în
cazul pierderii unuia dintre servere. O alt ă consecin ță favorabil ă a acestui concept este
disponibilitatea datelor. Astfel, exist ă posibilitatea de a trimite opera țiile de citire c ătre servere
diferite, ceea ce duce la o posibilitate mai mic ă de suprainc ărcare a unui singur server [3].
Sharding este o metod ă de a distribui date pe mai multe servere. Sistemele de baze de date
care con țin o cantitate mare de informa ții pot dep ăși limita de RAM a sistemului, ceea ce duce la o
supra încărcare a capacit ății I/O a discului. De asemenea, aplica țiile care au o rat ă de interog ări
foarte mare a bazei de date pot atinge maximul capacit ății de procesare a serverului pe care se afl ă
aceasta. Pentru a adresa cre șterea bazei de date, există două posibilități: scalare pe vert icală
(îmbun ătățirea serverului din pun ct de vedere al procesorului, capacit ății memoriei RAM, al
spațiului de stocare) și scalare pe orizontal ă (împărțirea datelor pe mai multe servere, numite
"shards", de unde vine și denumirea de "sharding"). Metoda ace asta de scalare pe orizontal ă este
mai pu țin costisitoare dec ât scalarea pe vertical ă, dar aduce și dezavantaje precum cre șterea
comple xității infrastructurii și a mentenan ței bazei de date [4].

20

21
CAPITOLUL 2. TEHNOLOGII UTILIZATE
2.1 INTERNETUL
Internetul este un sistem global de rețele de calculator interconectate care folosește o serie
de protocoale ( TCP/IP ) pentru a realiza legăturile dintre miliarde de dispozitive de pe întreaga
planetă. TCP/IP este setul de protocoale principale folosite pentru a transmite informația. El
realizează și gestionează atât conexiunea dintre două calculatoare cât și pache tele de date trimise
între ele. Internetul oferă o multitudine de servicii ce rulează la nivel de rețea, printre care cele mai
cunosc ute sunt : WWW (world wide web), email (poștă electronică), VoIP (telefonie prin internet)
și FTP (transfer de fișiere) [5].
WWW -ul sau Web -ul este un spațiu informațional unde resursele sunt identificate și
accesate după niște identificatori globali numiț i URI . Cea mai cunoscută formă de URI este URL –
ul , cunoscut de asemenea ca adresă web. Web -ul este unealta principala folosită de oameni pentru a
interacționa cu internetul. Pentru a folosi web -ul este nevoie de un web browser. Un web browser
este o apli cație software folosită pentru preluarea, prez entarea și trimiterea de resurse și informații
pe web. Informațiile pot fi de tip pagină web, imagine, video sau orice altă formă de prezentare.
Browserele pot fi folosite atât pentru navigarea pe web cât și pe ntru a accesă informații în cadrul
unei rețele private sau fișiere într -un sistem de fișiere. Principalele browsere folosite la momentul
prezent sunt Google Chrome, Firefox, Ope ra, Safari , Microsoft Edge și Internet Explorer [6].
Procesul de navigare folos ind un browser începe prin introducerea unui URL de către
utilizator. Acesta este interpretat apoi de browser care, în funcție de protocolul setat la început,
efectuează operația de cerere a datelor, apoi răspunsul este încărcat în browser pentru utilizato r[6].

Figura 2.1 : Func ționarea unui web browser
Sursa: [6]
În cadrul procesului se remarc ă trei componente cheie: clientul (web user), serverul (web
server) și protocolul.
2.1.1 PROTOCO LUL DE COMUNICARE HTTP
Un protocol este un sistem de reguli care permite dou ă sau mai multor entit ăți în cadrul unui
sistem de comunicare să transmit ă informații. Aceste reguli definesc sintaxa, semantica și
sincronizarea comunic ării și opț ional metode de recuperare în cazul apariției unei erori.
Protocoalele pot fi imp lementate hardware, software sau o combinație din cele două.
HTTP este un protocol pentru nivelul de aplicație folosit pentru comunicări de date pe web.
Acesta fun cționează pe baza unui mecanism de cerere -răspuns în modelul computațional de client –
server. Clientul trimite un mesaj HTTP de cerere către server, iar serverul efectuează operațiile
necesare pentru a putea construi și transmite răspunsul. Răspunsul conține informații despre statusul
cererii în header și conținutul cerut în body [7].

22
HTTP definește metode pentru a identific a acțiunea care se dorește a fi efectuată pe server.
Ce rezultă în urmă unei acțiuni depinde de modul în care a fost implementată pe server. În cele mai
multe cazuri pachetul obținut este un fișier sau rezultatul unui exe cutabil de pe server. Inițial
HTTP/1.0 a definit 3 metode GET, POST și HEAD. Ulterior s -au mai adăugat încă 5 metode:
OPTIONS, PUT, DELETE, TRACE și CONNECT în HTTP/1.1. Aceste metode se împart în două
categorii [7]:
• metode care prin conven ție sunt defini te cu scopul de a extrage date de pe server f ără
a modifica starea pe server : HEAD, GET, OPTIONS, TRACE
• metode care sunt definite cu scopul de a efectua modific ări pe server : POST, PUT,
DELETE, PATCH .
2.1.2 MODELUL CLIENT -SERVER
Un sistem distribuit este un sistem software în care componentele aflate pe diferite
calculatoare legate în rețea comunică și își coordonează acțiunile prin transmitere de mesaje [8].
Printre propriet ățile sistemelor distribuite se g ăsesc:
• Sistemul trebuie să poată tolera erori în noduri individuale [9]
• Structura sistemului (topologia rețelei, latența rețelei, numărul de calculatoare) nu
este cunoscută în avans, sistemul poate fi format din diferite tipuri de calculatoare și link-uri de
rețea, iar sistemul se poate schimba în timpul executării unui program distribuit [10]
• Fiecare nod are doar o viziune limitată, incompletă a sistemului. Fiecare nod poate
cunoaște doar o parte a datelor de intrare [9]
Modelul client -server este un sistem distribuit care parti ționeaz ă sarcinile și volumul de
munc ă dintre furnizorul unei resurse sau a unui serviciu ( server ) și solicitantul serviciului (client).
2.1.3 XML, JSON
În prezent cele mai comune formate pentru transferul de date sunt XML (Extensible Markup
Language) și JSON (JavaScript Object Notation).
XML este un limbaj de marcare pentru documente care conține informație structurată.
Informația structurată conține atât date ( cuvinte, poze, etc), cât și indica ții asupra rolului pe care îl
are în context ( rubrica, nota de subsol, con ținutul unui tabel, etc.). XML este un un subset de
SGML (Standard Generalized Markup Language) [11].
Un document XML prezintă dou ă componente: o declara ție și conținutul propiu -zis. În
declara ție se specific ă versiune a documentului și sistemul de codare folosit pentru caractere. În zona
de con ținut datele sunt marcate fără excepție cu etichete de început și sfârșit, pentru fiecare segment
în parte. Etichetele de inceput au forma "<numele_etichetei> " , iar cele de final
"</numele_etichetei>". În cadrul etichetelor se pot defini și diferite atribute, pentru o precizie mai
mare în structura documentului (<nume_eticheta atribut=”valo are”> continut
</nume_eticheta> )[11].
JSON este un format de schimb facil, care folosește obiecte sub forma unor perechi de
atribute și valori. De asemenea este usor de parsat și generat pentru calculatoare. Se bazeaz ă pe un
subset al limbajului de programare JavaScript. Este independent de limba folosit ă utiliz ând
conven ții de reprezantare ase mănătoare cu cele din familia de limbaje de programare C.
JSON este construit pe dou ă structuri [12]:

23
• colec ție de perechi de atribute și valori care poate fi interpretat ă ca un obiect, structur ă,
dicționar, înregistrare sau matrice asociativ ă

Figura 2.2 : JSON forma colec ției de perechi atribute -valori
Sursa: [ 12]
• o list ă ordonat ă de valori care poate fi repre zentat ă ca un vector, matrice, list ă sau secven ță

Figura 2.3 : JSON forma listei ordonate de valori
Sursa: [ 12]
2.2 LIMBAJE DE PROGRAMARE
Limbajul de programare este un limbaj construit cu scopul de a facilita comunicarea de
instrucțiuni către o ma șină hardware. Acesta reprezintă un set de reguli și expresii pentru
formularea instrucțiunilor adresate unui computer. În cele mai multe cazuri e ste folosit pentru
realizarea de aplicații software care pot implic a efectuarea de operații matematice, implementarea
de algoritmi, gestionarea de periferice, afișarea de informații, etc [13].
Toate limbajele de programare conțin un set de componente pentru reprezentarea datelor și
pentru procesarea sau manipularea respectivelor date. Aceste componente sunt definite de o serie de
reguli sintactice și semantice care le descriu structura și semnificația. Sintaxa este form a de
suprafaț ă a unui limbaj de p rogramare. De obicei form a limbajului este de tip text care poate
conține cuvinte, numere și semne de punctuație, însă există și excepții [13].
Sintaxa descrie combinațiile posibile de simboluri care pot form a un program corect din
punct de vedere sintacti c. Aceast a este definită de o combinație de expresii regulate pentru structură
lexicală și o fo rmă Backus -Naur pentru structura gramaticii [13].
Semantica se ocupă de interpretarea structurilor de cod valide din punct de vedere sintactic.
De cele mai multe ori semantica unui limbaj de programare verifică dacă variabilele, funcțiile,
clasele, etc au fost definite într -un mod corespunzător. De asemenea se evaluează utilizarea corecta
a expresiilor și a variabilelor în conformitate cu tipurile definite, respect area controlului de acces la
resurse, etc [13].
Limbajele de programare se împart în două mari categorii:
• limbaje care necesită un compilator pentru a interpreta codul și pentru a -l transforma într-o
form ă binara (cod obiect). Rolul compilatorului apare din necesitatea de a face tranzi ția de la un
limbaj de programare de nivel înalt , la unul de nivel sc ăzut ( cod masin ă sau assembler). Cele mai
cunoscute limbaje de acest gen sunt C, C++, C#, Java, șamd[13].
• limbaje de scriptare, care nu necesită un compilator ci sunt interpretate într-un mediu de
rulare. Aceste limbaje sunt mai u șor de utilizat datorit ă permisivit ății sintacticii și semanticii. Codul
este de obicei scurt și tinut în fisiere separate sau in teractiv. Se remarc ă lipsa unui punct de inceput
specific, codul fiind executat pe loc la apelare [13].

24
Pentru realizarea aplica ției au fost necesare utilizarea și imbinarea mai multor limbaje de
programare și marcare.

2.2.1 C#, .NET FRAMEWORK
C# este un limbaj de programare orientat pe obiecte care permite dezvoltarea de diverse
aplica ții securizate care functioneaz ă pe .NET Framework. Astfel se poate crea aplica ții Windows,
servicii web, componente distribuite, aplica ții web client -server, ap licații cu baze de date [14].
Din .NET Framework am folosit pentru crearea aplica ției de server ASP.NET, acesta
expun ând un API care poate fi interogat de c ătre un client autorizat pentru ob ținerea a diverse
informa ții. Interogarea se face folosin d request -uri de tip HTTP, iar datele sunt transmise sub format
JSON. Pentru securizare s -a folosit ASP.NET Identity , o alt ă component ă expus ă de .NET
Framework care ofer ă suport pentru autentificare și autoriza ție folosind token -uri de securitate
jwt[14].
2.2.2 TYPESCRIPT, ANGULAR
Angular 5 este un framework care permite construirea facil ă a unei aplicatii web. Acesta
combin ă template -uri declarative, injectarea dependin țelor și unelte pentru testare cap ăt la cap ăt.
Are la baza structura MVVM (Model -View -ViewModel), suporta granularizarea aplica ției la nivel
de module de business, și oferă diverse tool -uri de compilare și împachetare pentru suport pe mai
multe browsere web cu timp de r ăspuns c ât mai bun. Aplica țiile pot fi scrise fie în Javascr ipt sau în
Typescript [15].
Typescript este o extensie a limbajului Javascript care permite anotarea tipurilor de date.
Acesta este compilat la final în Javascript astfel fiind compatibil cu orice browser și se poate face
dezvoltare pe orice masina. Avantaj ul principal al acestuia fa ță de Javascript este în timpul de
dezvoltare software, anotarea tipurilor permi țând men ținerea ordinii și impunerea anumitor reguli
într-un limbaj care la baz ă este foarte permisiv [15].
2.2.3 HTML, CSS
HTML (HyperText Markup Language) este un limbaj de marcare standard folosit pentru
crearea de pagini Web. Documentele HTML sunt documente SGML cu semantici generice care
permit reprezentarea de informa ții într-o gamă largă de domenii. Browserele Web pot citi fi șiere
HTML și să le redea ca pagini web scrise sau audio [16].
Elementele de tip HTML reprezintă blocurile principale din care sunt construite paginile
web. Astfel putem incorpora imagini și obiecte în pagină și să facem formulare interactive. Oferă
resursele necesare pentru a cre a documente structurate folosind semantici structurale pentru text
precum paragrafe, liste, citate, rubrici, șamd. Elementele sunt definite folosind o etichetă de
început cuprins ă între paranteze unghiulare (<html>) și o etichetă de sfârșit (</ html>). Există și
excepții, una dintre ele fiind situația în care nu e xistă conținut între etichete. Î n acel caz se
folosește o singură etichetă de formă " <link />" sau se păstrează forma etichetei de început
(<img>).Browserele Web nu afișează aceste etich ete, dar le interpretează pentru a reda conținutul
în pagină într -o formă corespunzătoare. Elementele prezintă de asemenea propiet ăți predefinite
care se specifică în etichet a de început între numele etichetei și parantez a de final [16].

25
Într-un document HTML se pot incorpora at ât cod JavaScript c ât și cod CSS pentru a defini
functionalit ăți și efecte vizuale. Codul JavaScript este delimitat folosind elemente de tip <script>
care înglobeaza codul, sau se specific ă în atributul "src" adresa unde se afl ă fisierul JavaScript.
Pentru CSS exista 3 op țiuni [16]:
• incadrarea codului CSS într-un element de tip "style"
• includerea unui fisier css folosind un element de tip "link", preciz ându-se în atributul url
adresa .
• scrierea de cod CSS în atributul style al unui element.
CSS ( Cascading Style Sheet) este un limbaj de stil folosit pentru descrierea format ării și
esteticii unui document scris într-un limbaj de marcare. De obicei este folosit pentru fisiere de tip
HTML și XHTML. Dupa HTML și JavaScript, CSS este a treia component ă necesar ă pentru
realizarea unei pagini Web. El ofer ă uneltele necesare pentru a crea pagini web atractive din punct
de vedere vizual, interfe țe pentru utilizatori în aplica ții web sau aplica ții mobile [17].
Arhitectura CSS permite s epararea codului pentru estetică, de documentul HTML prin
crearea de fisiere de tip ".css". Aceast ă separare poate îmbun ătăți accesul la cod din diferite pagini.
Un fi șier css poate defini o estetic ă care să se aplice în toată aplica ția web, sau s ă formateze
componente specifice.

2.3 SISTEME DE GESTIUNE A BAZELOR DE DATE
2.3.1 MICROSOFT SQL SERVER
SQL Server este unul din cele mai populare sisteme de gestiune a bazelor de date (SGBD)
pentru baze de date rela ționale. Acesta este creat și distribuit de către Microsoft. Ca orice alt sistem
relațional, SQL Server p ăstreaz ă datele în tabele și foloseste un li mbaj structurat de interogare (SQL
– Structured Query Language) pentru accesul la baza de date. La SQL Server, schema bazei de date
este predefinit ă pe baza cerin țelor aplica ției și a regulilor care guverneaz ă relațiile între coloanele
tabelelor. Informa țiile corelate pot fi ținute în tabele separate, dar asociate cu ajutorul jonc țiunilor.
În acest mod , duplicarea de date este minimă [18].
2.3.2 MONGODB
MongoDB este o baz ă de date creat ă de MongoDB, Inc. Acesta pastreaz ă datele în
documente de tip JSON, a c ăror structur ă poate varia. Informa țiile corelate sunt ținute împreun ă
pentru a fi accesate mai rapid prin intermediul limbajului de interogare specific MongoDB.
MongoDB folose ște scheme dinamice , ceea ce înseamn ă că se pot crea înregistr ări fără a fi definită
în prealabil o structur ă (cum ar fi câ mpurile sau tipurile de val ori prezente în câmpuri). Modificarea
structurii înregistră rilor (numite și documente) se face ad ăugând pur și simplu c âmpuri noi, sau
ștergând câmpuri vechi. Acest model de date permite reprezentarea ierarhic ă a rela țiilor, salvarea cu
ușurință în baza de date a vectorilor și a structurilor complexe. Documentele într-o colecț ie nu
trebuie s ă conțină un set identic de c âmpuri, iar denormalizarea datelor este des întâlnită. MongoDB
a fost de asemenea proiectat s ă dispun ă de disponibilitate și scalabilitate mare , are incluse
funcționalit ățile de replicare a datelor și auto-sharding [19].

26

27
CAPITOLUL 3. PREZENTAREA APLICAȚ IEI
3.1 STRUCTURA APLICAȚIEI
Aplica ția este compus ă din 3 p ărți: partea de client, partea de server și cele 2 baze de date.
Partea de client reprezint ă interfaț a aplica ției web, realizat ă cu tehnologiile: HTML, CSS și Angular
5. Partea de server este creat ă cu ASP .NET Framework, sub forma unui Web API, care este apelat
de client pentru a afi șa informa țiile din baza de da te. Cele 2 baze de date sunt: baza de date
relațional ă, care p ăstreaz ă informa țiile universit ății necesare anului curent și baza de date
nerela țional ă, care stocheaz ă informa țiile condensate ale tuturor anilor preceden ți.
3.1.1 BAZ E DE DATE

Figura 3.1 : Schema bazei de date relaț ionale – university
Baza de date relațional ă (university) a fost creat ă cu ajutorul framework -ului ORM Entity
Framework, sistemul Model First. Astfel, am creat ini țial schema bazei de date, a șa cum arat ă în
Figura 3.1, cu toate tabelele și atributele fiec ărei entit ăți. Pe baza acestei scheme s -au generat
modelele (clasele de C#) pentru fiecare entitate/tabel ă. Mai departe, am generat și am rulat scriptul
de creare a bazei de date.

28
După cum se observ ă în schem ă, exist ă entitatea p ărinte Perso ană (Person) , cu entit ățile
copii: Administrator, Secretar (Secretary), Profe sor (Professor) , Student. Acestea sunt entit ățile
cărora le vor corespune utilizator i în baza de date ASP .NET Identity, în tabela AspNetUsers.
Fiecare lin ie din tabela Person va avea un corespondent în tabela AspNetUsers și un corespondent
în una din tabelele Administrator, Secretary, Professor sau Student.
Celelalte tabele reprezint ă elemente specifice unei universit ăți: Disciplină (Subject), Serie
(Series), An universitar (Year), Înscriere (Enrollment), Curs (Attendance). Un profesor poate preda
la una sau mai multe discipline , iar o serie poate avea unul sau mai mul ți profesori. Am eviden țiat
legătura de M:N între profesor și serie printr -o tabel ă de legatur ă numit ă Disciplină (Subject ). Un
profesor apar ține unui departament, iar departamentul are în componen ța sa unul sau mai mu lți
profesori. Un student apar ține unei serii în cadrul unui an universitar, leg ătura dintre ele fii nd
reprezentat ă în baza de date prin tabela Î nscriere ( Enrollment ). O inscriere implic ă un set de cursuri
la care studentul va lua parte, în final primind o nota, acest aspect îl putem reg ăsi în tabela Curs
(Attendance).
Cealalt ă bază de date, cea non -relațională (archive), este folosit ă ca arhiv ă pentru tabela
Attendance a fiec ărui an universitar. Fiind creat ă cu MongoDB, "arhiva " este o colec ție de
documente. La sf ârșitul fiec ărui an, informa țiile din tabela Attendance a bazei de date SQL sunt
transformate în entități de tip Exam și adăugate în baza de date non -relațional ă, pentru a fi f olosite
la generarea de grafice statistice, care pot fi v ăzute în aplica ție.
O alta utilizare pentru baza de da te NoSQL este cea de pastrare a logurilor și de salvare a
valorilor mă surate în cadrul testelor de performanța . Toat e măsură torile asupra timpi lor de efectuare
a operațiilor pe bazele de date au fost inregis trate într -o colecție din MongoDB, numită
"performance_tests".
3.1.2 SECURITATE
Accesul la date în aplica ție este permis d oar utilizatorilor înregistra ți. Securitatea este
implementat ă cu ajutorul modulului ASP.NET Identity, folosind co nturi individuale. Acest modul
își creeaz ă o baz ă de da te care con ține tabele specifice unui sistem de autentificare . Dintre ace stea,
în aplica ție sunt folosite: tabela de utilizatori (AspNetUsers), tabela de roluri (AspNetRoles) și
tabela de legatur ă dintre ele (AspNetUserRoles) . Exist ă 4 nivele de acces: Student, Profesor,
Secretar, Administrator. Parolele utilizatorilor sunt ținute în format criptat în baza de date.
Utilizatorii nu își pot crea personal cont în aplica ție. Conturile noi vor fi create doar de
Administrator. Utilizatorii cu rolul de Administrator pot crea , modifica și șterge conturi de tip
Administrator, Secreta r, Profesor sau Student . Fiecare utilizator are acces doar la pagi nile specifice
tipului să u de utilizator.
3.2 FUNCȚIONAREA APLICAȚIEI
În momentul acces ării aplica ției, utili zatorul este întampinat de pagina de autentificare .
Acesta trebuie s ă completeze c âmpurile de utilizator ș i parola cu creden țialele primite. Conturile de
acces î n aplica ție pot fi create numai de administratorii sistemului. Î n urma autentificarii cu succes
în aplica ție, în funcț ie de tipul utilizatorului, acesta poate avea acces la diverse pagini.

29

Figura 3.2: Pagina de autentificare
O pagin ă comună pentru to ți utilizatorii este cea de Date personale. Aici utilizatorul îsi poate
verifica datele personale care i -au fost setate pe cont ( Emai l, Prenume, Nume, CNP ) precum ș i
cele specific e tipului de utilizator:
• Profesori : departamentul de care apar țin și disciplinele pe care le pred ă în anul current. În caz
de eroare , departamentul poate fi schimbat de c ătre un administrator, iar disciplinele pot fi
schimbate de c ătre secr etariat fie î n urma unei gre șeli sau la începutul anului urmă tor.
• Secretar: anul de care este responsabil. Administratorul poate schimba aceasta valoare dac ă este
nevoie.
• Student: anul matricol , reprezent ând anul în care a fost creat contul și numă rul matr icol, care
este un identificator unic pentru student. Aceste date pot fi modificate doar de c ătre
administrator.
De asemenea, aici utilizatorul îsi poate schimba parola apă sând butonul albastru “Schimb ă
parola”. Se va afi șa un formular î n care trebuie intr odus ă parola curent ă și apoi parola nou ă de dou ă
ori, pentru confirmare .

30
3.2.1 PAGINI PROFESOR

Figura 3. 3: Pagina "Date personale" , pentru utilizator de tip "profesor"
Catalogul este o pagin ă specific ă profesorului , în care acesta poate vedea studen ții care sunt
înscriș i la disciplinele predate de el în anul curent. Profesorul are responsabilitatea să treac ă notele
studenț ilor la timp în urma examenelor , pentru a putea fi arhivate de aplica ție. Pentru a trece o not ă,
acesata trebuie s ă faca du blu click stânga pe câ mpul de not ă și va deveni editabil ă. În urma inser ării
unei valori în câmp, acesta devine verde ca să marcheze faptul c ă a fost editat. Numai dup ă ce se
trece și data , se va salva nota automat î n sistem și câmpurile vor reveni la culoarea initi ală.
Tabelul poate fi sortat și filtrat pe fiecare coloan ă. De asemenea , acesta suportă o că utare
global ă care va verifica textul î n fiecare colo ană. Regula de filtrare și cautare globală pe baza careia
se caut ă parsează datele verificâ nd dac ă cuvantul s cris este con ținut î n valoare.

31

Figura 3. 4: Pagina "Catalog", specifică tipului de utilizator "profesor"
Ultima pagină la care are access un profe sor este pagina de statistici. Aceasta expune dou ă
filtre : Disciplin ă si An. În urma complet ării acestora se afiș ează urmatoarele:
• un grafic linie cu evolu ția mediei anuale pe serie din ultimii 5 ani
• un pie chart cu ponderea notelor pe respectivul an

Figura 3. 5: Pagina "Statistici", specifică tipului de utilizator "profesor"
Studentul are o singură pagină specific ă, numită “Situa ția școlar ă”. Aceasta con ține bilanț ul
tuturor disciplinelor la care a fost înscris studentul din anul 1 pan ă în anul curent. D atele pot fi
sortate, filtrate ș i se pot efectua c ăutări pe ele. Asemănă tor cu catalogul profesorului, datele sun t
verificate dacă conțin textul c ăutat.

32
3.2.2 PAGINI STUDENT

Figura 3.6 : Pagina "Situaț ie școlar ă", specific ă tipului de utilizator "student"
Pagina “Student” este prima pagin ă specific ă secretarului. Aceasta permite secretarului să
caute un student ș i să vizualizeze datele personale, înscrierile și situaț ia școlar ă. Informaț iile sunt
separate pe 2 subpagini, pagina de situa ție școlar ă oferind aceleaș i func ționalit ăți ca și pagina
“Situa ție școlar ă” specific ă utilizatorului de tip student.

33
3.2.3 PAGINI SECRETAR

Figur a 3.7: Pagina "Student", specifică tipului de utilizator "secretar"
Pagina “Înscrieri” conț ine înscrierile studenț ilor într-o serie, în anul universitar curent (afișat
în col țul din dreapta al tabelului) . Aceasta este tot o pagină specific ă utiliz atorului de tip "secretar".
După cum s e poate observa si in figura 3.8 , tabelul dispune, ca ș i celelalte, de sortare, filtrare ș i
paginare.

Figura 3.8 : Pagina "Î nscrieri", specific ă tipului de utilizator "secretar"
Secretarul va verifica, la începutul anului, după generarea de înscrieri noi, dac ă există vreun
student care doreș te să se transfere sau să promoveze prin intermediul unei cereri către decan , și va
face modificarea în cadr ul acestei pagini, că utând studentul î n tabel. Un click pe linia
corespunzatoare studentului va deschide o fereastr ă care conține datele î nscrierii studentului, unde
pot fi editate c ămpurile de Serie și/sau An. În caz de gre șeala de înscriere sau in caz de
exmatriculare, secretarul poate chiar s ă șteargă î nregistrarea cu pricina.

34

Figura 3.9 : Pagina "Î nscrieri", sec țiunea "Modifică înscriere"
Pagina "Discipline" reflectă tabela respectiv ă din baza de date ("Subjects"). Aceasta
reprezint ă disciplinele care sunt predate în anul curent î n cadrul universit ății. List a este
corespondentul aproape identic a extrasel or din planul de învăță mant, av ând în plus câte un profesor
care pred ă fiecare disciplină . Lista a fost g ândită ca fiind relativ constant ă pe parcursu l anilor.

Figura 3. 10: Pagina "Discipline", specific ă tipului de utilizator "secretar"

35
La nevoie, secretarul poate s ă faca modific ări, cu menț iunea c ă exist ă validă ri care nu -i vor
permite sa recreeze o combina ție deja existent ă de nume Disciplină, Serie ș i Profesor. În rest,
secretarul poate adă uga, șterge și edita orice disciplin ă. Deoarece numă rul de profesori din care se
poate alege este foarte mare, completarea profesorului se face cu ajutorul unui c âmp cu sugestii
automate, care filtreaz ă list a pe masură ce utilizatorul tastează, după cum se poate vedea în figura
3.11.

Figura 3.1 1: Pagina "Discipline", sec țiunea "Adaug ă disciplin ă"
Pagina de Utilizatori este singura pagină specifică administratorului. Aceasta conț ine lista
tuturo r utilizatorilor care au acces în aplicaț ie. Ace știa sunt separa ți în patru sec țiuni: Studen ți,
Profesori, Secretari, Administratori. În func ție de tipul utilizatorului, vor apărea î n tabel coloanele
specifice acestuia. Tabela poate fi sortat ă și filtrat ă și se pot face și căutări pentru diver și utilizatori.

36
3.2.4 PAGINI ADMINISTRATOR

Figura 3 .12 Pagina "Utilizatori", specifică tipului de utilizator " administrator ", secțiunea "Studenț i"
Pentr u a modifica un utilizator se dă click pe acesta ș i va ap ărea un modal cu un formular
precompletat cu detaliile utilizatorului. Pent ru a crea un utilizator se apasă butonul de cre ează
utilizator și va apă rea acela și formular , dar cu toate câmpurile goale. Î n func ție de ti pul
utilizatorului care se doreș te a fi creat , formular ul va con ține câmpuri specifice acestuia. Câ mpul
email prezint ă un caz aparte pentru utilizatori, el fiin d folosit pentru autentificare ș i nu poate fi
schimbat dupa ce a fost creat utilizatorul.

37

Figura 3.1 3: Pagina "Utilizatori", secțiunea "Stude nți", secțiunea "Adaug ă student"

38
CAPITOLUL 4. TESTARE A PERFORMAN ȚELOR
Pentru a face teste de performan ță, au fost create func ții, care s ă genereze un set mare de
date, pe care să poată fi facute interogări și mă surați timpii. Deoarece Entity Framework are
mecanisme interne de prelucrare ș i salvare a datelor, fiind un intermediar între utilizator și limbajul
SQL, nu am dorit ca aceste mecanisme să afecteze măsură torile și am ales s ă creez î n partea de
client func ții care s ă trimit ă cererile mai departe la s erver, pentru a fi transmise, câ t mai
independent, la baza de date.
Acest lucru s -a dovedit a fi func țional doar pentru seturi de date mici, deoarece existen ța
conceptului de "timeout" întrerupe conexiunea c u serverul, daca aceasta durează prea mult . Pentru a
evita aceasta problem ă, am redus se tul de date de la 100 de studenț i pe serie, la 20 de studen ți pe
serie, ș i am ales s ă trimit mai multe cereri, pentru a genera cat mai multe linii in baza de date .
Din nou, am întalnit probleme la partea de server, care, dup ă crearea datelor pentru 3 -4 ani,
returnează o eroare de tipul "Out of memory".
Am masurat î n cât timp se realizeaz ă in SQL interogarile pentru c ele mai des folosite pagini:
obținerea din baza de date a notelor pentru student (" GetAttendancesForStudent "), a notelor pentru
profesor(" GetAttendancesFor Professor" ), și a listei de î nscrieri din anul curent
(GetCurrentEnrollments "). Am efectuat mă surători cu c âte 100 de seturi de date, apel ând fiecare
dintre cele 3 metode de 100 de ori , cu parametri diferi ți de fiecare dat ă, unde permitea metoda ( în
cazul studenților ș i al profesorilor). Rezultatele au fost ob ținute fă când o mediere a valorilor, pentru
fiecare set d e test (corespondente cu datele pe un anumit num ăr de ani).
În urma ac estor m ăsurători limitate, s -au obținut rezultatele reprezentate în figurile 4.1, 4.2
și 4.3. Observ ăm că doar pentru student și înscrieri s-au obț inut rezultate conform aș teptărilor: o
tendință de cre ștere a sarcinii serverului în urma populă rii bazei de date.
Aceste m ăsurători nu sunt foar te conclusive însă, din cauza setului mic de date (20 de
studen ți pe serie). Dupa cum se observ ă, rezultatele au ca unitate de mă sură milisecundele, ceea se
înseamn ă că ar fi putut ușor sa fie influenț ate de factori ext erni, cum ar fi alte procese care mai
ruleaz ă pe computer în momentul execu ției, sau chiar a lte threaduri din cadrul aplicaț iei.

39

Figura 4.1 Măsurători pentru funcț ia "GetAttendancesForStudent"

Figura 4.2 Mă surători pentru func ția "GetAttendancesForProfessor" 01020304050607080
1 2 3Milisecunde
Nr ani baza dateGetAttendancesForStudent SQL
GetAttendancesForStudent
012345678910
1 2 3Milisecunde
Nr ani baza dateGetAttendancesForProfessor SQL
GetAttendancesForProfessor
SQL

40

Figura 4.3 Măsură tori pentru func ția "GetCurrentEnrollments "

024681012
1 2 3Milisecunde
Nr ani baza dateGetCurrentEnrollments SQL
GetCurrentEnrollments SQL

41
CONCLUZII
Arhitectura propusă este una complexă, cu atât mai mult cu cât logica sistemului universitar
în sine diferă de la o universitate la alta. Din acest motiv, este dificil de gasit o reprezentare
abstractă a acestuia, chiar și având la dispoziție atât modelul relațional, cât și cel non -relațional.
Arhitectura hibrid este rar folosită pentru aplicații de acest gen, de obicei preferându -se
folosirea unei singure baze de date (relațională sau non -relațională). Aceasta însă vine cu avantaje
mari la nivel de scala bilitate, atât la dimensiunea datelor, cât și la reprezentarea domeniului de
lucru, indiferent cât de complexă este logica acestuia. Astfel, aplicația poate fi extinsă pentru mai
multe universități, facilitând adaptarea la variațiile regulilor de funcționa re a acestora.
În realizarea acestei implementări, unul dintre aspectele studiate care ar fi putut afecta
performanț a aplicației a fost f olosirea Entity Framework și a limbajului LINQ pentru interogare .
Acestea aduc atat avantaje, cât și dezavantaje. U n aspect pozitiv este ușurinta implementării datorita
conceptelor de programare orientată pe obiecte. În același timp, se pierde controlul asupra
interogarilor SQL, codul generat de Entity Framework nefiind întotdeauna optim. De asemenea,
gestionarea insta nțelor fiecarui context al bazelor de date în aplicație pentru un timp îndelungat
poate duce la probleme de performanță, dacă nu chiar și de funcționalitate.
Ca extindere a acestei aplicații se poate discuta despre includerera disciplinelor op ționale și
a celor facultative. Pentru a implementa aceast ă funcționalitate, trebuie ad ăugat la pagina
studentului o component ă care s ă-i permit ă alegerea disciplinelor opționale dintr -o list ă, alcătuită pe
baza informa țiilor generate despre student în urma înscrierii într-un nou an școlar. Baza de date va
trebui modificat ă pentru a suporta aceste no i informa ții. Se va crea o nou ă tabel ă de legatur ă care s ă
reprezinte lista de discipline pentru fiecare elev din serie în fiecare an. Se va discuta avantajul
folosirii Mon goDB pentru a stoca aceast ă tabel ă(colecț ie), în contextul în care folosirea
informa țiilor din tabele SQL necesare acesei entit ăți poate afecta performan ța aplica ției.
O alta posibilitate de extindere pentru acest proiect ar fi gestionarea cererilor de tr ansfer sau
de promovare a anului în cazuri speciale. În primul r ând, aceast ă modificare necesit ă un formular
accesibil studentului, pe care s ă-l completeze în cadrul aplica ției. Dupa salvarea lui, acesta va fi
vizibil contului corespunz ător decanului facult ății, care va avea posibilitatea accept ării sau
respingerii acestei cereri. În final, cererile vor fi vizibile secretarilor, care vor face modificarea
repectiv ă.
Pentru o mai bun ă comunicare între utilizatorii aplica ției, și totodat ă o extindere care
justific ă alegerea unei arhitecturi hibrid este integrarea aplica ției cu un sistem de chat. Acesta va
putea permite comunicarea instant ă între utilizatorii autentifica ți. Astfel, un student poate semnala o
neconcordan ță la note secretarului sau profe sorului, pentru a verifica și eventual corecta validitatea
notei. Mesajele sistemului de chat vor fi p ăstrate în baza de date NoSQL, care este cunoscut ă ca
fiind tipul de model de baze de date optim pentru un astfel de sistem.

42

43
BIBLIOGRAFIE
[1] Microsoft . „Traditional relational database solutions | Microsoft Docs ”.
https://docs.microsoft.com/en -us/azure/architecture/data -guide/relational -data/. [accesat la data
15.06.2018.]
[2] Microsoft . „Non-relational data and NoSQL | Microsoft Docs ”.
https://docs.microsoft.com/en -us/azure/architecture/data -guide/big -data/non -relational -data/.
[accesat la data 25.06 2018.]
[3] MongoDB. „Replication – MongoDB Manual".
https://docs.mongodb.com/manual/replication/ . [accesat la data 10.07.2018.]
[4] MongoDB. „Sharding – MongoDB Manual ". https://docs.mongodb.com/manual/sharding/.
[accesat la data 11.07.2018.]
[5] „RFC 1123 – Requirements for Internet Hosts – Application and Support ".
https://tools.ietf.org/html/ rfc1123 /. [accesat la data 20.0 3.2018.]
[6] Group, W3C Technical Architecture. „Architecture of the World Wide Web, Volume One "
https://www.w3.org/TR/webarch/. [accesat la data 12.02.2018.]
[7] „RFC 2616 – Hypertext Transfer Protocol” – HTTP/1.1. https://tools.ietf.org/html/rfc2616/.
[accesat la data 20.02.2018.]
[8] Coulouris, George, și alții. „Distributed Systems: Concepts and Design (5th Edition)”.
Boston : Addison -Wesley, 2011. ISBN 0 -132-1430 1-1.
[9] Ghosh, Sukumar. „Distributed Systems – An Algorithmic Approach”. s.l. : Chapman &
Hall/CRC, 2007. ISBN 978 -1-58488 -564-1.
[10] Lynch, Nancy A. „Distributed Algorithms”. s.l. : Morgan Kaufmann, 1996. ISBN 1 –
55860 -348-4.
[11] „XML Introduction ”. https://www.w3schools.com/xml/xml_ whatis .asp . [accesat l a data
28.05.2018.]
[12] „Introducing JSON”. http://json.org/ . [accesat la data 10.03.2018.]
[13] „What is a Programming Language ”. https://www.computerhope.com/jargon/p/proglang.htm
[accesat la data 25.05.2018.]
[14] Microsoft ." ASP.NET overview | Microsoft Docs ".https://docs.microsoft.com/en –
us/aspnet/overview . [accesat la data 05.08.2018.]
[15] Angular ."Angular -What is Angular?" .https://v5.angular.io/docs . [accesat l a data
18.07.2018.]
[16] „RFC 1866 – Hypertext Markup Language – 2.0”. https://tools.ietf.org/html/rfc1866/ .
[accesat la data 18.05.2018.]
[17] „HTML & CSS – W3C”. https://www.w3.org/standards/webdesign/htmlcss#whatcss .
[accesat la data 25.05.2018.]
[18] Microsoft ."SQL Server 2017 on Windows and Linux | Microsoft" .
https://www.microsoft.com/en -us/sql -server/sql -server -2017 /.[accesat l a data 03 .08.2018.]
[19] MongoDB. „MongoDB and MySQL Compared”.
https://www.mongodb.com/compare/mongodb -mysql?jmp=docs . [accesat la data 28.06.2018.]

44

45
ANEXE
Anexa 1. Exam.cs

46
Anexa 2. UniversityService.cs ( parțial – metode de CRUD pentru Subject)

47

48
Anexa 3. UniversityController.cs (par țial – metode de CRUD pentru Subject)

49

Anexa 4. EnrollmentUI.cs

50

51
Anexa 5. professor -grades.component.html ( componenta ProfessorGrades )

52

53
Anexa 6. professor -grades.component .ts (componenta ProfessorGrades )

54
Anexa 7. UniversityService .cs (parțial – metodele de testare a performanței)

55
Anexa 8. ArchiveService.cs

Anexa 9. MongoDB – interogare pentru a obț ine mediile valorilor de test

56
Anexa 10. AttendanceUI.cs

57