Aplicație pentru gestiunea statelor de funcțiuni Absolvent: Scafariu Bogdan – Andrei Coordonator: Conf. dr. Sasu Lucian Mircea Conf. dr. Maican… [628210]

LUCRARE DE DIPLOMĂ
Absolvent: [anonimizat]: Conf. dr. Sasu Lucian Mircea
Conf. dr. Maican Cătălin
Brașov
2019 – 2020

LUCRARE DE DIPLOMĂ
Aplicație pentru gestiunea statelor de funcțiuni
Absolvent: [anonimizat]: Conf. dr. Sasu Lucian Mircea
Conf. dr. Maican Cătălin
Brașov
2019 – 2020

Cuprins
1 Introducere 3
1.1 Scurtă descriere a temei . . . . . . . . . . . . . . . . . . . . . 3
1.2 Motivația alegerii temei . . . . . . . . . . . . . . . . . . . . . 3
1.3 Contribuții personale în lucrare . . . . . . . . . . . . . . . . . 4
1.4 Structura lucrării . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Detalierea temei 5
2.1 Scopul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Cerințe funcționale . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Cerințe nefuncționale . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Utilizatori și rolul lor . . . . . . . . . . . . . . . . . . . . . . . 8
3 T ehnologii folosite 10
3.1 Limbajul SQL și SQL Server . . . . . . . . . . . . . . . . . . . 10
3.1.1 Modelul relațional . . . . . . . . . . . . . . . . . . . . 10
3.1.2 SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.3 Interogări SQL . . . . . . . . . . . . . . . . . . . . . . 11
3.1.4 Manipularea datelor SQL . . . . . . . . . . . . . . . . 12
3.1.5 Definirea datelor SQL . . . . . . . . . . . . . . . . . . 12
3.1.6 Controlul datelor SQL . . . . . . . . . . . . . . . . . . 13
3.1.7 Instrucțiuni SQL folosite în abundență în cod: . . . . . 13
3.1.8 Proceduri stocate . . . . . . . . . . . . . . . . . . . . . 14
3.1.9 Serviciul de rapoarte SQL . . . . . . . . . . . . . . . . 16
3.2 Limbajul C# și Entity Framework . . . . . . . . . . . . . . . 17
3.2.1 Ce este Entity Framework? . . . . . . . . . . . . . . . 18
3.2.2 De ce modelul EDM? . . . . . . . . . . . . . . . . . . . 18
3.2.3 Evoluție și modele . . . . . . . . . . . . . . . . . . . . 19
3.2.4 Arhitectura Entity Framework . . . . . . . . . . . . . 20
3.2.5 Abordarea database first . . . . . . . . . . . . . . . . . 21
3.2.6 Avantajele folosirii Entity Framework . . . . . . . . . . 22
3.2.7 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1

3.2.8 ASP.NET Web API . . . . . . . . . . . . . . . . . . . 24
3.3 Vue.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.1 Avantajele utilizării Vue.js: . . . . . . . . . . . . . . . 27
3.4 Dot Net Nuke . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4.1 Module Dot Net Nuke . . . . . . . . . . . . . . . . . . 29
3.4.2 Gestionare utilizatori în cadrul Dot Net Nuke . . . . . 30
3.4.3 Avantajele utilizării Dot Net Nuke . . . . . . . . . . . 31
4 Modelul relațional 32
4.1 Introducere . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2 Entități . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5 Arhitectura aplicației 41
5.1 Introducere . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2 Scopul arhitecturii software . . . . . . . . . . . . . . . . . . . 42
5.3 Arhitectura stratificată – N Tier . . . . . . . . . . . . . . . . . 42
5.4 Descrierea arhitecturii folosite în cadrul proiectului . . . . . . 43
5.5 Avantajele utilizării arhitecturii software . . . . . . . . . . . . 45
6 V erificarea și validarea aplicației 46
6.1 Verificarea aplicației . . . . . . . . . . . . . . . . . . . . . . . 46
6.2 Validarea aplicației . . . . . . . . . . . . . . . . . . . . . . . . 46
6.2.1 Testarea unitară . . . . . . . . . . . . . . . . . . . . . 46
6.2.2 Testarea acceptării din partea utilizatorilor. . . . . . . 48
7 Manualul de instalare și utilizare a aplicației 49
7.1 Instalarea aplicației . . . . . . . . . . . . . . . . . . . . . . . . 49
7.1.1 Pregătirea nivelelor de prsistență a datelor și de logică
a aplicației . . . . . . . . . . . . . . . . . . . . . . . . 49
7.1.2 Pregătirea interfeței utilizatorilor . . . . . . . . . . . . 50
7.1.3 Crearea modulelor în cadrul Dot Net Nuke . . . . . . . 50
7.2 Utilizarea aplicației . . . . . . . . . . . . . . . . . . . . . . . . 54
7.2.1 Autentificare și acces . . . . . . . . . . . . . . . . . . . 54
7.2.2 Prestatorul de curs . . . . . . . . . . . . . . . . . . . . 56
7.2.3 Responsabilul de posturi/coordonatorul de catedră . . 59
7.2.4 Aprobarea statului de funcțiune din partea rectoratului 63
8 Posibilități de extindere 65
2

Capitolul 1
Introducere
1.1 Scurtă descriere a temei
Statul de funcțiuni este o reprezentare detaliată a informațiilor cuprinse
în organigrama Universității. Acesta trebuie să cuprindă denumirea depar-
tamentelor, denumirea funcției, numărul de posturi și gradul lor de ocupare.
În cadrul instituțiilor de învățământ superior din România, statele de
funcțiuni sunt elaborate pe baza planurilor de învățământ redactate pen-
tru fiecare domeniu și specializare conform standardelor ARACIS, în con-
formitate cu actele normative care reglementează învățământul universitar.
Pentru stabilirea funcțiilor didactice și a numărului posturilor din statele de
funcțiuni sunt luate în calcul și formațiile de studiu, grupările de cursuri des-
fășurate în comun pentru mai multe programe de studii, situația disciplinelor
opționale și repartizarea pe departamente a sarcinilor didactice.
Prin intermediul statelor de funcțiuni este organizată activitatea didac-
tică astfel încât să se asigure atât calitatea actului educațional cât și renta-
bilitatea acestuia.
1.2 Motivația alegerii temei
Statele de funcțiuni stau la baza organizării ciclului universitar, deoarece
ele implică activitățile de: organizare a planului de învățământ, gestiune a
personaluluișidestructurăaactivitățiididactice. Considerămcădezvoltarea
unei soluții informatice pentru acest proces va spori transparența, încrederea,
modernizarea, timpul de organizare, eficacitatea și modularizarea în Univer-
sitatea “Transilvania” din Brașov. De asemenea, prin crearea acestei soluții
vor putea fi centralizate date importante într-un format ușor accesibil, care
mai apoi pot fi folosite pentru dezvoltarea altor programe software menite
3

dezvoltării și eficientizării proceselor Universității “Transilvania” din Brașov.
1.3 Contribuții personale în lucrare
• Identificarea operațiilor cheie în realizarea statelor de funcțiuni și îm-
părțirea lor în module independente.
• Proiectarea unei soluții software fiabilă, ușor de utilizat, care acoperă
întregul proces de elaborare a statelor de funcțiuni.
• Adaptarea soluției la baza de date deja existentă a Universității.
1.4 Structura lucrării
Lucrarea de față este structurată în [8] capitole, astfel:
• Capitolul 1 prezinta introducerea în temă.
• Capitolul 2 prezintă detalierea temei.
• Capitolul 3 prezintă descrierea tehnologiilor folosite.
• Capitolul 4 reprezintă modelul relațional.
• Capitolul 5 reprezintă arhitectura aplicației.
• Capitolul 6 reprezintă verificarea, validarea și testarea aplicației.
• Capitolul 7 reprezintă manualul de utilizare și instalare a aplicației.
• Capitolul 8 reprezintă descrierea posibilităților de extindere rezultate
în urma aplicației de gestiune a statelor de funcțiuni.
4

Capitolul 2
Detalierea temei
2.1 Scopul
Scopul principal al acestei lucrări este acela de a crea o aplicație web care
să gestioneze statele de funcțiuni din Universitate, aceasta va include prelu-
area planurilor de învățământ și împărțirea lor pe catedre, crearea cuplajelor
șiafișareaacestora, creareadeposturișiatribuirealorcătrecadreledidactice.
Pentru a susține această aplicație este necesară implementarea unei baze
de date care să stocheze planurile de învățământ, cuplajele între materile din
planurile de învățământ, cadrele didactice, disciplinele, catedrele, posturile și
statele de funcțiuni și de o altă aplicație de tip serviciu web, care să permită
comunicarea aplicației cu baza de date.
Aplicația de tip serviciu web va fi realizată în limbajul C# ca ASP.NET
Web Api Application.
5

Acțiunile pentru care va fi folosită aplicația sunt următoarele (cu excepția
realizării planurilor de învățământ):
Figura 2.1: Diagramă acțiuni
Aplicația va fi folosită de două categorii de utilizatori în felul următor:
• Responsabilii atribuiți fiecărei catedre vor executa operațile de prelu-
are a planurilor de învățământ pe anul Universitar curent, de creare a
cuplajelor, dupăcarepeceledecreareposturi, atribuirecadredidactice
și adăugare discipline. După ce vor fi finalizate toate aceste operații va
exista opțiunea de trimitere a statului de funcțiune către validare.
• Rectoratul va prelua statele de funcțiuni și le va putea aproba sau
respinge. Dacă sunt respinse statele de funcțiuni se vor întoarce la
directorii de departament, care le vor modifica sau vor concepe unul
nou.
6

Figura 2.2: Diagramă utilizatori
7

2.2 Cerințe funcționale
• Centralizarea tuturor planurilor de învățământ din anul curent pentru
fiecare catedră în parte.
• Crearea cuplajelor între materii.
• Crearea posturilor aferente cadrelor didactice.
• Alocarea cadrelor didactice pe posturi.
• Adăugarea disciplinelor în cadrul unui post.
2.3 Cerințe nefuncționale
• Toateplanuriledeînvățământpeanulcurentșicorespunzătoarefiecărei
catedre în parte trebuie să fie completate în prealabil.
• Posturile pot fi doar de două feluri: de bază și la plata cu ora.
• Fiecare cadru didactic are un număr de ore convenționale în funcție de
gradul didactic pe care îl deține.
• Pentru postul de bază trebuie alocat un singur cadru didactic per dis-
ciplină.
• Pentru postul la plata cu ora pot fi alocate mai multe cadre didactice
per disciplină.
• Aplicația trebuie să se integreze cu DNN (DotNetNuke) pentru a putea
fi accesată din intranetul Universității.
• Fiecare pagină va fi integrată separat, ca modul, în Dot Net Nuke iar
restricționarea accesului se va face tot din cadrul Dot Net Nuke.
2.4 Utilizatori și rolul lor
Există 4 tipuri de utilizatori:
• prestatorul de curs.
• responsabilul de posturi.
• directorul de departament.
8

• rectoratul.
Prestatorul de curs se va ocupa de realizarea cuplajelor între materii.
Acesta va avea acces la o pagină web care va reprezenta centralizarea ma-
teriilor din planurile de învățământ aprobate pe anul universitar în curs și
corespunzătoare catedrei din care acesta face parte și la altă pagină web care
îi va permite realizarea cuplajelor între materile respective.
Responsabilul de posturi se va ocupa de crearea posturilor aferente ca-
drelor didactice care fac parte din catedra pe care acesta o reprezintă. Acesta
va avea acces la o pagină web de creare, vizualizare, modificare și ștergere
posturi și va fi supravegheat de către directorul de departament care va
avea acces la aceleași pagini. Rectoratul va putea aproba sau respinge un
stat de funcțiune.
Figura 2.3: Operații executate de utiizatori
9

Capitolul 3
T ehnologii folosite
3.1 Limbajul SQL și SQL Server
3.1.1 Modelul relațional
Modelul relațional reprezintă o bază de date sub forma unei colecții de
relații. Prin relație nu ne referim la nimic altceva decât la un tabel de valori.
Fiecare rând al tabelului va reprezenta o colecție de valori de date. Aceste
rânduri vor reprezenta o entitate sau relație din lumea reală.
Fiecare tabel și coloană vor avea un nume, astfel vor putea interpreta sem-
nificația valorilor pentru fiecare rând în parte.
Datele sunt reprezentate ca un set de relații. În modelul relațional, datele
sunt stocate sub formă de tabele. Cu toate acestea, stocarea fizică a datelor
este independentă de modul în care datele sunt organizate logic.
Concepte
• Atribut: reprezintă fiecare coloană dintr-un tabel. Este proprietatea
care definesțe o relație.
• Tabel: relațiile sunt salvate sub formă de tabel. Acesta este stocat
împreună cu entitățile sale.
• Tuplu: este un singur rând dintr-un unui tabel, care conține o singură
înregistrare.
• Schema de relație: reprezintă numele relației și atributele sale.
• Grad: numărul total de atribute dintr-o relație.
• Cardinalitate: număr total de rânduri dintr-un tabel
10

• Coloana: reprezintă setul de valori pentru un atribut specific.
• Instanța de relație: este un set fin de tupluri în sistemul RDBMS.
Instanțele de relație nu au niciodată tuple duplicate.
• Cheie de relație: fiecare rând are unul, două sau mai multe atribute,
care se numește cheie de relație.
• Domeniu de atribut: fiecare atribut are o valoare și un domeniu de
valoare predefinite, care este cunoscut ca domeniu de atribut.
3.1.2 SQL
SQL este un limbaj de interogare structurat, care se bazează pe concep-
tele modelului relațional. A fost conceput pentru a stoca date, care pot fi
modificate prin executarea diferitor clauze. Acesta se bazează pe mai multe
elemente. Pentru o utilizare cât mai eficientă, comenzile de limbaj necesare
sunt executate cu ajutorul unei interfețe de linie de comandă.
Elemente de limbaj SQL:
• Clauze: acestea reprezintă componente ale enunțurilor și interogărilor
• Expresii: produc valori scalare sau tabele. Aceste valori sunt formate
din rânduri de date și coloane.
• Predicate: specifică condiții. Aceste condiții sunt utilizate pentru limi-
tarea efectelor instrucțiunilor și a interogărilor sau pentru a schimba
fluxul programului.
• Interogări: având un criteriu dat, aceasta va prelua date.
• Declarații: cu ajutorul lor putem controla tranzacții, conexiuni, sesiuni
sau fluxul de programe. Instrucțiunile SQL sunt folosite pentru expe-
dierea întrebărilor de la client la server. Serverul procesează aceste
instrucțiuni și returnează răspunsurile clientului.
3.1.3 Interogări SQL
Interogările reprezintă operații SQL comune, cu ajutorul cărora putem
căuta informații în baza de date. Acestea încep cu instrucțiunea ”SELECT”,
iar cu ajutorul clauzelor pot fi specifice.
11

3.1.4 Manipularea datelor SQL
Prin manipularea datelor ne referim la o modificare asupra unui tabel
deja creat, o actualizare sau o ștergere a unor valori deja existente în tabel.
Exemple:
Insert into PI_Cuplaj_Detalii
(ID_Cuplaj ,
ID_PlanMaterie_Detalii ,
ID_Materie ,
PozitieMaterieInCuplaj )
values
(@ID_Cuplaj ,
@ID_PlanMaterie_Detalii ,
@ID_Materie ,
@PozitieMaterieInCuplaj)
DELETE FROM PI_Cuplaj_Detalii
WHERE
ID_Cuplaj_Detalii = @ID_Cuplaj_Detalii ;
UPDATE PI_Cuplaj_Detalii
SET
ID_Cuplaj = @ID_Cuplaj ,
ID_PlanMaterie_Detalii = @ID_PlanMaterie_Detalii ,
ID_Materie = @ID_Materie ,
PozitieMaterieInCuplaj = @PozitieMaterieInCuplaj ,
created_by = @created_by ,
created_on = @created_on ,
modified_by = @modified_by ,
modified_on = @modified_on ,
deleted_by = @deleted_by
WHERE
ID_Cuplaj_Detalii = @ID_Cuplaj_Detalii ;
3.1.5 Definirea datelor SQL
Definirea datelor permite utilizatorului să definească noi tabele și ele-
mente.
Cu instrucțiunea CREATE TABLE se poate crea o nouă tabelă într-o bază
de date existentă.
12

Exemplu:
CREATE TABLE PI_Cuplaj (
ID_Cuplaj bigint ,
ID_AnUniv bigint ,
ID_CatedraResponsabilaCuplaj bigint ,
ID_PlanMaterieLaCareSeCupleaza bigint ,
NrSemestruDinAn int ,
NrSemestruDinPlan int ,
Nr_Ore_Curs int ,
Nr_Formatii_Curs int ,
Nr_Ore_Seminar int ,
Nr_Formatii_Seminar int ,
Nr_Ore_Laborator int ,
Nr_Formatii_Laborator int ,
Nr_Ore_Proiect int ,
Nr_Formatii_Proiect int
);
3.1.6 Controlul datelor SQL
SQL permite utilizatorului să definească accesul pe care fiecare dintre
utilizatorii din tabel îl pot avea la tabelul real.
CudeclarațiaGRANTsevorautorizautilizatoriisămodificetabelulselectat.
Exemplu:
GRANT SELECT ON PI_Cuplaj TO public ;
3.1.7 Instrucțiuni SQL folosite în abundență în cod:
• “SELECT”-InstrucțiuneaSELECTesteutilizatăpentruaselectadate
dintr-o bază de date.
• “WHERE” – Clauza WHERE este utilizată pentru a extrage doar acele
înregistrări care îndeplinesc o condiție specificată.
• “ORDER BY” – este utilizat pentru a sorta setul de rezultate în ordine
ascendentă sau descendentă.
• “INSERT INTO” – instrucțiunea INSERT INTO este utilizată pentru
a insera înregistrări noi într-un tabel.
13

• “UPDATE” – instrucțiunea UPDATE este utilizată pentru a modifica
înregistrările existente într-un tabel.
• “DELETE” – instrucțiunea DELETE este utilizată pentru a șterge în-
registrările existente dintr-un tabel.
• “JOIN” – o clauză JOIN este utilizată pentru a combina rânduri din
două sau mai multe tabele, pe baza unei coloane comune între ele.
3.1.8 Proceduri stocate
În SQL Server procedurile stocate reprezintă instrucțiuni SQL grupate,
combinate cu o trimitere comună la limbajul de execuție (CLR) Microsoft
.NET Framework sau elemetele T-SQL care introduc programarea procedu-
rală, variabile locale și funcții matematice, pentru procesarea textului, date-
lor, etc.
Acestea pot:
• accepta parametrii de intrare
• returna una sau mai multe valori de ieșire
• efectua operații în baza de date
• apela alte proceduri
Exemplu:
Adăugarea unei înregistrări noi în tabelul PI_Cuplaj:
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE PROCEDURE <SF_CuplajAdd>
@ID_AnUniv bigint ,
@NrSemestruDinAn int ,
@Nr_Ore_Curs int ,
@Nr_Formatii_Curs int ,
@Nr_Ore_Seminar int ,
@Nr_Formatii_Seminar int ,
@Nr_Ore_Laborator int ,
@Nr_Formatii_Laborator int ,
@Nr_Ore_Proiect int ,
14

@Nr_Formatii_Proiect int ,
@ID_CatedraResponsabilaCuplaj bigint ,
@ID_PlanMaterieLaCareSeCupleaza int
AS
BEGIN
SET NOCOUNT ON;
Insert into PI_Cuplaj
(ID_AnUniv, NrSemestruDinAn ,
Nr_Ore_Curs, Nr_Formatii_Curs ,
Nr_Ore_Seminar , Nr_Formatii_Seminar ,
Nr_Ore_Laborator , Nr_Formatii_Laborator ,
Nr_Ore_Proiect , Nr_Formatii_Proiect ,
ID_CatedraResponsabilaCuplaj ,
ID_PlanMaterieLaCareSeCupleaza)
values
(@ID_AnUniv, @NrSemestruDinAn ,
@Nr_Ore_Curs, @Nr_Formatii_Curs ,
@Nr_Ore_Seminar, @Nr_Formatii_Seminar ,
@Nr_Ore_Laborator , @Nr_Formatii_Laborator ,
@Nr_Ore_Proiect , @Nr_Formatii_Proiect ,
@ID_CatedraResponsabilaCuplaj ,
@ID_PlanMaterieLaCareSeCupleaza)
END
A vantaje:
• În procedurile stocate comenzile sunt executate într-o singură serie,
ceea ce va ajuta la reducerea traficului din rețea sau server.
• Performanță îmbunătățită deoarece procesorul de interogare nu trebuie
să creeze un nou plan, deci durează mai puțin timp pentru a procesa
procedura.
• Reutilizarea codului.
• Întreținere mai ușoară.
În cadrul lucrării, modelul relațional și limbaju SQL au fost folosite pen-
tru crearea tabelelor și view-urilor necesare aplicației și crearea proceduri-
lor stocate necesare preluării, modificării și ștergerii datelor. Toate acestea
constituie începutul modului de lucru database first din cadrul Entity Fra-
mework.
15

3.1.9 Serviciul de rapoarte SQL
Serviciul de rapoarte SQL (SSRS) face parte din suita Microsoft SQL
Server services. Acesta este administrat printr-o interfață web și este utilizat
pentru pregătirea și livrarea unei varietăți de rapoarte interactive, care mai
apoi pot fi tipărite. Serviciul SSRS oferă o interfață în Microsoft Visual
Studio astfel încât dezvoltatorii, precum și administratorii SQL să se poată
conecta la bazele de date SQL și să utilizeze instrumente SSRS pentru a
forma rapoartele SQL în mai multe moduri complexe. De asemenea, oferă
un instrument „Generator de rapoarte” pentru utilizatorii mai puțin tehnici
săformatezerapoarteleSQLcuocomplexitatemaimică. Rapoarteledefinite
pot fi descărcate în diferite formate, inclusiv Excel, PDF, CSV, XML, TIFF
și Arhiva Web HTML.
Modul de lucru este următorul:
• Utilizatorii raportului sunt persoane care lucrează cu date sau care do-
resc să vizualizeze informații legate de date. Aceștia trimit o solicitare
către serverul SSRS.
• Serverul găsește metadatele necesare raportului și trimite o cerere de
date către sursa acestora.
• Datele returnate sunt contopite cu definiția raportului pentru a crea
raportul propriu zis, apoi acesta este returnat către client.
Serviciul de rapoarte SQL include instrumente de dezvoltare, instrumente
de administrare și de vizualizare. Componentele cele mai importante sunt
următoarele:
• Report Builder: este un instrument ad-hoc de publicare a rapoartelor
care sunt executate pe un computer de tip client. Are o interfață de
tip drag and drop și este ușor de folosit.
• Report Designer: este un instrument pentru dezvoltarea tuturortipu-
rilor de rapoarte. Este integrat în Visual Studio.
• Report Manager: verifică un raport și îl potrivește cu cerințele date.
• Report Server: este un server care folosește baza de date SQL pentru
a stoca informații despre metadate.
• Report server database: stochează metadate, definițiile rapoartelor,
resurse, setări de securitate, date de livrare.
A vantaje:
16

• Acces eficient de raportare a informațiilor din Microsoft SQL Server.
• Integrare cu Visual Studio.
• Securitatea este administrată printr-o metodă bazată pe roluri care
poate fi aplicată la dosare și rapoarte.
• Producție rapidă a rapoartelor relaționale.
Această tehnologie este folosită pentru generarea rapoartelor legate de pos-
turile cadrelor didactice din Universitate.
3.2 Limbajul C# și Entity F ramework
C# este un limbaj de programare modern, orientat pe obiecte (POO),
care poate fi utilizat pentru a îndeplini o gamă largă de sarcini și obiective
care se întind pe o varietate de profesii.
Programarea orientată pe obiecte se bazează pe conceptul de obiecte care
pot conține date. C# este potrivit pentru aplicații care aparțin sistemelor
găzduite, cât și pentru cele care aparțin sistemelor încorporate, de la sisteme
foarte mari care folosesc funcții de operare sofisticate, până la sisteme foarte
mici care au funcții dedicate.
Un aspect interesant în ceea ce privește C# este economia din punct de ve-
dere al memoriei și al puterii de procesare, drept urmare aplicațiile vor avea
o performanță mai bună.
Ca și alte limbaje de programare cu scop general, C# poate fi utilizat pen-
tru a crea o serie de programe și aplicații diferite: aplicații mobile, aplicații
desktop, servicii bazate pe cloud, site-uri web, software pentru întreprinderi
și jocuri.
În cazul de față, limbajul C# a fost folosit pentru dezvoltarea unei aplicații
Web API.
ASP.NET Web API este un cadru cu ajutorul căruia se pot construi servicii
HTTP care pot fi apoi apelate de diverși clienți precum: tablete, browsere și
telefoane mobile.
Aplicațiile construite cu ajutorul cadrului Web API sunt folosite pentru ex-
punerea de date și servicii pe diferite dispozitive. Web API este o platformă
cu sursă deschisă și se folosește pentru realizarea de servicii REST. Acest tip
de servicii reprezintă modalitatea prin care două sisteme pot comunica prin
intermediul HTTP.
În cazul de față, aplicația Web API se va afla pe server, va prelua date din
baza de date cu ajutorul cadrului oferit de Entity Framework și le expune
17

clientului reprezentat de aplicația construită în cadrul Vue.js.
3.2.1 Ce este Entity F ramework?
Entity Framework reprezintă un cadru construit pe baza modelului de
date de entitate (EDM). EDM este destinat dezvoltării unei aplicații cen-
trate pe date. De asemenea, extinde modelul relațional clasic cu concepte
din modelarea Entitate – Relație (E-R). Conceptele centrale din EDM sunt
entități și relații. Entitățile reprezintă obiecte de nivel superior cu existență
și identitate independente, în timp ce Relațiile sunt utilizate pentru a descrie
două sau mai multe entități.
Prin urmare, folosind Entity Framework vom putea lucra cu obiecte și clase
specifice, în loc să ne concetrăm pe tabele, rânduri și coloane din baza de
date, ceea ce va oferi abstractizare datelor.
3.2.2 De ce modelul EDM?
Modelul de date de entitate (EDM) este destinat dezvoltării unei aplicații
centrate pe date. Întrebarea evidentă care apare este: ”De ce să nu folosim
(sau să extindem) unul dintre modelele de date deja stabilit?”. Există cel
puțin patru alți candidați moderni pentru un astfel de model de date:
• Modelul de date SQL (tabele, coloane, chei, constrângeri de integri-
tate referențiale). SQL99 extinde acest model de bază pentru a include
caracteristicile relaționale ale obiectelor(tipuri definite de utilizator, ti-
puri structurate și distincte, metode, tabele, referințe).
• Modelul de date CLR (clase, câmpuri, metode, proprietăți, valori și
tipuri Ref, colecții).
• Modelul XSD bazat pe XML Infoset (Atomic-, tipuri de listă și uniuni,
tipuri primitive și derivate, ID, IDREF, ENTITY).
• Modelul de date UML (clase, obiecte, generalizări, atribute, operații,
agregări).
Motivul general este că avem nevoie de ceva care să mapeze curat atât pen-
tru CLR, cât și pentru baze de date relaționale precum SQLServer, pentru
programabilitate și, respectiv, persistență.
Niciuna dintre metodele de mai sus nu are toate facilitățile necesare pentru
18

aceste lucruri. CLR este un runtime orientat pe obiect, imperativ de pro-
gramare și nu are un model de date nativ sau noțiuni de constrângeri de
integritate, relații sau persistență.
EDM a fost conceput pentru a face o mapare descendentă curată din punct
de vedere CLR, cât și față de o bază de date relațională și ascendentă până
la performanțele UML. Designerii pot lucra cu concepte familiare UML, care
pot fi compilate în etape XML, CLR și SQL.
Practic, acest model ne ajută să construim clase pe baza tabelelor, procedu-
rilor și relațiilor din baza de date, folosindu-se de ajutorul tehnicii de asociere
care are rol în legarea obiectului de lumile relaționale.
3.2.3 Evoluție și modele
Entity Framework a evoluat dintr-o metodologie cunoscută sub numele
de Entity Relationship Modeling (ERM). Un ERM definește o schemă de
entități și relațiile lor unele cu altele. Entitățile nu sunt la fel ca obiectele.
Entitățile definesc schema unui obiect, dar nu și comportamentul acestuia.
• MODEL CONCEPTUAL:
Modelul conceptual este locul în care sunt descrise clasele de model.
Acest fișier este împărțit în două secțiuni principale: primul este un
container care listează toate entitățile și relațiile gestionate de Entity
Framework, iar al doilea conține o descriere detaliată a structurii lor.
• MODEL DE DEPOZITARE:
Modelul de stocare este echivalentul modelului conceptual, dar descrie
organizarea bazei de date. Acest fișier nu numai că este conceptual
similar cu cel precedent, dar folosește și aceleași noduri XML. Spre
deosebire de modelul conceptual, nu este posibil împărțirea acestui
modelînmaimultefișierefizice. Primasecțiuneaacestuifișierprezintă
toate tabelele, vizualizările, procedurile stocate și cheile străine care
sunt afectate. A doua secțiune descrie elementele enumerate în primul
nod.
În ceea ce privește tabelele și vizualizările, sunt descrise coloanele și
tastele primare. Când vine vorba de procedurile stocate, sunt descriși
parametrii de intrare și ieșire. Descrierea unei chei străine conține
informații despre tabelul implicat, cardinalitatea și regulile de ștergere
și actualizare.
• MODEL DE ASOCIERE:
Fișierul de asociere este complet diferit. Sarcina sa nu constă în a
19

descrie ceva, ci a compensa diferențele care există între cele două mo-
dele anterioare. Aici se întâmplă adevărata magie a mapării: se face
o asociere a unei clase la una sau mai multe tabele, se mapează o ta-
belă la una sau mai multe clase, se definește asocierea moștenirii și se
realizează asocierea procedurilor stocate atât pentru actualizări cât și
pentru regăsirea obiectelor.
Există un singur nod important în acest fișier: acesta asociază clasa la
un tabel și poate fi repetat de mai multe ori pentru a ne asigura că
o clasă poate fi mapată pe mai multe tabele și invers. Ca și fișierul
cu descrierea stocării și spre deosebire de fișierul conceptual, fișierul de
asociere nu poate fi împărțit în mai multe fișiere.
3.2.4 Arhitectura Entity F ramework
F urnizori specifici pentru sursele de date.
Entity Framework se construiește pe modelul de date ADO.NET. Există fur-
nizorispecificipentrucâtevasurserelaționale, non-relaționaleșiserviciiWeb.
F urnizorul EntityClient
EntityFrameworkincludeunnoufurnizordedate, numitEntityClient. Acest
furnizor găzduiește serviciile implementând transformări de mapare din con-
ceptuale în construcții logice. Furnizorul EntityClient este o vizualizare ba-
zată pe valori și include următoarele servicii:
• EDM / eSQL. Furnizorul EntityClient procesează și expune date în
termeni de valori EDM. Interogările și actualizările sunt formulate fo-
losind eSQL. Sunt procesate prin interogare și actualizează motoarele
de rețele care au încorporate transformări de mapare și cunoștințe des-
pre capabilitățile surselor de date.
• Asocierea. View mapping este subsistemul care implementează vizuali-
zări bidirecționale (citește și scrie) care permit aplicaților manipularea
datelor în termeni de entități și relații. Maparea de la tabele la entități
este specificată declarativ printr-un limbaj de definire a mapării
• Store-specific bridge. Este un serviciu care acceptă capacitățile de exe-
cuție a interogării din rețeaua de interogare și coordonează generarea
de interogări folosind sintaxa specifică furnizorului.
• Serviciuldemetadate. Suportătoateactivitățilededescoperireameta-
datelor componentelor care rulează în cadrul furnizorului EntityClient.
Toate metadatele asociate cu concepte EDM (entități, relații, seturi de
entități, relații), stocarea conceptelor (tabele, coloane, constrângeri) și
20

conceptele de mapare sunt expuse prin interfețe de metadate. Com-
ponenta serviciilor de metadate servește, de asemenea, ca o legătură
între instrumentele de modelare a domeniului care suportă proiectarea
aplicației bazată pe model.
• Tranzacții. FurnizorulEntityClientseintegreazăcucapacitățiletranzac-
ționale de bază.
• API. API-ul furnizorului EntityClient respectă modelul ADO.NET ba-
zat pe Conexiune, Obiecte de comandă și obiecte DataReader. Entity-
Client acceptă comenzi sub formă de text eSQL sau arbori canonici și
produce obiecte DataReader ca rezultat.
Componentele conectate ocazional.
Entity Framework îmbunătățește modelul bine stabilit de programare deco-
nectat al ADO.NET DataSet cu ajutorul colecțiilor memorate de entități și
seturi de entități.
Baza de date încorporată.
Entity Framework cuprinde capabilitățile unui motor de baze de date încor-
porat cu o memorie scăzută, pentru a îmbogăți serviciile pentru aplicațiile
care au nevoie de experiențe bogate în programare cu chaching de nivel me-
diu.
Instrumente de proiectare și metadate.
Entity Framework se integrează cu designeri de domenii pentru a permite
dezvoltarea aplicațiilor bazate pe modele. Instrumentele includ modelele
EDM, mapare și modelatori de interogare.
Straturi de programare.
ADO.NET permite conectarea mai multor straturi de programare la stratul
de servicii de date al entității expus de furnizorul EntityClient. Componenta
Object Services este un astfel de strat de programare care reprezintă o pâr-
ghie către obiectele CLR. Există mai multe mecanisme prin care un strat de
programare poate interacționa Entity Framework. Unul dintre mecanismele
importante sunt arborii de expresie LINQ.
Servicii.
Servicii de date SQL vor fi create în cadrul Entity Framework.
3.2.5 Abordarea database first
Există două modalități de lucru în Entity Framework: code first și data-
base first.
În abordarea code first programatorul se concentrează asupra domeniului
21

aplicației și crează clasele pentru entitățile domeniului, după care Entity
Framework se va ocupa de crearea datelor necesare pentru modelul relațio-
nal.
În abordarea database first se va crea baza de date care va reprezenta
modelul relațional, iar apoi Entity Framework se va ocupa de generarea en-
tităților necesare către trecerea la un model orientat pe obiecte.
Am ales să folosim abordarea database first deoarece dezvoltarea aplica-
ției se face într-un context în care există o bază de date stabilă în Universi-
tate, ci anume baza de date a proiectului AGSIS, care conține date utile ce
urmează a fi preluate, integrate și relaționate cu lucrarea pentru gestiunea
statelor de funcțiuni. Prin urmare, această abordare este mult mai eficientă
din punct de vedere al timpului deoarece se va folosi de codul deja existent
în Universitate.
Această abordare constă dintr-un meniu asistent, proiectat în Visual Stu-
dio, care introduce un model de obiect dintr-o bază de date existentă. Toate
clasele modelului dedus au proprietăți, dar nu au metode. Visual Studio,
însă, implementează modelul obiectului prin clase parțiale .NET. Aceasta
înseamnă că, scriind propriile extensii la acele clase, putem adăuga o metodă
la obiectele care implementează logica de afaceri. Putem avea, de exemplu,
o clasă SumHours care știe să calculeze suma totală a orelor de curs dintr-un
post.
3.2.6 A vantajele folosirii Entity F ramework
Un mare avantaj al Entity Framework este persistarea unui model de
obiect către o schemă relațională de tabele, deoarece ne vom concentra efor-
turile noastre de programare pe obiecte, nu pe tabele sau setări din baza de
date, ceea ce ridică nivelul de abstractizare al aplicației.
Modelarea domeniului de afaceri prin obiecte duce la o separare mult mai
simplă a preocupărilor, deoarece structura sa împărțită în clase conferă un
cadru eficient pentru implementarea logicii aplicației în interiorul stratului
corespunzător aplicației, nu în interiorul interfeței utilizatorului, cum am fi
obligați în alte cazuri.
În cazul în care suntem nevoiți să trecem de la modelul relațional la un mo-
del bazat pe obiecte, Entity Framework oferă simplitate și un timp de lucru
redus, deoarece ne scutește de efortul pe care l-am depune în mod normal
pentru crearea claselor și realizarea conexiunilor între clase și elementele din
modelul relațional. Acesta va genera obiecte pentru tabele, vizualizări și
22

proceduri stocate definite în baza de date. De asemenea, configurează toate
relațiile dintre diferitele obiecte ale bazei de date.
Relațiile sunt generate automat pentru orice reguli de integritate referenți-
ale definite în baza de date. Atunci când există o relație între două obiecte
(tabele) din model, înregistrările de detaliu pot deveni o parte a obiectului
principal. De exemplu; obiectul post are un element de navigare către obiec-
tul profesor, fiecare profesor aparține unui departament specific. Odată ce
modelul a fost creat, datele pot fi accesate folosind un ObjectQuery. Datele
sunt memorate în cache local la fiecare client și toate modificările sunt scrise
în baza de date prin instrucțiuni INSERT, UPDATE și DELETE.
Toateacesteprocesenecesitădoarcâtevaacțiunideconfigurarealeprograma-
torului, ceea ce eficientizează foarte mult timpul petrecut pentru dezvoltarea
aplicației.
3.2.7 Exemple
Clasă generată de Entity Framework:
public partial class PI_Cuplaj
{
public PI_Cuplaj()
{
this . PI_Cuplaj_Detalii =
new HashSet<PI_Cuplaj_Detalii >();
}
public long ID_Cuplaj
{ get ; set ; }
public long ID_AnUniv
{ get ; set ; }
public int NrSemestruDinAn
{ get ; set ; }
public int Nr_Ore_Curs
{ get ; set ; }
public int Nr_Formatii_Curs
{ get ; set ; }
public int Nr_Ore_Seminar
{ get ; set ; }
public int Nr_Formatii_Seminar
{ get ; set ; }
public int Nr_Ore_Laborator
23

{ get ; set ; }
public int Nr_Formatii_Laborator
{ get ; set ; }
public int Nr_Ore_Proiect
{ get ; set ; }
public int Nr_Formatii_Proiect
{ get ; set ; }
public long ID_CatedraResponsabilaCuplaj
{ get ; set ; }
public int ID_PlanMaterieLaCareSeCupleaza
{ get ; set ; }
public virtual ICollection<PI_Cuplaj_Detalii>
PI_Cuplaj_Detalii
{ get ; set ; }
}
Apelarea unei proceduri stocate:
public void CuplajDeleteById(long idCuplaj)
{
try
{
using (var connection = new AGSIS_10_10_2017_Entities())
{
connection . SF_CuplajDeleteById(idCuplaj );
}
}
catch (Exception e)
{
logger . Error(e , e . Message );
}
}
3.2.8 ASP .NET W eb API
3.3 V ue.js
Vue.js este o bibliotecă pentru construirea de interfețe web interactive.
Obiectivul Vue.js este de a oferi avantajele componentelor de legare a datelor
și de vizualizare compozibile cu un API, cât mai simplu.
24

LabazaVue.jsseaflăunsistemrelaționaldelegareadatelorcarefaceextrem
de simplu păstrarea sincronizării datelor și DOM-ului (DOM = Model de
obiect document). Când se utilizează jQuery pentru a manipula manual
DOM, codul pe care îl scriem este adesea imperativ, repetitiv și predispus
la erori. Vue.js îmbracă conceptul de vizualizare bazată pe date. În cuvinte
simple, înseamnă că folosim sintaxa specială în șabloanele noastre HTML
normale pentru a „lega” DOM-ul la datele de bază. După crearea legăturilor,
DOM-ul va fi păstrat în sincronizare cu datele. Ori de câte ori modificăm
datele, DOM-ul se actualizează în consecință. Drept urmare, cea mai mare
parte din logica aplicației noastre este acum manipularea directă a datelor,
în loc să încurcăm actualizările DOM. Acest lucru face ca codul nostru să fie
mai ușor de scris, mai ușor de motivat și mai ușor de întreținut.
Șablonul HTML, îmbunătățit cu legături, este o mapare declarativă a stării
de date de bază, care este, la rândul ei transformată în JavaScript.
Sistemul de componente reprezintă un concept important în Vue.js, deoarece
este o abstractizare care ne permite să construim aplicații la scară largă
compuse din componente mici, independente și deseori reutilizabile. Prin
urmare, orice tip de interfață de aplicație poate fi rezumat într-un arbore de
componente, care împreună alcătuiesc una sau mai multe pagini.
Rutarea este metoda care permite utilizatorului să comute între pagini fără
a reîmprospăta pagina ceea ce face navigarea ușoară și cu adevărat plăcută
în aplicația web și conferă performanță timpului de execuție.
Exemplu pentru declararea de rute:
import CentralizareMaterii from
”../ pages/payroll/CentralizatorMaterii ”;
import CreareCuplajeMaterii from
”../ pages/payroll/CreareCuplaje ”;
import CrearePost from
”../ pages/post/Post”
export const routes = [
{
path : ”/ centralizatorMaterii ”,
component: CentralizareMaterii
},
{
path : ”/creareCuplajeMaterii ”,
component: CreareCuplajeMaterii
},
25

{
path : ”/crearePost ”,
component: CrearePost
}
];
Exemplu de apelare a unei rute:
<div class=”card options”>
<router link
class=”btn btn primary btn sm”
to=”/creareCuplajeMaterii”>ă
Realizeaz cuplaje
</router link>
</div>
Proiectele realizate în Vue.js sunt împărțite în secțiuni, fiecare secțiune fiind
reprezentată de câte un folder separat, ceea ce înseamnă că se lucrează cu
module și fiecare secțiune va fi un singur modul.
• În folderul „Core” sunt incluse acele fișiere care sunt comune tuturor
modulelor (de exemplu, conectarea sau limba paginii).
• În folderul „Pagini” sunt incluse toate paginile acelui modul, care va
avea acces la obiectul de stocare, router și fereastră.
• În folderul „Servicii” sunt incluse toate fișierele de servicii.
• În folderul „Rute” sunt incluse toate rutele legate de modulul dat.
• În folderul „Magazin” sunt incluse toate fișierele de gestionare „vuex”.
• În folderul „Test” sunt incluse toate testele legate de modulul dat.
• În final, avem un fișier cu numele modulului dat în format „vue”, care
este calea principală pentru a ne conecta la modulul nostru.
Modulele pot fi create de utilizator, ceea ce conferă aplicației extensibi-
litate și separare de preocupări, sau pot fi importate din diverse surse de
pe internet. Cele mai folosite module importate în paginile web realizate
penntru aplicație sunt:
• axios: oferă ajutor la apelarea Web API – urilor create pentru aplicație.
• FlashMessage: oferă ajutor la afișarea mesajelor în interfața utilizato-
rului.
26

• VueRouter: pentru definirea rutelor dintre pagini.
• vSelectPage: este o componentă ce oferă opțiunea unui meniu dro-
pdown în care se pot filtra elementele după textul introdus de utiliza-
tor.
• CircleLoader: utilizat atunci când se așteaptă preluarea datelor de pe
server.
• XIcon: reprezintă o icoană vizuală în formă de ”x”.
• PlusIcon: reprezintă o icoană vizuală în formă de ”+”.
• SweetModal: este o fereastră modală unde se execută diverse acțiuni
ale utilizatorului.
Cu ajutorul Vue.js s-au creat pagini web separate, ci anume: pagină
web de centralizare a materiilor pentru cuplaje, pagină web de gestionare a
cuplajelor, paginăwebdecentralizareamateriilorpentruposturi, paginăweb
de gestionare a posturilor cadrelor didactice, care mai apoi au fost integrate
în module separate din cadrul Dot Net Nuke pentru a fi incluse în intranetul
Universității.
3.3.1 A vantajele utilizării V ue.js:
• Dimensiune foarte mica
Unul dintre cele mai mari avantaje ale Vue.js este dimensiunea mică.
Dimensiunea acestui cadru este de 18–21KB și nu necesită timp pentru
utilizator să o descarce și să o folosească. Aceasta nu înseamnă că are
viteză mică din cauza dimensiunilor mici. În schimb, este mai eficient
din puctul de vedere al dimensiunii decât toate cadrele voluminoase
precum React.js, Angular.js și Ember.js.
• Integrare simplă
Vue.js este, de asemenea, popular printre dezvoltatorii web, deoarece le
facilitează integrarea cu aplicațiile existente. Acest lucru se datorează
faptului că se bazează pe framework-ul JavaScript și poate fi integrat în
alteaplicațiiconstruitepeJavaScript. Acestlucruînseamnăcăesteutil
pentru dezvoltarea de noi aplicații web, precum și pentru modificarea
aplicațiilorpreexistente. AceastăintegrareesteposibilădeoareceVue.js
are componente pentru o paletă mai largă.
27

• Flexibilitate
Un mare avantaj al Vue.js este flexibilitatea. Aceasta permite utiliza-
torului să își scrie șablonul în fișier HTML, fișier JavaScript și fișier
JavaScript pur folosind noduri virtuale. Această flexibilitate face, de
asemenea, ușor de înțeles pentru dezvoltatorii React.js, Angular.js și
oricealtnoucadruJavaScript. Vue.jss-adoveditbeneficîndezvoltarea
acelor aplicații simple care rulează direct din browsere.
• Extensibilitate și separarea preocupărilor datorită modulelor care pot
fi create astfel încât să respecte principiile responsabilității unice.
• Comunicare bidirecțională
Și nu în ultimul rând, Vue.js facilitează, de asemenea, comunicarea în
două sensuri datorită arhitecturii sale MVVM, ceea ce face destul de
ușor de gestionat blocurile HTML. În acest sens, pare foarte aproape
de Angular.js, care grăbește și blocurile HTML.
3.4 Dot Net Nuke
Platforma Dot Net Nuke este construită în cadrul .NET și este proiectată
pentru a fi ușor de utilizat, fără a necesita cunoștințe de programare extinse.
Caracteristicile platformei Dot Net Nuke includ metode de proiectare care
permit schimbarea cu ușurință a aspectului unui site web și posibilitatea de
a încorpora module terțe pentru a adăuga funcționalități suplimentare. De
asemenea, mai multe site-uri pot fi construite pe aceeași arhitectură.
Platforma este open source și poate fi instalată și găzduită cu ușurință,
permițând libertății persoanelor cu cadrul atât în medii non-comerciale cât
și comerciale – toate acestea în schimbul acordării de credit comunității pro-
iectului DotNetNuke.
Dot Net Nuke este ideal atunci când vine vorba de crearea, desfășurarea
și gestionarea site-urilor web de tot felul. Permite administratorilor să lu-
creze eficient cu instrumente personalizate, suplimente și ansambluri terțe,
ceea ce face mai ușor gestionarea oricărui număr de site-uri web. Tehnologia
Dot Net Nuke a fost concepută în esență pentru a ușura activitatea proiec-
tanților, dezvoltatorilor, editorilor de conținut și administratorilor.
În arhitectura platformei Dot Net Nuke, mai multe site-uri pot fi cre-
ate pe cadrul principal oferit de platformă. Fiecare site construit în cadrul
platformei este format din mai multe pagini, fiecare conținând mai multe
28

mini-aplicații numite module care oferă funcționalități specifice, cum ar fi
comerțul electronic. Aceste module pot apărea pe mai multe pagini ale ace-
lorași site-uri. Inclusiv intranetul Universității este construit pe baza acestor
moduledincadrulDotNetNuke, undesuntinseratediversepaginijavascript.
3.4.1 Module Dot Net Nuke
În Dot Net Nuke când spunem modul ne referim la un tip de extensie care
se pot adapta site-ului la care lucrăm în funcție de nevoile noaste. Ele sunt
principalul motor al funcționalității site-ului și conferă conceptul de separare
de preocupări, deoarece fiecare modul este independent și poate fi inserat
oriunde în cadrul paginii.
Modulele din cadrul Dot Net Nuke pot fi descărcate din surse externe și
apoi implementate sau pot fi dezvoltate și personalizate chiar de către utili-
zator, ceea ce conferă o extensibiltate crescută a platformei.
Dezvoltarea propriului modul pentru Dot Net Nuke pote fi gestionată în
multe feluri, cu instrumente precum Visual Studio, dar nu numai. Regula
pe care trebuie să o respecte fiecare modul este aceea de a fi compatibil cu
VB.NETsauC#. Deasemenea, modululsuportăinserareadecodjavascript,
ceea ce face ca Vue.js să fie o alegere utilă pentru dezvoltarea de module in-
tegrate în intranetul Universității.
Componenta modulelor este utilizată pentru pachete și instalarea modu-
lelor. Toate modulele ar trebui să utilizeze această componentă pentru a
defini controalele sau funcțiile acceptate.
Este permis un singur modul component pentru fiecare pachet. Pentru a
instala o serie de module ca unitate, pot fi incluse, în același fișier manifest,
diferite pachete, fiecare conținând definiția unui singur modul.
Fiecare modul poate include o serie de ”ModuleDefitions” și ”Module
Controls”, structura fiind următoarea:
<moduleDefinition>
<friendlyName/>
<defaultCacheTime/>
<moduleControls>
29

<moduleControl>
<controlKey />
<controlSrc />
<supportsPartialRendering />
<controlTitle />
<controlType />
<iconFile />
<helpUrl></helpUrl>
<viewOrder>0</viewOrder>
</moduleControl>
</moduleControls>
<permissions>
<permission code=”” key=”” name=”” />
</permissions>
</moduleDefinition>
3.4.2 Gestionare utilizatori în cadrul Dot Net Nuke
În cadrul platformei Dot Net Nuke administratorul poate căuta și selecta
un cont al unui utilizator, iar după aceea poate forța o schimbare de parolă
pentru acel cont, îl poate autoriza pentru anumite operațiuni sau poate să
revoce o autorizare și poate atribui un rol utilizatorului selectat.
Fiind compatibil cu C#, în momentul în care definim o funcție API într-
un Web Controller putem integra funcții Dot Net Nuke care ne ajută să
restricționăm accesul la acel API. De asemenea, din interfața oferită de Dot
NetNuke, administratorulvaputeasetaopțiuneadevizibilitateaunuimodul
în funcție de utilizatorul sau categoria de utilizatori pe care o dorește.
Exemplu:
[ DnnAuthorize( StaticRoles = ”Cadru Didactic ”)]
[HttpGet]
public IHttpActionResult List (long ID_AnUniv,
long ID_Catedra)
{
try
{
var result = _postService . List (ID_AnUniv,
ID_Catedra );
return Ok( result );
}
catch (Exception e)
30

{
return Content
(HttpStatusCode . InternalServerError ,
e . Message );
}
}
Pentru acest API va fi permis accesul doar utilizatorilor care fac parte din
categoria ”Cadru Didactic”.
3.4.3 A vantajele utilizării Dot Net Nuke
• Instrumente puternice
Dot Net Nuke dispune de bare de instrumente care au fost concepute
pentru a codifica și implementa eficient preferințele de găzduire, proiec-
tări, opțiuni de securitate, precum și o varietate de alte funcționalități
utile. În plus, există o varietate de alte instrumente puternice furni-
zate de cadrul Dot Net Nuke care pot fi valorificate la maximum prin
ajustarea lor în funcție de nevoi.
• Administrare simplă
Se poate crea, monitoriza și publica conținut pe site-ul dvs. web fără
a avea abilități tehnice specifice, permițând administrarea simplă.
• Extensibilitatea: se pot crea și integra module proprii sau importa
module deja existente în cadrul comunității.
• Securitatea: se poate configura accesul și vizibilitatea în funcție de
utilizator.
• Separarea preocupărilor: modulele create pot fi independente unele de
altele.
• Comunitatea
CautilizatorDotNetNukeputemapelaîntotdeaunaladeunnucleude
dezvoltare care este format dintr-o comunitate uriașă de dezvoltatori.
31

Capitolul 4
Modelul relațional
4.1 Introducere
Pentru modelarea bazei de date am utilizat sistemul de gestiune Micro-
soft SQL Server deoarece aplicația va fi integrată în sistemul informatic al
Universității Transilvania, iar acesta este sistemul utilizat în universitate.
Entitățiile create sunt strâns legate de cele deja existente în sistemul de ges-
tiunealuniversitățiișidecelecreatedeunaltstudentpentrusoluțiasoftware
a planurilor de învățământ.
4.2 Entități
Pentru rezolvarea problemei este necesară crearea unor tabele care să
reprezinte cuplajele între materii și posturile aferente profesorilor din Uni-
versitate.
Pentru fiecare an universitar se realizeză cuplaje între materiile din planul
de învățământ, apoi pentru cuplaje și materiile necuplate se creează posturi
de titular sau suplinitor cu un anumit număr de ore de curs/seminar/labo-
rator/proiect, care sunt atribuite către profesori.
Pentru a îndeplini aceste funcții ne folosim de următoarele tabele create în
cadrul proiectului complementar ”Aplicație pentru gestiunea planurilor de
învățământ” realizat de colegul Curta Andrei Ioan:
• PI_PlanInvatamantIndex
• PI_PlanInvatamant_Semestru
• PI_PlanInvatamant_Materie_Detalii
• PI_PlanInvatamant_Materie
32

• PI_PlanInvatamant_Status
De asemenea, ne folosim de următoarele tabele deja existente în sistemul
de gestiune al universității:
• AnUniversitar
• Catedra
• Profesor
• TipGradDidactic
• TipCicluInvatamant
• TipF ormaInvatamant
Tabelele create pentru soluția statelor de funcțiuni sunt următoarele:
• PI_Cuplaj, tabela 4.1- conține informațiile generale despre un cu-
plaj.
• PI_Cuplaj_Detalii, tabela 4.2- face legătura între cuplaj și ma-
teriile existente în acel cuplaj.
• PI_Post, tabela 4.3- conține informațiile de bază ale unui post
• PI_Post_Profesor, tabela 4.4- face legătura dintre un post și
profesor.
• PI_Post_Profesor_Materie, tabela 4.5-facelegăturaîntrepost,
profesor și materie. De asemenea, conține și numărul orelor de curs/-
seminar/laborator/proiect predate de profesor în cadrul postului res-
pectiv.
• PI_Aprobare_Stat_F unctiune, tabela 4.6- conține informații
referitoare la aprobarea unui stat de funcțiune dintr-un anumit an uni-
versitar.
PI_Cuplaj
PKID_Cuplaj bigintrol de identificator pentru cu-
plaje
FKID_AnUniv bigintreprezintă legătura cu tabela de
ani universitari
33

FKID_CatedraResponsabilaCuplaj bigintreprezintă legătura cu catedra
responsabilă de crearea cuplaju-
lui
FKID_PlanMaterieLaCareSeCupleaza bigintreprezintălegăturacuplanulma-
teriei principale din cuplaj
NrSemestruDinAn intnumărul semestrului din anul în
curs
Nr_Ore_Curs intnumărul total al orelor de curs
atribuite cuplajului
Nr_Formatii_Curs intnumărul total al formaților care
vorparticipalaoreledecursîntr-
o săptamână
Nr_Ore_Seminar intnumărul total al orelor de semi-
nar atribuite cuplajului
Nr_Formatii_Seminar intnumărul total al formațiilor care
vor particia la orele de seminar
într-o săptamână
Nr_Ore_Laborator intnumărul total al orelor de labo-
rator atribuite cuplajului
Nr_Formatii_Laborator intnumărul total al formațiilor care
vor partivipa la orele de labora-
tor într-o săptamână
Nr_Ore_Proiect intnumărul total al orelor de proiect
atribuite cuplajului
Nr_Formatii_Proiect intnumărul total al formaților care
vor participa la orele de proiect
într-o săptamână
Tabela 4.1: PI_Cuplaj
Demonstrație pentru normalizarea tabelei de cuplaje
• Nu există grupuri repetitive în cadrul entităților tabelei. Grupurile
care puteau fi repetitive sunt reprezentate de legături către tabelul
PI_PlanInvatamant_Materie, creatdecătrecolegulCurtaAndreiIoan
în cadrul proiectului complementar ”Aplicație pentru gestiunea planu-
rilor de învățământ”, rezultă că relația este în forma normală unu.
• Cheiea primară este compusă dintr-un singur atribut: ID_Cuplaj. Din
acest motiv nu poate exista o dependență parțială de cheie, deci relația
este în formă normală doi.
34

• Nuexistăniciodependențătranzitivădecheie, decirelațiaesteînformă
normală trei.
PI_Cuplaj_Detalii
PKID_Cuplaj_Detalii bigintcheie primară
FKID_Cuplaj bigintreprezintă legătura cu tabela de cu-
plaje
FKID_PlanMaterie bigintreprezintă legătura cu planul materiei
în cadrul unui cuplaj
Tabela 4.2: PI_Cuplaj_Detalii
Demonstrație pentru normalizarea tabelei care conține detalii ale cupla-
jelor:
• Nu există grupuri repetitive în cadrul entităților tabelei. Grupurile
care puteau fi repetitive reprezintă legături către tabela cuplajelor și
cea a planurilor materilor, rezultă că relația este în forma normală unu.
• Cheiaprimarăestecompusădintr-unsinguratribut: ID_Cuplaj_Detalii.
De aceea nu putem avea dependență parțială de cheie, deci relația este
în formă normală doi.
• Nuexistăniciodependențătranzitivădecheie, decirelațiaesteînformă
normală trei.
PI_Post
PKID_Post bigint cheie primară
FKID_AnUniv bigint reprezintă anul universitar
pentru care este creat postul
FKID_TipGradDidactic bigint reprezintă legătura către ta-
bela cu tipuri de grade di-
dactice de unde se pot prelua
informații despre nivelul unui
post
FKID_TitluStiintific bigint reprezintă titlul științific asig-
nat postului
FKID_Catedra bigint reprezintă catedra responsa-
bilă de post
NrCrt int numărul criteriu al postului
35

TitularSauSuplinitor tinyint reprezintă tipul postului care
poate fi de titular sau suplini-
tor
TotalOreConventionale decimal(4, 2) numărul total de ore conven-
ționale atribuite postului
Tabela 4.3: PI_Post
Demonstrație pentru normalizarea tabelei de posturi
• Nu există grupuri repetitive în cadrul entităților tabelei, rezultă că
relația este în forma normală unu.
• Cheiea primară este compusă dintr-un singur atribut: ID_Post. De
aceea nu putem avea dependență parțială de cheie, deci relația este în
formă normală doi.
• Nuexistăniciodependențătranzitivădecheie, decirelațiaesteînformă
normală trei.
PI_Post_Profesor
PKID_Post_Profesor bigintcheie primară
FKID_Profesor bigintface trimitere către profesorul care
va fi inclus în post
FKID_Post bigintlegătura către tabela de posturi
NrOrdine intnumărul de ordine al profesorului
în cadrul postului
Tabela 4.4: PI_Post_Profesor
Demonstrație pentru normalizarea tabelei care conține detaliile profeso-
rilor în cadrul posturilor
• Nu există grupuri repetitive în cadrul entităților tabelei. Grupurile
care necesitau acest lucru sunt reprezentate de legături către tabelele
Profesor și Post, rezultă că relația este în forma normală unu.
• Cheieaprimarăestecompusădintr-unsinguratribut: ID_Post_Profesor.
De aceea nu putem avea dependență parțială de cheie, deci relația este
în formă normală doi.
36

• Nuexistăniciodependențătranzitivădecheie, decirelațiaesteînformă
normală trei.
PI_Post_Profesor_Materie
PKID_Post_Profesor_Materie bigint cheie primară
FKID_Post_Profesor bigint realizează legătura cu tabela
Post_Profesor
FKID_PlanMaterie bigint reprezintă planul materiei care
aparține unui post
NrCrt int numărul de ordine al materiei
predate de un profesor în ca-
drul unui post
ApartineDeCuplaj tinyint câmp ajutător din care putem
deducedacămateriafaceparte
dintr-un cuplaj sau nu
Nr_Ore_Curs decimal(4, 2) numărul total de ore de curs
predate de un profesor pentru
o materie într-o săptămână în
cadrul unui post
Nr_Ore_Seminar decimal(4, 2) numărul total de ore de se-
minar predate de un profesor
pentru o materie într-o săp-
tămână în cadrul unui post
Nr_Ore_Laborator decimal(4, 2) numărultotaldeoredelabora-
torpredatedeunprofesorpen-
tru o materie într-o săptămână
în cadrul unui post
Nr_Ore_Proiect decimal(4, 2) numărultotaldeoredeproiect
predate de un profesor pentru
o materie într-o săptămână în
cadrul unui post
Tabela 4.5: PI_Profesor_Materie
Demonstrație pentru normalizarea tabelei care conține informațiile ma-
teriilor din cadrul unui post
• Nu există grupuri repetitive în cadrul entităților tabelei, rezultă că
relația este în forma normală unu.
• Cheieaprimarăestecompusădintr-unsinguratribut: ID_Post_Profesor_Materie.
37

De aceea nu putem avea dependență parțială de cheie, deci relația este
în formă normală doi.
• Nuexistăniciodependențătranzitivădecheie, decirelațiaesteînformă
normală trei.
PI_Aprobare_Stat_F unctiune
FKID_AnUniv bigint realizează legătura cu tabela
de ani universitari
FKID_CatedraResponsabila bigint reprezintă catedra aferentă
statului de funcțiune.
Aprobat tinyint câmpcuajutorulcăruiaputem
observa dacă statul de func-
țiune a fost aprobat sau nu
Comentarii nvarchar(MAX) Comentarii aduse la adresa
statului de funcțiune. Este util
în cazul respingerii, pot fi adă-
ugate observații cu modificări
necesare.
Tabela 4.6: PI_Aprobare_Stat_Functiune
Demonstrație pentru normalizarea tabelei care conține aprobările statelor
de funcțiuni.
• Nu există grupuri repetitive în cadrul entităților tabelei, rezultă că
relația este în forma normală unu.
• Nu există cheie primară, prin urmare nu putem avea dependență pa-
rțială de cheie, deci relația este în formă normală doi.
• Nuexistăniciodependențătranzitivădecheie, decirelațiaesteînformă
normală trei.
Diagrama relațiilor dintre tabele este următoarea:
38

Figura 4.1: Diagrama relațiilor dintre tabele
39

Deasemenea, pentruo abstractizaremai marea aplicației șipentrumani-
pularea mai ușoară a datelor a fost necesară crearea următoarelor 3 view-uri:
• View_PI_CentralizatorMaterii: acesta centralizează informații din ta-
belele PI_PlanInvatamant_Index, PI_PlanInvatamant_Materie,
PI_PlanInvatamant_Semestru, create în cadrul proiectului comple-
mentar ”Aplicație pentru gestiunea planurilor deînvățământ” realizat
de colegul Curta Andrei Ioan și tabelele Materie, TipFormaInv, TipCi-
cluInv, Catedra, N_LimbaPredare prezente în cadrul proiectului ”AG-
SIS” al Universității.
• View_PI_CentralizareMateriiByCuplaje: acesta reprezintă o struc-
tură ajutătoare pentru a putea aduce date mai ușor în interfața cre-
ată pentru gestiunea cuplajelor între materii. Ca deosebire față de
View_PI_CentralizatorMaterii,centralizatoruldecuplajeneoferăcâm-
puri care ne ajută să observăm dacă o materie este cuplată sau nu,
unde este cuplată o materie, dacă este cazul, și, pentru materiile cu-
plate, ne ajută să observăm care este materiaprincipală din cuplaj și
care sunt cele secundare. De asemenea, în acest centralizator materiile
secundare vor prelua numărul de ore și numărul de formații aferente
materiei principale.
• View_PI_CentralizatorMateriiPost: a fost creat cu scopul de ușura
preluarea datelor pentru interfața de gestiune a posturilor cadrelor di-
dactice. Spre deosebire de View_PI_CentralizareMateriiByCuplaje,
exclude materiile secundare dintr-un cuplaj și ne oferă date despre nu-
mărul de ore rămase libere pentru fiecare materie în parte după ce au
fost atribuite posturi cadrelor didactice.
Pentru manipuarea datelor s-a folosit combinația dintre utilizarea proce-
durilor stocate și maparea obiectual-relațională în cadrul codului client, ceea
ce oferă următoarele avantaje:
1. Încapsularea codului
2. Abstractizarea codului
3. Posibilitate de optimizare mai ușoară
4. Scriere nativă a codului
40

Capitolul 5
Arhitectura aplicației
5.1 Introducere
”Arhitectura este rezultatul unui set de decizii de afaceri și tehnice. În
momentul creării, schița este influențată din mai multe părți, astfel și exe-
cuția va fi influențată de schimbări în funcție de mediul din jur pe care
arhitectul trebuie să cunoască.” [ 18]
Arhitectura poate fi definită ca un proces prin care, în urma discuțiilor înte
solicitanțiiuneiaplicațiișiceicarevorcreaaplicația, seiaudeciziifundamen-
tale în legătură cu crearea și structurarea aplicației astfel încât să poată fi
satisfăcute cerințele tuturor oamenilor implicați în proces, cerințe precum:
scalabilitate, securiate, calitate, adaptabilitate, extensibilitate, modularitate,
coeficiență de cost.
Deciziile care sunt luate în cadrul stabilirii elementelor arhitecturii sunt stra-
tegice deoarece pot fi dificil de modificat, au impact asupra multor procese
interconectate, implică perioade îndelungate de implementare sau creare și
pot avea impact asupra mai multor persoane.
De exemplu, aceste decizii pot fi:
• Alegerea unei arhitecturi REST, bazată pe microservicii.
• Alegerea limajelor de programare, pentru care există posibilitatea să fie
utilizate o perioadă îndelungată. Înlocuirea unui limbaj de programare
este costisitoare și afectează atât echipa de dezvoltare cât și cea de
mentenanță.
• Alegerea unui framework, care se aseamănă cu alegerea unui limbaj
de programare la durata de folosire și posibilele probleme generate de
schimbarea sa.
41

5.2 Scopul arhitecturii software
Scopul unei arhitecturi software este diferit de la caz la caz, totuși putem
spune că la comun acestea vizează:
• Beneficiile care sunt aduse în urma modificărilor.
• Perspectivă generală asupra posibilelor interacțiuni cu alte sisteme.
• Securitatea și aspectul responsiv al interfeței.
• Costurile proiectului.
• Implicațiile personalului.
5.3 Arhitectura stratificată – N Tier
Figura 5.1: Diagrama arhitecturii stratificate
Sursa: Richards, M(2015). Software Architecture Patterns – Understanding
Common Architecture Patterns and When to Use Them [ 19]
42

Fiecare strat al arhitecturii are un rol bine definit, independent unul de
altul. Este util pentru aplicații cu un număr mare de clienți și un număr
mare de conexiuni concurente.
Componenta Customer Screen răspunde de acceptarea cererii clientului
și afișarea informațiilor solicitate. Acest modul nu știe unde sunt stocate da-
tele, sau câte tabele trebuie să fie interogate pentru a obține datele. Odată ce
primește o cerere de la client, înaintează cererea la modulul Customer Dele-
gate care este responsabil pentru cunoașterea modulelor din stratul Business
care procesează solicitarea, cum ajunge cererea la modulul respectiv și de
ce date are nevoie (contractul). Customer Object din stratul Business este
responsabil pentru agregarea tuturor informațiilor necesare tratării solicită-
rii primite. Acest modul apelează la modulul Customer DAO (data access
object) din stratul Persistence pentru a obține datele solicitate și la modulul
Order DAO pentru comenzi. Aceste module la rândul lor execută instruc-
țiuni SQL pentru a prelua datele corespunzătoare din stratul Database și a
le transmite înapoi la Customer Object din stratul Business. Odată ce Cus-
tomer Object primește datele, agregă datele și transmite aceste informații
înapoi la la modulul Customer Delegate, care le transferă apoi modulului
Customer screen care le prezintă utilizatorului.
5.4 Descrierea arhitecturii folosite în cadrul
proiectului
Arhitectura folosită în cadrul proiectului este cea bazată pe mai multe
straturi . Am ales să folosim această arhitectură deoarece modul acesteia de
gestionare al clienților și a conexiunilor este potrivit cu cerințele aplicației
și este compatibilă cu modul de lucru al Universității, ceea ce va permite o
mentenanță mai ușoară.
43

Figura5.2: Diagramaarhitecturiiaplicațieipentrugestiuneastatelordefunc-
țiuni
• Stratul 1 al aplicației (Customer Screen) este reprezentat de interfață
creată pentru utilizator reprezentată de paginile create în Vue.js.
• Customer Delegate este reprezentat de controllere Web API realizate
cu ajutorul limbajului C#.
• Stratul al doilea al aplicației (Business) este reprezentat de Entități,
validări și servicii realizate cu ajutorul cadrului creat de Entity Fra-
mework.
• Stratulaltreilea, depersistență, esterealizattotcuajutorulmijloacelor
puse la dispoziție de Entity Framework.
• Ultimul strat este reprezentat de baza de date, tabelele, view-urile și
procedurile stocate create în Microsoft SQL Server.
44

Primele două straturi sunt integrate în infrastructura Dot Net Nuke pentru
a putea fi introduse ulterior în modulul de Intranet al Universității.
5.5 A vantajele utilizării arhitecturii software
Atunci când utilizăm o arhitectură software beneficiem de următoarele
avantaje:
• Structură solidă a aplicației.
• Scalabilitate.
• Reducerea costurilor.
• Evitarea duplicării codului.
• Ajută la gestionarea complexității.
• Adaptabilitate mai ridicată, deoarece arhitectura software creează o
separare clară a sarcinilor.
• Prioritizarea obiectivelor conflictuale. Facilitează comunicarea cu păr-
țile interesate, contribuind la un sistem care să le satisfacă mai bine
nevoile. Arhitectura oferă capacitatea de a comunica cu privire la de-
ciziile de proiectare înainte de implementarea sistemului, atunci când
acestea sunt încă relativ ușor de adaptat.
• O mai bună întreținere a codului. Este mai ușor să menținem software-
ul existent, deoarece structura codului este vizibilă și cunoscută, deci
este mai ușor să găsim buguri și anomalii.
45

Capitolul 6
V erificarea și validarea
aplicației
6.1 V erificarea aplicației
Prin conceptul de verificare a aplicației ne punem întrebarea: ”Construim
produsul corect?”. Pentru a răspunde la această întrebare trebuie să ne asi-
gurăm că aplicația noastră satisface cerințele impuse de către client și că se
conformează nivelului de calitate așteptat.
Produsul final a fost supus procesului de verificare, care a constat în asigura-
rea respectării cerințelor funcționale și nefuncționale ale aplicației, mențio-
nate în capitolul 2 secțiunile 2 și 3 și prin parcurgerea programului pentru a
asigura respectarea arhitecturii și design-ului stabilit, care conferă nivelul de
calitate a codului.
6.2 V alidarea aplicației
Spre deosebire de procesul de verificare, în procesul de validare nu ne
punem întrebarea, ci afirmăm că am construit produsul corect. Această
afirmație se face pe baza testării, care reduce viteza de recurență a eșecurilor.
6.2.1 T estarea unitară
Testareaunitarăestenivelulsoftwaredetestarecarearescopuldeavalida
dacă fiecare unitate a softului creat funcționează așa cum a fost proiectat.
Prin unitate ne referim la cea ma mică parte dintr-un soft care poate fi
testată, de exemplu: în cadrul programării orientate pe obiect aceasta poate
fi o metodă.
46

Este obligatoriu ca acest nivel de testare să fie implementat fără a afecta
sistemul real de programare.
Aplicația de gestiune a statelor de funcțiuni a fost testată pentru validarea
cazurilor de introducere a datelor care nu respectă logica de funcționare a
programului și pentru validarea permisiunilor de acces a resurselor, ceea ce
conferă siguranță cu privire la nivelul de securitate a aplicației.
Testele create respectă modelul ”Arrange, Act, Assert” care o structură ce
respectă următoarea ordine:
1. Stabilirea de precondiții a testării.
2. Aplicarea asupra metodei.
3. Verificarea ca rezultatele obținute să fie cele așteptate.
Exemplu de funcție de testare unitară care folosește o bază de date Mock,
pentru a nu afecta sistemul real de programare, și care testează dacă imple-
mentarea validării pentru setul de date funcționează corect:
public class PostTest
{
private readonly PostService _postService ;
private readonly Mock<AGSIS_Entities>
_context = new Mock<AGSIS_Entities >();
public PostTest ()
{
_postService = new PostService (_context . Object );
}
[ Fact ]
public void ShouldNotReturnValidationError ()
{
//Arrange
Post post = new Post ();
//Act
post .NrCrt = 1;
//Assert
Assert .Throws
<FluentValidation . ValidationException>
(() => { _postService .Add(post ); });
}
}
47

6.2.2 T estarea acceptării din partea utilizatorilor.
Aceasta este forma finală a testării și are rolul de a valida dacă produsul
creat îndeplinește nevoile utilizatorilor reali ai aplicației.
Ca primă modificare a aplicației în urma acestei testări a fost intodusă opțiu-
nea de sortare a datelor afișate în interfețele de centralizare create în cadrul
Vue.Js. Datele sunt sortate în funcție de câmpul ales de utilizator prin se-
lectarea capului de tabel din cadrul paginii web.
După această modificare a fost necesară retragerea aplicației din testare din
cauza erorilor survenite în urma modificărilor aduse proiectului ”Aplicație
pentru gestiunea planurilor de învățământ” realizat de colegul Curta An-
drei Ioan. În urma testării de acceptare a utilizatorilor pentru aplicația de
gestiune a planurilor de învățământ a fost necesară schimbarea structurii
tabelelor care cuprind date referitoare la materiile cuprinse într-un plan de
învățământ, date ce sunt legate de view-urile necesare creării centralizatoa-
relor, cuplajelor și a materiilor din cadrul unui post descrise în capitolul 4,
fapt ce a generat erori legate de funcționarea aplicației de gestiune a statelor
de funcțiuni.
Pentru a corecta aceste erori au fost necesare:
• Schimbareacoduluidecreareaview-uluiView_PI_CentralizatorMaterii
astfel încât să fie compatibil cu noua structură tabelară a aplicației de
gestiune a planurilor de învățământ și să returneze datele necesare apli-
cației de gestiune a statelor de funcțiune.
• FolosireadatelorreturnatedeView_PI_CentralizatorMateriiîncadrul
View_PI_CentralizareMateriiByCuplaj. Aceastămodificareafostadusă
pentru a fi necesară schimbarea codului doar într-un singur loc în cazul
în care va apărea o eroare similară.
• Folosirea datelor returnate de View_PI_CentralizareMateriiByCuplaj
în cadrul View_PI_CentralizatorMateriiPost din același motiv descris
la punctul anterior.
• Actualizarea datelor de conectare a EntityFramework la baza de date
pentru a modifica clasele create de acesta astfel încât să nu existe pro-
bleme de compatibilitate cu noua structură a modelului relațional.
48

Capitolul 7
Manualul de instalare și
utilizare a aplicației
7.1 Instalarea aplicației
Aplicația relaționează cu elemente din cadrul bazei de date AGSIS a Uni-
versității și cu elemente care aparțin proiectului ”Aplicație pentru gestiunea
planurilor de învățământ” realizat de colegul Curta Andrei Ioan. Prin ur-
mare, înainte de a începe procedura de instalare, trebuie să ne asigurăm că
baza de date AGSIS este intactă și să instalăm aplicația pentru gestiunea
planurilor de învățământ.
După aceea, pentru instalarea modelului relațional, administratorul de sis-
tem va trebui să ruleze fișierul statef.sql în cadrul consolei de management
SQL Server Management Studio.
7.1.1 Pregătirea nivelelor de prsistență a datelor și de
logică a aplicației
Pentru o integrare corectă cu platforma de intranet a Universității trebuie
să asigurăm integritatea tuturor referințelor către pachetele puse la dispoziție
de Dot Net Nuke din directorul bin al instalării DNN și să verificăm ca aceste
pachete să se afle la aceleași versiuni cu cele folosite pentru funcționarea
platformei de intranet.
În fișierul App.config pot fi modificate detalii care se referă la conectarea cu
baza de date.
Fișierele .dll rezultate în urma compilării codului trebuie să fie mutate în
fișierul bin din cadrul Dot Net Nuke pentru a putea rula aplicația.
49

În directorul API se va găsi codul responsabil de partea de persistență a
datelor și de logica aplicației, care va putea fi preluat și adăugat în cadrul
api-urilor deja existente pentru baza de date AGSIS. De asemenea, după
adăugare se pot configura și permisiunile de acces specifice Dot Net Nuke.
7.1.2 Pregătirea interfeței utilizatorilor
Codul sursă deja compilat se află în folderul codCompilat.
Dacă se doresc modificări codul va trebui recompilat. Pentru a putea realiza
modificări trebuie avute în vedere următoarele aspecte:
• Instalarea prealabilă a Node.js.
• Folosirea instrucțiiunii npm install într-o linie de comandă, pentru
instalarea tuturor modulelor folosite în cadrul interfețelor.
Pentru integrarea interfețelor se pot modifica următoarele configurări:
• schimbarea valorii de la cheia publicPath din fișierul vue.config cu va-
loarea care corespunde căii către folderul DesktopModules din Dot Net
Nuke.
• schimbarea valorii VUE_App_API_URL, care se găsește în fișierul
.env.production, cuovaloarecorespunzătoareURL-uluicarereprezintă
API-ul pentru procesarea datelor.
7.1.3 Crearea modulelor în cadrul Dot Net Nuke
Pentru a crea un modul nou în cadrul platformei Dot Net Nuke va trebui
să fim autentificați cu un cont de administrator. După aceea, vom putea
naviga către opțiunea de Create New Extension din secțiunea de setări a
meniului de administrare. (figura 7.1)
50

Figura 7.1: Secțiunea de setări ale meniului de administrare
Odată executat acest pas se vor completa următoarele opțiuni după cum
urmează (figura 7.2):
• Pentru Tipul extensiei se va alege: Module.
• Numele extensiei va fi introdus la latitudinea utilizatorului.
• Descrierea și versiunea extensiei sunt opționale și vor fi introduse la
latitudinea utilizatorului.
După completarea opțiunilor trebuie apăsat butonul save din partea de jos
a paginii. În continuare, se va căuta modulul salvat în lista de module,
după care trebuie să apăsăm butonul în formă de creion corespunzător mo-
dulului. După aceea vom naviga la opțiunea Extension Settings , apoi la
MODULE DEFINITIONS , după care vom apăsa butonul Add+. (figura
7.3)
51

Figura 7.2: Crearea unui modul
Figura 7.3: Definiția unui modul
52

În secțiunea deschisă în urma apăsării butonului Add+ va trebui adăugat
numele modulului, după care se va apăsa butonul Save. În continuare, vom
apăsa butonul în formă de creion care va afișa un panou. În cadrul panoului
vom apăsabutonul Add+și vom completa formularul după cum urmează
(figura7.4):
• Key: nu se va completa nimic.
• Title: titlul pe care dorim să îl atribuim definiției modulului.
• Source Folder: se va completa calea corespunzătoare fișierului Deskto-
pModules a codului sursă.
• Source File: se va alege fișierul index.html corespunzător.
După completarea acestor opțiuni se poate salva, iar modulul va fi pregătit
pentru folosire.
53

Figura 7.4: Extensia unui modul
7.2 Utilizarea aplicației
7.2.1 Autentificare și acces
Pentru utilizarea aplicației este necesară autentificarea în platforma de
intranet a Universității.
Pentru a ne autentifica trebuie să navigăm către site-ul: https://intranet.
unitbv.ro , unde va apărea următoarea interfață:
54

Figura 7.5: Interfața de autentificare în intranet
Mai departe, utilizatorul va trebui sa își introducă Email-ul instituțional
și parola în câmpurile aferente, după care va trebui să apese butonul ”Intra
in cont”. Acest lucra va finaliza operațiade autentificare.
După autentificare, în partea de sus a ecranului va apărea următorul
meniu:
Figura 7.6: Meniu opțiuni intranet
Dacă se navighează către secțiunea ”ACASA” și se selectează această
opțiune din meniu, vor fi afișate următoarele pagini în funcție de rolul utili-
zatorului autentificat:
• pentru un utilizator care are rolul de prestator curs se va afișa opțiunea
care îi va permite navigarea către pagina de vizualizare a centralizato-
rului de materii pentru cuplaje.
• pentru utilizatorii care au rolul de responsabil posturi sau de coordo-
nator catedră se va afișa opțiunea care îi va permite navigarea către
pagina de vizualizare a centralizatorului de materii pentru posturi.
• pentru utilizatorul care are rolul de a aproba statul de funcțiune din
partea rectoratului se va afișa opțiunea de state de funcțiuni.
55

În cazul în care nu este prezentă una sau mai multe dintre opțiunile enu-
merate mai sus reiese că utilizatorul autentificat nu a primit accesul necesar
către modulul respectiv din partea administratorului sistemului. Dacă deține
rolul aferent modulului va trebui să facă o cerere către administrator, care
va avea sarcina de a îi acorda permisiunile necesare.
În funcție de rolul asignat utilizatorului modul de utilizare al aplicației este
următorul:
7.2.2 Prestatorul de curs
Acest utilizator are dreptul de a accesa pagina de centralizare a materiilor
pentru cuplaje care arată în felul următor:
Figura 7.7: Centralizator materii pentru cuplaje
În partea de sus a ecranului este o opțiune de alegere a anului universitar
pentru care utilizatorul dorește să vizualizeze centralizatorul.
Întabelulprezentînpaginăsepotvizualizainformațiigeneralereferitoare
la toate materiile (precum denumirea materiei, semestrul, catedrele coordo-
natoare și prestatoare, numărul de ore de curs, seminar, laborator și proiect
și informații privind materia principală la care este cuplată o altă materie)
care aparțin unui plan de învățământ aprobat din anul universitar selectat
și care au aceeași catedră coordonatoare sau prestatoare cu catedra căreia
aparține utilizatorul autentificat. De asemenea, datele se pot sorta crescător
sau descrescător în funcție de preferința utilizatorului după cum urmează:
56

pentru a sorta crescător datele se va face click pe câmpul din cadrul capului
de tabel după care se dorește sortarea datelor, pentru a sorta descrescător se
va apăsa dublu click.
Dacă o materie nu se găsește în acest tabel poate însemna că nu are de-
partamentul aferent compatibil sau planul de învățământ din care face parte
nu a primit toate aprobările necesare.
Butonul albastru din partea de sus a paginii ne va redirecționa către pa-
gina în care se pot realiza cuplaje între materii.
Figura 7.8: Pagină web pentru gestionarea cuplajelor
În această pagină se vor găsi exact aceleași materii ca și în centralizator.
Pentru a crea un cuplaj trebuie să selectăm materia care ne dorim să fie
secundară și să executăm o operație de drag and drop peste materia care ne
dorim să fie principală.
Nu se pot realiza cuplajele în cazurile în care:
• Materiile alese urmează să fie predate în semestre diferite.
• Forma de învățământ diferă.
57

• Departamentul coordonator de curs al materiei principale nu este ace-
lași cu cel atribuit utilizatorului autentificat.
În cazul în care încercăm să creăm un cuplaj care nu este valid vom primi,
în colțul din dreapta al paginii, un mesaj de eroare similar cu:
Figura 7.9: Eroare la crearea cuplajelor
După crearea unui cuplaj, materiile secundare se vor poziționa în tabel
sub cea principală:
Figura 7.10: Cuplaj
Numărul de ore și de formații va apărea doar în dreptul materiei prin-
cipale și poate fi modificat de către utilizator, însă acesta se va actualiza în
baza de date doar după ce utilizatorul va apăsa butonul albastru de actuali-
zare din dreptul materiei.
Materiile secundare au în stânga lor un ”x” roșu care atunci când este
apăsat permite înlăturarea materiei respective din cuplaj.
În cazurile în care acțiunea de drag and drop nu este posibilă, utilizatorul
poate folosi butonul verde în formă de ”+” din stânga materiei. Acesta
trebuie să aleagă materia principală și să apese butonul verde din stânga ei.
O dată apăsat, butonul va deschide o fereastră care conține materiile valabile
pentru cuplaj, iar utilizatorul va trebui să bifeze materiile secundare care vor
face parte din cuplaj.
58

Figura 7.11: Selectarea materiilor secundare pentru cuplaj
Cuplajul se va crea doar în momentul în care utilizatorul apasă butonul
”Confirmă” albastru din partea dreaptă a ecranului. Dacă dorim să anulăm
opțiunea de creare a cuplajului, tot ce trebuie făcut este să apăsăm butonul
în formă de ”x” din partea superioară a paginii sau să dăm click cu mouse-ul
în afara chenarului reprezentat de pagină.
7.2.3 Responsabilul de posturi/coordonatorul de cate-
dră
Dupărealizarea cuplajelor întrematerii, acestutilizatorul vaaveaacces la
paginadecentralizareamateriilorpentruposturi, carearatăînfelulurmător:
Figura 7.12: Centralizator materii pentru posturi
În partea de sus a ecranului este o opțiune de alegere a anului universi-
tarpentru care utilizatorul dorește să vizualizeze centralizatorul.
În tabelul prezent în pagină se pot vizualiza denumirea materiilor împre-
ună cu numărul de ore rămase libere după crearea de posturi care o includ.
În această pagină se pot vedea doar materiile principale dintr-un cuplaj sau
cele care nu au fost cuplate deloc atâta timp cât au ore rămase libere. Datele
59

din tabel se pot sorta asemenea modelului prezentat în pagina centralizato-
rului pentru cuplaje.
Butonul albastru din partea de sus a paginii ne va redirecționa către pa-
gina în care se pot gestiona posturile aferente cadrelor didactice.
Figura 7.13: Pagină principală post
În această pagină se pot observa toate posturile create pe anul curent. În
partea superioară a fiecărei înregistrări din tabel se află informațiile generale
despre post (numărul criteriu, denumirea postului, titlul postului, numărul
de ore convenționale și un câmp care ne arată dacă postul respectiv este de
titular sau suplinitor). Sub aceste informații în partea stângă se află pro-
fesorii aferenți fiecărui post, iar în dreapta lor materiile pe care aceștia le
predau împreună cu informațiile despre numărul de ore predate de profesor
și procentul aferent acestuia din numărul total de ore disponibile materiei.
Pentru a crea un post nou trebuie să apăsăm butonul albastru ”Creează
post” din partea superioară a paginii. După ce am executat această operație
va apărea următoarea pagină:
60

Figura 7.14: Creare post pas 1
Primul câmp reprezintă numărul criteriu al postului, este generat auto-
mat, dar poate fi schimbat de utilizator în funcție de preferințe, singurele
numere care nu pot fi alese sunt cele care există deja în cadrul altor posturi.
Al doilea câmp reprezintă gradul didactic aferent postului. Acesta este ales
dintr-o listă care conține toate gradele didactice recunoscute de Universitate.
Al treilea câmp reprezintă titlul științific aferent postului, care, de asemenea,
este ales dintr-o listă cu toate titlurile științifice recunoscute de Universitate.
Ultimul câmp reprezintă o bifă care semnifică dacă postul va fi de titular sau
nu. În cazul în care se debifează postul va fi considerat de suplinitor.
În cazul în care nu sunt completate toate câmpurile sau numărul criteriu
ales aparține altui post deja existent vom fi notificați printr-un mesaj roșu
de eroare.
Pentru a trece la pasul următor de creare a unui post vom apăsa butonul
albastru ”Adaugă profesori și materii”. În cazul în care ne răzgândim și nu
dorim să continuăm vom da click oriunde înafara chenarului paginii sau pe
iconița ”x” din colț.
Pagina în care se adaugă profesorii și materiile aferente unui post este urmă-
toarea:
Figura 7.15: Creare post pas 2
În partea superioară a paginii se află informațiile alese la pasul 1, iar
în mijloc se află un dropdown unde se poate căuta și alege un profesor di
cadrul catedrei de care aparține utilizatorul autentificat. După ce este ales
61

un profesor, acesta poate fi introdus în cadrul postului cu ajutorul butonului
”+” verde din dreapta. Nu se poate introduce același profesor de mai multe
ori încadrul aceluiași post, iar pentru un post de titular se poate introduce
doar un singur profesor. În cazul în care nu respectăm acest lucru vom fi
înștiințați printr-un mesaj de eroare roșu.
După atribuirea profesorilor va apărea câte un dropdown în dreptul fiecăruia,
de unde se pot alege materiile fiecărui profesor, apoi se va completa numărul
de ore atribuite profesorului pentru materia respectivă.
Figura 7.16: Atribuirea materiilor către un profesor
În cazul în care o materie a fost alocată din greșeală, aceasta poate fi
eliminată printr-un click pe iconița roșie în formă de ”x” din stânga materiei.
Atenție: fiecare materie care a fost asignată unui profesor trebuie să aibe
mai mult de 0 ore atribuite și nu are voie să depășească maximul indicat în
partea dreaptă a fiecărei căsuțe pentru atribuire ore. În caz contrar, vom fi
notificați print-un mesaj roșu de eroare.
Pentru a termina crearea unui post trebuie să apăsăm pe butonul albastru
”Confirmă” din colțul ferestrei.
Posturiledejacreateșiprofesoriișimateriileatribuitesepotștergedinpagina
principalăcuajutorulbutonuluiroșuînformăde”x”dinparteastângă. Dacă
va fi ștearsă ultima materie a unui profesor, acesta va fi șters și el și dacă va
fi șters ultimul profesor din cadrul unui post va fi șters și postul.
Pentru a actualiza un posteste nevoie să dăm click pe butonul verde în formă
de ”+” de lângă numărul orelor convenționale al postului respectiv. Se va
deschide o pagină asemenea celei de creare de la pasul 2 dar cu restricția de
a șterge sau modifica materiile și profesorii adăugați în prealabil, singurele
opțiuni de actualizare fiind: adăugarea de profesori și materii noi.
62

Figura 7.17: Pagină de actualizare post
7.2.4 Aprobarea statului de funcțiune din partea rec-
toratului
Acest utilizator va avea acces la pagina care permite aprobarea sau res-
pingerea statelor de funcțiuni.
În prima parte a paginii vom alege anul universitar și departamentul pe care
dorim să lucrăm. Sub aceste câmpuri se va afla o bară de încărcare, care nu
va dispărea decât în momentul în care snt alese ambele opțiuni. (figura 7.18)
Figura 7.18: Alegere an universitar și departament
Dupăcefacemacestlucrusevorîncărcaposturileaferentedepartamentu-
lui ales, pentru anul universitar selectat împreună cu două butoane de unde
putem aproba sau respinge un stat de funcțiune și un text care ne indică
statusul statului de funcțiune ales. (figura 7.2.4)
63

Figura 7.19: Aprobare/Respingere stat de funcțiune
În momentul în care aprobăm sau respingem un stat de funcțiune va
apărea fereastra corespunzătoare figurii 7.2.4unde putem scrie observații
sau sugestii, iar apoi putem apăsa pe butonul Confirmă, care va finaliza
operațiunea și va actualiza statusul statului de funcțiune.
Figura 7.20: Comentare și finalizare acțiune
64

Capitolul 8
Posibilități de extindere
Pe baza aplicației de gestiune a statelor de funcțiuni, care extinde la
rândul ei aplicația de gestiune a planurilor de învățământ se pot dezvolta
soluții care să informatizeze procese de lucru ale Universității, cât și serii
de rapoarte necesare ce includ informații cuprinse în cadrul cuplajelor sau
posturilor cadrelor didactice.
Exemple de asemenea extinderi ar fi:
• Realizarea unei aplicații de informatizare a orarului bazat pe o bază de
date SQL, nu pe fișiere Excel. Acest lucru ar face digitalizarea orarelor
mai eficientă și distrubirea lor către studenți și cadre didactice mai
ușoară.
• Crearea de rapoarte referitoare la gradul de ocupare a unui cadru di-
dactic.
• Crearea de rapoarte referitoare la costurile necesare pentru cadrele di-
dactice.
• Dacă se combină informațiile privind cuplajele dintre materii și numă-
rul de grupe și studenți corespunzători grupelor, se poate afla numărul
maxim de locuri necesare într-o sală pentru desfășurarea orelor.
65

Bibliografie
[1] Hassan Djirdeh, Fullstack Vue: The Complete Guide to Vue.js, Create-
Space Independent Publishing Platform, Apr 2018
[2] Callum Macrae, Vue.js: Up and Running: Building Accessible and Per-
formant Web Apps, O’Reilly Media, Mar 2018
[3] Tzik Ben-Gan, T-SQL Fundamentals , Microsoft Press; 3 edition August
13, 2016
[4] Dusan Petkovic, Microsoft SQL Server 2019: A Beginner’s Guide,
McGraw-Hill Education; 7 edition, 02.01.2020
[5] WalterShields,SQLQuickStartGuide: TheSimplifiedBeginner’sGuide
to Managing, Analyzing, and Manipulating Data With SQL, ClydeBank
Media LLC; 1 edition 18.11.2019
[6] Jon P Smith, Entity Framework Core in Action, Manning Publications;
1st edition August 4, 2018
[7] John Paul Mueller, Microsoft ADO.NET Entity Framework Step by
Step, Microsoft Press; 1 edition August 15, 2013
[8] Mitchel Sellers, Professional DotNetNuke Module Programming, Wrox;
1 edition Feb 24, 2009
[9] John K. Murphy, DotNetNuke 5.4 Cookbook, Packt Publishing Sept 3,
2010
[10] ***, Relational Data Model in DBMS: Concepts, Constraints, Example,
https://www.guru99.com/relational-data-model-dbms.html.
[11] ***,WhatisEntityFramework?,https://www.entityframeworktutorial.net/what-
is-entityframework.aspx.
66

[12] ***, Introduction to Entity Framework,
https://www.dotnettricks.com/learn/entityframework/introduction-to-
entity-framework.
[13] José A. Blakeley, David Campbell, S. Muralidhar, Anil Nori, The
ADO.NET Entity Framework: Making the Conceptual Level Real
[14] ***, Overview of Vue.js, https://v1.vuejs.org/guide/overview.html.
[15] ***, What is Vue.js and What are its Advantages,
https://hackernoon.com/what-is-vue-js-and-what-are-its-advantages-
4071b7c7993d.
[16] Rouse, M.: What is DNN Platform (DotNetNuke)? – Defini-
tion from WhatIs.com, https://whatis.techtarget.com/definition/DNN-
DotNetNuke.
[17] DNN Advantages Daniel Domer DotNetNuke Development: What
is DotNetNuke?, http://www.13below.com/blog/post/1473/what-is-
dotnetnuke.
[18] Software Architecture in Practice, Third Edition by Len Bass, Paul
Clements, Rick Kazman
[19] Software Architecture Patterns, by Mark Richards Feb. 2015
[20] C.J. Date, The Database Relational Model: A Retrospective Review
and Analysis, Pearson; 1 edition 15.05.2000
[21] C.J. Date, SQL and Relational Theory: How to Write Accurate SQL
Code, O’Reilly Media; 3 edition 16.11.2015
67