ACADEMIA DE STUDII ECONOMICE DIN BUCUREȘTI [612093]

ACADEMIA DE STUDII ECONOMICE DIN BUCUREȘTI
Facultatea de Cibernetică, Statistică și Informatică Economică
Specializarea Informatică Economică

Informatizarea activității de gestiune a
căminelor studențești

Coordonator științific:
Prof. univ. dr. UȚĂ Adina Ileana

Autor:
IANUȘ Cătălina Teodora

București 2019

Cuprins

Introducere ………………………….. ………………………….. ………………………….. ………………………….. …… 6
1. Descrierea domeniului ………………………….. ………………………….. ………………………….. …………….. 7
1.1 Descrierea activității ………………………….. ………………………….. ………………………….. ………….. 7
1.2 Soluții și aplicații software existente ………………………….. ………………………….. ………………… 9
1.2.1 Soluția actuală pentru gestiunea căminelor ………………………….. ………………………….. ….. 9
1.2.2 Platforma de gestiune a căminelor Campus Living Villages ………………………….. …….. 11
2. Metode tehnice și instrumente utilizate în realizarea aplicației ………………………….. ……………. 14
2.1 Visual Studio 2019 și Inte rnet Information Services ………………………….. ……………………… 14
2.2 Tehnologia ASP.NET ………………………….. ………………………….. ………………………….. ………. 14
2.3 Modelul MVC ………………………….. ………………………….. ………………………….. …………………. 15
2.4 C# ………………………….. ………………………….. ………………………….. ………………………….. ……… 17
2.5 Code First Entity Framework ………………………….. ………………………….. ………………………… 18
2.6 SQL Server ………………………….. ………………………….. ………………………….. …………………….. 19
2.7 Linq ………………………….. ………………………….. ………………………….. ………………………….. …… 20
2.8 JQuery ………………………….. ………………………….. ………………………….. ………………………….. .. 20
2.9 Ajax ………………………….. ………………………….. ………………………….. ………………………….. ….. 21
2.10 HTML 5 ………………………….. ………………………….. ………………………….. ……………………….. 22
2.11 Bootstrap ………………………….. ………………………….. ………………………….. ……………………. 22
3. Analiza și proiectarea aplicației ………………………….. ………………………….. ………………………….. 23
3.1 Specificarea cerințelor ………………………….. ………………………….. ………………………….. ……… 23
3.1.1 Diagrame ale cazurilor de utilizare ………………………….. ………………………….. …………… 24
3.2 Analiza sistemului informatic ………………………….. ………………………….. ………………………… 27
3.2.1 Diagrame de activitate ………………………….. ………………………….. ………………………….. .. 27
3.2.2 Diagrama de clase ………………………….. ………………………….. ………………………….. ……… 29
3.2.3 Diagrame de stare ………………………….. ………………………….. ………………………….. ……… 30
3.2.4 Diagrame de interacțiune ………………………….. ………………………….. ………………………… 31
3.3 Proiectarea ………………………….. ………………………….. ………………………….. ……………………… 33
3.3.1 Diagrama de clase detaliată ………………………….. ………………………….. …………………….. 33
3.3.2 Proiectarea bazei de date ………………………….. ………………………….. …………………………. 34
3.3.3 Proiectarea interfețelor utilizator ………………………….. ………………………….. ……………… 36
3.3.4 Diagrama de componente ………………………….. ………………………….. ……………………….. 36
3.3.5 Diagrama de desfășurare ………………………….. ………………………….. …………………………. 37
4. Implementarea și prezentarea aplicației ………………………….. ………………………….. ……………….. 38

4.1 Concepte de bază ………………………….. ………………………….. ………………………….. …………….. 38
4.2 Contul Studentului ………………………….. ………………………….. ………………………….. …………… 40
4.3 Contul Recepționerului ………………………….. ………………………….. ………………………….. …….. 42
4.4 Contul administratorului ………………………….. ………………………….. ………………………….. …… 44
Concluzii ………………………….. ………………………….. ………………………….. ………………………….. ……. 47
Bibliografie ………………………….. ………………………….. ………………………….. ………………………….. …. 49

Lista figurilor

Figură 1 .1 Ilustrație – Informatizarea gestiunii căminelor ………………………….. ………………………….. ………… 9
Figură 1.2 Facilități Campus Living Villages ………………………….. ………………………….. ………………………….. 12
Figură 1.3 Mesagerie Campus Living Villages ………………………….. ………………………….. ……………………….. 12
Figură 2.1 Ilustrație – Modelul MVC ………………………….. ………………………….. ………………………….. ……….. 15
Figură 2.2 Structurare MVC în Visual Studio ………………………….. ………………………….. ………………………… 17
Figură 2.3 Ilustrație – Generarea bazei de date prin intermediul Entity Framework ………………………….. . 18
Figură 2.4 Generar ea unei tabele ………………………….. ………………………….. ………………………….. …………… 19
Figură 2.5 SQL în Visual Studio ………………………….. ………………………….. ………………………….. ………………. 20
Figură 2.6 Crearea unui datepicker și a unui timepicker cu JQuery ………………………….. ……………………… 21
Figură 2.7 Exemplu de implementare Ajax în funcția de ștergere ………………………….. ……………………….. 22
Figură 3.1 Diagrama generală a cazur ilor de utilizare ………………………….. ………………………….. ……………. 24
Figură 3.2 Diagrama de utilizare a cererii de reparare ………………………….. ………………………….. …………… 25
Figură 3.3 Diagrama cazului de utilizare înregistrare vizită ………………………….. ………………………….. ……. 26
Figură 3.4 Diagrama de activitate pentru repararea unei defecțiuni ………………………….. …………………… 28
Figură 3.5 Diagrama de activitat e pentru înregistrare a unei vizite ………………………….. ……………………… 28
Figură 3.6 Diagrama de activitate pentru trimiterea unui mesaj ………………………….. …………………………. 29
Figură 3.7 Diagrama de clase ………………………….. ………………………….. ………………………….. ………………… 29
Figură 3.8 Diagrama de stare pentru cererea de reparare ………………………….. ………………………….. …….. 30
Figură 3.9 Diagrama de stare pentru înregist rarea unei vizite ………………………….. ………………………….. … 30
Figură 3.10 Diagrama de secvență pentru cerere de reparare ………………………….. ………………………….. .. 31
Figură 3.11 Diagrama de secvență pentru înregistrarea unei vizite ………………………….. ……………………. 32
Figură 3.12 Diagrama de secvență pentru întrebări și răspunsuri ………………………….. ……………………….. 33
Figură 3.13 Diagrama detaliată a cla selor ………………………….. ………………………….. ………………………….. .. 34
Figură 3.14 Schema bazei de date ………………………….. ………………………….. ………………………….. ………….. 35
Figură 3.15 Interfețele principale ale aplicației ………………………….. ………………………….. …………………….. 36
Figură 3.16 Diagrama de componente ………………………….. ………………………….. ………………………….. ……. 36
Figură 3.17 Diagrama de desfășurare ………………………….. ………………………….. ………………………….. …….. 37
Figură 4.1 Structura MVC a proiectului AplicațieCămin ………………………….. ………………………….. ………… 38
Figură 4.2 Maparea controller -ului și a acțiunii în URL ………………………….. ………………………….. ………….. 39
Figură 4.3 Student – Pagina de trimitere a unei cereri de reparare ………………………….. ……………………… 40
Figură 4.4 Inițializarea bazei de date în Controller ………………………….. ………………………….. ……………….. 41
Figură 4.5 Fucncția din Controller pentru generarea formularului ………………………….. ………………………. 41
Figură 4.6 Student – Pagina de adr esare a unui mesaj ………………………….. ………………………….. …………… 42
Figură 4.7 Student – Pagina întrebări frecvente ………………………….. ………………………….. ……………………. 42
Figură 4.8 Recepționer – Pagina de înregistrare a unui vizitator ………………………….. ………………………….. 42
Figură 4.9 Recepționer – Pagina pentru vizualizare a studenților ………………………….. ………………………… 43
Figură 4.10 Recepționer – Pagina de înregistrare a unui vizite ………………………….. ………………………….. .. 43
Figură 4.11 Recepționer – Pagina de finalizare a unei vizite ………………………….. ………………………….. …… 43
Figură 4.12 Funcția de editare ………………………….. ………………………….. ………………………….. ……………….. 44
Figură 4 .13 Administrator – Pagina cererilor de reparare ………………………….. ………………………….. ………. 45
Figură 4 .14 Funcția pentru formularul asignării unei cereri ………………………….. ………………………….. …… 45
Figură 4 .15 Administrator – Pagina de asignare ………………………….. ………………………….. ……………………. 45
Figură 4 .16 Funcția de asignare ………………………….. ………………………….. ………………………….. ……………… 46
Figură 4 .17 Administrator – Pagina cererilor asignate ………………………….. ………………………….. …………… 46
Figură 4 .18 Administrator – Rezultatul exportului în PDF ………………………….. ………………………….. ………. 46

Lista tabelelor
Tabel 1.1 Primire vizitatori – soluție actuală VS soluție informatizată ………………………….. ………………….. 10
Tabel 1.2 Înregistrare defec țiuni – soluție actuală VS soluție informatizată ………………………….. ………….. 11
Tabel 3 .1 Descrierea cazului de utilizare pentru cererea de reparare ………………………….. ………………….. 26
Tabel 3.2 Descrierea cazului de utilizare pentru înregistrarea unei vizite ………………………….. …………….. 27

6
Introducere

Aplicația are ca scop pe de o parte, înlesnirea comunicării dintre studenții cazați în
căminele studențești și administrație, și pe de altă parte, dorește să asigure un mediu sigur pentru
studenții aflați în căminele universității. Inspirația pentru această temă a izvorât din faptul că am
fost unul dintre studenții cazați în căminele Belvedere din cadrul Academiei de Studii Economice
București, unde am petrecut 3 ani.
Atunci când un student primește contul de la facultate și este repartizat la unul din căminele
disponibile, i se va oferi acces și la aplicație. Aceasta îi va fi utilă, în primul rând, pentru a se
integra mai ușor în comunitate. Toate defecțiunile pe care acesta le sesizează în cameră pot fi
raportate prin intermediul aplicației, gestionate de administrație și de meseriași. Administratorul
având, la rândul lui, un cont din care va lua la rând cererile, pe care le va asigna unor meseriași,
iar în urma remedierii, vor fi arhivate. De asemenea, studentul poate adresa întrebări către
administrație și poate vizualiza informații utile despre programul cantinelor, secretariatelor sau
casieriilor.
Problema defecțiunilor din camere este momentan soluționată de un caiet amplasat la
recepția fiecărui cămin în care studenții cuprind în paginile acestuia diferitele defecte ale camerei
lor și ora la care sunt găsiți în cameră. Meseriașii iau la rând caiet ul și în funcție de specialitate, își
aleg defecțiunile ce le pot rezolva, merg în fiecare cameră și la final se semnează. În camerele în
care nu se află nimeni, revin ulterior, doar dacă nu uită și studenții din camera respectivă se trec
din nou în caiet. Deși pare destul de ușor de folosit, fiind un simplu caiet de notițe, scenariul se
poate înrăutăți atunci când studenții nu țin cont de programul meseriașilor și notează ore foarte
târzii. De multe ori, studenții ce nu au fost găsiți în timpul de lucru al meseriașilor uită să se mai
noteze și cum această bază de date fizică se poate umple cu un flux mare de informații, unele
probleme pot rămâne neobservate și, deci, nerezolvate. Aplicația își propune să informatizeze acest
mijloc de comunicare.
Printre alte soluții se numără și înregistrarea vizitelor de către recepționerii căminelor.
Aceștia vor înscrie în sistem vizitatorii noi și de fiecare dată când vor păși în cămin, li se va
completa un formular de vizită. Astfel, nu se vor crea dubluri în sistem, cum se întâmplă momentan
în cadrul caietului care capturează datele vizitatorului la fiecare vizită. De asemenea, se vor
înregistra data și ora sosirii, precum și ora plecării.

7
1. Descrierea domeniului
1.1 Descrierea activității

Întotdeauna am tr ăit cu ideea că dacă nu faci ceva care să ajute și să adauge un strop de
valoare activității tale de zi cu zi, atunci mai bine nu faci acel lucru. Și cum în aproximativ toate
domeniile există câte o aplicație software care să ușureze procesul activității l or, eu am vrut să mă
orientez către un domeniu simplu în care desfășurarea acțiunilor se poate realiza și fără
informatizare, dar care, în prezența unui software, aș putea produce un lucru unic care să
optimizeze cu adevărat toată munca.
În prezent, activ itatea căminelor după repartizarea studenților nu constă în multe acțiuni,
majoritatea fiind simple și concise. Totuși, în ciuda simplității, există o adevărată responsabilitate
pentru student, recepționer și administrator. Fiecare are rolul său într -un că min studențesc, iar
relațiile bune dintre aceștia duc la creșterea calității vieții.

Studentul repartizat în cămin are rolul de locatar, persoană care are dreptul la o cameră
și care își însușește obligația de a o menține într -o stare cât mai bună. Acesta trebuie să raporteze
starea camerei chiar și la cea mai mică defecțiune apărută. De asemenea, va permite meseriaș ilor
să intre în cameră pentru a repara eventualele deranjamente și pentru a raporta starea unui bun.
Atunci când are neclarități, poate discuta cu administratorul căminului. De asemenea, studentul
trebuie să primească vizitatori până în ora 23:00, iar ori ce abatere de la regulă trebuie transmisă
recepționerului.
Atunci când studentul constată că starea unui bun s -a deteriorat, acesta se duce la recepție
și notează într -un caiet, pe un rând nou, următoarele detalii: numele persoanei care reclamă
defecțiune a, data și intervalul orar la care poate fi găsit în cameră, numărul de telefon și detaliile
defecțiunii, nespecificând neapărat categoria. Meseriașii sunt disponibili toată ziua în împrejurarea
căminelor studențești și se împart în modul următor: electric ianul merge la căminul X, tâmplarul
la căminul Y, rezolvă defecțiunile aferente și realizează ulterior rocada.
Deoarece în unele cazuri studenții uită să pună ora la care sunt găsiți în cameră sau pun o
oră destul de târzie, când meseriașii nu mai sunt di sponibili, aceste defecțiuni sunt amânate. În
unele situații, meseriașii nu observă defecțiunile nerezolvate de pe caiet și trec mai departe,
studenții ajungând să se treacă din nou pe caiet. Nu putem să învinuim pe nimeni, deoarece viața

8
studenților este destul de dinamică, își fac planuri spontane și uită de ora trecută pe caiet. Într -un
final, amânate sau nu, toate defecțiunile se rezolvă.

Administratorul căminului este persoana care gestionează toate activitățile unui cămin.
Acesta se asigură de buna funcționare a tuturor lucrurilor și răspunde la orice neclaritate a
studenților. El este principalul mediator între student și cămin, realizând cazarea sau redistribuirea
lor. Verifică în fiecare lună chitanțele studenților și îi notează pe aceia care nu a u plătit regia de
cămin până la data scadentă, pentru a -i atenționa. De asemenea, acesta este principalul răspunzător
de tot ce se petrece în cămin.
Activitatea acestuia începe doar după distribuirea studenților pe camere, lucru împlinit de
către Serviciul de Cazare. După ce au fost repartizați, studenții vin cu contractul de cazare, o copie
după buletin și legitimația primită de la Serviciul de Cazare. Administratorul verifică actele și le
oferă cheia. Administratorii au biroul la parterul fiecărui cămin ș i, pe parcursul anului, este vizitat
de studenți pentru diferitele lor nelămuriri.
Când vine vorba de plata regiei, administratorul realizează doar cea de -a doua verificare a
ei, deoarece verificarea principala se face automat în sistemul existent folosit de casierii atunci
când studentul plătește și se eliberează chitanța. Tocmai de aceea, studenții lasă în fiecare luna
dovada plății regiei la recepția căminului.

Recepționerul este persoana care se ocupă de siguranța căminului. Acesta trebuie să
legitime ze studenții și vizitatorii, pentru a se asigura de validitatea datelor. Tocmai de aceea, poate
să restricționeze accesul în cazul în care nu sunt satisfăcute anumite cerințe (de exemplu, intervalul
orar în care vizitatorul dorește să intre în cămin). Prin urmare, recepționerul mai este cunoscut și
ca având rolul de paznic al căminului.
Atunci când un vizitator intră în cămin, recepționerul îi cere buletinul și îi preia două date
cu caracter personal: nume, CNP. De asemenea, pe același rând, scrie data și ora sosirii lui.
Informațiile despre studentul vizitat sunt furnizate tot de către vizitator: numele și camera
studentului. La momentul părăsirii căminului de către vizitator, recepționerul trece și ora plecării
lui. Dacă acest vizitator revine și în altă zi, se repetă procesul prin înscrierea lui din nou în caiet.

9
1.2 Soluții și aplicații software existente
1.2.1 Soluția actuală pentru gestiunea căminelor

Momentan, soluția pusă la dispoziție de către cămine este înregistrarea tuturor defecțiunilor
și a tuturor vizitelor pe caiete separate, amplasate la recepție. Cu toate că aceasta este cea mai
simplă metodă și nu necesită, de exemplu, îndemânarea în lucrul cu calculatorul, poate avea câteva
dezavantaje, printre care amintim posibila p ierdere a datelor (în cazul defecțiunilor) sau
pătrunderea în cămin a unor persoane care nu expun informații valide cu privire la studenții vizitați.
Aplicația din lucrarea de față oferă o soluție prin prisma informaticii. Cele 3 mari roluri
din gestiunea unui cămin au un cont și pot astfel să administreze activitățile de zi cu zi dintr -un
cămin studențesc.

Figură 1.1 Ilustrație – Informatizarea gestiunii căminelor

În tabelul 1.1 sunt reprezentate avantajele și dezavantajele soluției actuale, în comparație
cu soluția lucrării de față, în ceea ce privește primirea de vizite în cămin.

10

Soluția
actuală Soluția
informatizată
Simplitate ✔ ✔
Oferă posibilitatea verificării datelor despre
studentul vizitat ✖ ✔
Nu permite dubluri => înregistrări unice ✖ ✔
Nu necesită îndemânarea în lucrul cu
calculatorul ✔ ✖

Tabel 1.1 Primire vizitatori – soluție actuală VS soluție informatizată

De asemenea, putem observa în tabelul următor situația înregistrării defecțiunilor.

Soluție
actuală Soluție
informatizată
Simplitate ✔ ✔
Optimizare ✖ ✔
Nu permite omiterea unor informații utile ✖ ✔

11
Oferă posibilitatea încadrării defecțiunii într -o
categorie ✖ ✔
Oferă posibilitatea actualizării datei sau
intervalului orar ✖ ✖
Nu necesită îndemânarea în lucrul cu
calculatorul ✔ ✖

Tabel 1.2 Înregistrare defecțiuni – soluție actuală VS soluție informatizată

Se poate constanta că nici una dintre soluții nu oferă posibilitatea actualizării unor
informații care se pot schimba deoarece sunt variabile în dinamismul vieții studențești – data și
intervalul orar în care studentul poate fi găsit în cameră pentru repararea defectelor raportate.
În ceea ce privește comunicarea studentului cu administrația căminelor studențești, soluția
actuală consta în adresar ea mesajelor cu privire la eventualele nelămuriri direct la biroul
administratorului fiecărui cămin. Aplicația oferă, totuși, un formular prin care studentul poate să
trimită mesaje pentru administrator. Acesta ia la rând mesajele și răspunde la ele, pentr u ca,
ulterior, acestea să apară pe pagina de Întrebări Frecvente , pagină disponibilă contului de student.
Astfel, toată lumea poate avea acces la informații generale, precum modalitatea de schimbare a
camerei.

1.2.2 Platforma de gestiune a căminelor Campus Living Villages

Campus Living Villages este o platformă pentru studenții cazați în campusul facultății
Bedfordshire, Anglia, Lutton. Această aplicație a fost realizată de Gravitate Design și prezintă o
sumedenie de facilități:
• istoric d e plăți și informații despre plățile viitoare;
• istoric de rezervări și informații despre rezervarea actuală;
• un magazin de diverse – de exemplu, un pachet esențial cu ustensile de bucătărie;
• o mesagerie cu notificări de la sistem (pentru confirmarea plățil or) și cu mesaje de la
proprietari;

12

Figură 1.2 Facilități Campus Living Villages

Această platformă înglobează mai multe servicii, inclusiv cele legate de plata chiriei
deoarece șederea lor în campus nu depinde neapărat de facultate, de media studentului. De
asemenea, observăm că în campusul facultăților din vestul Europei se încearcă d igitalizarea tuturor
acțiunilor.
O asemănare între aplicația Campus Living Villages și aplicația lucrării de față este
mesageria care, în cazul soluției din Anglia, este unidirecțională (de la administrator sau proprietar
spre student), iar în cazul soluț iei noastre, poate fi chiar bidirecțională având în vedere faptul că
studentul trimite un mesaj și apoi îl vizualizează, împreună cu ceilalți studenți în pagina de
Întrebări Frecvente.

Figură 1.3 Mesagerie Campus Living Villages

13
O altă asemănare este posibilitatea de a raporta o defecțiune. Atunci când un student de la
facultatea Bedfordshire este repartizat la o cameră, are acces la această funcționalitate prin
intermediul aplicației Campus Livi ng Villages. Deoarece contextul în care viața de cămin din
Anglia ia naștere este destul de diferit de cel din România, și aceste doua funcționalități sunt ușor
deosebite. Studentul din Anglia, fiind cazat într -o casă unde există băi comune și bucătărie, p oate
raporta pentru porțiuni cu deranjamente din imobil, selectând fiecare nivel în parte până ajunge la
porțiunea respectivă. Nu selectează o anumită categorie de încadrare a defecțiunii, dar are
posibilitatea de a o descrie în maxim 20 de cuvinte. Specif ică, de asemenea, camera și numele.

14
2. Metode tehnice și instrumente utilizate în realizarea aplicației

Aplicația are ca public țintă atât persoane tinere – studenții, cât și persoane mature –
administratorii și recepționerii. Identificarea audienței este unul dintre cele mai importante lucruri
deoarece astfel se poate contura conceptul aplicației prin oferi rea unui răspuns la următoarele
întrebări:
• Ce stil trebuie folosit astfel încât să fie potrivit ambelor categorii de vârstă?
• Ce tehnologii trebuie folosite astfel încât să fie accesibile altor dezvoltatori care ar putea
să aducă ulterior modificări din do rința adăugării unor funcționalități noi?

Așadar, din necesitatea de a reutiliza codul și de a ușura întreținerea, aplicația a fost
realizată în tehnologia Microsoft ASP.NET, modelul MVC, utilizând mediul de dezvoltare Visual
Studio și limbajul de progra mare C#. Pentru stiluri și grafică au fost folosite Bootstrap și JQuerry,
de unde au fost alese culori și stiluri.
2.1 Visual Studio 2019 și Internet Information Services
Până acum un an, acest mediu de dezvoltare nu era un software gratuit și era disponibil
spre utilizare numai persoanelor care îl cumpărau sau aveau un cont acreditat de o instituție. Ultima
versiune apărută, Visual Studio 2019, este un program accesibil tu turor persoanelor pasionate și
interesate de programare. Acesta oferă un spațiu de dezvoltare pentru programe Windows, aplicații
Web sau aplicații Mobile. Prezintă, de asemenea, un instrument prin care se pot descărca resurse
pentru stil, precum Bootstrap sau pentru anumite funcționalități, precum DataTables, numit NuGet
Manager.
În plus, Visual Studio prezintă și un mediu de lansare pentru toate aplicațiile Web, prin
intermediul IIS – Internet Information Services. Acesta prezintă protocolul HTTP și crea ză o adresă
URL odată ce este activat, la rularea aplicației.
2.2 Tehnologia ASP.NET
Aplicația este realizată în tehnologia Microsoft numită ASP.NET. Aceasta se bazează pe
platforma de dezvoltare .NET și prezintă o sumedenie de avantaje, printre care se regăsește
compatibilitatea cu peste 20 de limbaje de programare, de unde și posibilitatea de a gestiona un
model orientat pe obiect.

15
ASP (Samame 2019) vine de la Active Server Pages, iar înainte de a fi întrecut de versiunea
sa, ASP.NET. a fost primul limbaj pentru crearea de pagini dinamice, folosind un limbaj clasic,
limbajul Visual Basic. În 2002, s -a lansat versiunea cunoscută astăzi, cea care folosește tehnologia
.NET și care suportă multe limbaje de programare: Visual Bas ic, C# și JScript. De asemenea, un
alt avantaj față de ASP cel clasic este faptul că ASP.NET este un limbaj totalmente orientat pe
obiect.
Alte obiective care au fost atinse de ASP.NET:
• Performanță – aplicația se compilează o singură dată;
• Viteză de programare – cu câteva linii de cod și în mai puțin de 5 minute, putem să
interogăm o bază de date și să facem rutine complexe;
• Servicii Web – prezintă instrumente care partajează date între diferite aplicații;
• Siguranță – prezintă instrumente care mențin siguranța aplicațiilor

În plus, ASP.NET nu se limitează doar la paginile Web care pot fi accesate prin intermediul
unui browser, așa cum sunt alte tehnologii (de exemplu, PHP), ci este utilizat pe scară largă, pentru
a construi aplicații Mobile, Web sau Desktop. Putem spune că această tehnologie este flexibilă.
2.3 Modelul MVC
Modelul MVC (Model – View – Controller) este un mod de lucru ce poate fi folosit în mai
multe tehnologii, însă este regăsit cu precădere în ASP.NET.

Figură 2.1 Ilustrație – Modelul MVC

Modelul MVC (Alvarez 2014) separă codul în trei fragmente (niveluri) diferite, delimitate
de responsabilitatea lor – Model, View și Controller. A fost inventat acum câteva decenii, în anii

16
‘70, de către Trygve Reenskaug (Reenskaug 2003) , informatician și profesor universitar din
Norvegia. În opinia acestuia, MVC este o soluție generală pentru controlul unor seturi mari de
date.

Modelul (primul nivel) încapsulează datele și procesele unui obiect, definind logica de
manipulare a datelor. Î n cazul aplicației de față, un vizitator al căminului poate să fie un obiect. Iar
datele personale ale acestuia, numele, prenumele și CNP -ul, pot fi accesate prin intermediul unor
metode ( setteri și getteri ). Pe lângă toate acestea, modelul conține și regu lile de validare, fiind
nivelul care acționează direct cu baza de date.
Mai jos putem observa o bucată de cod din modelul Vizitator, câmpul numeVizitator cu
regulile de validare corespunzătoare:

[Required (ErrorMessage = "Numele este obligatoriu!" )]
[RegularExpression (@"^[a -zA-Z]+[ a -zA-Z-_]*$" , ErrorMessage = "Numele trebuie să conțină
litere!" )]
public string numeVizitator { get; set; }

View (cel de -al doilea nivel) este nivelul care primește și afișează datele, având în spate
un șa blon HTML pe care îl invocă la rulare. De exemplu, vizitatorii regăsiți în baza de date pot fi
transmiși sub formă de listă unui View numit Index.cshtml care îi afișează utilizatorilor sub formă
de tabel HTML.
Controller (cel de -al treilea nivel) culege ev enimentele din partea utilizatorului,
acționează asupra modelului și prezintă o noua afișare a datelor – returnând un nou View.
Controller -ul este cel care face posibilă comunicarea dintre Model și View. El decide care este
View -ul ales pentru Model = cont rolează toate acțiunile.
Mai jos putem observa o acțiune ce returnează un View. Acțiunea și View -ul au aceeași
denumire – AdaugareVizitator, pentru a fi un cod cât mai intuitiv. View -ul prezintă un formular
prin care recepționerul poate adăuga un vizitator , tocmai de aceea, odată cu returnarea acelui View,
se trimite și modelul Vizitator.
public ActionResult AdaugareVizitator ()
{
var viewModel = new Vizitator { };
return View( "AdaugareVizitator" , viewModel );
}

17

Așadar, având în vedere separarea codului în 3 nivele, acest model oferă un cadru curat de
lucru. Programatorul se poate concentra asupra unui singur nivel la un moment dat: date, logică
sau mod de prezentare. Altfel spus, atunci când se necesi tă modificarea paginii de html din View,
actualizarea nu o să afecteze modelul sau datele stocate.
În imaginea de mai jos se remarcă structurarea în fișiere separate a modelului MVC.

Figură 2.2 Structurare MVC în Visual Studio
2.4 C#
C# este un limbaj de programare orientat pe obiecte și desemnat să compileze diverse
aplicații care se execută în Framework -ul .NET. Este un limbaj simplu și eficient, foarte
asemănător cu limbajul Java, atât din punct de vedere sintactic, cât și din punct de vedere
arhitectural, ceea ce oferă accesibilitate unei populații mari de programatori. De cele mai multe
ori, cadrul de dezvoltare ASP.NET este folosită cu C# sau cu Visual Basic.NET.
De ce aplicația este realizată cu ajutorul C# și nu Visual Basic?
• sintaxa este asemănătoare cu cea a limbajului Java, pe când VB.NET prezintă o
sintaxă asemănătoare cu limba engleză – fiind un limbaj de script (se folosesc
cuvinte precum AND în loc de semnul & din programare), ceea ce ar fi un adevărat
avantaj pentru pro gramatorii începători, dar nu neapărat pentru cei care au o
oarecare experiență și caută ceva similar cu anumite concepte deja învățate;
• C# este mult mai folosit în cadrul .NET, decât este folosit Visual Basic.

18
2.5 Code First Entity Framework

Așa cum îi spune și numele, Code First (Întâi Codul), este o metodă ce se concentrează
mai întâi pe crearea claselor și apoi pe generarea bazei de date cu ajutorul acestora. Metoda este
pusă în aplicare prin intermediul Entity Framework care ajută la maparea obiecte lor.

Figură 2.3 Ilustrație – Generarea bazei de date prin intermediul Entity Framework

Baza de date a aplicației lucrării de față a fost realizată prin metoda Code First având în
vedere simplitatea și flexibilitatea pe care le pune la dispoziție programatorilor. În continuare sunt
prezentați pașii prin care se crează baza de date cu ajutorul acestei metode.

1. Se definește Modelul
2. Se definește conexiunea cu baza de date în clasă numită IdentityModels (ce conține
ApplicationUser și ApplicationDbContext) și se inițializează modelul tot în
ApplicationDbContext:
public DbSet <Student > Studenti { get; set; }
Această linie de cod va genera tabela pentru modelul respectiv, ce are deja definite
câmpurile și proprietățile acestora.
3. Deoarece se constată o modificare în ApplicationDbContext, este necesară o migrare care
să efectueze actualiz ările apărute. În cazul nostru, să genereze o tabelă. Migrarea se
realizează prin următoarea comandă scrisă în consola de Package Manager:
add-migration [nume_migrare]
4. În momentul de față migrarea a fost generată și putem observa codul care se va folosi l a
generarea tabelei:

19

Figură 2.4 Generarea unei tabele

5. După ce programatorul verifică migrarea, salvează toate modificările prin următoarea
comandă:
update -database
2.6 SQL Server

Pentru implementarea și gestiunea bazei de date s -a utilizat SQL Server, conexiunea
realizându -se prin intermediul Entity Framework în Visual Studio. În cadrul acestuia putem
observa tabelele, câmpurile și proprietățile lor, cheile primare și cheile externe. De asemenea,
avem acces la scripturile pe care le putem folosi pentru modificarea trăsăturilor sau generarea unor
noi tabele.
Aplicația folosește Microsoft SQL Server deoarece datele sunt stocate în mod relațional,
fapt dovedit de existența legăturilor dintre tabele. De asemenea, SQL Server oferă un acces rapid
la date, iar mentenanța tabelelor este facilă.

20

Figură 2.5 SQL în Visual Studio
2.7 Linq

Așa cum SQL vine de la Structured Query Language, Linq vine de la Language Integrated
Query și reprezintă o sintaxă prin care se pot accesa date din diferite surse. Acest instrument este
valabil atât pentru C#, cât și pentru VB.net.
Aplicația de față a u tilizat Linq pentru a prelua datele dintr -o singură sursă: SQL Server,
însă această sintaxă se poate folosi pentru multe tipuri de surse de date, pe lângă baze de date:
servicii web, documente XML și așa mai departe.
public ActionResult IndexNerasp unse()
{
var mesaje = _context.Mesaje. Where (m => m.raspuns == null).ToList();
return View (mesaje );
}
2.8 JQuery

Jquery (Chuburu 2018) este o librărie gratuită JavaScript ce oferă interactivitate aplicației,
fiind folosită pe scară largă în dezvoltarea Web. Deoarece nu necesită cunoștințe avansate de
JavaScript tot mai multe persoane aleg să importe librăria în proiectele lor.

21
Aplicația de față a utilizat câteva pluginuri gratuite ce rezolvă anumite situații specifice în
aspectul unui site: datepicker și timepicker . Culorile și stilul acestor pluginuri (widgets) au fost
alese în conformitate cu șablonul aplicației.

Figură 2.6 Crearea unui datepicker și a unui timepicker cu JQuery

Putem observa cum prin intermediul celor două funcții au fost create un datepicker pentru
un câmp de tip dată și un timepicker pentru un câmp de tip oră, specificându -se formate și setând
valori implicite. Cele două instrumente create contribuie la interactivitatea aplicației deoarece se
deschid în momentul în care utilizatorul apasă pe câmpurile de dată/oră pentru a introduce
informațiile.
2.9 Ajax

Ajax înseamnă Asynchronous JavaScript and XML și se referă la un set de tehnici de web
folosite în limbajul JavaScript ce permit datelor să fie trimise sau primite spre și de la baza de date.
În exemplul de mai jos putem observa cum la confirmarea ștergerii din partea utilizatorului
a unei vizite înregistrate, se identifică vizita selectată, metoda de eliminare și funcția ce trebuie

22
apelată în caz de succes. Toți acești pași se derulează în spate, fără a afecta experiența
utilizatorului.

Figură 2.7 Exemplu de imple mentare Ajax în funcția de ștergere
2.10 HTML 5

Mai întâi de toate trebuie specificat faptul că HTML – Hypertext Markup Language nu
este un limbaj de programare deoarece nu generează funcționalități dinamice, însă reprezintă un
sistem standardizat prin care se crează și se structurează secțiuni, paragr afe, legături externe pentru
paginile Web.
Aplicația a folosit HTML 5 care a adus multe îmbunătățiri față de versiunile anterioare,
printre care amintim ca exemple:
• manipularea conținutului multimedia prin intermediul etichetelor de <audio> și <video>;
• utilizarea și manipularea imaginilor generate de camera calculatorului;
• introducerea unor atribute noi (de exemplu: hasFocus, activeElement).
2.11 Bootstrap

Bootstrap (Benites 2017) este o librărie ce conține stiluri, teme și șabloane pentru aplicațiile
Web. Inițial creată ca o soluție internă pentru Twitter, Bootstrap s -a dezvoltat, a devenit publică și
gratuită începând cu august 2011, fiind astăzi cunoscută ca cel mai popular cadr u de dezvoltare
adaptabilă (web și mobile) pentru HTML, CSS și JavaScript.
Aplicația a preluat tema Flatly din librăria Bootstrap ce propune culori calde și prietenoase,
potrivite pentru ambele categorii de vârstă.

23
3. Analiza și proiectarea aplicației
3.1 Specificarea cerințelor

Aplicația din lucrarea de față oferă o soluție ce utilizează informatica pentru gestiunea unor
activități din căminele studențești. Aplicația are 3 tipuri de utilizatori, fiecare având facilități
proprii: Student, Recepționer, Administrator.
Mai jos sunt detaliate posibilitățile de interacțiune cu aplicația a fiecărui cont.

Studentul:
• Trimite o cerere de reparare:
o oferă informații despre defecțiunea din cameră și în ce categorie (Electric, Instalații,
Structură, M obilier) se identifică;
o selectează data și intervalul orar în care poate fi găsit în cameră;
o cererea va conține o singura defecțiune – excepție: pot fi mai multe dacă se regăsesc
în aceeași categorie; pentru defecțiunile diferite, se vor înregistra cereri separate;
• Adresează întrebări către administrator
• Vizualizează și verifică pagina de Întrebări Frecvente
• Vizualizează informații despre cantine, regia de cămin și modalitățile de plată,
administratorii căminelor etc.

Recepționerul:
• Înregistrează vizitator
• Înregistrează o vizită pentru un vizitator înregistrat după ce îl găsește după CNP; introduce
data sosirii și alege studentul pentru care se face vizita
• Navighează prin lista cu studenții căminelor pentru a verifica validitatea informaț iilor
oferite de vizitator la intrarea în cămin
• Navighează prin lista de vizite înregistrate, le poate sorta de la cea mai nouă la cea mai
veche, având și opțiunea de a șterge o vizită (în cazul în care a fost introdusă greșit)
• Navighează prin lista cu viz itatorii înregistrați, cu posibilitatea de a edita informațiile
despre un anumit vizitator

24
Administrator cămin:
• Navighează prin lista vizitelor efectuate în cămine
• Navighează prin lista de studenți
• Navighează prin lista de defecțiuni:
o alege defecțiunea spre a o asigna unui meseriaș prin apăsarea butonului de asignare
o alege meseriașul și finalizează asignarea
o aceste defecțiuni vor apărea ulterior într -o pagină cu defecțiuni asignate pentru o
mai bună organizare și va avea posibilitatea de a l e exporta în format PDF
o odată rezolvate, cererile de reparare pot fi arhivate

Astfel, cu ajutorul acestui sistem, defecțiunile din fiecare cameră ajung să fie rezolvate la
timp iar vizitele în cămin se fac mai sigur. Capitolul are rolul de a detalia cerințele funcționale pe
care trebuie să le îndeplinească aplicația, prin intermediul unor diagrame ale cazurilor de utilizare.

3.1.1 Diagrame ale cazurilor de utilizare

Diagrama generală a cazurilor de utilizare

Cazurile de utilizare ilustrează sistemul și oamenii, organizațiile sau alte persoane ce au rol
de actori și interacționează cu aplicația. Acestea nu oferă multe detalii, dar reliefează o idee de
bază într -un mod schematic.
Cei 3 actori ai cazului general de utilizar e sunt studentul, administratorul și recepționerul
deoarece aceștia sunt utilizatorii care interacționează cu aplicația de gestiune a căminelor.

Figură 3.1 Diagrama generală a cazurilor de utilizare

25

Diagrama cazului de utilizare cerere de reparare

Figură 3.2 Diagrama de utilizare a cererii de reparare

Element al cazului de
utilizare Descriere
SCOP Rezolvarea unei defecțiuni
NUME Cerere de reparare
ACTOR PRINCIPAL Student/Administrator
DESCRIERE Presupune un ansamblu de operații ce conduc la rezolvarea unor
defecte din camerele căminelor
PRECONDIȚII Regăsirea unui calculator în administrația fiecărui cămin
POSTCONDIȚII Obiectele defecte au fost repuse în starea de funcționare
DECLANȘATOR Trimiterea de către student a unei cereri de reparare

26
FLUX DE BAZĂ 1.Studentul oferă informații despre defecțiunea din cameră și în ce
categorie se identifică.
2.Selectează data și intervalul orar în care poate fi găsit în cameră.
4.Administratorul primește defecțiunile și informațiile despre student și
cameră.
5.Alege defecțiunea și o asignează unui meseriaș.
6.Administratorul tipărește defecțiunile asignate și le oferă meseriașului.
7.Meseriașul le repară.
Tabel 3.1 Descrierea cazului de utilizare pentru cererea de reparare

Diagrama cazului de utilizare înregistrare vizită

Figură 3.3 Diagrama cazului de utilizare înregistrare vizită

Element al cazului de
utilizare Descriere
SCOP Înregistrarea unei noi vizite în cămin
NUME Înregistrare vizită
ACTOR PRINCIPAL Recepționer

27
DESCRIERE Presupune înregistrarea vizitatorilor în baza de date, precum și
informațiile vizitei.
PRECONDIȚII Regăsirea unui calculator la recepția fiecărui cămin. Recepționerul are
acces la sistem și conexiunea cu baza de date este activă.
POSTCONDIȚII Vizita a fost înregistrată cu succes sau nu a fost înregistrată în cazul în
care informațiile despre noua vizită nu sunt confirmate de sistem
DECLAN ȘATOR Legitimarea vizitatorului
FLUX DE BAZĂ 1.Recepționerul înregistrează sosirea
2.Înregistrează informații despre vizitator în cazul în care acesta este un
vizitator nou
3.Caută în baza de date pentru a verifica validitatea datelor cu privire la
camera la care se face vizita.
4.Înregistrează plecările
Tabel 3.2 Descrierea cazului de utilizare pentru înregistrarea unei vizite

3.2 Analiza sistemului informatic
3.2.1 Diagrame de activitate

Diagramele de activitate au rolul de a ilustra pașii de executare a unui caz de utilizare,
oferind informații despre situațiile implicate și aplicând condiții asupra fluxului de acțiuni.
Mai jos au fost detaliate diagramele de activitate pentru repararea unei defecțiuni – modul
în care cererea este trimisă de la student la administrator și condițiile de traversare între cele trei
partiții (student, sistem, administrator) – , pentru înregistrarea unei vizite – ce evidențiază modul în
care se desfășoară înregistrarea unui vizite atât pentru un viz itator existent în sistem, cât și pentru
un vizitator nou, implicând recepționerul și vizitatorul – și pentru trimiterea unui mesaj – de la
student la administrator.

28
Diagrama de activitate pentru reparare defecțiune

Figură 3.4 Diagrama de activitate pentru repararea unei defecțiuni

Diagrama de activitate pentru înregistrare vizită

Figură 3.5 Diagrama de activitate pentru înregistrare a unei vizite

29
Diagrama de activitate pentru întrebări și răspunsuri student -administrator

Figură 3.6 Diagrama de activitate pentru trimiterea unui mesaj

3.2.2 Diagrama de clase

Figură 3.7 Diagrama de clase

30
3.2.3 Diagrame de stare

Diagrama de stare pentru cererea de reparare

Figură 3.8 Diagrama de stare pentru cererea de reparare

Diagrama de stare pentru înregistrare vizită

Figură 3.9 Diagrama de stare pentru înregistrare a unei vizite

31
3.2.4 Diagrame de interacțiune

Diagramele au rolul de a descrie interacțiunea dintre mai mult elemente ale unei activități.
Deoarece reprezintă o descriere dinamică a sistemului, între actori și obiecte iau naștere o serie de
mesaje și răspunsuri, cu scopul de a ilustra și evidenția modul în care acesta colaborează.

Diagrama de secvență pentru cererea de reparare

Figură 3.10 Diagrama de secvență pentru cerere de reparare

32
Diagrama de secvență pentru vizită

Figură 3.11 Diagrama de secvență pentru înregistrarea unei vizite

Observăm că atunci când vizitatorul nu vine cu informații valide despre studentul vizitat,
vizita nu se poate efectua. Această situație poate avea două cauze. Fie vizitatorul a încurcat căminul
în care studentul ce urmează a fi vizitat este, fie nu a venit cu intenția de a vizita pe cineva.
Aplicația, în cazul înregistrării vizitelor, are rolul de a -i facilita recepționerului posibilitatea
de restricționare a accesului în cazul persoanelor mincinoase, cu intenții rele.

33
Diagrama de secvență pentru întrebări și răspunsuri student -administrator

Figură 3.12 Diagrama de secvență pentru întrebări și răspunsuri

3.3 Proiectarea
3.3.1 Diagrama de clase detaliată

Diagrama de clasă detaliată prezintă clasele și atributele acestora. Pentru o mai bună
înțelegere a funcționalității, sunt enumerate și activitățile prin care administratorul, studentul și
recepționerul interacționează la nivelul aplicației.

34

Figură 3.13 Diagrama detaliată a claselor

3.3.2 Proiectarea bazei de date

Putem observa că baza de date conține 11 tabele:
• Camera este tabela care stochează camerele unui cămin, având ca atribute: Numar,
NumarPaturiOcupate, Status, TipCamera. Atributul identitate este definit de Id, tabela fiind
legată de Cămin prin cheia externa IdCamin.
• Cămin este tabela care stochează căminele, fiind identificate prin Id. Tabela prezintă un
singur câmp: NumeCamin.
• Administrator este tabela care stochează câteva informații despre administratorii
căminelor: Nume, Prenume. Această tabela are o legătură externă cu tabela Camin,
identificată de cheie externă IdCaminGestionat.
• Student este tabela care stochează informații despre studentul repartizat la un cămin:
Nume, Prenume, An, Facultate, NumarTelefon, CNP. Prezintă o legătură externă cu tabela
Camera, identificată prin cheie externă IdCamera.
• Mesaj este tabela care stochează mesajele trimise de student. Observăm atributele Text și
Raspuns ce reprezintă mesajul studentului și răspunsul administratorului.

35
• Categorie_defecțiune este tabela care stochează diferitele categorii de defecțiuni, având
un sin gur câmp de tip text: Categorie.
• Cerere_reparare este o tabela care stochează detaliile despre defecțiune și despre
studentul care trimite cererea. Tabela are legături externe identificate de cheile externe
IdCamin, IdCategorie, IdMeseriasAsignat.
• Meseri aș este tabela care stochează informațiile despre meseriașii căminelor studențești:
Nume, Prenume, NumarTelefon, Specializare.
• Vizitator este tabela care stochează informații despre vizitatorii ce sunt înregistrați în
sistem odată ce pășesc în cămin: NumeV izitator, PrenumeVizitator, CNP.
• Vizită este tabela care stochează informații despre vizită, tocmai de aceea este necesară
existența unor legături externe cu tabelele Student și Vizitator. Aceste legături externe se
identifică prin cheile externe IdStudent și IdVizitator.
• Recepționer este tabela care stochează informații despre recepționerii căminelor
studențești: Nume, Prenume.

Observăm faptul că între toate aceste tabele există legături unu la unu sau legături unu la
mulți
Figură 3.14 Schema bazei de date

36
3.3.3 Proiectarea interfețelor utilizator

Figură 3.15 Interfețele principale ale aplicației

3.3.4 Diagrama de componente

Diagrama de componente prezintă fișierele executabile, librăriile, documentele și alte
elemente ce formează, prin interconectare, un sistem software. Aplicația utilizează modelul MVC
(Model – View – Controller) care este detaliat în diagrama de mai jos. Identificăm astfel tipul de
legături regăsi te între cele 3 niveluri ale arhitecturii MVC prin exemplificarea a 4 funcționalități
din aplicație: afișare vizitatori, adăugare vizitator, afișare vizite și înregistrare vizită.

Figură 3.16 Diagrama de componente

37

3.3.5 Diagrama de desfășurare

Diagrama de desfășurare prezintă componente specifice ce evidențiază configurațiile
rețelei fizice. Oferă o idee despre cum software -ul este implementat și rulat.

Figură 3.17 Diagrama de desfășurare

38
4. Implementarea și prezentarea aplicației
4.1 Concepte de bază

Aplicația a fost realizată în ASP.NET MVC având ca suport cadrul de dezvoltare oferit de
Visual Studio 2019. Pentru a crea un nou proiect de acest tip, s -a ales opțiunea ASP.NET Web
Application, în Framework -ul .NET și limbajul de programare C# (Freeman 2013) .
Așa cum a fost specificat și într -un capitol anterior, MVC împarte fișierele soluției în 3
niveluri: Model, View și Cont roller.
Models conține toate clasele, reprezentând obiectele și proprietățile specifice acestora, și
prin intermediul cărora proiectul poate manipula datele.
Controllers conține clase ce controlează și gestionează cererile venite de la utilizatori,
oferind ulterior un răspuns. Prin intermediul unui Controller se pot realiza acțiuni de interogare,
editare, ștergere etc., acestea fiind implementate în interiorul unor metode numite ActionResult.
De asemenea, clasele trebuie să conțină în de numirea lor cuvântul Controller pentru a determina
intuitivitate la nivelul codului.
Views conține clase ce au un șablon HTML și reprezintă interfața utilizatorului. Prin aceste
clase se afișează datele din Model, iar utilizatorul are posibilitatea de a le modifica, cererea
ajungând la Controller, printr -o acțiune.

Figură 4.1 Structura MVC a proiectului AplicațieCămin

Proiectul mai conține și alte dosare importante, precum App_Start și App_Data.
App_Start conține fișiere executabile, de configurare f olosite la rularea aplicației. Unul din
aceste fișiere poartă numele de RouteConfig. Fiecare aplicație MVC conține cel puțin un traseu de
intrare, acesta fiind configurat implicit de către proiect, odată creat.

39

Figură 4.2 Maparea controller -ului și a ac țiunii în URL

Observăm în figura de mai sus că numele rutei este Default (implicit) iar șablonul URL
conține un controller, o acțiune și un id. De exemplu, dacă aplicăm următoarea adresă în browser
după ce rulăm aplicația, obținem posibilitatea de a edi ta vizitatorul cu id -ul 13:
http:/ /localhost:55610 /Vizitatori /Edit/13
Așadar, Vizitatori reprezintă Controller -ul (denumit în proiect, de
fapt, VizitatoriController, însă MVC este suficient de intuitiv și păstrează doar șirul de caractere
existent înainte de sufixul Controller), Edit reprezintă metoda, acțiunea, iar 13 este id-ul
vizitatorului.
Firește că această adresă necesită existența unei acțiuni de editare care primește ca
parametru un id, se află în Controller -ul Vizitatori și despre care se va menționa în paginile
următoare.

App_Data conține un fișier cu extensia MDF ce semnifică Master Database File, fiind
principala extensie folosită de Microsoft SQL Server. În cazul aplicației de față, baza de date s -a
creat prin metoda Code First cu ajutorul Entity Framework, metodă ce a f ost detaliată în capitolul
al II-lea.
Pași pentru generarea bazei de date:
1. Scrierea codului pentru clasele de obiecte: atribute, restricții, legături;
2. Inițializarea modelelor ca DbSet în ApplicationDbContext;
3. Adăugarea unei migrări prin comanda add -migra tion [nume migrare];
4. Verificarea codului de generare sau actualizare a bazei de date și salvarea prin comanda
update -database;
5. Pentru orice modificare în modele, se aplică din nou punctele trei și patru.
După ce baza de date a fost pusă la punct, se începe implementarea propriu -zisă
funcționalității. În continuare vor fi prezentate paginile principale ale fiecărui cont.

40
4.2 Contul Studentului
Cea mai importantă facilitate a studentului este posibilitatea de a trimite o cerere de
reparare către admi nistrație, în care descrie problema cu care se confruntă în cameră. Această
cerere este trimisă prin intermediul unui formular ce prezintă validări pentru câmpuri cu scopul de
a asigura că nicio informație utilă nu este omisă.

Figură 4.3 Student – Pagi na de trimitere a unei cereri de reparare

Pentru început, a fost creat un Model ce va conține elementele necesare pentru definirea
unei cereri: lista de cămine, lista de categorii, cererea. Listele au fost enunțate astfel în modelul
compus:
public IEnumerable <CategorieDefectiune > Categorii { get; set; }
public IEnumerable <Camin > Camine { get; set; }

Pentru ca interfața să primească un obiect de tipul modelului descris mai sus, a fost realizată
în Controller acțiunea care trimite utilizatorul la pagina formularului. Această acțiune inițializează
listele din model cu listele din baza de date, identificată în Controller prin ApplicationDbContext.

41

Figură 4.4 Inițializarea bazei de date în Controller

Figură 4.5 Fucncția d in Controller pentru generarea formularului

Observăm că în View este trimis un obiect de tip CerereNoua ce conține liste pentru drop –
down și un obiect de tip CerereReparare ce prezintă toate proprietățile unei cereri.
În interfață modelul primit trebuie definit astfel:
@model AplicatieCamin.ViewModels. CerereNoua

Fiecare câmp de completare este adăugat într -un bloc care returnează la final obiectul
obținut în urma introducerii datelor de către student. Acest bloc conține acțiunea de creare a unei
cereri = de salvare în baza de date, și obiectul creat, respectiv CerereReparare:
@using (Html. BeginForm ("Create" , "CerereReparare" ))

Listele despre care s -a menționat mai sus sunt folosite la încărcarea obiectelor drop -down
cu date. De exemplu, drop -down pentru Camine are lista de Camine inițializată cu datele din baza
de date, iar la selectarea unui cămin, în atributul CaminId din clasa CerereReparare se va stoca Id –
ul caminului ales.
@Html. DropDownListFor (m => m.CerereReparare.CaminId, new
SelectList (Model.Camine, "Id", "numeCamin") , "Selectează cămin" , new { @class = "form –
control" })
Studentul mai poate, de asemenea, să trimită un mesaj către administrație și poate verifica
pagina de Întrebări Frecvente.

42

Figură 4.6 Student – Pagina de adresare a unui mesaj

Figură 4.7 Student – Pagina întrebări frecvente

Pentru a afișa lista de întrebări și răspunsuri, s -a realizat următoarea interogare:
var mesaje = _context.Mesaje. Where (m => m.raspun s != null).ToList ();
return View (mesaje );
4.3 Contul Recepționerului

Recepționerul se ocupă de înregistrarea vizitatorilor și a
vizitelor. De asemenea, acesta verifică validitatea informațiilor oferite
de vizitator despre studentul vizitat prin căutarea în lista studenților.
Atunci când un vizitator nou intră în cămin, rece pționerul îl
înregistrează în sistem printr -un formular.
După înregistrare, vizitatorul oferă informații despre studentul
vizitat și recepționerul are posibilitatea de a verifica validitatea
acestora. Accesează lista de studenți și îl caută după nume, ca meră
sau orice alt câmp.
Figură 4.8 Recepționer – Pagina de
înregistrare a unui vizitator

43

Figură 4.9 Recepționer – Pagina pentru vizualizare a studenților

De asemenea, poate ordona studenții după orice etichetă. În continuare, se va înregistra
vizita, selectându -se un vizitator și un student, specificând de asemenea data și ora. La final, după
ce vizita s -a încheiat, vizita se poate finaliza.

Figură 4.10 Recepționer – Pagina de înregistrare a unui vizite

Figură 4.11 Recepționer – Pagina de finalizare a unei vizite

Pentru a finaliza o vizită, recepționerul selectează vizita respectivă din listă și ajunge la
pagina de încheiere, unde trebuie să selecteze ora plecării. În momentul în care vizita e selectată

44
spre finalizare, în acțiune se primește un obiect de tip Vizit a. Mai întâi se cauta vizita în baza de
date după Id -ul primit de la vizita selectată, și, apoi, se inițializează ora de plecare a vizitei găsite
cu ora introdusă de utilizator în pagina de încheiere.

O altă funcționalitate importantă a recepționerului e ste aceia de a edita datele despre un
vizitator dacă inițial au fost introduse greșit. În lista de vizitatori, atunci când utilizatorul apasă pe
numele vizitatorului, se deschide din nou fereastra de înregistrare, de data asta având câmpurile
completate. D upă ce s -au făcut modificările aferente, prin apăsarea butonului, se apelează acțiunea
de editare care primește ca parametru id -ul vizitatorului editat, se actualizează datele și apoi se
returnează din nou lista de vizitatori.

Figură 4.12 Funcția de edit are
4.4 Contul administratorului

Administratorul are posibilitatea de a vizualiza cererile de reparare venite de la studenți,
de a le asigna unor meseriaș i și de a le arhiva. Pentru afișarea într -o listă a cererilor, s -a folosit de
următoarea interogare în Controller:
var cereri = _context.Cereri. Include (c => c.Camin). Include (c => c.categorie)
.Where (c => c.MeseriasId==null). Where (c => c.rezolvat == null). ToList ();
return View (cereri);

Observăm că pentru a afișa cererile primite, Id -ul meseriașului este null. Acest lucru este
util deoarece în momentul asignării unui meseriaș de către administrator, când acel câmp se
completează, cererea va trece din lista de cereri noi în lista de cereri asignate.

45

Figură 4.13 Administrator – Pagina cererilor de reparare

Pentru pagina de asignare, este nevoie de un model care să cuprindă clasa CerereReparare
și o lisă de meseriaș i pentru a putea încărca drop -down -ul. În acțiunea ce ne oferă interfața pentru
asignare, inițializăm lista cu lista meseriașilor din baza de date.

Figură 4.14 Funcția pentru formularul asignării unei cereri

Figură 4.15 Administrator – Pagina de asign are

46
Odată apăsat butonul de asignare, se apelează acțiunea prin care se actualizează în baza de
date cererea de reparare, completându -se Id -ul meseriașului.

Figură 4.16 Funcția de asignare

În final, se afișează lista de cereri asignate și meseriașii corespunzători. Putem observa
faptul că în dreptul fiecărei cereri se află buton de Rezolvă care ne conduce spre funcția de
finalizare a cererii – altfel spus, defecțiunea a fost reparată și cererea poate să fie arhivată.

Figură 4.17 Administrator – Pagina cererilor asignate
De asemenea, odată ce se selectează un meseriaș, există posibilitatea exportului în PDF a
cererilor asignate acestuia. Acest lucru a fost implementat tot prin jquery, folosind un plugin
specific pentru crearea și stilizarea tabelelor.

Figură 4.18 Administrator – Rezultatul exportului în PDF

47
Concluzii

În concluzie, această lucrare are scopul de a prezenta modul în care anumite activități
simple din cadrul căminelor studențești pot fi gestionate mai ușor prin intermediul informaticii,
optimizând munca celor care participă la bunăstarea și siguranța stude nților. Aplicația pentru
cămin, numită Belvedere, având drept inspirație cei 3 ani în care am locuit în căminele Academiei
de Studii Economice din București, a fost realizată în tehnologia ASP.NET, modelul MVC, logica
fiind conferită de limbajul de program are C#.
Trecerea de la hârtii la calculatoare pentru rezolvarea unor activități – defecțiuni,
comunicare, primire de vizitatori – motivează utilitatea aplicației. Drept urmare, în momentul de
față aplicația ar putea rezolva fără probleme toate aceste a cțiuni, singura cerință ar fi existența unui
calculator la recepția fiecărui cămin, în biroul administratorilor existând deja unul.
Printre beneficiile utilizării aplicației se numără:
• Optimizarea și organizarea activităților
• Evitarea folosirii hârtiei => diminuarea poluării apelor și aerului
• Evitarea pierderilor de date
• Evitarea dublicatelor

Totuși, aplicația nu este perfectă și necesită mai multe îmbunătățiri ce se pot implementa
în viitor. Acestea sunt:
• Pentru administrator:
o Dezvoltarea contului astfel încât să poată să verifice și să vizualizeze pe deplin
drepturile tuturor utilizatorilor
o Adăugarea posibilității de a actualiza sau șterge anumite întrebări odată ce au fost
răspunse și afișate pe pagina de Întrebări Frecvente
• Pentru studen t:
o Implementarea unui forum în care poate comunica cu restul studenților cazați în
cămine
o Adăugarea unei pagini care să afișeze istoricul cererilor de reparare trimise de -a
lungul timpului
o Adăugarea posibilității de a actualiza ora dintr -o cerere trimisă, funcționalitate ce
este valabilă maxim 12 ore după ce a fost trimisă

48
• Pentru recepționer:
o Securizarea unor informații care ar putea fi citite cu ușurință dacă calculatorul nu
este închis în timp ce recepționerul nu se găsește la birou, precum CNP -ul
vizitatorilor
o Optimizarea funcției de realizare a unei vizite noi

Și nu în ultimul rând, o altă posibilitate de dezvoltare ar fi crearea unui cont chiar și pentru
meseriaș, în acest caz fiind utilă implementarea unei aplicații android. O altă funcționali tate ce ar
fi de folos este un chat prin care meseriașul poate discuta direct cu studentul dacă se întâmpină o
problemă.

49
Bibliografie

Alvarez, Miguel Angel. 2014. Qué es MVC. 2 Ianuarie. https://desarrolloweb.com/articulos/que –
es-mvc.html.
Benites, Alexander Guevara. 2017. „¿Qué es Bootstrap?” DevCode. https://devcode.la/blog/que –
es-bootstrap/.
Chuburu, Laura. 2018. „Qué es JQuery y cómo implementarlo.” Laura Chuburu.
https:// www.laurachuburu.com.ar/tutoriales/que -es-jquery -y-como -implementarlo.php.
Freeman, Adam. 2013. Pro ASP.NET MVC 5. New York : Apress.
Reenskaug, Trygve M. H. 2003. „The Model -View -Controller (MVC) Its Past and Present.” 1 –
16.
Samame, Roxana. 2019. ASP vs PHP ¿Cuál escoger? Ventajas y Desventajas.
https://bsginstitute.com/bs -campus/blog/ASP -vs-PHP-Ventajas -y-Desventajas -1127.