Proiect Licenta Acs Georgescu P Bogdan Gabriel 88041 [625603]

UNIVERSITATEA POLITEHNICA BUCUREȘTI
FACULTATEA DE AUTOMATICĂ ȘI CALCULATOARE
DEPARTAMENTUL CALCULATOARE

PROIECT DE DIPLOMĂ

Aplicație integrată pentru salarizare
Versiunea 2019

Georgescu Bogdan -Gabriel

Coordonator științific:
Conf. dr. ing. Boicea Alexandru

BUCUREȘTI
2019

CUPRINS
1 Sinopsis ………………………….. ………………………….. ………………………….. ………………………….. ….. 4
2 Abstract ………………………….. ………………………….. ………………………….. ………………………….. ….. 4
3 Mulțum iri ………………………….. ………………………….. ………………………….. ………………………….. .. 4
1 Introducere ………………………….. ………………………….. ………………………….. ………………………….. 5
1.1 Context ………………………….. ………………………….. ………………………….. ………………………… 5
1.2 Problema ………………………….. ………………………….. ………………………….. ……………………… 5
1.3 Obiective ………………………….. ………………………….. ………………………….. ………………………. 5
1.4 Structura lucrării ………………………….. ………………………….. ………………………….. ……………. 5
2 Analiza și specificarea cerințelor ………………………….. ………………………….. ………………………….. 6
2.1 Specificații generale versiunea 1.0 (Alpha) ………………………….. ………………………….. ……… 6
2.2 Specificații generale versiunea 1.1 (Alpha) ………………………….. ………………………….. ……… 6
2.3 Specificații generale versiunea 2.0 (Closed Beta) ………………………….. ………………………….. 7
2.4 Specificații generale versiunea 2.1 (Open Beta) ………………………….. ………………………….. .. 8
2.5 Specific ații generale versiunea 2.2 (Open Beta) ………………………….. ………………………….. .. 8
2.6 Versiunea 3.0 (Release) ………………………….. ………………………….. ………………………….. …… 8
3 Studiu de piață / Abordări existente ………………………….. ………………………….. ……………………… 9
3.1 Produse similare ………………………….. ………………………….. ………………………….. ……………. 9
3.2 Tehnologii folosite ………………………….. ………………………….. ………………………….. ………… 11
3.2.1 Desktop vs. Web ………………………….. ………………………….. ………………………….. ……. 11
3.2.2 .Net Framework vs. Java vs. Electron ………………………….. ………………………….. …….. 12
3.2.3 Prezentare WPF ………………………….. ………………………….. ………………………….. …….. 15
3.2.4 Entity Framework 6 ………………………….. ………………………….. ………………………….. .. 16
3.2.5 CEF Sharp ………………………….. ………………………….. ………………………….. …………….. 16
4 Soluția propusă ………………………….. ………………………….. ………………………….. …………………… 17
4.1 Prezentarea aplicației ………………………….. ………………………….. ………………………….. ……. 17
4.1.1 Vizualizarea salariaților și rapoartelor ………………………….. ………………………….. ……. 18
4.1.2 Informații salariat ………………………….. ………………………….. ………………………….. ….. 18
4.1.3 Întreruperi de muncă ………………………….. ………………………….. ………………………….. 20
4.1.4 Deduceri personale, D112 și Ordine de Plată ………………………….. ………………………. 20
4.2 Organizarea componentelor aplicației ………………………….. ………………………….. ………….. 22
4.2.1 Plugin -uri ………………………….. ………………………….. ………………………….. ……………… 22

4.2.2 Shell ………………………….. ………………………….. ………………………….. ……………………. 23
4.2.3 Core ………………………….. ………………………….. ………………………….. ……………………. 23
4.3 Arhitectura componentelor ………………………….. ………………………….. ………………………… 23
4.3.1 Arhitectură Core ………………………….. ………………………….. ………………………….. ……. 24
4.3.2 Arhitectură Shell ………………………….. ………………………….. ………………………….. ……. 26
4.3.3 Arhitectură Plugin.Sal ………………………….. ………………………….. …………………………. 26
4.3.4 Arhitectură ReportViewer ………………………….. ………………………….. ……………………. 27
4.3.5 Alte plugin -uri………………………….. ………………………….. ………………………….. ……….. 27
4.4 Arhitectura Bazei de date ………………………….. ………………………….. ………………………….. . 28
4.4.1 Tabele Date Salariați ………………………….. ………………………….. ………………………….. . 28
4.4.2 Tabele Date Unitate ………………………….. ………………………….. ………………………….. .. 30
4.4.3 Tabele Date Configurare ………………………….. ………………………….. ……………………… 31
5 Detalii de implementare ………………………….. ………………………….. ………………………….. ………. 32
5.1 Interpretorul de formule ………………………….. ………………………….. ………………………….. .. 32
5.1.1 Transformare formule ………………………….. ………………………….. ………………………… 32
5.1.2 Interpretare formule ………………………….. ………………………….. ………………………….. 33
5.2 Generatorul de rapoarte ………………………….. ………………………….. ………………………….. .. 34
5.3 Vizual izatorul de rapoarte ………………………….. ………………………….. ………………………….. 35
6 Studiu de caz / Evaluarea rezultatelor ………………………….. ………………………….. …………………. 36
6.1 Teste unitare ………………………….. ………………………….. ………………………….. ……………….. 36
6.2 Teste de integrare ………………………….. ………………………….. ………………………….. ………… 37
6.3 Testare manuală ………………………….. ………………………….. ………………………….. ………….. 37
6.4 Deployment ………………………….. ………………………….. ………………………….. ………………… 38
6.5 Validarea soluției ………………………….. ………………………….. ………………………….. …………. 38
6.6 Rezult ate ………………………….. ………………………….. ………………………….. …………………….. 39
7 Concluzii ………………………….. ………………………….. ………………………….. ………………………….. .. 41
7.1 Dezvoltări ulterio are ………………………….. ………………………….. ………………………….. …….. 41
8 Bibliografie ………………………….. ………………………….. ………………………….. ………………………… 42
9 Anexe ………………………….. ………………………….. ………………………….. ………………………….. …… 43
9.1 Bază de date ………………………….. ………………………….. ………………………….. ……………….. 43
9.2 Interpretor formule ………………………….. ………………………….. ………………………….. ………. 44
9.3 Generare rapoarte ………………………….. ………………………….. ………………………….. ……….. 46

1 SINOPSIS
Scopul acestei lucrări este pr ezentarea unei aplicații de salarizare optimizată pentru a fi
utilizată de către instituțiile publice. Lucrarea începe prin prezentarea motivației de a dezvolta
o astfel de aplicație, problemele identificate la produsele deja existente și strategia de
rezo lvare a acestora. În continuare se prezintă o analiză a cerințelor software și un studiu de
piață, ambele realizate in cremental pentru a putea avea un produs funcțional în cel mai scurt
timp. Următoarele subiecte prezentate oferă o vedere de ansamblu asupra soluției propuse
și a detaliilor de implementare, iar în final este realizată o evaluare a rezultatelor urmată de
prezentarea concluziilor și a dezvoltărilor ulterioare .

2 ABSTRACT
The purpose of this paper is to present a salary payment application, optimized for the public
domain. The paper begins with the presentation of my motivation to develop such an
application , the most important problems with the currently available products and the
strategy used to solve the identified pr oblems and offer a better solution. Next, I present a
software requirements analysis and the market research, both done in an incremental way in
order to be able to present a minimum viable product as soon as possible. Going further, I am
offering an overv iew of the proposed solution and implementation details. Finally, the results
of the development process are presented alongside the conclusi ons of the whole project and
future improvements .

3 MULȚUMIRI
Aș dori să încep prin a îi mulțumi domnului profesor coordonator Alexandru Boicea , care m -a
ghidat de -a lungul redactării acestei lucrări.
De asemenea, le mulțumesc doamnei contabil Popa George ta și domnului contabil Radu
George de la primăriile Ungheni, Argeș , respectiv Balaci, Teleorman și doamnei expert
Contabil Bîrlădeanu Cristina , de la Cabinetul de Contabilitate Bîrlădeanu , Pitești, Argeș pentru
toate informațiile și consultanța pe care mi le-au oferit , dar și pentru timpul alocat testării
acestui produs .

1 INTRODUCERE
1.1 Context
Aplicațiile software au ro lul de a îmbunătăți viața persoanelor care le folosesc prin diminuarea
efortului necesar pentru a rezolva diferite probleme. Cu toate astea, o aplicație care nu ține
cont de toate nevoile utilizatorului poate crește cantitatea necesară de efort.
Din acest motiv am ales să dezvolt un set de aplicații, orientate domeniului public, care să
aducă soluții optime și eficiente pentru toate nevoile util izatorilor. Aplicația de salarizare
(„SAL”) face parte din acest set de aplicații, fiind ultima adăugare la pachet ul „ContrAll ”.

1.2 Problema
La momentul curent, nu există pe piață o soluție completă în ceea ce privește salarizarea în
domeniul public. Nici o aplicație actuală nu oferă integrări specializate compatibile cu toate
aplicațiile puse la dispoziție de Guvernul României (generarea XML pentru D112, generare
automată a ordinelor de plată, integrare cu ReviSal ).
O alta problema importantă a soluțiilor e xistente este reprezentată de imposibilit atea
modificărilor formulelor de calcul folosite de aplicație în urma sch imbărilor legislative.
Majoritatea soluțiilor de pe piață nu oferă suport pentru acest lucru, iar celelalte oferă suport
minimalist (schimbare a valorii salariului minim pe economie sau alte schimbări de acest gen ).

1.3 Obiective
Acest proiect are ca obiectiv principal îmbunătățirea experienței utilizatorului și eficientizarea
salarizării pentru a reduce volumul de muncă. Pentru îndeplinirea acestui obiectiv, voi încerca
să rezolv cele două probleme identificate mai sus, ținând cont și de cerințele clienților î n
timpul dezvoltării.
Pentru aceasta lucrare am ca obiectiv să dezvolt o aplicație de salarizare complet funcțională
care să suporte modificăr i ale formulelor de calcul direct din aplicație, să aibă integrare atât
cu Declarația 112 cât și cu generarea de O P-uri și care să suporte generarea de rapoarte, atât
predefinite cât și personalizabile.

1.4 Structura lucrării
În Capitolul 2 sunt prezentate to ate specificațiile aplicației, împărțite pe etape de dezvoltare
(versiuni), dar și modificările aduse de la o vers iune la alta. În Capitolul 3 este făcută o
comparație cu celelalte produse de pe piață, ce oferă acestea și ce aduce în plus soluția
propusă. Capitolul 4 vine cu completări tehnice, oferind o privire de ansamblu asupra

arhitecturii aplicației și a tehnolog iei folosite pentru dezvoltarea acesteia. În continuare, în
Capitolul 5, se regăsesc informații specifice referitoare la implementarea soluție i propuse.
Capitolul 6 prezintă studiul de caz și evaluarea rezultatelor procesului de dezvoltare, iar
ultimul cap itol prezintă concluziile.

2 ANALIZA ȘI SPECIFICA REA CERINȚELOR
Pentru specificarea cerințelor am colaborat cu o firmă de contabilitate, person al și salarizare
și cu doi potențiali clienți. Am ales să abordez o dezvoltare incrementală având în vedere
crearea unui MVP cât mai rapid. După ce am reușit să prezint un MVP, cei doi clienți au început
să folosească aplicația în paralel cu altă aplicație pe care deja o utilizau, pentru a identifica
eventuale buguri sau funcționalități lips ă. Această abordare împreună cu implicarea
colaboratorilor au redus timpul de dezvoltare a aplicației la doar patru luni și a ajutat la
dezvoltarea unui produs fiabil ca re concurează cu cele mai cunoscute opțiuni de pe piață .

2.1 Specificații generale versiunea 1.0 (Alpha)
Aplicația trebuie să aibă funcționalitate de bază pentru calculul salariilor, respectând legislația
în vigoare, să ofere o interfață prietenoasă cu utiliz atorul și suport pentru generarea de
rapoarte obligatorii (state de plată, rapoarte recapitulative).
Funcționalități de bază:
– Adăugare/Ștergere/Editare a salariaților unității ;
– Schimbarea parametrilor salariali de bază (salariu minim pe economie, cuantum
impozit, cuantum CAS si CASS etc.);
– Schimbarea lunii cu cal cul automat al zilelor lucrătoare;
– Calcul automat al salariului net și al dărilor la stat, pe baza salariului brut și al
numărului de zile/ore lucrate în lună;
– Vizualizarea parametrilor calculați (s alariul net și dările la stat);
– Generarea de rapoarte.

2.2 Specificații generale versiunea 1.1 (Alpha)
După finalizarea testelor pe versiunea de bază a aplicației ( 1.0) am început dezvoltarea de
funcționalități avansate specifice calculului salarial. Printre acestea se numără: suport pentru
întreruperi (concedii, ab sențe nemotivate, absențe motivate și concedii medicale), suport
pentru sporuri și rețineri predefinite, îmbunătățiri ale interfeței grafice.
Funcționalități noi:

– Suport pentru întreruperile de munc ă;
– Adăugare/Ștergere/Editare pentru concedii medicale și p relungirea acestora pe bază
de certificat medical de prelungire;
– Suport pentru sporuri și rețineri predefinite și integrarea acestora în sistemul de calcul
salarial;
– Suport pentru sporuri impozabile și neimpozabile;
– Suport pentru zilele de liber național.
Modificări necesare pentru a integra noile funcționalități:
– Reorganizarea interfeței grafice pentru a permite integrarea noilor funcționalități;
– Modificarea sistemului de calcul salarial pentru a fu ncționa cu întreruperile de muncă
și sporurile/reținerile;
– Modificarea sistemului care calculează numărul de zile lucrătoare din lună, pentru a
ține cont de zilele libere la nivel național.

2.3 Specificații generale versiune a 2.0 (Closed Beta)
După finalizare a testelor pent ru versiunea precedenta ( 1.1), având o aplicație funcțională de
salarizare, aceasta a trecut în Closed Beta fiind testata de o firmă de contabilitate și personal
cu care am colaborat pentru a defini cerințele aplicației. Astfel am început ad ăugarea de
funcționalități c are să îmbunătățească experiența utilizatorilor și fiabilitatea aplicației. După
implementarea funcționalităților descrise mai jos am avut primul MVP , aplicația fiind
prezentată primilor clienți.
Funcționalități noi:
– Organizare pe subdomenii și profile a a ngajaților;
– Panou de administrare (Admin Panel);
– Selectare subdomeniilor si profilelor utilizate;
– Denumirea bazei de date utilizate;
– Modificarea formulelor de calcul salarial;
– Adăugare/Editare/Ștergere pentru sporuri și rețineri ;
– Alte setări administrative .
– Suport de bază pentru generarea XML -ului D112 (fără suport pentru concedii
medicale).
Modificări necesare pentru a integra noile funcționalități:
– Modificarea sistemului de calcul salarial pentru a funcționa cu interpretorul de
formule;
– Reorganizarea inte rfeței grafice pentru a integra noile funcționalități.

2.4 Specificații generale versiunea 2.1 (Open Beta)
Aplicația intră în Open Beta și începe să fie utilizată de doi clienți care o folosesc în paralel cu
o altă aplicație cu fun cții similare, pentru testar e.
Pentru această versiune am adăugat următoarele funcționalități:
– Suport complet pentru generarea XML -ului D112;
– Suport pentru generarea manuală de Ordine de Plată (funcționalitate identică cu
aplicația OP/FV pusă la dispoziți e de ANAF)
În urma feedback -ului de la clienți am adăugat:
– Suport pentru operatori logici și operații de tipul if -then -else în interpretorul d e
formule;
– Suport conturi IBAN pentru rețineri;
– Panoul de informații, în care sunt disponibile toate rezultatele calcului salarial , fiind o
extindere a afișajului de bază ;
– Rapoarte noi (stat salarii pentru plata în cont, situația concediilor de odihnă)
– Suport pentru fracție de normă și plata contribuțiilor de către angajator , în
conformitate cu OUG 4/2017 și completă rile ulterio are din OUG 3/2018;

2.5 Specificații generale versiunea 2.2 (Open Beta)
Aplicația începe să fie din ce în ce mai utilizată de către clienți oferind funcționalitate completă
în ceea ce privește calculul salarial și generarea documentelor necesare.
În continuare, adaug funcționalități care să îmbunătățească experiența utilizatorilor și să
mărească securitatea și fia bilitatea aceste ia. După rezolvarea tuturor bug -urilor și micilor
probleme de compatibilitate, aplicația intră in producție (versiunea 3. 0).
Funcționalități adăugate:
– Sistem de back -up si restore în cloud. Această funcționalitate asigură, în primul rând,
consistența datel or clienților, iar în al doilea rând, le permite consultanților să
acceseze bazele de date ale clienților care din diferi te motive au decis să își
managerieze singuri serverul de baze de date;
– Creare de rapoarte personalizate din interfața aplicației.

2.6 Versiunea 3.0 (Release)
Prima versiune de producție a aplicației. A ceasta începe să fie utilizată în mod curent de către
clienți. Se mai adaugă funcționalități în funcție de nevoile și cerințele clienților. Nu mai apar
schimbări majore, aplicația funcționând în parametri.

Lucrez la optimizări de viteză (reducând numărul de query -uri și aplicând un sistem de lazy –
loading) și îmb unătățiri ale interfeței grafice.

3 STUDIU DE PIAȚĂ / AB ORDĂRI EXISTENTE
În acest capitol voi prezenta mai întâi produsele deja existent e pe piață cu plusuri și minusuri
față de soluția propusă, iar în final voi face o scurtă prezentare a tehnologiilor folo site și o
comparație între tehnologiile alternative.

3.1 Produse similare
Pe piață există o mulțime de aplicații de salarizare pentru uz g eneral, dar un număr destul de
mic de aplicații care să ofere toate funcționalitățile de care are nevoie o instituție pub lică.
Cele mai importante produse similare de pe piață sunt APLxPERT – Salarii produs de SOBIS,
ReSum produs de Indeco Soft și ALLinALL Salarizare produs de Mondosoft. Toate cele trei
aplicații oferă aceleași funcționalități pentru calculul salarial ca și soluția propusă. Diferențele
încep să apară atunci când se vorbește despre cât de prietenoase cu utilizatorul și intuitive
sunt aceste aplicații , dar și când se pune problema unor funcționalități complexe precum
generarea ordinelor de plată, controlul form ulelor de calcul sau personalizarea rapoartelor.
În primul rând, toate cele trei aplicații sunt mai aproape de o interfață pent ru lucrul cu bazele
de date decât niște aplicații dedicate de salarizare. Majoritatea interfețelor din aceste aplicații
au aspect tabelar greu de urmărit și utilizat (Imaginea 1) în comparație cu interfețele grafice
din soluția propusă, care au un aspect c urat, intuitiv și ușor de urmărit. Acest lucru reprezintă
avantajul principal atunci când vine vorba de creșterea numărului de cl ienți. De asemenea,
împreună cu interfața grafică prietenoasă, fiabilitatea și consumul redus de resurse hardware
fac soluția p ropusă să fie peste nivelul concurenței.

Imagine 1 Interfață date angajat din APLxPERT – Salarii1

În al doilea rând, tehnologiile învechite folosite în aceste aplicații pot cauza probleme de
compatibilitate sau chiar vulnerabil ități de securitate, prevenirea celor două fiind foarte
dificil de realizat pe Framework -uri pentru care nu se mai oferă suport.
Astfel de probleme, în special cele de securitate pot permite atacatorilor să corupă datele
sau să le preia fără prea mult efort. Este, în opinia mea, datoria dezvoltatorilor să nu
permită acest lucru.
Atât problemele de securitate, cât și cele de compatib ilitate sunt adresate de aplicația
prezentată prin fol osirea celor mai noi versiuni de Framework -uri și utilizarea celor ma i noi
tehnologii disponibile .
O altă diferență importantă este data faptul ca în afară de aplicația produsa de Mondosoft,
nici una di n cele prezentate nu are suport pentru modificarea formulelor de calcul salarial,
iar sistemul de formu le din aplicația de la Mondosoft este foarte dificil de utilizat datorita
sintaxei foarte încărcată. Ca și comparație în Tabelul 1 se pot vedea câteva fo rmule atât din
aplicația de la Mondosoft cât și din aplicația prezentată , unde se poate observa o diferență
clară între sim plitatea formulelor folosite în soluția propusă și complexitatea celor din
aplicația produsă de Mondosoft.

1 https://it.sobis.ro/wp -content/uploads/2018/08/pliant -Salari i.pdf

Parametru
salarial Mon dosoft Salarii ContrAll Sal
Salariu brut QX("SNOO")+QX("SBAS")+QX("SFDS")+
QX("CDOD")+QX("STEL")+QX("SCGR")+
QX("SDIS")+QX ("SURB")+QX("SPO2")+
QX("SPO3")+PS("RT05")+PS("SM01")+
QX("INDC")+QX("CFP1")+QX("CFP2")+
QX("SSV3")+QX("SSV2")+QX("SREL")+
PS("SM12") +PS("SM06")+PS("SM05")+PS("SM09") SEFL + SPOR + INCO + IHRA
+ H
Venit impozabil IF(QX("VBRT") -QX("CCAS") -QX("CSAN") -QX("IMAT") -QX("CSOM") –
QX("SID1") -QX("SID2") -QX("DPER")>0,QX("VBRT") -QX("CCAS") –
QX("CSAN") -QX("IMAT") -QX("CSOM") -QX("SID1") -QX("SID2") –
QX("D PER") -PS("RT11"),0) VNET + TVAC + TMAS +
TCAD – DEDU – SIN1 – SIN2 –
SIN3 – PPRV
Impozit calculat IF(PS("FIMP")*1==1, 0, RT(QX("VIMP")*0.10))+PS("SM07") VIMP / 10 * AREIMP
Tabel 1 Comparație formule de calcul2

Un alt plus important al soluției propuse e ste generarea de Ordine de Plată, funcționa litate
disponibilă doar în soluția oferită de SOBIS. Celelalte aplicații neavând nici măcar un suport
minimalist pentru acest lucru. Acest aspect este foarte important deoarece, generarea
automată a ordinelor de p lată este mult mai rapidă decât crearea manuala a acestora cu
aplicați a de la ANAF, iar o unitate cu 50 de angajați poate depăși cu ușurință 300 de ordine de
plată lunar.
Ca și plus al produselor deja existente merită menționată integrarea cu aplicațiile l or de
contabilitate pentru transferarea automată a notelor contabile. Trebuie amintit totuși că
acest lucru reprezintă un plus doar atâta timp cât încă nu am terminat de dezvoltat o soluție
completă pentru contabilitate (ContrAll Conta).
În concluzie, se p oate observa că, deși fiecare dintre aceste aplicații are câteva
funcționalități care coincid cu cele din soluția propusă, nici una dintre ele nu oferă
funcționalitatea completă de care instituțiile publice au nevoie .

3.2 Tehnologii folosite
În continuare voi prezenta tehnologiile folosite pentru dezvoltarea aplicației și le voi compara
cu alte tehnologii similare. De asemenea, voi prezenta motivele principale pentru care am
ales să dezvolt o aplicație desktop și nu o aplicație web.
3.2.1 Desktop vs. Web
Când vine v orba de aplicații desktop și aplicații web se poate observa cu uș urință ca ambele
categorii au avantaje și dezavantaje, unele mai importante, altele mai puțin importante. Din

2 Formulele prezentate sunt extrase din cele două aplicații pe care se face comparația și reprezintă formule
corecte utilizate în mod curent pentru calculul salarial.

acest motiv, pentru ca un produs să fie fiabil și să aibă succes pe piață, trebui e aleasă categoria
care se potrivește cel mai bine viitorilor uti lizatori.
Principalul avantaj al unei aplicații desktop este că rulează independent pe mașina fizică a
utilizatorului, și nu necesită o conexiune permanentă la internet permițând funcționarea într-
un mediu offline. Același lucru nu se poate spune și despre o aplicație Web, care nu poate
funcționa fără o conexiune la internet și chiar dacă o conexiune există, performanța aplicației
depinde de lățimea de bandă disponibilă. Funcționarea offline e ste foarte importantă p entru
că o mare parte din potențialii clie nți ai aplicației sunt din zona rurală unde există probleme
cu conexiunea la internet.
Un alt avantaj al unei aplicații desktop dedicate este accesul la mai multe servicii puse la
dispoziție de sistemul de operare, servicii de sistem care nu sunt disponibi le într -o aplicație
web. De asemenea, o aplicație nativă are a amprentă mai mică asupra resurselor sistemului
decât o aplicație web, lucru care permite aplicație să ruleze și pe sisteme mai s labe din punct
de vedere hardware. De exemplu, o instanță de Chro me cu 10 tab -uri deschise poate depăși
cu ușurință 2 Gb de RAM, pe când soluția propusă nu a depășit 150 Mb RAM nici în timpul
testelor de stres. Mai multe detalii despre performanța aplicați ei în Capitolul 6.
Ca și dezavantaje ale aplicațiilor desktop, ce le mai relevante sunt reprezentate de
constrângerile de utilizare și accesibilitate fiind instalate pe mașinile fizice, dar și de faptul că
fiind instalate pe mașinile pe care rulează, updata rea și instalarea pentru un număr mare de
clienți poate dura dest ul de mult timp. Aceste probleme nu sunt întâlnite în cazul aplicațiilor
web, unde aplicația nu trebuie să fie instalată pe mașina de pe care este utilizată, iar
updatarea este centralizată.
În urma analizei tuturor avantajelor si dezavantajelor expuse mai sus și a discuțiilor cu clienții,
am decis să merg pe dezvoltarea unei aplicații desktop datorită amprentei reduse asupra
resurselor sistemului dar mai ales datorită faptului că nu necesită o conexiune constantă la
internet și poate funcționa într -un medi u cu conexiune și lățime de bandă limitate.
3.2.2 .Net Framework vs. Java vs. Electron
După decizia de a dezvolta o aplicație desktop a urmat partea de stabilire a tehnologiei și a
Framework -ului î n care aplicația avea să fie dezvoltată. În acest subcapitol prez int câteva
dintre tehnologiile folosite pentru dezvoltarea aplicațiilor desktop și motivez prin comparație
alegerea Windows Presentation Foundation pentru dezvoltarea soluției prezentate.
Principalele tehnologii disponibile pentru dezvoltare de aplicații d esktop sunt :
– .Net Framework , dezvoltat de Microsoft , având trei Framework -uri de dezvoltare
desktop: WPF – Windows Presentation Foundation, WinForms și UWP – Universal
Windows Platform;
– Java , dezvoltate de Oracle, cu cele două Framework -uri orientate deskt op: Swing și
JavaFX ;

– Electron , soluție open source dezvoltată de GitHub care permite folosirea
tehnologiilor web (JavaScript, HTML, CSS) pentru a dezvolta aplicații desktop.
Toate cele trei t ehnologii de mai sus prezintă avantaje și dezavantaje multiple, existând
diferențe notabile între toate, dar cele mai importante caracteristici rămân performanța și
popularitatea.
Dintre toate tehnologiile prezentate, cea mai populară este Wind ows Presenta tion
Foundation din .Net Framework, urmată îndeaproap e de WinForms tot din .Net Framework.
Popularitatea tehnologiilor bazate pe Java și Electron este mult sub cea ale tehnologiilor din
.Net Framework. Acest lucru se poate vedea in Graficul 1, bazat pe un sondaj realizat de
Telerik in 20163. În urma sondajul ui s-a ajuns la concluzia ca peste 96% dintre dezvoltatorii de
aplicații desktop folosesc una din tehnologiile dezvoltate de Microsoft. În ultimii ani a crescut
procentul de utilizare al UWP, dar nu exis tă date clare cu privire la acest lucru, unele surse
sugerând undeva la 10% altele undeva la 15% și mici scăderi în numărul de utilizatori din zona
WPF și WinForms. De asemenea, numărul de utilizatori Electron a crescut datorită faptului că
este folosit în aplicații cunoscute precum Slack, Visual Studio Code , Atom și GitHub Desktop.
La începutul lui 2019 fiind peste 750 de aplicații oficiale dezvoltate în Electron4.

Diagrama 1 Preferințele dezvoltatorilor de aplicații desktop

3 https://www.telerik.com/blogs/survey -report -the-dotnet -developer -of-2016
4 https://electronjs.org/apps 0 5 10 15 20 25 30 35 40 45 50AlteleElectronUWPWinFormsWPF
Procentul de utilizare raportat la 1000 de programatori

Pe lângă problema popularității și accesului la documentație, se pune și problema
consumului de resurse. Analiza prezentată mai jos se bazează pe crearea unei aplicații care
afișează „ Hello world!” într-o fereastră simplă. Comparația este făcută pe cele mai populare
Framework -uri din .Net și Java, WPF ș i Swing, dar și Electron , rezultatele putând fi
vizualizate în Diagrama 2.
Pe lângă cantitatea de memorie utilizată de o astfel de aplicație, pentru comparația de
performanță este foarte relevant și numărul d e procese pe care aplicația le pornește. În
urma testelor realizate pe aplicația „Hello World!” am observat că atât soluția din WPF cât și
cea din Swing pornesc un sigur proces, pe când soluția creată cu Electron pornește cinci
procese pentru aceeași aplic ație.
Aceste rezultate demonstrează că din pun ct de vedere al consumului de resurse, .Net WPF
este cea mai performantă tehnologie.

Diagrama 2 Memoria utilizate de aplicația „Hello World!”
Toate măsurătorile de performanță pre zentate au fost făcute utilizând apli cația Proc ess
Explorer disponibilă pe pagina de documentație Microsoft5.
Toate cele prezentate mai sus fac ca cea mai potrivită tehnologie pentru dezvoltarea
produsului prezentat în această lucrare să fie Windows Presen tation Foundation .

5 https://do cs.microsoft.com/ro -ro/sysinternals/downloads/process -explorer 0 10 20 30 40 50 60 70 80WPFSwingElectron
Medie Maxim Minim

3.2.3 Prezentare WPF
WPF (Windows Presentation Foundation) este una din tehnologiile din suita .Net, dezvoltată
și menținută de Microsoft încă din 2006 . Cu toate că este o tehnologie apărută acum 13 ani,
succesul pe care îl are se datorează f iabilității și eficienței, dar și facil ității cu care se pot
dezvolta aplicații în WPF. Fiind o tehnologie ajunsă la maturitate deplină, este bine
documentată și cu foarte puține probleme care să țină în mod direct de WPF.
Ca și arhitectură, aceasta folose ște o arhitectura multinivel. Niv elul d e vârf oferă servicii de
nivel înalt și este scris integral în C#. Nivelul de mijloc este cel care se ocupă cu translatarea
codului în obiecte Direct3D (texturi și triunghiuri) folosind o componenta de nivel inferior,
numită milcore.dll. Accesul la această componentă este blocat utilizatorului, toată
interacțiunea realizându -se prin intermediul nivelului de vârf (MacDonald, 2010) .

Figura 2 Arhitectură WPF (MacDonald, 2010)

Ca și limbaj de programare, WPF se bazează pe C#, iar pentru construirea interfeței grafice,
Microsoft pune la dispoziție propriul limbaj markup – XAML.
C# este un limbaj dezvoltat de Microsoft în 2000 fiind chiar cel mai folosit din toată suita
.Net. Este un limbaj complet pentru uz general și este multi -paradigmă, având caracteristici
de limbaj orientat obiect, imperativ, funcțional și declarativ și este compatibil cu toate
obiectele din Common Language Runtime . Din acest motiv este foarte ușor de în țeles și de
utilizat de programatori care sunt obișnuiți cu diferite paradigme. (2019) .
XAML (Extensible Application Markup Language) este un limbaj de markup foarte similar cu
XML , pe care se și bazează, dar modificat de Micro soft pentru a putea funcționa cu șablonul
MVVM din WPF. Interfețele grafice construite cu XAML sunt legate automat de proprietăți și
atribute din Common Language Runtime, având astfel compatibilitate foarte bună și cu
biblioteci scrise în alte limbaje care sunt compilate în CLR. (Ghoda Ashish, 2011)

MVVM (Mode – View – View Model) este pattern -ul structural principal din WPF. Acesta
permite separarea componentelor unei aplicații în trei subc omponente pentru a facilita
dezvoltare a rapidă a aplicațiilor desktop. (Model -View -ViewModel (MVVM) Design Pattern
using Windows, 2010)
Modelele reprezintă o abstractizare a datelor, și conțin doar informații, de obicei, proven ite
din baza de date. Chiar daca modelele se ocupă cu datele, acestea nu procesează datele și
nici măcar nu știu de unde provin datele.
View -urile sunt componentele interfeț ei grafice. Acestea sunt create cu XAML, dar au și o
parte de cod, de unde se pot m odifica diferite caracteristici programatic. Acestea pot fi
legate direct la un mod el, pentru view -uri care nu necesită procesare, sau pot fi legate la
proprietăți ale view modelelor pentru view -uri mai dinamice.
View Modelele se ocupă cu partea de Busines s Logic a aplicației – aduc da tele din baza de
date și le leagă de modele, procesează datele, le transmit către View pentru afișare etc.
3.2.4 Entity Framework 6
Entity Framework 6 este un O/RM (Object -Relational Mapping) lansat pen tru prima dată in
2008 și upda tat constant în ultimii zece a ni datorită nivelului mare de utilizare și cerințelor
comunității. Este o tehnologie matură care oferă suport pentru un număr mare de
funcționalități și baze de date (SQL Server, MySQL/MariaDB, Po stgreSQL, Oracle etc.).
(Driscoll, și alții, 2013)
Ca și funcționalitate principală, EF6 permite crearea bazelor de date prin metoda Code -First.
Acest lucru este foarte important deoarece nu mai este nevoie să fie create manual tabelele
și relațiile dintre ele. Tot ceea ce trebuie făcut este crearea modelelor din cod și specificarea
cheilor prin adnotări. Există totuși posibilitatea de a crea și relații mai complexe din cod (chei
multiple, ștergere în cascadă etc.) .
Un alt aspec t important al abordării Code -First este ușurința cu care se pot face migrări ale
tabelelor. Tot ce trebuie făcut este rularea comenzii „Add -Migration <Nume -Migrare>” și
migrarea este creată automat pe baza structurii tabelelor și modificărilor din modele. Mai
mult de atât, se pot acti va migrările automate astfel încât nici comanda de creare a unei
migrări să nu mai fie necesară. După crearea fișierelor de migrare se apelează comanda
„Update -Database” pentru a aplica migrarea pe baza de date.
Desigur, deși este un O/RM foarte puternic , există situații când anumite inter ogări pe baza
de date sunt prea complexe pentru ca EF6 să le facă eficient. În aceste situații se poate
interveni pentru a face query -uri manuale utilizând biblioteca LINQ ( Language -Integrated
Query ).
3.2.5 CEF Sharp
CEF Sharp este un wrapper compatibil .Net peste Chromium Embedded Framework creat de
Marshall A. Greenblat. Acesta este un wrapper open source compatibil cu toate limbajele CLR,
având implementări funcționale atât pentru WPF cât și pentru WinForms. (2019)

În soluția prezentată în această lucrare , CEF Sharp este folosit pentru a vizualiza, salva ca
PDF și imprima rapoa rtele HTML generate de aplicație.
4 SOLUȚIA PROPUSĂ
Acest capitol prezint ă detaliat aplicația dar și toate aspectele referitoa rea la dezvoltarea
soluției propuse : împărțirea pe componente si organizarea acestora, arhitectura fiecărei
componente, prezentarea workflow -ului aplicației și în final prezentarea structurii bazelor de
date folosite.

4.1 Prezentarea aplicației

La deschider ea aplicației, utilizatorul trebuie să introducă numele de utilizator și parola
pentru a se loga, dar poate să introducă si adresa s erver -ului de baze de date (URL sau IP).

Figura 3 Panou logare aplicație

În urma logării cu suc ces, aplicația de salarizare este pornită iar utilizatorul poate începe
utilizarea ei. Interfața acesteia este împărțită în mai mul te componente :
4.1.1 Vizualizarea salariaților și rapoartelor
Din această componentă se poate seta luna în care se lucrează, se
pot căuta salariați după nume sau CNP, se pot filtra după sursele
de finanțare, domeniu și profil.
De asemenea, se pot adăuga și șterge salariați și se pot salva
modificările în baza de date.
Pentru generarea de rapoarte se selectează rapoartele care se
doresc și se setează data raportării apoi se apasă butonul
„Generează rapoarte”.
Tot din această componentă se poate porni și interfața de
personalizare a rapoartelor, apăsând butonul „Editare Rapoarte” .
Imagini cu rapoartele generate de aplicație pot fi găs ite în
secțiunea Anexe.

4.1.2 Informații salariat
În această secțiune se introduc informațiile despre salariat și despre contractul acestuia , toate
aceste informații fiind necesare pentru calculul salarial sau pentru completarea rapoartelor.
De aseme nea, tot în această secțiune se introduc și informațiile despre adresă și metoda de
plată aleasă de angajat (cash sau prin transfer bancar).
Figura 4 Vizualizarea
salariaților și rapoartelor

Figura 5 Interfața cu informațiile despre salariat și despre contract

Figura 6 Adresa și informațiile de plată ale salariatului
Tot în acest panou se găsește și interfața pentru completarea funcțiilor ocupate de salariat,
cu toate sporurile și reținerile pe care acesta le are.

Figura 7 Interfață funcții, sporuri și rețineri

4.1.3 Întreruperi de muncă
În aceas tă secțiune există d ouă interfețe, una pentru întreruperi obișnuite (motivate și
nemotivate) și una pentru concedii medicale. Ambele informații permit introducerea tuturor
datelor prevăzu te de l egislația în vigoare.

Figura 8 Interfață întreruperi obișnuite

Figura 9 Interfață concedii medicale

4.1.4 Deduceri personale, D112 și Ordine de Plată

Figura 10 Interfață pentru ad ăugarea persoanelor aflate în întreținere și a persoanel or
co-asigurate

Figura 11 Interfață configurare D112

Figura 12 Interfață completare, editare și generare OP

4.2 Organizarea com ponentelor aplicației
Aplicația este organizata după o arhitectură de tip plugin . Există un Shell al aplicației care
încarcă plugin -uri după necesitățile utilizatorului, dar și un Core care conține toate interfețele
și modelele comune plugin -urilor , cât și toate s etările de con figurare ale aplicației, salvate
local . Fiecare plugin este un dll care știe doar de existența Core -ului și nu poate accesa niciun
alt plugin și nici Shell -ul. Acest mod de organizare a componentelor permite modificare sau
chiar înloc uirea oricărui plugin fără a afecta celelalte module ale aplicației.

Diagrama 3 Relațiile dintre componentele aplicației

4.2.1 Plugin -uri
– Plugin.Sal: plugin -ul principal al aplicației de salarizare. Acesta este încărcat în Shell la
pornirea aplicației și conține majoritatea componentelor cu care interacționează
utilizatorul în timpul operării;
– Plugin.Settings: plugin -ul pentru setări. Acesta este încărcat atunci când utilizatorul
accesează setările aplicației și permite editarea diferitelor d ate despre unitate,
conectare și alte setări specifice aplicației de salarizare;
– Plugin.AdvancedSettings: este un plugin care oferă control asupra formulelor de calcul
salarial, configurarea și setarea sporurilor, reținerilor, zilelor de liber naț ional și
organizarea categoriilor de salariați și surselor de finanțare;
– Plugin.ReportViewer: plugin destinat vizualizării rapoartelor generate, salvării și
imprimării lor
– Plugin.Activator: responsabil cu verificarea validității licenței aplicației.

Cu toa te că plugin -urile nu se cunosc între ele, acestea pot să comunice fiind conectate la
aceeași bază de date sau prin intermediul Core -ului, modificând configurațiile locale. Astfel,
dacă utilizatorul modifică o setare a aplicației din plugin -ul de set ări, plugin -ul principal v -a
putea accesa acea setare chiar dacă nu știe de existența plugin -ului din care aceasta a fost
modificată.
4.2.2 Shell
Componenta de bază a aplicației, Shell -ul reprezintă fundația pe ste care se încarcă toate
celelalte componente . Pe l ângă încărcarea plugin -urilor, acesta este folosit pentru a realiza
conexiunea la serverul de baze de date, asigură eliberarea memoriei dacă un plugin nu este
folosit pentru o perioadă de timp și , apelând plugin -ul de validare, verifica validitatea licențe i
la pornirea aplicației.
4.2.3 Core
Componenta de legătur ă a aplicației, face posibilă comunicarea între plugin -uri care
accesează aceleași date prin setările locale ale aplicației sau prin modificarea datelor din
tabelele comune ale bazei de date. Mai mult, Co re-ul conține implementări pentru toate
clasele, modelele și funcționalitățile pe care le folosesc mai multe plugin -uri, eliminând astfel
existența codului duplicat din plugin -uri diferite.

4.3 Arhitectura componentelor
Pentru componentele care au interfață g rafică, am folosit MVVM ca pattern de design
structural. Acesta este un model de lucru creat de Microsoft pentru a facilita dezvoltarea de
aplicații desktop și pentru a crea o separație bine definită între părțile de UI/UX și business
logic ale aplicației (Model -View -ViewModel (MVVM) Design Pattern using Windows, 2010) .
Pattern -ul de design specific MVVM este Observable, fiind folosit pentru a notifica View -ul de
toate schimbările care se produc pe componentele legate la el și pentru a oferi o experiență
plăcută utilizatorilor (fără reîncărcări și click -uri pe diferite butoane pentru a vedea rezultatele
calculate de aplicație, acestea fiind calculate în timp real pe alte thread -uri).

Diagrama 4 Inte racțiunea între componentele arhitecturii MVVM6

Plugin -urile respectă, de asemenea, și modelul Singleton, existând maxim o instanță a
fiecăruia la orice moment. De acest lucru se ocupă Shell -ul despre care se poate spune că
funcționează după modelul Facto ry ușor modificat pentru a asigura funcționalitatea de
Singleton a plugin -urilor.
4.3.1 Arhitectur ă Core
Core -ul aplicației conține funcționalități folosite de toate celelalte plugin -uri dar și de Shell.
Acesta funcționează ca o bibliotecă de funcții, modele, en um-uri, convertoare și componente
de uz general.
Nefiind o componentă menită să funcționeze independent, nu are o arhitectură specifică,
fiind mai apropiat de structura unei biblioteci clasice. Nu are interfață grafică proprie, dar
conține implementări de mici componente grafice folosite de plugin -uri.
Conține atât clase statice, utilizare fără a fi instanțiate, cât și clase care au nevoie de
instanțiere pentru a fi folosite.

6https://docs.microsoft.com/en -us/xamarin/xamarin -forms/enterprise -application -patterns/mvvm –
images/mvvm.png

În imaginea din stânga se poate observa toată
structura Core -ului.
Convertoarel e sunt folosite pentru a modela afișajul
anumitor valori din baza de date și implementează
interfața IValueConverter .
În Datab ase se găsește implementarea provider -ului
pentru conexiunea la baza de date de setări avansate,
dar și logica de update automat a setărilor locale în
momentul când aplicația are conexiune la internet .
Enum -urile sunt folosite pentru a facilita completarea
de informații în diferite dropdown -uri și liste din
aplicație, ocupând în același timp un spațiu mai mic
decât dacă în baza de da te ar fi salvate șiruri de
caractere sau alte date mai voluminoase. Pentru a
menține standardele de UX, enum -urile sunt folosite
împreună cu convertoarele.
ListView conține o implementare de baza a unei
componente de tip listă. Această implementare este
extinsă și modificată de fiecare listă din aplicație.
Migrations conține toate migrările bazei de date
pentru a satisface modificările modelelo r. Acestea
sunt folosite de ORM pentru a face update bazelor de
date.
Models conține toate modelele comune plugin -urilor.

MysqlTools conține logica de backup/restore pe cloud a datelor. Acesta funcționează apelând
mysqldump.exe și mysql.exe pentru a expo rta o bază de date de pe un server și a o importa
pe un alt server.
Reports reprezintă o componentă importanta a C ore-ului deoarece conține toată logica, toate
interfețele și clasele generice pentru generarea automata de rapoarte HTML. Voi explica mai
în profunzime acest sistem în Capitolul 5.
TreeItem, la fel ca ListView, conține implementarea generica a unei compone nte dintr -o
vizualizare arborescentă (TreeView).
Figur a 13 Structura fișiere Core

Validators cuprinde algoritmii de validare pentru diferitele date introduse în aplicație (CNP,
CIF, numere de telefon, email -uri etc.)
View conține toate View -urile comune folosite de plugin -uri.
Următoarele clase conțin implementările pentru diferite componente și servicii folosite în
aplicație. Printre ele se numără sistemul de management al se tărilor locale, interpretorul de
formule, un convertor HTML -to-PDF, managerul de servicii, generatorul de coduri PD F417
pentru Ordinele de Plată și câteva componente implementate să suporte Observable.
4.3.2 Arhitectură Shell
Entry -point -ul aplicației, Shell -ul funcționează ca un plugin loader, identificând toate plugin –
urile disponibile, verificând existența și validitatea licenței și încărcând plugin -urile on –
demand. În plus, se ocupă și cu login -ul utilizatorulu i în aplicație.
Images conține toate imaginile v izibile la deschiderea
aplicației (Logo, Background).
Services conține definițiile serviciilor folosite pentru
func ționarea aplicației. Printre acestea se numără
serviciul de conectare la bazele de date și serviciul de
încărcare a plugin -urilor.
View si Vi ewModels conțin View -urile și respectiv
ViewModelelel pentru login, configurația inițială (la prima
pornire a aplic ației), și pagina principală. Deoarece Shell –
ul nu are interacțiune cu baza de date, acesta nu are
modele.
Clasa EntryPoint este cea care se ocupă cu pornirea
thread -ului principal al programului și pornește StudioApp
care extinde clasa Application .
Restu l reprezintă componente ajutătoare sau fișiere.

4.3.3 Arhitectură Plugin.Sal
Acest plugin conține interfața grafică și logica pentru tot ce înseamnă salarizare, reprezentând
astfel cea mai importantă parte a aplicației. Ca și în cazul Shell -ului și acest plugin respectă
șablonul MVVM, dar spre deosebire de Shell acesta, lucrând cu informații din baza de date
are și partea de modele.
Figur a 14 Structură fișiere Shell

Se poate observa o structurare similară cu cea a Shell -ului,
cel puțin in ceea ce privește convertoarele, enum -urile,
migrările, v iew-urile și view modelele.
Există totuși câteva comp onente în plus față de Shell:
Controls cuprinde componentele de UI de tipul UserControl.
Acestea sunt componente mici care se folosesc împreună
pentru a forma un View mai complex,
Ordinele de plată sunt de asemenea implementate în acest
plugin, având atât componente de UI cât și de business logic.
O altă componentă importantă este Editorul de Rapoarte,
care permite utilizatorilor să își personalizeze rapoartele
după preferințe.
Una dintre cele mai import ante componente ale acestei
aplicații este ResourceCa lculator . Acesta are rolul de a folosi
interpretorul de formule, formulele de calcul salarial și
datele de bază(salariu brut, sporuri, rețineri, norma de
muncă și numărul de zile lucrate) pentru a calcul a toate
sumele necesare (salariu net, CAS, CASS, impo zit, CAM etc.)
Despre editorul de rapoarte și despre ResourceCalculator voi
oferi mai multe informații în Capitolul .

4.3.4 Arhitectură ReportViewer

Această componentă are rolul de a încărca rapoartele HTM L,
pentru vizualizare. Folosește de asemenea, MVVM și este
asemănător cu celelalte plugin -uri.

4.3.5 Alte plugin -uri
Restul plugin -urilor (Setări, Setări Avansate și Activator) au o structură similară cu cele
prezentate mai sus, iar din punct de vedere al implementării , nu conțin n imic din ce nu am
prezentat dej a. Din aceste motive am ales să nu le mai prezint pe fiecare în parte.

Figur a 15 Structură fișiere
Plugin.Sal
Figur a 16 Structură f ișiere
ReportViewer

4.4 Arhitectura Bazei de date
Datorită faptului că încă de la început s -a dorit ca aplicația să poată funcționa cu un server de
baze de date local, dar în același timp update -urile legislative să poată fi trimise over -the-air,
aceasta funcționează cu mai multe baze de date care nu trebuie să fie neapărat în același
server fizic. Astfel, baza de date care menține setările și configurați ile globale ale aplicației
este localizată în Cloud, iar baza de date care se ocupă cu păstrarea datelor introduse d e
utilizator poate fi localizată atât în Cloud cât și pe un server dedicat ales de utilizator.
Această abordare este cauzată de faptul că un număr mare de potențiali clienți, în special cei
din zonele rurale, au uneori probleme cu conexiunea la internet sa u își doresc ca bazele de
date să fie pe serverele lor fizice. În cele ce urmează voi prezenta ambele baze de date și voi
descrie relațiile dintre ele și nevoia de a avea anumite tabele.
4.4.1 Tabele Date Salariați

Figura 17 Tabelele cu datele salariaților și relațiile dintre ele
Datorită faptului ca sunt 12 tabelele și majoritatea au multe câmpuri, imaginea de mai sus nu
este completă, dar o imagine mai clară și mai detaliată se găsește în Anexe .
Tabela principală este cea care identifică dosarele angajaților – foldermodels . Aceasta este
compusă dintr -un ID (cheia primară), numărul cererii de ang ajare (pentru identificarea
angajatului) și o dată care reprezintă luna din ca re face parte dosarul respectiv.
Deși în structura inițială, la schimbarea de lună se duplicau doar anumite date și abordarea
era de tipul copy -on-write, în urma testării și a di scuțiilor cu clienții am concluzionat că nu

este cea mai potrivită abordare și am trecut pe o duplicare completă a datelor la schimbarea
de lună .
În primul rând, abordare a copy -on write implica adăugarea de noi tabele pentru a asigura
consistența datelor ș i legăturile corecte între datele modificate și datele nemodificate. Acest
lucru crea întârzieri în aducerea datelor din baza de date în memoria aplicației dar și întârzieri
cauzate de logica suplimentară necesară pentru o funcționare corectă sistemului de copy -on-
write.
În al doilea rând, discutând cu clienții am înțeles că se dore ște o evidență completă a tuturor
modificărilor apărute de la o lună la alta. Acest lucru a reprezentat un motiv în plus pentru a
alege ca datele să fie complet duplicate de la o lună la alta, în ciuda faptului că poate fi
neeficient din punct de vedere al spațiului ocupat.
4.4.1.1 Descrierea tabelelor
1. personmodels conține toate datele de identificare ale salariaților (nume, prenume,
CNP, serie și număr CI etc);
2. addressmodels conține info rmații despre adresa angajaților;
3. contractmodels conține informațiile despre contractele de muncă ale salariaților;
4. functionmodels conține informații despre funcțiile ocupate de salariați;
5. paymentmodels conține informații despre metodele de plată a angajaț ilor
(cash/card);
6. spormodels și retineremodels conțin inf ormații despre sporurile și reținerile aplicate
funcțiilor;
7. remotermodels conține informații despre persoanele aflate în întreținerea unui
salariat. Aceste informații sunt folosite pentru determinare a deducerilor personale;
8. vacationmodels conține informați i despre toate întreruperile unui salariat, în afară de
concediile medicale;
9. medicalvacationmodels conține informații despre concediile medicale ale angajaților;
10. certificatemodels conține informații despre certificatele medicale corespunzătoare
concediilor medicale.
4.4.1.2 Relații între tabele
– foldermodels – addressmodels: 1 to 1
– foldermodels – contractmodels: 1 to 1
– foldermodels – personmodels: 1 to 1
– foldermodels – paymentmodels: 1 to 1
– foldermodels – vaca tionmodels: 1 to many
– foldermodels – functionmodels: 1 to many
– foldermodels – remotermodels: 1 to many
– foldermodels – medicalvacationmodels: 1 to many
– functionmodels – spormodels: 1 to many

– functionmodels – retineremodels: 1 to many
– medicalvacationmodels – certificatemodels: 1 to many
– functio nmodels – spormodels: 1 to many
4.4.2 Tabele Date Unitate
Aceste date sunt salvate, de asemenea, pe serverul ales de client, împreună cu datele despre
salariați și au rolul de a ține setările locale ale aplicației.

Figura 18 Tabelele cu datele unității
4.4.2.1 Descrierea tabelelor
1. conexiunemodels conține datele de conectare în cazul în care clientul dorește să le
salveze ;
2. dateunitatemodels conține toate informațiile despre unitate (informații de contact,
numele conducătorilor unității etc.);
3. adresaunitatemodels conține informațiile despre adresa unității;
4. setarisalariimodels conține alte setări ale aplicației;
5. updatemodels conține timestamp -uri pentru a putea identifica dacă este nevoie ca
setările locale s ă fie updatate din baza de date de setări. Acest lucru este util atunci
când sunt mai mulți utilizatori care folosesc aplicația de pe calculatoare diferite.

4.4.2.2 Relații între tabele
Între aceste tabele nu există relații de niciun fel, deoarece ele conțin info rmații specifice
unității.
4.4.3 Tabele Date Configurare
Spre deosebire de cele două categorii de tabele prezentate mai sus, aceste a sunt salvate
exclusiv pe Cloud, fiecare instanță a aplicației conectându -se la același server și la aceeași bază
de date.
Datele de configurare și existența lor exclusiv singulară au un rol foarte important în sistemul
de update over -the-air, deoarece conțin toate informațiile care intră în calculul salarial. Din
acest motiv, accesul la setările avansate ale aplicației este restricț ionat și este permis doar
consultanților nu și clienților. Mai multe detalii despre funcționarea sistemului de update vor
fi prezentate în Capitolul 5 al acestei lucrări.

Figura 19 Tabele cu informațiile de configurare
4.4.3.1 Descrierea tabelelor
1. srmodels – conține informațiile, formulele și descrierile despre fiecare spor și fiecare
reținere impuse de legislație;
2. formulamodels – conține formule de calcul pentru fiecare parametru salarial. Mai
multe detalii despre cum funcționează sistem ul de calcul și interpretorul de formule
în Capitolul 5;
3. admins – conturi utilizatori cu drepturi de administrare;
4. legaldays – zilele libere
5. updatesmodels – la fel ca în cazul setărilor locale, și această tabelă are rolul de a
menține timestamp -uri ale ult imele modificări. Util pentru sistemul de update over –
the-air;

6. subdomainmodels, profilemodels și ibanmodels țin informații referitoare la
subdomeniile și profilele din domeniul administrației publi ce locale și IBAN -urile sursă
pentru plata dărilor pentru f iecare profil în parte.
4.4.3.2 Relații între tabele
– subdomainmodels – profilemodels: 1 to many
– profilemodels – subdomainmodels: 1 to many
Restul tabelelor nu au relații între ele deoarece conțin doar info rmații care nu depind de alte
tabele.

5 DETALII DE IMPLEMENT ARE
În acest capitol voi prezenta componentele cele mai importante ale aplicației , dar și
dificultățile pe care le -am întâmpinat în timpul dezvoltării. Consider că cele mai importante
componente al e acestui proiect sunt, în ordinea aceasta, motorul de inte rpretat formule,
generatorul de rapoarte HTML și vizualizatorul de rapoarte. Acestea trei oferă funcționalitate
completă soluției și permit utilizatorilor să rezolve orice problemă legată de salari zare.

5.1 Interpretorul de formule
Una dintre cele mai importa nte părți ale acestei aplicații este interpretorul de formule , buna
funcționare a sa fiind unul din obiectivele acestui proiect . Acesta se bazează pe transformarea
formulelor matematice din forma infixată în forma postfixată și interpretarea formei
postfix ate pentru a permite introducerea modificărilor legislative în aplicație fără intervenția
programatorilor .
5.1.1 Transformare formule
Transpunerea formulelor din forma infixată în forma postfixată se fac e pentru a elimina
parantezele și pentru a reduce astfel co mplexitatea algoritmului de interpretare. O altă
problemă a formei infixate este dificultatea cu care se poate tine cont de precedența
operatorilor. Aceeași problemă nu este la fel de dificil de re zolvat în cazul formei postfixate.

Tabel 1 Formă infixată vs. Formă postfixată
Formă Infixată Formă postfixată
A + B * C + D A B C * + D +
(A + B) * (C + D) A B + C D + *
A * B + C * D A B + C + D +

Pentru transformarea din forma normală în forma postfixată am aplicat algoritmul lui
Hamblin , pe care l -am adaptat pentru a oferi suport și pentru operatorul ternar (?:). Acest
algoritm folosește o stivă și o coadă pentru a transforma un set de simboluri o rdonate,
reprezentând formula în formă normală, într-un set de simboluri reprezentând f ormula în
formă postfixată.

Figura 20 Algoritmul lui Hamblin (Wood, 1968)
Implementarea acestui algoritm se poate găsi în secțiunea Anexe.
5.1.2 Interpretare formule
Interpretarea de formule se face folosi nd, de asemenea, o stivă si un set de simboluri
reprezentând formula în formă postfixată. Pentru a putea interpreta seturi mai complexe de
formule, am mo dificat algoritmul să suporte și comparații ( <, >, = ), operații logice (&, |) ,
operatorul ternar, ridic are la putere, radical și logaritm. Cu modificările aduse asupra
algoritmului acesta poate interpreta orice fel de formulă atâta timp cat este corectă di n
punct de vedere matematic. Mai mult de atât, poate înlocui tag-urile din formule cu valorile
date din tr-un dicționar.
Implementarea acestui algoritm se poate găsi în secțiunea Anexe.

5.2 Generatorul de rapoarte
Această componentă stă la baza generării tuturor rapoartelor din aplicație și este împărțită în
două componente. Prima se ocupă cu înlocuirea tag-urilor din header și footer cu datele
despre unitate , iar cea de -a doua se ocupă cu generarea tabelelor și com pletarea lor cu
informații.
Ca și bază, pentru fiecare raport există un set de template -uri HTML care conțin stilizarea
făcută cu CSS și in cazul fo oter -ului și al header -ului conțin și structura completată cu tag -uri
în loc de valori .
La generarea unui raport, cele trei structuri de bază sunt încărcate de aplicație, completate
cu date și concatenate într -un singur fișier HTML care reprezintă raportu l. Acest fișier nu este
salvat pe disc, ci este încărcat în vizualizatorul de rapoarte, de unde poate fi sa lvat ca PDF sau
imprimat.
Pentru a reduce cantitatea de cod duplicat, generatorul este compus cu clase generice și se
folosește de reflexie pentru a putea accesa câmpurile și proprietățile modelelor pe care nu le
cunoaște. Aceste clase expun, de asemenea, și un set de proprietăți care ajută la modelarea
și formatarea datelor din rapoarte.
displayName – numele coloanei ;
varaibleName – numele
câmpului d in modelul pe care e
bazat raportul (funcționează și
cu indirectări câmp.subcâmp) ;
computeFormula – formula de
calcul pentru valorile din coloana.
Se folosește atunci când nu avem
informația existentă într -un câmp
din model;
format și totalFormat sunt
formatări pentru valorile din
coloane si, respectiv, totalul
coloanei, dacă există;

hasTotal – specifică existența unui total al valorilor de pe coloan ă;
isAutoIncrement – invalidează toate celelalte proprietăți, iar coloana devine o coloana de
numerotare .
Figur a 21 Proprietățile unei coloane

Clasa ListReportAb stract< Model, AditionalData > este o clasă generică și conține
implementările de bază pentru generarea rapoartelor. Primul parametru generic reprezintă
tipul de modele care vor fi folosit ca sursă de date, iar cel de -al doilea parametru mod elează
un set de date adiționale de care ar putea fi nevoie în raport.

Ca și wo rkflow generatorul funcționează astfel:
1. Se inițializează toate componentele de care este nevoie și se deschid fi șierele
template;
2. Se creează dicționarele care conțin informații le pentru footer si header și se înlocuiesc
tag-urile cu valorile din dicționar ;
3. Se creează coloanele cu datele necesare. Înainte de creare, datele pot fi filtrate cu
ajutorul unei funcții de filtrare;
4. Se generează tabelul HTML cu datele din obiectele colo ană, linie cu linie;
5. Se concatenează header -ul, tabelul și footer -ul și se salvează în memorie. Opțional se
poate salva și pe disc prin setarea proprietății de salvare la true.
Pentru crearea unui nou tip de raport se creează o clasă care moștenește clasa
generator și se suprascriu me todele necesare pentru a completa raportul cu date
specifice lui. Un exemplu de clasă care generează un raport este disponibil în secțiunea
Anexe.
Pentru generarea rapoartelor personalizate am creat o interfață grafică din care utilizatorii
pot seta toate proprietățile necesare unui raport. Aceste proprietăți sunt apoi serializate și
salvate în setările locale ale aplicației. Pentru generarea rapoartelor personalizate,
generatorul deserializează proprietățile și aplică pașii de mai sus.

5.3 Vizualizatorul de rapoarte
Implementat utilizând CEF Sharp, vizualizatorul de rapoarte este o instanță de Chromium în
care se încarcă HTML -urile rapoartelor pentru a putea fi vizualizate.
Această componentă nu este una foarte complexă, dar este s ingura care a reușit să creeze
probleme. Datorită faptului ca în .Net fiecare task nou este pornit pe un alt thread și în
general totul merge cum trebuie, am omis faptul că un Chromium este destul de mare și are
o perioadă de timp în care trebuie să se ini țializeze. Astfel nu m -am ocupat de o sincronizare
propriu -zisă a thread -urilor și am avut câteva probleme din cauza asta, în special când
generarea rapoartelor se ter mina înaintea inițializării instanței de Chromium și se încerca
trimiterea către vizualiz ator a rapoartelor.
Pentru a putea realiza această sincronizare, thread -ul care încarcă Chromium pune în
așteptare thread -ul care încearcă să ii trimită rapoartele, până când inițializarea este
completă.

6 STUDIU DE CAZ / EVAL UAREA REZULTATELOR
În acest cap itol voi prezenta procedurile de testare folosite pentru a asigura calitatea soluției
propuse, apoi voi discuta despre sistemul de deployment al aplicației, iar la final voi face o
scurtă prezentare a rezultatelor și a impresiilor clienților exist enți.

6.1 Teste unitare
Testarea unitară este foarte importantă pentru a verifica funcționarea corectă a metodelor și
proprietățile unei clase . Acestea au un rol foarte important, nu doar în testarea
componentelor unei aplicații, dar și pentru a asigura menți nerea fun cționalităților vechi
atunci când apar modificări în cod.
În acest proiect am încercat să am un Code -Coverage cât mai mare pentru componentele cu
foarte multă logică computațională, ajungând la ~70% pentru funcțiile din interpretorul de
formule ș i calculu l indemnizației pentru concedii medicale.
Pentru testarea unitară am folosit sistemul integrat din Visual Studio, care permite crearea de
teste și seturi de date de testare specifice fiecărei componente în parte. Acest tool permite
utilizatorilor să aibă o privire de ansamblu asupra testării unitare, dar și un control foarte bun
asupra căror teste să se ruleze și când.

Figura 22 Rularea testelor unitare
Pot spune că acest gen de testare mi se pare foarte important pent ru o dezvo ltare rapidă și
cu predis punere limitată la bug -uri. Un alt aspect important al testări unitare este dat de
faptul că identificarea sursei problemei devine foarte ușoară. Mai mult de atât, scrierea
testelor unitare este foarte rapidă.

Figura 23 Exemplu test unitar Interpretor Formule

6.2 Teste de integrare
Testele de integrare sunt folosite pentru a verifica interoperabilitatea între componente
distincte care lucrează împreună. Aceste teste sunt extrem de importa nte, mai ales în pr oiecte
mari sau proiecte la care au lucrat un număr mare de persoane. Deși soluția prezentată nu se
încadrează la cea de -a doua categorie, fiind un proiect mare, se încadrează la prima categorie
și necesită existența unui set minimal de teste de integrare.
În acest proiect, testele de integrare au fost realizate folosind sistemul de testare unitară pus
la dispoziție de Visual Studio, singurele diferențe între testele de integrare și cele unitare fiind
complexitate cazurilor de test și fap tul că testele de i ntegrare verificau compatibilitatea între
componente pe când cele unitare verifică funcționalitatea componentelor.

6.3 Testare manuală
Deși una dintre cele mai dificile tipuri de testare, în special din punct de vedere al timpului pe
care îl consumă, testarea manuală rămâne una dintre cele mai bune metode de testare a
aplicațiilor, mai ales pentru interfețele grafice.
Pentru acest proiect, testarea manuală a avut mai multe etape.
Prima etapă este reprezentată de testarea manuală făcută pe d ate generate aleato r, pentru
a verifica consistența datelor la afișare, dar și funcționalitate interfeței grafice. Tot în această
etapă am încercat să introduc date invalide pentru a vedea cum răspunde aplicația la erori de
acest gen.
Cea de -a doua etapă a fost reprezentată de testarea cu date preselecționate pentru a verifica
dacă rezultatele generate de aplicație coincid cu rezultatele așteptate.
În ultima etapă, aplicația a fost testată pe date reale, în paralele cu alte aplicații de salarizare,
pentru a verifica consiste nța rezultatelor la scară larga (100+ angajați introduși în aplicație).

6.4 Deployment
Pentru producție am creat o configurație diferită de cea de dezvoltare, în care să nu existe
setări locale predefinite ( datele unității, numele reprezent anților etc.). Astf el, atunci când fac
build -ul aplicației în configurația de producție , compilatorul știe să nu adauge setările locale.
Pentru crearea unui installer am folosit Microsoft Visual Studio Installer Projects7, un utilitar
gratuit, creat de Microsoft pentru a fac ilita crearea rapidă de installer -e. Ca și utilizare, acesta
dispune de o interfață grafică în care utilizatorul poate adăuga ierarhia de fișiere de care
aplicația va avea nevoie pentru a funcționa. Utilitarul permi te și rularea de scripturi și comenzi
atât pre -install cât și post -install .
Pentru versionarea componentelor am folosit Build Version Increment Add -in8 creat de Paul
Melia. Acest utilitar poate fi configurat să incrementeze versiunile componentelor după
anumite reguli , dar și în funcție de config urația de build. Incrementarea versiunilor este foarte
importantă, deoarece installer -ul creat cu Installer Projects înlocuiește doar dll -urile cu
versiune mai nouă decât cele deja instalate, iar în lipsa versionăr ii utilizatorul ar fi nevoit să
dezinstal eze manual aplicația înainte de a porni instalare.
În ceea ce privește CI/CD, am considerat că o astfel de soluție nu este necesară, deoarece nu
îmi doresc ca aplicația să fie disponibilă pe internet, ci doar să fie disponibilă clienților
existenți. De ase menea, crearea unui deployment manual durează sub 5 minute și nu are loc
suficient de frecvent pentru a fi nevoie de o soluție care să automatizeze acest proces.

6.5 Validarea soluției
După cum am prezentat și în secți unile anterioare, atât dezvoltarea soluți ei cât și validarea ei
au fost realizate în strânsă colaborare cu oameni cu experiență în domeniul salarizării
instituțiilor publice.
Mai mult de atât, aplicația se află în producție de la 1 mai 2019, fiind utilizat ă în mod curent
de peste 10 clienți din t rei județe diferite. Acest lucru îmi conferă încrederea să afirm că
soluția este complet funcțională , îndeplinește cu succes toate obiectivele propuse și respectă
cerințele software stabilite.

7
https://marketplace.visualstudio.com/items?itemName=VisualStudioClient.MicrosoftVisu alStudio2017Installer
Projects
8https://marketplace.visualstudio.com/items?itemName=PaulMelia.BuildVersionIncr ementAdd –
inVS2015VS15Preview&ssr= false#overview

6.6 Rezultate
Ca și rezultate, aplicația a dat dovadă de o perform anță foarte bună atât din punct de vedere
al puterii de procesare cât și din punct de vedere al memorie utilizate . Pentru a putea vizualiza
aceste rezultate de performanță am realizat câteva teste pentru care a m colectat datele și le-
am compilat în câteva grafice.

Figura 24 Rezultatele adăugării automate a 1000 de salariați simultan

Testul din imaginea de mai sus este cel mai mare test de stres pe care l -am realizat pe
aplicație. Acesta a fost compus din generarea , procesarea și adăugarea în baza de date a 1000
de salariați, reprezentând o situație de stres a aplicație în care nu se poate ajunge în practică .
Rularea acestui caz de test a durat î n medie 43 de secunde și a fost rulat de 5 ori. Se poate
observa în imaginea de mai s us că și în acest caz extrem memoria folosită de aplicație nu a
depășit 175 MB.

Diagrama 5 Rezultate teste de stres9

Datorită faptului că nu am avut acces la codul sursă al aplicațiilor concurente, o comparație
directă bazată teste de stres nu a fost posibilă. Am încercat totuși introducerea de date în
două dintre aplicațiile existente și am putut vizualiza care este consumul de resurse în cazu l
unor operații simple . Ambele aplicații având consumuri destul de mari atât din punc t de
vedere al utilizării procesorului, cât și din punct de vedere al memoriei ocupate, ajungând
pană la 30% utilizare medie și 150Mb RAM ocupat.
Mai mult de atât, nici un a dintre aplicații nu se ocupa de prinderea erorilor, introducerea de
date eronate sa u incomplete cauzând închiderea lor.
Analizând aceste inform ații, pot spune că rezultatele soluției propuse se ridică la nivelul
așteptărilor , dar și peste nivelul concure nței.

9 Testele de stres au fost rulate din versiunea de development, în modul debug. Acest lucru adaugă un overhead
de aproximativ 50Mb 00.511.522.533.5
100 de salariati 300 de salariati 600 de salariati 1000 de salariati
Memorie Utilizată (100Mb) Număr de procese Utilizare procesor (0-10)

7 CONCLUZII
Aplicația „ContrAll Sal” este o aplicație completă de salarizare pe ntru instituțiile publice.
Aceasta se ridică deasupra aplicațiilor concurente prin performanță, funcționalitate, dar cel
mai important, prin faptul că este intuitivă și a fost dezvoltată ținând cont de nevoile clienților.
În ceea ce privește atingerea obie ctivelor, pot spune că aplicația este un succes. Are
implementate toate funcț ionalitățile necesare dar și multe altele care au rolul de a îmbunătăți
experiența utilizatorului și a -i ușura munca. Printre acestea se numără: rapoartele
personalizate, personal izarea sporurilor și reținerilor, generarea ordinelor de plată, generarea
automată a Declarației 112 și controlul asupra formulelor de calcul salarial.
De asemenea, în această lucrare am prezentat și o comparație între soluția propusă și soluțiile
deja ex istente pe piață, pentru a evidenția diferențele între ele și plusurile pe ca re „ContrAll
Sal” le aduce.
Ulterior am prezentat tehnologiile disponibile și am motivat tehnologiile alese prin comparații
de popularitate și performanță . Ulterior am prezentat ș i arhitectura soluției și a
componentelor e i, urmate de detaliile de implemen tare ale celor mai importante
componente.
Pentru evaluarea soluție am folosit testare unitară pe com ponentele cele mai importante
(interpretorul de formule), testare manuală pentr u interfața grafică, testare prin comparație
cu alte aplicații pentru testare a funcționalităților de calcul, toate aceste metode asigurând
buna funcționare a aplicației și facilitând procesul de lansare în producție.
Ca și dovadă a funcționalității, aplica ția a ajuns să fie utilizată , ca sistem unic de salarizare, de
peste 10 clien ți din trei județe diferite, în doar o lună de la lansarea versiunii finale. Acest
lucru demonstrează că, deși sunt și alte companii pe piață, această soluție este suficient de
bună încât să convingă clienții să renunțe la aplicații cu care lucrează de pes te 10 ani.

7.1 Dezvoltări ulterioare

În continuare îmi doresc să extind aplicația pentru a avea integrare cu ReviSal , să fac
modificările necesare pentru a putea fi utilizată cu ușu rință și de companii din domeniul privat
și să dezvolt și o aplicație de contabilitate care să aibă integrarea cu aplicația de salarii pentru
generarea automată a notelor contabile.

8 BIBLIOGR AFIE

2019. C Sharp (programming language). Wikipedia. [Online] 05 15, 2019.
https://en.wikipedia.org/wiki/C_Sharp_(programming_language).

2019. CEFSharp. CEFSharp. [Online] 05 17, 2019. http://cefsharp.github.io/.

Driscoll, Brian, et al. 2013. Entity Framework 6 Recipes. Berkeley : Apress, 2013.

Ghoda Ashish, Mamta Dalal. 2011. XAML developer reference. s.l. : Pearson Education, 2011.

MacDonald, Mathew. 2010. Pro WPF in VB 2010: Windows Presentation Foundation in .NET
4. s.l. : Apres s, 2010. 9781430272410.

Model -View -ViewModel (MVVM) Design Patter n using Windows. Sorensen, E., Mikailesc, M.
2010. s.l. : MegaByte Journal, 2010.

Wood, D. 1968. A proof of Hamblin's algorithm for translation of arithmetic expressions from
infix to postf ix form. s.l. : Kluwer Academic Publishers, 1968. 1572 -9125.

9 ANEXE

9.1 Bază de date

Figura 25 Tabelele complete cu datele salariaților și relațiile dintre ele

9.2 Interpretor formule

Figura 26 Implementarea Algoritmului lui Hamblin pentru transformarea din forma
norm ală în forma postfixată

Figura 27 Interpretor de formule în formă Postfixată

9.3 Generare rapoarte

Figura 28 Getter coloane pentru un raport

Figura 29 Completare dicționar foot er pe baza informațiilor din setările locale ale
aplicației

Figura 30 Procesare adițională a valorilor din coloane

Figura 31 Alte proprie tăți ajutătoare

Figura 32 Situație recapitulativă generată de aplicație

Figura 33 Stat de salarii generat de aplicație