-PLANIFICAREA TASK -URILOR PE LINIILE DE PRODUCȚIE – [615194]

UNIVERSITATEA “LUCIAN BLAGA” DIN SIBIU
FACULTATEA DE INGINERIE
DEPARTAMENTUL DE CALCULATOARE ȘI INGINERIE ELECTRICĂ

PROIECT DE DIPLOMĂ

Îndrumător: Șef lucr. dr. mat. Crețulescu Radu

Absolvent: [anonimizat] : Ingineria Sistemelor Multimedia

– Sibiu, 2017 –

UNIVERSITATEA “LUCIAN BLAGA” DIN SIBIU
FACULTATEA DE INGINERIE
DEPARTAMENTUL DE CALCULATOARE ȘI INGINERIE ELECTRICĂ

APLICA ȚIE WEB
-PLANIFICAREA TASK -URILOR PE LINIILE DE PRODUCȚIE –

Îndrumător: Șef lucr. dr. mat. Crețulescu Radu

Absolvent: [anonimizat] : Ingineria Sistemelor Multimedia

– Sibiu, 2017 –

Cuprins
1 INTRODUCERE ………………………….. ………………………….. ………………………….. ………………….. – 1 –
1.1 DESCRIEREA TEMEI ………………………….. ………………………….. ………………………….. …………………… – 1 –
1.2 OBIECTIVE ………………………….. ………………………….. ………………………….. ………………………….. … – 2 –
1.3 MOTIVAȚIE ………………………….. ………………………….. ………………………….. ………………………….. . – 3 –
2 TEHNOLOGII ȘI LIMBAJ E UTILIZATE ………………………….. ………………………….. …………………… – 4 –
2.1 SCURTĂ DESCRIERE ………………………….. ………………………….. ………………………….. ………………….. – 4 –
2.2 DETALII DESPRE SOFTUL UTILIZAT ………………………….. ………………………….. ………………………….. ….. – 5 –
2.2.1 Visual Studio ………………………….. ………………………….. ………………………….. ……………… – 5 –
2.2.2 C# ………………………….. ………………………….. ………………………….. ………………………….. .. – 6 –
2.2.3 Arhitectura platformei framework -ului .NET ………………………….. ………………………….. – 8 –
2.2.4 .NET și ASP .NET ………………………….. ………………………….. ………………………….. ………… – 9 –
2.2.4.1 Comparare framework -uri ASP .NET ………………………….. ………………………….. ………………… – 10 –
2.2.4.2 Web Forms ………………………….. ………………………….. ………………………….. ………………………. – 11 –
2.2.5 Javascript ………………………….. ………………………….. ………………………….. ……………….. – 12 –
2.2.6 CSS ………………………….. ………………………….. ………………………….. …………………………. – 13 –
2.2.7 Bootstrap ………………………….. ………………………….. ………………………….. ……………….. – 14 –
2.2.8 Console application ………………………….. ………………………….. ………………………….. ….. – 16 –
2.2.9 Class library ………………………….. ………………………….. ………………………….. …………….. – 17 –
2.2.9.1 Class library vs Shared Project ………………………….. ………………………….. …………………………. – 17 –
2.2.10 Baze de date Oracle ………………………….. ………………………….. ………………………….. …. – 18 –
2.2.10.1 Comparație cu alte baze de date ………………………….. ………………………….. …………………… – 18 –
2.2.10.2 Structuri fizice ………………………….. ………………………….. ………………………….. ………………… – 19 –
2.2.10.3 Structuri logice ………………………….. ………………………….. ………………………….. ……………….. – 20 –
2.2.11 SQL Developer ………………………….. ………………………….. ………………………….. …………. – 20 –
2.2.12 IIS………………………….. ………………………….. ………………………….. ………………………….. . – 21 –
2.2.13 Task Scheduler ………………………….. ………………………….. ………………………….. ………… – 24 –
3 ARHITECTURA APLICAȚI EI ………………………….. ………………………….. ………………………….. …. – 25 –
3.1 STRUCTURA APLICAȚIEI ………………………….. ………………………….. ………………………….. ……………. – 25 –
3.1.1 Structura aplicației WEB ………………………….. ………………………….. ……………………….. – 25 –
3.1.1.1 Front -end ………………………….. ………………………….. ………………………….. ………………………… – 25 –
3.1.1.2 Back -end ………………………….. ………………………….. ………………………….. …………………………. – 27 –
3.1.1.3 Legătura intre back -end și front -end ………………………….. ………………………….. ……………….. – 27 –
3.1.2 Structura serviciului de mail -uri ………………………….. ………………………….. ……………… – 28 –

3.1.3 Structura proiectului de clase ………………………….. ………………………….. …………………. – 29 –
3.1.4 Clase ………………………….. ………………………….. ………………………….. ………………………. – 29 –
3.1.4.1 Baza de date ………………………….. ………………………….. ………………………….. …………………….. – 30 –
3.1.4.2 Clase pentru popularea listelor ………………………….. ………………………….. ……………………….. – 31 –
3.1.4.3 Clase pentru funcții ………………………….. ………………………….. ………………………….. …………… – 32 –
3.1.4.4 Clase pentru grafice ………………………….. ………………………….. ………………………….. ………….. – 33 –
3.1.4.5 Clase pentru task -uri ………………………….. ………………………….. ………………………….. …………. – 33 –
3.1.4.6 Clase pentru utilizatori ………………………….. ………………………….. ………………………….. ………. – 34 –
3.1.4.7 Clase pentru mail -uri ………………………….. ………………………….. ………………………….. …………. – 35 –
3.1.4.8 Legătura claselor de task -uri, utilizatori și mail -uri ………………………….. …………………………. – 36 –
3.1.5 Diagrama clas elor ………………………….. ………………………….. ………………………….. ……. – 37 –
3.2 STRUCTURA BAZEI DE DA TE ………………………….. ………………………….. ………………………….. ……….. – 37 –
4 IMPLEMENTĂRI ………………………….. ………………………….. ………………………….. ………………. – 39 –
4.1 MODULELE APLICAȚIEI WEB ………………………….. ………………………….. ………………………….. ……… – 39 –
4.1.1 Autentificare ………………………….. ………………………….. ………………………….. …………… – 39 –
4.1.2 Creare cont ………………………….. ………………………….. ………………………….. ……………… – 41 –
4.1.3 Pagina de start și layout -ul aplicației ………………………….. ………………………….. ………. – 43 –
4.1.4 Adăugare task -uri ………………………….. ………………………….. ………………………….. ……. – 46 –
4.1.5 Vizualizare lista task -uri ………………………….. ………………………….. ………………………… – 49 –
4.1.6 Vizualizare detalii și editare task ………………………….. ………………………….. …………….. – 52 –
4.1.7 Reprogramare task ………………………….. ………………………….. ………………………….. ….. – 59 –
4.1.8 Acceptare/Delegare task ………………………….. ………………………….. ……………………….. – 60 –
4.1.8.1 Acceptare ………………………….. ………………………….. ………………………….. ………………………… – 61 –
4.1.8.2 Delegare ………………………….. ………………………….. ………………………….. ………………………….. – 62 –
4.1.9 Editare informații cont ………………………….. ………………………….. ………………………….. – 63 –
4.1.10 Setări administrator ………………………….. ………………………….. ………………………….. …. – 65 –
4.1.10.1 Serviciul de trimis mail -uri ………………………….. ………………………….. ………………………….. … – 66 –
4.1.10.2 Editare informații din baza de date ………………………….. ………………………….. ………………… – 68 –
4.2 SERVICIUL DE TRIMIS M AIL-URI ………………………….. ………………………….. ………………………….. ……- 70 –
4.3 APLICAȚIA DE CLASE CO MUNE ………………………….. ………………………….. ………………………….. ……. – 75 –
5 CONCLUZII ………………………….. ………………………….. ………………………….. ……………………… – 78 –
6 WEBLIOGRAFIE ȘI BIBL IOGRAFIE ………………………….. ………………………….. …………………….. – 80 –

– 1 –
1 Introducere
1.1 Descrierea temei
În acest moment, în majoritatea firmelor și companiilor care au ca scop principal
producția, pentru a asigura un nivel optim de calitate a produselor și o eficiență ridicată a
angajaților, este esențială menținerea unei bune comunicări între toate părțile implicate în
acest proces.
Putem spune că unul dintre cele mai importante elemente este asigurarea unei metode
optime de comunicare pe liniile de producție, astfel încât operatorii și tehnicienii prezenți să
își cunoască sar cinile care trebuie îndeplinite de către aceștia, iar inginerilor prezenți în
producție, cei care propun task -uri către anumite persoane responsabile, să poată vedea în
timp real statistici cu privire la statusul task -urilor acordate, pentru a putea interv eni.
În momentul participării mele într -o astfel de companie, pe liniile de producție, task –
urile inițializate de către ingineri erau în format scris, atașate pe un panou specific unei linii de
producție, cu anumite detalii și informații specifice sarcinii , responsabilul care trebuie să se
ocupe de acel task, și un status care trebuie actualizat, sub forma unui model PDCA ( Plan,
Do, Check, Act ) de către tehnicianul sau operatorul responsabil. Acesta din urmă trebuia să
verifice constant aceste panouri și ac ele fișe pentru a vedea daca a primit un task nou, iar
inginerii erau nevoiți să se deplaseze între mai multe asemenea puncte, atât pentru a completa
fișele respective, cât și pentru a verifica statusul lor.
Tema aleasă de mine, are ca scop asigurarea unei astfel de posibilități de comunicare,
rapidă, eficientă și ușor de utilizat, pentru a elimina unul dintre factorii prezenți pe liniile de
producție ale companiilor, care în anumite situații reușesc să îngreuneze producția, iar modul
prin care am încercat să realizez acest lucru a fost prin intermediul unei aplicații WEB, cu o
interfață modernă, ușor accesibilă și ușor de gestionat.
Totodată, după simplificarea procesului, având toate datele relevante într -un singur
loc, procesul de verificare a fost și ma i mult simplificat prin intermediul graficelor actualizate
în timp real în funcție de situația curentă. Acestea împreună cu posibilitatea de a notifica
persoanele implicate în anumite task -uri, prin intermediul unui mail, care conținea detalii
sumare despr e task, și un link cu ajutorul căruia puteai accesa direct toate informațiile
înregistrate cu privire la acesta din interiorul aplicației, conduc la o mai bună administrare a
timpului la locul de muncă în aceste situații.

– 2 –
După o analiză a întregului proce s ce trebuie urmărit, am creat o schemă care cuprinde
în mare toți pașii principali care trebuiau urmăriți, asigurând un mod de lucru natural, cu
reguli bine definite, scurt și concis, încercând să cuprind toate variantele de interpretări ale
task-urilor c are pot apărea în rutina zilnică, după cum se poate observa din figura 1.1.

Figura 1.1 Fluxul de lucru
1.2 Obiective
Obiectivul meu a fost, așa cum am menționat și mai sus, de a găsi o modalitate care să
rezolve problema lipsei de comunicare și procesul gre u de preluare și verificare a task -urilor
existente, sau de creare a unor task -uri noi.

– 3 –
De aceea, pentru a asigura o interfață comună și ușor de utilizat de către toți acești
membrii ai procesului de producție, cea mai bună variantă era constituită de impl ementarea
unei aplicații software accesibilă tuturor.
O aplicație WEB aduce cele mai multe avantaje, cum ar fi portabilitatea,
compatibilitatea între diferite platforme, ușurința de accesibilitate, fapt ce m -a determinat să
încep implementarea unui soft me nit să rezolve aceste probleme sub forma unei aplicații
WEB, în ASP .NET webforms și c#, fiind tehnologii moderne și cu suport extins, fapt ce
constituie un avantaj în începerea unui proiect folosind tehnologii noi.
Un alt obiectiv a fost integrarea modelu lui curent, PDCA, cunoscut de toți angajații
firmei, în aplicația WEB, pentru a amplifica nivelul de familiarizare a noilor utilizatori cu
aplicația, oferindu -le posibilitatea de a lucra cu un model cunoscut de către ei, fără a fi nevoiți
să învețe noi met ode de evaluare, încercând astfel o digitalizare a metodei deja existente.
Atingerea acestor obiective urma să asigure un total confort în utilizare, eficiență
sporita, păstrând modelul cunoscut, și o implementare ușoară, având la dispoziție toate
informaț iile necesare despre procesul de lucru cu metodele folosite, fiind benefice deci atât
mie, din ipostaza de programator, cât și utilizatorilor viitoarei aplicații.
1.3 Motivație
După implementarea unei versiuni de test, care conținea doar o parte de adăugare a
task-urilor într -o bază de date, de vizualizare a tuturor task -urilor cu informații mai reduse,
sub o formă tabelară și posibilitatea vizualizării de informații complete cu privire la un task,
menținând modelul cunoscut, după selectarea lui, feedback -ul primit a fost unul în totalitate
pozitiv, aplicația reușind să reducă din timpul pierdut de către angajați prin deplasările la
panourile de care aminteam mai sus și prin căutarea în formularele scrise task -urile cu interes
personal.
Răspunsurile pozitive la această inițiativă m -au motivat să continui dezvoltarea
aplicației, și să implementez funcții care mie îmi păreau utile cât și sugestiile primite de la alți
utilizatori, extinzând astfel ficționalitățile aplicației cu altele secundare, dar la fel de utile .
Un alt factor motivațional important este constituit de oportunitatea și de dorința de a
putea explora și învăța să lucrez cu medii și tehnologii noi, în prisma unui proiect complex,
care urma să îmi îmbogățească cunoștințele în domeniu, întâmpinând diferite situații specifice
programării aplicaților WEB, care, după părerea mea, datorită avantajelor pe care le oferă sunt
tot mai practice.

– 4 –
2 Tehnologii și limbaje utilizate
2.1 Scurtă descriere
Pentru implementarea unei astfel de aplicații este nevoie de uti lizarea unor diverse
servicii și framework -uri.
Cel mai important este alegerea unui limbaj de programare despre care ști că îți oferă
posibilitatea creării aplicației dorite. Limbajele de programare folosite de mine au fost C# și
ASP .net. Cel mai util me diu de programarea pentru aceste limbaje este Visual Studio, produs
de Microsoft, care oferă suport și documentație pentru acestea, ușurând astfel procesul de
implementare.
Având unul dintre obiective crearea unei interfețe ușor de înțeles și de utilizat de către
oricine, a apărut nevoia de a folosi și alte tehnologii ale căror specific constă în dezvoltarea
interfeței cu utilizatorul. Pe lângă formatări cu ajutorul CSS și a javascript, am folosit și unul
din cele mai populare framework -uri dezvoltate în a cest sens, și anume Bootstrap.
Pentru a putea publica această aplicație, făcând -o accesibilă utilizatorilor țintă, este
nevoie de un server, în cazul nostru IIS (Internet Information Services) care este capabil de
interpretarea unui astfel de format, pagin ile compilate din ASP .net având extensia .aspx .
Toate aceste componente nu ar avea nicio valoare fără datele introduse de utilizatori,
de aceea în căutarea unui mediu de stocare a datelor am ales serviciile de baze de date oferite
de Oracle, părând foarte ușor de utilizat și de configurat prin clientul lor de Windows numit
Oracle SQL developer.
Odată cu dezvoltarea aplicației au apărut și alte nevoi sau cerințe, una dintre ele fiind
atenționarea utilizatorilor printr -un email în anumite momente (când task -urile primite /
trimise / delegate au expirat / au fost finalizate / au fost modificate), iar pentru acest lucru a
fost nevoie crearea unui serviciu care să ruleze mereu și să trimită aceste notificări
utilizatorilor. Astfel am creat o nouă aplicație, în același mediu de programare, Visual Studio,
de tip consolă care se ocupă de trimiterea de mail -uri, programat cu ajutorul serviciului de
Windows Task Scheduler să ruleze o data pe zi.
În momentul creări i celei de a doua aplicații, consol ă, complementare a plicației WEB,
a fost nevoie de partajarea anumitor resurse între acestea. Astfel a apărut nevoia unei a treia
aplicații, de tip Class Library, care conține doar conexiunea la baza de date și clasele utilizate,
care odată compilat creează un fișier . dll (Dynamic -link library ) folosit ca referință de ambele

– 5 –
proiecte. O modificare adus ă acestui proiect se propag ă și în celelalte proiecte în mod
automat.
Pentru aplicația aleasă de mine, în acest moment avem:
– O soluție în mediul Visual Studio, care conține trei proiecte :
o aplicația WEB
o aplicația de tip consol ă – responsabil ă cu trimiterea mail -urilor
o aplicația comună de timp Class Library – care asigură consistența dintre
celelalte două proiecte
– O bază de date Oracle în care sunt stocate toate informațiile necesare
– Alte tehnologii, servicii și framework -uri care au ajutat la finalizarea proiectului
2.2 Detalii despre softul utilizat
În rândurile următoare voi aduce mai multe detalii cu privire la mediul de programare
folosit pentru crearea aplicației, tehnologii și framework -uri utilizate în timpul desfășurării
acestui proiect.
Softurile descrise în rândurile următoare sunt cele mai relevante scopului proiectului,
și cele cu un impact ridicat asupra calității produsului final .
2.2.1 Visual Studio
Microsoft Visual Studio este un mediu de dezvoltare integrat (IDE) de la Microsoft.
Acesta este folosit pentru a dezvolta programe de calculator pentru Microsoft Windows,
precum și site -uri web, aplicații web, servicii web și aplicații mobile.
Visual Studio utilizează platforme de dezvoltare software Microsoft cum ar fi
Windows API, Windows Forms, Windows Presentation Foundation, Windows Store și
Microsoft Silverlight.
Visual Studio include un editor de cod care suportă IntelliSense (component ă de
completare a codului), precum și factorizarea codului. [1]
Debugger -ul integrat funcționează atât ca un de panator la nivel de sursă, cât și ca un
depanator la nivel de mașină. Alte instrumente încorporate sunt: un instrument de analiză al
codului, designer de formulare pentru construirea de aplicații grafice, designer web, designer
de clasă și designer de sche mă de baze de date.
Acesta acceptă plugin -uri care îmbunătățesc funcționalitatea la aproape toate
nivelurile, inclusiv adăugarea unor noi seturi de instrumente, cum ar fi editorii și designerii

– 6 –
vizuali, pentru limbajele sau seturile de instrumente specifi ce unui anumit domeniu, sau
pentru alte aspecte ale dezvoltării software (cum ar fi Team Foundation Server).
Visual Studio suportă diferite limbaje de programare și permite editorului de cod și
depanatorului să suporte (în grade diferite) aproape orice li mbaj de programare, cu condiția să
existe un serv iciu specific limbajului. [2]
Lista limbajelor încorporate includ e C, C++ și C++ / CLI (prin Visual C++), VB.NET
(prin Visual Basic .NET), C# (prin Visual C#), F# (din Visual Studio 2010) și TypeScript (din
Visual Studio 2013 Update 2).
Suportul pentru alte limbaje, cum ar fi Python, Ruby, Node.js, M și altele, este
disponibil prin intermediul serviciilor de limbaj i nstalate separat.
Acesta acceptă, de asemenea XML / XSLT, HTML / XHTML, JavaScript și CSS.
Java (și J#) au fost și ele suportate în trecut.
Caracteristici: [2]
• Editor de cod: Ca orice alt IDE, acesta include un editor de cod care acceptă
evidențierea sintaxei și finalizarea codului . Editorul Visual Studio acceptă, de
asemenea, setarea marcajelor pentru navigare rapidă. Visual Studio include și
compilație în fundal .
• Debugger: Visual Studio include un program de depanare care funcționează atât ca un
depanator la nivel de sursă, cât și ca debugger la nivel de mașină.
• Designer: Visual Studio include o serie de designeri vizuali care ajută la dezvoltarea
aplicațiilor. A ceste instrumente includ:
o Windows Forms Designer,
o WPF Designer,
o Web designer
Microsoft oferă o versiune gratuită a Visual Studio numită ediție Community care
acceptă plugin -uri și este disponibilă fără niciun cost.
2.2.2 C#
C# este un limbaj de programare orient at pe obiecte care le permite dezvoltatorilor să
construiască o varietate mare de aplicații robuste și securizate, compatibile cu framework -ul
.NET. Acesta poate fi folosit pentru crearea aplicaților pentru Windows, servicii web XML,
aplicații server -clien t, aplicații legate la baze de date și multe altele. C# Visual pune la
dispoziție un editor de code avansat , o interfață ușor de utilizat, un debugger integrat și multe

– 7 –
alte instrumente care ușurează dezvoltarea aplicațiilor bazate pe limbajul C# și framew ork-ul
.NET. [3]
Sintaxa C# este extrem de expresivă, dar este, de asemenea, simplă și ușor de învățat.
Sintaxa limbajului C# va fi recunoscută oricărei persoane ca re este familiarizată cu C, C++
sau Java. Dezvoltatorii care cunosc oricare dintre aceste limbaje pot de obicei să înceapă să
lucreze productiv în C# într -un timp foarte scurt. Sintaxa C# simplifică multe dintre
complexități ale C++ și oferă caracteristici importante, cum ar fi tipurile de valori care pot fi
nule, enumerări, expresii lambda și acces direct la memorie, care nu se găsesc în Java. C#
suportă metode și tipuri generice, care asigură o siguranță sporită și performanță crescută.
Language -Integrat ed Query (LINQ) face ca interogarea introdusă să fie o construcție de
limbaj de primă clasă. [4]
Ca limbaj orientat pe obiecte, C# sprijină conceptele de încapsular e, moștenire și
polimorfism. Toate variabilele și metodele, inclusiv metoda principală, punctul de intrare al
aplicației, sunt încapsulate în cadrul definițiilor de clasă. O clasă poate moșteni direct o clasă
părinte, dar poate implementa orice număr de in terfețe. Metodele care înlocuiesc metodele
virtuale într -o clasă părinte necesită un cuvânt cheie „override” ca o modalitate de a evita
redefinirea în mod accidental. În C#, o structura este un tip de clasa care funcționează
asemănător unei stive care poat e implementa interfețe, dar nu suportă moștenirea. [3]
Pe lângă aceste principii de bază orientate pe obiecte, C# facilitează dezvoltarea
componentelor software pri n intermediul mai multor construcții inovatoare de limbaj, printre
care: [5]
– Metode de încapsulare numite delegații , care permit notificări de eveniment în
condiții de siguranță.
– Proprietăți care servesc drept de acces pentru variabilele de membri privați.
– Atribute, care oferă meta date declarative despre tipuri la timpul de execuție.
– Comentariile în documentele XML
– Language -Integrated Query (LINQ) care oferă capabilități integrate de interogare
într-o varietate mare de surse de date.
Dacă trebuie să interacționați cu alte softuri Windows cum ar fi obiectele COM sau
DLL -urile native Win32, puteți face acest lucru în C# printr -un proces numit "Interop".
Interop permite programelor C# să facă aproape orice poate face o aplicație nativă C++. C#
suportă chiar și pointeri și conceptul de cod "nesigur" pentru acele cazuri în care accesul
direct la memorie este absolut critic. [4]

– 8 –
Procesul de construire al aplicațiilor în limbajul de programare C# este simplu în
comparație cu C și C++ și mai flexibil decât în Java. Nu există fișiere separate de antet și nici
o cerință ca metod ele și tipurile să fie declarate într -o anumită ordine. Un fișier sursă C# poate
defini orice număr de clase, structuri, interfețe și evenimente.
2.2.3 Arhitectura platformei framework -ului .NET
Programele C# rulează pe framework -ul .NET, o componentă integrală a Windows
care include un sistem de execuție virtuală numit CLR (common language runtime) și un set
unificat de biblioteci de clase. CLR este implementarea comercială de către Microsoft a
infrastructurii lingvistice comune (CLI), un standard internațional care stă la baza creării de
medii de execuție și dezvoltare în care limbajele și bibliotecile colaborează fără probleme.
Codul sursă scris în C# este compilat într -un limbaj intermediar (IL) care se
conformează specificației CLI. Codul și resursele IL, cum ar fi fișiere bitmap și șirurile de
caractere, sunt stocate pe disc într -un fișier executabil denumit un ansamblu, de obicei cu
extensia .exe sau .dll. Un ansamblu conține un manifest care ne oferă informații despre
tipurile, versiunea și cerințele de sec uritate ale ansamblului.
Când programul C # este executat, ansamblul este încărcat în CLR, care poate lua
diverse acțiuni pe baza informațiilor din manifest. Apoi, dacă cerințele de securitate sunt
îndeplinite, CLR efectuează compilarea „ just in time ” (JIT) pentru a converti codul IL în
instrucțiuni mașină native. CLR oferă și alte servicii legate gestionarea excepțiilor și
gestionarea resurselor. Codul care este executat de CLR este denumit uneori "cod gestionat",
spre deosebire de "codul negestionat" care este compilat în limbajul mașinii native care
vizează un anumit sistem. Figura 2.1 ilustrează relațiile de compilare și timpul de execuție ale
fișierelor cu cod sursă C#, bibliotecile, asamblările și CLR din clasa .NET Framework. [6]
Interoperabilitatea lingvistică este o caracteristică cheie a framework -ului .NET.
Deoarece codul IL produs de către compilatorul C# este conform cu „Common Type
Specification” (CTS), cod ul IL generat de C# poate interacționa cu codul care a fost generat
din versiunile .NET ale Visual Basic, Visual C++ sau oricare dintre celelalte douăzeci de
limbaje compatibile cu CTS. Un singur ansamblu poate conține mai multe module scrise în
diferite l imbaje .NET, iar tipurile se pot referi unul la celălalt ca și cum ar fi fost scrise în
același limbaj. [7]

– 9 –

Figura 2.1 De la codul sursă C# la execuția mașinii [3]

Framework -ul .NET include, de asemenea, o bibliotecă extinsă de peste 4000 de clase
organizate în namespace -uri care oferă o mare varietate de funcționalități utile pentru orice, de
la utilizarea fișierelor până la manipularea șirurilor, de la controale în Windows Forms până la
parsarea fișierelor XML. Aplicația tipică C# utilizează extensiv biblioteca de clasă .NET
Framework pentru a gestiona lucrurile comune.
2.2.4 .NET și ASP .NET
Framework -ul .NET constă în CLR (common language runtime) și biblioteca
de clase .NET Framework. Limbajul de rulare comun este fundamentul .NET. Vă puteți gândi
la timpul de execuție ca agent care gestionează codul la timpul de execuție , oferind servicii de
bază, cum ar fi gestionarea memoriei, gestionarea firului și remoting. De fapt, conceptul de
management al codului este un principiu fundamental al runtime -ului. Codul care vizează
timpul de execuție este cunoscut sub numele de cod ge stionat(managed code), în timp ce
codul care nu vizează timpul de execuție este cunoscut sub numele de cod
negestionat(unmanaged code). [7]
Biblioteca de clase est e o colecție cuprinzătoare, orientată spre obiecte, de tipuri
reutilizabile care se pot utiliza pentru a dezvolta aplicații variind de la aplicații tradiționale de
linie de comandă sau interfață grafică (GUI) la aplicații bazate pe cele mai recente inovați i
furnizate de ASP.NET, cum ar fi Formulare Web și servicii Web XML.

– 10 –
Framework -ul .NET poate fi găzduit de componente neadministrate care încarcă
runtime -ul comun al limbajului în procesele lor și inițiază executarea unui cod gestionat,
creând astfel un me diu software care să poată exploata atât funcțiile gestionate, cât și cele
neadministrate. [8]
ASP.NET găzduiește timpul de execuție pentru a oferi un mediu scalabi l, de partea
serverului pentru codul gestionat .[9]
Internet Explorer este un exemplu de aplicație negestionata care găzduiește timpul de
execuție (sub forma unei ex tensii de tip MIME). Utilizarea Internet Explorer pentru a găzdui
runtime -ul permite încorporarea componentelor gestionate sau controalelor Windows Forms
în documente HTML. Găzduirea runtime -ului în acest fel face posibilă gestionarea codului
mobil, dar cu îmbunătățiri semnificative pe care numai codul gestionat le poate oferi.
ASP.NET este un framework de web gratuit pentru construirea de site -uri și aplicații
web folosind HTML, CSS și JavaScript . De asemenea, cu ajutorul ASP .NET se pot crea API –
uri Web și se pot utiliza tehnologii în timp real, cum ar fi Web Sockets. [9]
ASP.NET oferă trei framework -uri pe ntru crearea de aplicații web: Web Forms,
ASP.NET MVC și ASP.NET Web Pages.
2.2.4.1 Comparare framework -uri ASP .NET
Mai jos am prezentat pe scurt o modalitate de a alege unul dintre cele trei framework –
uri amintite pe baza experiențelor anterioare sau pe baza st ilului de dezvoltare al codului.

Experiență similara Stil de dezvoltare al aplicațiilor
Web
Forms Windows Forms,
WPF, .NET Dezvoltare rapidă utilizând o bibliotecă bogată de controale care
încorporează marcajul HTML
MVC Ruby on Rails, .NET Control complet asupra marcajului HTML, codului și marcajului separat
și testelor ușor de scris. Cea mai bună alegere pentru aplicațiile mobile și
pentru o singură pagină (SPA).
Web
Pages Classic ASP, PHP Marcajul HTML și codul împreună în același fișier
Tabel 2 .1 Comparare Framework -uri ASP .NET

Toate cele trei framework -uri ASP.NET se bazează pe framework -ul .NET și pe
funcționalitatea de bază a .NET și ASP.NET. De exemplu, toate cele trei cadre oferă un model
de securitate de autentificare, bazat pe membri, i ar toate au aceleași facilități pentru

– 11 –
gestionarea solicitărilor, gestionarea sesiunilor și așa mai departe, care fac parte din
funcționalitatea ASP.NET de bază. [6][7][8]
În plus, cele trei framework -uri nu sunt complet independente, iar alegerea unuia nu
exclude utilizarea unui alt framework. Deoarece framework -urile pot coexista în aceeași
aplicație web, nu este neobișnuit să se vadă componentele individuale ale aplicațiilor scrise
utilizând diferit e cadre. De exemplu , porțiuni de cod pentru un client al unei aplicații ar putea
fi dezvoltate în MVC pentru a optimiza markup -ul, în timp ce accesul la date și porțiunile
administrative sunt dezvoltate în Web Forms pentru a profita de controalele de date și de
accesul simplu la date. [9]
2.2.4.2 Web Forms
ASP.NET Web Forms face parte din framework -ul web ASP.NET și este inclus în
Visual Studio.
Web Forms sunt pagini pe care utilizatorii le solicită utilizând browser -ul lor. Aceste
pagini pot fi scrise folosind o combinație de cod HTML, scripturi pe partea clientului ,
controale de server și cod server. Când utilizatorii accesează o pagină, aceasta este com pilată
și executată pe server de către framework, iar apoi framework -ul generează marcajul HTML
pe care browser -ul îl poate afișa. O pagină ASP.NET Web Forms prezintă informații
utilizatorului în orice browser sau dispozitiv client. [10]
Utilizând Visual Studio, pot fi create formulare Web ASP.NET. Mediul de dezvoltare
integrat Visual Studio (IDE) permite adăugarea de controale pe pagini folosind metode de
„drag and drop” dintr -o lista de controale, putând apoi seta cu ușurința proprietățile acestora,
metode și evenimente de pe pagina. Aceste proprietăți, metode și evenimente sunt folosite
pentru a defini comportamentul paginii web, aspectul și așa mai departe. Codul responsabil cu
rolul de a gestiona logica paginii poate fi scris în orice limbaj .NET, cum ar fi Visual Basic
sau C#.
ASP.NET Web Forms este:[10]
– Bazat pe tehnolog ia Microsoft ASP.NET, în care codul care rulează pe server
generează dinamic ieșirea paginii web în browser sau în dispozitivul client.
– Compatibil cu orice browser sau dispozitiv mobil. O pagină Web ASP.NET redă
automat codul corect HTML compatibil cu brow ser-ul pentru stiluri, layout, etc.
– Compatibil cu orice limbaj suportat de runtime -ul limbajului .NET, cum ar fi
Microsoft Visual Basic și Microsoft Visual C#.

– 12 –
– Construit pe framework -ul Microsoft .NET. Aceasta oferă toate avantajele
framework -ului, inclusi v un mediu gestionat și moștenirea.
– Flexibil pentru că pot fi adăugate controale create de utilizatori și de la terțe părți.
ASP.NET Web Forms oferă:
– Separarea codului HTML și a altor coduri UI din logica aplicației.
– O suită bogată de controale de server p entru sarcini comune.
– Legătură puternică a datelor.
– Suport pentru scripting pe partea clientului care se execută în browser.
Framework -ul bazat pe Web Forms oferă următoarele avantaje:
– Acesta susține un model de eveniment care păstrează starea curentă prin HTTP.
– Utilizează un model de controler de pagină care adaugă funcționalitate paginilor
individuale.
– Utilizează formularele bazate pe stare sau pe server, ceea ce face mai ușor
gestionarea informațiilor de stare.
– Dezvoltarea rapidă a aplicațiilor.
În gen eral, este mai puțin complex pentru dezvoltarea aplicațiilor, deoarece
componentele (clasa de pagini, comenzile etc.) sunt strâns integrate și de obicei necesită un
cod mai mic decât modelul MVC.
2.2.5 Javascript
JavaScript, prescurtat ca "JS", este un limbaj de run-time de nivel înalt, dinamic,
interpretat și fără tipuri de variabile, orientat pe obiecte, cu funcții de primă clasă și este cel
mai bine cunoscut sub numele de limbaj de scripting pentru paginile web, dar este folosit și în
multe medii non -browser.
JavaScript rulează pe partea clientului web, care poate fi folosit pentru a proiecta /
programa modul în care paginile web se comportă la apariția unui eveniment. JavaScript este
un limbaj ușor de învățat și de asemenea un limbaj foarte puternic de script ing, utilizat pe
scară largă pentru controlul comportamentului paginii web. [11]
Pe scurt, JavaScript este un limbaj de scripting dinamic care susține construcția de
obiecte bazate pe prototipuri. Sintaxa de bază este intenționat similară atât cu Java cât și cu
C++ pentru a reduce numărul de concepte noi necesare pentru a învăța limbajul. [12]
JavaScript poate funcționa atât ca limbaj procedural, cât și orientat pe obiecte.
Obiectele sunt create în mod programabil în JavaScript , prin atașarea de metode și proprietăți
la alte obiecte goale la timpul de execuție, spre deosebire de definițiile clasei sintactice

– 13 –
comune în limbajele compilate precum C++ și Java. Odată ce un obiect a fost construit, acesta
poate fi folosit ca un model (sau prototip) pentru crearea unor obiecte similare.
Alături de HTML și CSS, JavaScript este una dintre cele trei tehnologii de bază ale
producției de conținut în World Wide Web. Majoritatea site -urilor web îl folosesc și toate
browser -ele web moderne îl suportă fără a fi nevoie de plug -in-uri. Este un limbaj de
scripting bazat pe prototip, multi -paradigmă, care este dinamic și susține stiluri de programare
orientate spre obiect, imperativ și funcțional. Are un API pentru a lucra cu text, matrice, date
și expresii, dar nu include niciun avantaj I / O, cum ar fi facilități de rețea, stocare sau grafică,
bazându -se pe mediul gazdă în care este încorporat. [12]
Deși ex istă similitudine puternică între JavaScript și Java, inclusiv numele limbajelor,
sintaxa și bibliotecile standard respective, cele două sunt limbaje distincte și diferă foarte mult
în ceea ce privește designul.
JavaScript este, de asemenea, utilizat în m edii care nu sunt bazate pe Web, cum ar fi
documente PDF, browsere specifice și widget -uri desktop. Mașinile virtuale JavaScript (VM)
și platformele construite pe ele au crescut, de asemenea, popularitatea JavaScript -ului pentru
aplicațiile Web. Pe partea clientului, dezvoltatorii au implementat în mod tradițional
JavaScript ca limbaj interpretat, dar browser -ele mai recente efectuează compilarea just -in-
time.
Programatorii utilizează, de asemenea, JavaScript în dezvoltarea de jocuri video, în
crearea de a plicații desktop și mobile și în programare de rețea de la server cu medii de
execuție cum ar fi Node.js.
2.2.6 CSS
Cascading Style Sheets (CSS) este un limbaj de script utilizat pentru prezentarea unui
document scris într -un limbaj de markup cum sunt paginile w eb. Deși cel mai adesea este
folosit pentru a seta stilul vizual al paginilor web și al interfețelor folosite de client scrise în
HTML și XHTML, limbajul poate fi aplicat oricărui document XML, inclusiv XML simplu,
SVG și XUL.
Împreună cu HTML și JavaScrip t, CSS este o tehnologie de bază folosită de
majoritatea site -urilor web, în interfețele utilizator pentru aplicații web și interfețele pentru
utilizatori pentru multe aplicații mobile. [13]
CSS este independent de HTML și poate fi utilizat cu orice limbaj de markup bazat pe
XML. Separarea codului HTML de CSS facilitează menținerea site -urilor, partajarea foilor de
stil între pagini și adaptarea paginilor la medii di ferite.

– 14 –
CSS este conceput în primul rând pentru a permite separarea conținutului
documentului de prezentarea documentelor, inclusiv aspecte precum aspectul, culorile și
fonturile. Această separare poate îmbunătăți accesibilitatea conținutului, poate oferi mai multă
flexibilitate și control în specificațiile de prezentare, permite mai multor pagini HTML să
partajeze formatarea prin specificarea CSS -ului relevant într -un fișier separat .css și să reducă
complexitatea și repetarea în conținutul structural. [14]
Separarea formatării și a conținutului face posibilă prezentarea aceleiași pagini de
marcare în diferite stiluri pentru diferite metode de randare, cum ar fi pe ecran, prin
imprimare, prin voce (prin intermediul browser -ului bazat pe vorbire sau cititor de ecran) și pe
dispozitive cu ecran tactil pe bază de Braille. De asemenea, poate afișa diferit pagina web, în
funcție de dimensiunea ecranului sau de dispozit ivul de vizualizare. De asemenea, clienții pot
specifica o altă foaie de stil, cum ar fi un fișier CSS stocat pe calculatorul propriu, pentru a
înlocui cel specificat de autor.
Modificările aduse designului grafic al unui document (sau sute de documente) p ot fi
aplicate rapid și ușor, prin editarea câtorva linii în fișierul CSS pe care îl folosesc, mai
degrabă decât prin modificarea marcajului în documente.
Specificația CSS descrie o schemă prioritară pentru a determina ce reguli de stil se
aplică dacă mai multe reguli se potrivesc cu un anumit element. În această așa -numită
cascadă, prioritățile (sau greutățile) sunt calculate și atribuite regulilor, astfel încât rezultatele
să fie previzibile. [14]
CSS are o sintaxă simplă și utilizează un număr de cuvinte cheie în limba engleză
pentru a specifica numele diferitelor proprietăți ale stilului.
O foaie de stil constă într -o listă de reguli. Fiecare regulă sau set de reguli constă într –
unul sau mai mulți selectori și un bloc de declarație.
2.2.7 Bootstrap
Bootstrap este un framework web gratuit și open -source pentru web design și aplicații
web. Acesta c onține șabloane de design HTML și CSS pentru tipografii, formulare, butoane,
navigație și alte componente de interfață, precum și extensii JavaScript opționale. Spre
deosebire de multe framework -uri web, se referă numai la dezvoltarea front -end-ului.[15]
Bootstrap este al doilea proiect cu cele mai multe stele de pe GitHub, cu mai mult de
107.000 de stele și 48.000 de copii modificate.
Bootstrap, denumit inițial Twit ter Blueprint, a fost dezvoltat de Mark Otto și Jacob
Thornton la Twitter ca un framework pentru a încuraja coerența între instrumentele interne.

– 15 –
Înainte de Bootstrap, s -au folosit diferite biblioteci pentru dezvoltarea interfeței, ceea ce a dus
la inconse cvențe și la o mare povară de întreținere.
Bootstrap acceptă cele mai recente versiuni ale browser -ului Google Chrome, Firefox,
Internet Explorer, Opera și Safari.
Începând cu 2.0, Bootstrap suportă un design web sensibil. Aceasta înseamnă că
aspectul pa ginilor web se ajustează dinamic, ținând cont de caracteristicile dispozitivului
utilizat (desktop, tabletă, telefon mobil).
Structura fișierelor folosite de framework -ul bootstrap, care conține fișiere ușor
editabile și ușor de personalizat pentru fiecare necesitate, este prezentata în figura 2.2:

Figura 2.2 Fișiere folosite de BootStrap [16]
Începând cu versiunea 3.0, Bootstrap a adoptat o filosofie de proiectar e mobilă,
subliniind în mod implicit designul receptiv.
Versiunea 4.0 Alpha a adăugat suportul Sass și flexbox.
Bootstrap este modular și constă într -o serie de foi de stil „Less stylesheet ” care
implementează diferitele componente ale setului de instrumente. Aceste foi de stil sunt în
general compilate într -un pachet și sunt incluse în paginile web, dar componentele individuale
pot fi incluse sau eliminate. Bootstrap oferă o serie de variab ile de configurare care
controlează lucrurile precum culoarea și umplutura de diverse componente.
De la Bootstrap 2, documentația Bootstrap a inclus un expert de personalizare care
generează o versiune personalizată a Bootstrap bazată pe componentele solic itate și pe diferite
setări.
Începând cu Bootstrap 4, Sass este folosit în loc de Less pentru foile de stil.

– 16 –
Fiecare componentă Bootstrap constă dintr -o structură HTML, declarații CSS și, în
unele cazuri, însoțirea codului JavaScript.
Sistemul de grilă și designul receptiv sunt standard cu un layout de rețea de 1170
pixeli. Alternativ, dezvoltatorul poate utiliza un aspect cu lățime variabilă. În ambele cazuri,
setul de instrumente are patru variante pentru a utiliza diferite rezoluții și tipuri de dispozit ive:
telefoane mobile, portret și peisaj, tablete și calculatoare cu rezoluție redusă și înaltă. Fiecare
variație ajustează lățimea coloanelor.
Bootstrap oferă un set de foi de stil care oferă definiții de bază pentru toate
componentele HTML cheie. Acestea oferă un aspect uniform și modern pentru formatarea
textului, a tabelelor și a elementelor de formă.
În plus față de elementele HTML obișnuite, Bootstrap conține și alte elemente de
interfață utilizate în mod obișnuit. Componentele sunt implementate ca cl ase CSS, care
trebuie aplicate anumitor elemente HTML dintr -o pagină.
Bootstrap vine cu mai multe componente JavaScript sub formă de plug -inuri jQuery.
Acestea oferă elemente suplimentare de interfață cu utilizatorul, cum ar fi casete de dialog,
vârfuri de instrumente și caruseluri. Ele extind, de asemenea, funcționalitatea anumitor
elemente de interfață existente, inclusiv, de exemplu, o funcție de auto -completare pentru
câmpurile de intrare. În versiunea 2.0, sunt acceptate următoarele plug -inuri JavaScri pt:
Modal, Dropdown, Scrollspy, Tab, Tooltip, Popover, Alertă, Buton, Restrângere, Carusel și
Typeahead. [15]
2.2.8 Console application
O aplicație consola este un program de calculator conceput pentru a fi utilizat printr -o
interfață de calculator numai pentru text, cum ar fi un terminal de text, interfaț a de linie de
comandă a unor sisteme de operare (Unix, DOS etc.) sau interfața bazată pe text inclusă în
sisteme de operare grafică pentru interfața cu utilizatorul (GUI), cum ar fi consola Win32 în
Microsoft Windows, Terminalul în Mac OS X și xterm în Uni x. [17]
Un utilizator interacționează în mod obișnuit cu o aplicație de consolă folosind doar o
tastatură și un ecran de afișare, spre deosebire de aplicațiile GUI , care în mod normal necesită
utilizarea unui mouse sau a altui dispozitiv de indicare. Multe aplicații de consolă, cum ar fi
interpreți de linie de comandă, sunt instrumente de linie de comandă, însă există și numeroase
programe de interfață cu utilizator ul (text-based user interface (TUI) ) bazate pe text.
Pe măsură ce viteza și ușurința de utilizare a aplicațiilor GUI s -au îmbunătățit în timp,
utilizarea aplicațiilor de consolă a scăzut mult, dar nu a dispărut. Unii utilizatori preferă pur și

– 17 –
simplu apli cații bazate pe console, în timp ce unele organizații se bazează în continuare pe
aplicațiile console existente pentru a gestiona sarcinile cheie de procesare a datelor.
Abilitatea de a crea aplicații de consolă este păstrată ca o caracteristică a unor med ii de
programare moderne, cum ar fi Visual Studio și .NET Framework pe Microsoft Windows,
deoarece simplifică foarte mult procesul de învățare al unui nou limbaj de programare prin
eliminarea complexității unei interfețe grafice de utilizator.
Pentru sarci nile de prelucrare a datelor și administrarea computerelor, aceste medii de
programare reprezintă nivelul următor al sistemului de operare sau controlul procesării datelor
după scripting. Dacă o aplicație va fi administrată doar de programatorul original ș i / sau de
câțiva colegi, este posibil să nu existe o interfață grafică destul de utilă, care să lase aplicația
mai ușoară, mai rapidă și mai ușor de întreținut.
2.2.9 Class library
O aplicație de tip Class Library are un scop important, mai ales în proiectele m ari, în
care o mare parte din cod poate fi refolosibil. Aceasta permite salvarea claselor, a business
logic -ului aplicației într -un proiect comun, care poate fi apelat din mai multe părți,
modificările acestuia fiind aplicate în toate aplicațiile în care p roiectul class library este folosit
ca și referință, modificările putând fi observate imediat după momentul compilării. [18]
O aplicație de acest tip nu are un exec utabil, nu poate fi rulata, în momentul compilării
codului prezent în aceasta generându -se automat un fișier ”dll” care conține toata structura
aplicației.
Acest fișier (nume_proiect.dll) îl regăsim în referințele proiectelor care folosesc class
library ca referință.
Acest tip de aplicație nu este singurul care oferă aceste beneficii.
2.2.9.1 Class library vs Shared Project
Diferența dintre un Shared Project și Class Library este că acesta din urma este
compilat și unitatea de reutilizare este codul asamblare, in timp in primul, unitatea de
reutilizare este codul sursă, iar codul partajat este încorporat în fiecare ansamblu care se referă
la proiectul partajat, lucru ce poate fi util atunci când se dorește crearea de ansambluri
separate care vizează anumite platfo rme, dar au în continuare cod comun.
În Class Library, atunci când codul este compilat, ansamblurile (dll -uri) sunt generate
pentru fiecare bibliotecă, dar, cu Shared Project, acesta nu va conține nicio informație antet,

– 18 –
astfel încât atunci când aveți o re ferință a unui proiect comun, acesta va fi compilat ca parte a
aplicației părinte. Nu vor fi create DLL -uri separate. [19]
În Class Library aveți permisiunea de a scrie numai codul C#, în timp ce proiectul
partajat poate avea orice fel de fișiere de cod C#, fișiere XAML sau fișiere JavaScript etc.
2.2.10 Baze de date Oracle
Un server de baze de date Oracle este alcătuit dintr -o bază de date Oracle ș i o instanță
Oracle. De fiecare dată când se pornește o bază de date, este alocată o zonă globală de sistem
(SGA) și sunt pornite procesele de fundal Oracle. Combinația dintre procesele de fundal și
buffer -ele de memorie se numește instanță Oracle.
La ins talarea bazelor de date, în mod implicit se pot accesa direct de pe ip -ul local, sau
de la adresa localhost de pe portul 8080, de unde se poate ulterior configura după
preferințe. [20]
2.2.10.1 Comparație cu alte baze de date

Join
type/feature PostgresSQL DB2 MSSQL MySQL Oracle Informix
Join-uri
naturale X X X
Utilizarea
clauzelor X X X
Join-uri
complete X X X X X
Join-uri
explicit
încrucișate X X X X X X
Tabel 2.2 Comparare baze de date
Datorit ă suportului mult mai extins și a documentației mai ample a bazei de date de la
Oracle, a făcut aceasta varianta să fie cea mai optim ă alegere. [21]
Dar datorită diferenței foarte mici intre acesta și MySQL , care are suport mai mare în
softurile utilizate pentru crearea proiectelor folosind serviciile Microsoft am recurs la o
comparație între acestea pentru a stabili mediul optim pentru crearea bazei de date.
Următoarele functionalitati sunt disponibile în O racle, dar nu și în MySQL, ceea ce a făcut
clara viitoarea alegere:

– 19 –
• Amânarea constrângerilor
• Verificarea constrângerile
• Interogări recursive
• Funcții în tabele
• Expresii comune
• Funcții bazate pe index
• Indice parțial
• Instrument optimizator pentru sub -interogări
• O mulțime de sintaxe non -standard (ex. ||)
2.2.10.2 Structuri fizice
1. Fișiere de date (* .dbf)
Fișierele conțin toate datele bazei de date. Datele structurilor de baze logice, cum ar fi
tabelele și indexurile, sunt stoca te fizic în fișierele de date alocate unei baze de date.
2. Fișiere de control (* .ctl)
Fiecare bază de date Oracle are un fișier de control. Un fișier de control conține intrări
care specifică structura fizică a bazei de date, cum ar fi numele bazei de date și numele și
locațiile fișierelor de date și fișierele de refacere a log -urilor.
3. Fișierele jurnal (* .log)
Funcția principală a redo log este de a înregistra toate modificările aduse datelor. Dacă
o eroare împiedică scrierea permanentă a datelor modificate în fișierele de date, atunci
modificările pot fi obținute din redo log, astfel încât munca nu se pierde niciodată.
4. Arhiva fișierelor jurnal (* .log)
Oracle arhivează fișierele jurnal în mod automat atunci când baza de date este în
modul ARCHIVELOG. Acest lucru împiedică oracolul să suprascrie fișierele de redo log
înainte de a fi arhivate în siguranță într -o altă locație.
5. Fișierele parametrilor (initSID.ora)
Fișierele cu parametri conțin o listă de parametri de configurare pentru acea instanță și
baza de d ate.
6. Alerte și urmărire fișiere log (* .trc)
Fiecare proces de server și de fundal poate fi scris într -un fișier de urmărire asociat.
Atunci când o eroare internă este detectată printr -un proces, ea elimină informații despre
eroare în fișierul de urmărire. Jurnalul de alertă al unei baze de date este un jurnal cronologic
de mesaje și erori.

– 20 –
2.2.10.3 Structuri logice
O bază de date este împărțită în unități de stocare logice denumite spații de
tabelă(tablespaces), care grupează structuri logice împreună. Unul sau mai multe fișiere de
date sunt create în mod explicit pentru fiecare spațiu de tabelă pentru a stoca fizic datele
tuturor structurilor logice într -un spațiu de tabelă.
La cel mai înalt nivel de granularitate, datele bazei de date Oracle sunt stocate în
blocur i de date. Un bloc de date corespunde unui număr specific de octeți din spațiul fizic al
bazei de date pe disc. Dimensiunea standard a blocului este specificată de parametrul de
inițializare DB_BLOCK_SIZE.
Următorul nivel al spațiului logic al bazei de dat e este o măsură (extent). O măsură
este un număr specific de blocuri de date contigue, obținute într -o singură alocare, utilizat
pentru a stoca un anumit tip de informații.
Deasupra domeniilor, nivelul de stocare logică a bazei de date este un segment. Un
segment este un set de masuri alocate unei anumite structuri logice. Diferitele tipuri de
segmente sunt:
• Segment de date – stochează datele de tabel
• Segment index – stochează datele index
• Segment temporar – spațiu temporar utilizat în timpul execuției SQL
• Rollback Segment – stochează anularea informațiilor
O schemă este o colecție de obiecte ale unei baze de date. O schemă este deținută de
un utilizator de bază de date și are același nume ca și acel utilizator. Obiectele de schemă sunt
structurile logice ca re se referă direct la datele bazei de date și includ structuri precum tabele,
vizualizări și indexuri.
2.2.11 SQL Developer
Oracle SQL Developer este un mediu integrat de dezvoltare (IDE) pentru lucrul cu
SQL în bazele de date Oracle, care simplifică dezvoltare a și gestionarea bazelor de date în
ambele implementări, tradiționale și Cloud.
Oracle Corporation oferă acest produs gratuit.
Utilizează Kitul de dezvoltare Java.
SQL Developer oferă o dezvoltare completă a aplicațiilor PL /SQL, o foaie de lucru
pentru rularea interogărilor și scripturilor, o consolă DBA pentru gestionarea bazei de date, o

– 21 –
interfață de rapoarte, o soluție completă de modelare a datelor și o platformă de migrare
pentru importarea bazelor de date de la alte baze de date către Or acle.[22]
2.2.12 IIS
Internet Information Services (IIS) pentru Windows Server este un server Web
flexibil, securizat și ușor de gestionat pentru a găzdui orice aplicație Web. De la streaming
media la aplicații web, arhitectura scalabilă și deschisă a IIS este gata să facă față celor mai
exigente sarcini. Internet Information Services (IIS, fost Internet Information Server) este un
server web extensibil creat de Microsoft. IIS acceptă HTTP, HTTPS, FTP, FTPS, SMTP și
NNTP.
Modul de funcționare al IIS, parcursul unei cereri de autentificare și de permitere a
accesului în aplicație a unui utilizator este prezentat în figura 2.3:

Figura 2.3 Mod funcționare IIS [23]

– 22 –
IIS are o arhitectură modulară. Modulele, numite și extensii, pot fi adăugate sau
eliminate individual, astfel încât să fie instalate numai modulele necesare funcționalității
specifice. IIS include module native ca parte a instalării complete. Aceste module sunt
caracteristici individuale pe care le utilizează serverul pentru a procesa cererile și includ
următoarele: [24]
• Module de securitate: utilizate pentru a efectua mai multe sarcini legate de securitate
în conducta de procesare a cererilor, cum ar fi specificarea schemelor de autentificare,
autorizarea URL -ului și filtrarea cererilor.
• Module de conținut: utilizate pentru a efectua sarcini legate de conținutul din conducta
de procesare a cererilor, cum ar fi procesarea cererilor pentru fișiere statice, returnarea
unei pagini implicite atunci când un client nu specifică o resursă într -o solicitare și
listarea conținutului unui director.
• Module de comprimare: utilizate pentru a efectua sarcini legate de comprimare în
conducta de procesare a cererilor, cum ar fi comprimarea răspunsurilor, aplicarea
codării transferului de compresie Gzip la răspunsuri și efectuarea precomprimării
conținutului static.
• Module cache: utilizate pentru a efectua sarcini legate de cache în conducta de
procesare a cererilor, cum ar fi stocarea informațiilor prelucrate în memorie pe server
și utilizarea conținutu lui memorat în cache în cererile ulterioare pentru aceeași resursă.
• Module de logare și diagnosticare: Se utilizează pentru a efectua sarcini legate de
logare și diagnoză în conducta de procesare a cererilor, cum ar fi transmiterea
informațiilor și starea procesării către HTTP.
Autentificarea a fost ușor modificată între IIS 6.0 și IIS 7, mai ales prin faptul că
utilizatorul anonim numit "IUSR_ {numeleCalculatorului}" este un cont încorporat în Vista și
în sistemele de operare viitoare și numit "IUSR". În s pecial, în IIS 7, fiecare mecanism de
autentificare este izolat în propriul său modul și poate fi instalat sau dezinstalat.
Caracteristicile care vizează performanța și administrarea mai ușoară sunt:
• Inițializare de aplicații: o funcție care permite administratorului să configureze
anumite aplicații pentru a porni automat pornirea serverului. Acest lucru reduce durata
de așteptare a utilizatorilor care accesează site -ul pentru prima dată după repornirea
unui server.
• Suport ASP.NET 4.5: Cu IIS 8.0, ASP .NET 4.5 este inclus în mod implicit

– 23 –
• Certificat de certificare SSL centralizat: facilitează gestionarea certificatelor,
permițând administratorului să stocheze și să acceseze certificatele pe o partajare de
fișiere.
• Scalarea multicore pe hardware -ul NUMA: optimizează performanța sistemelor care
rulează NUMA, cum ar fi executarea mai multor procese de lucru sub o singură
aplicație.
• Restricții dinamice de adrese IP: o funcție care permite unui administrator să blocheze
dinamic IP -uri sau intervale de IP care au lovit serverul cu un număr mare de solicitări
• CPU Throttling: un set de comenzi care permit administratorului de server să
controleze utilizarea procesorului de către fiecare grup de aplicații
• Logare îmbunătățită: o funcție care permite colectarea de va riabile de server, antete de
cerere și anteturi de răspuns în jurnalele IIS
• Înregistrarea ETW: un furnizor de servicii ETW care permite colectarea de jurnale în
timp real folosind diferite instrumente de urmărire a evenimentelor
• Recuperarea automată a cert ificatelor: o funcție care detectează momentul în care un
certificat de site a fost reînnoit și redevine automat site -ul la acesta
IIS Express, o versiune ușoară (4.5 -6.6 MB) a IIS, este disponibilă ca un server
freeware independent și poate fi instalată p e Windows XP cu Service Pack 3 și versiuni
ulterioare ale Microsoft Windows. IIS 7.5 Express acceptă numai protocoalele HTTP și
HTTPS. Este portabil, stochează configurația pe un utilizator per utilizator, nu necesită
privilegii administrative și încearcă să evite conflictele cu serverele web existente pe aceeași
mașină. IIS Express poate fi descărcat separat sau ca parte a WebMatrix sau Visual Studio
2012 și ulterior. (În Visual Studio 2010 și mai devreme, dezvoltatorii web care dezvoltă
aplicații ASP.NET folosesc serverul de dezvoltare ASP.NET). În mod implicit, IIS Express
servește doar trafic local. [25]
Potrivit Netcraft, pe 13 februarie 2014, IIS a avut o cota de piață de 32,80%, ceea ce a
devenit al doilea server web cel mai popular din lume, in spatele Apache HTTP Server la
38,2%. Netcraft a înregistrat o tendință crescătoare în ceea ce privește cota de piață pentru IIS,
începând cu anul 2012. O zi mai târziu, î nsă, W3Techs prezintă rezultate diferite. Potrivit
W3Techs, IIS este al treilea server web cel mai folosit din spatele Apache HTTP Server (locul
1) și Nginx. În plus, aceasta indică o tendință de scădere constantă pentru utilizarea IIS
începând cu februari e 2013.

– 24 –
2.2.13 Task Scheduler
Task Scheduler este o componentă a Microsoft Windows care oferă posibilitatea de a
programa lansarea de programe sau scripturi la ore predefinite sau după intervale de timp
specificate: planificarea sarcinilor (programarea sarcinilor ). A fost pentru prima dată introdusă
în Microsoft Plus! Pentru Windows 95 ca agent de sistem, dar a fost redenumit la Task
Scheduler odată cu Internet Explorer 4.0 și Windows 98. Serviciul Windows Event Log
trebuie să ruleze înainte ca Task Scheduler să p ornească. [26]
Acest serviciu nu ar trebui să fie confundat cu planificatorul care alocă resurse CPU
proceselor aflate deja în memorie.
Serviciul Task Scheduler fun cționează prin gestionarea sarcinilor. Sarcina se referă la
acțiunea (sau la acțiunile) luată ca răspuns la declanșator. O sarcină este definită prin
asocierea unui set de acțiuni, care pot include lansarea unei aplicații sau luarea unor acțiuni
definite î n mod particular, la un set de declanșatoare, care pot fi fie bazate pe timp, fie bazate
pe evenimente. În plus, o sarcină poate conține și meta date care definesc modul în care
acțiunile vor fi executate, cum ar fi contextul de securitate în care va funcț iona sarcina. [26]
Sarcinile sunt serializate în fișiere .job și sunt stocate în folder -ul special numit Task
Folder, organizat în subdirectoare . Programat, dosaru l de sarcini este accesat utilizând
interfața ITaskFolder sau obiectul de scripting TaskFolder și sarcinile individuale utilizând
interfața IRegisteredTask sau obiectul RegisteredTask.

– 25 –
3 Arhitectura aplicației
Proiectul este structurat în patru componente principale: aplicația web (Asp .NET
webforms), serviciul de trimis mail -uri (console application), proiect comun de implementare
a claselor (class library) pentru a asigura accesul la clasele actualizate ambelo r proiecte
amintite anterior și baza de date Oracle.
Aplicația web este structurata pe mai multe module, care ne asigura o dezvoltare
corecta și o aplicație completa în momentul în care toate modulele stabilite inițial sunt
funcționale și interconectate.
3.1 Structura aplicației
După cum am amintit în rândurile anterioare, întreaga arhitectura a aplicației este
împărțită în mai multe module independente, create sub forma unor proiecte diferite, dar care
în final prin strânse legături deservesc același scop fin al sub forma unsei singure aplicații.
În acest proiect, la crearea unei noi pagini, sunt create în mod automat doua fișiere
separate, unul cu extensia .aspx în care se va scrie codul de front -end iar celălalt cu extensia,
în cazul nostru .cs reprezentând u n fișier în care se va scrie codul de back -end în limbajul de
programare C#, acesta putând să difere în funcție de alegerile fiecărui programator.
În subcapitolele următoare, este prezentata structura fiecăreia dintre proiectele
prezente.
3.1.1 Structura aplica ției WEB
Aplicația web creată poate fi împărțită în două părți generale, separate, de front -end și
de back -end care împreuna alcătuiesc ansamblul necesar creării unei aplicații software
complexe, atât din punct de vedere al interfeței cu utilizatorul cât și din punct de vedere al
mecanismului complex de calcul ce se află în spatele acesteia.
Partea de front -end a aplicației constă în cod scris în general cu ajutorul framework –
ului ASP .NET, iar partea de back -end consta în codul scris în limbajul de progra mare C#, dar
și în partea bazei de date, C# asigurând în acest proiect legătura dintre baza de date și front –
end.
3.1.1.1 Front -end
Partea de front -end în aplicațiile ASP .NET este foarte ușor de învățat de oricine are
puțină experiență în a programa aproape în or ice alt mediu de programare al aplicațiilor web.

– 26 –
Aceasta poate fi realizată aproape în întregime folosind doar cod HTML, CSS și
JavaScript, însă pentru a crea în mod mai ușor, sau mai rapid o aplicație mai complexa, ASP
.NET ne permite folosirea unor contr ollere gata implementate, care ne asigura o personalizare
rapida prin modificarea atributelor pe care acestea le dețin deja, dar ne și oferă din start
legătura cu partea de back -end. Aceasta legătura se face prin folosirea tag -ului „runat” cu
atributul „se rver” (ex: runat=”server” ) ce poate fi folosit în interiorul tuturor controalelor.
Un alt avantaj îl reprezintă abilitatea de a crea o pagina responsabila cu layout -ul
aplicației, denumita pagina „master”, aceasta denumire fiind și extensia fișierului crea t, în
care se pot importa fișiere css sau javascript, se pot adaugă elemente care sunt dorite pe viitor
în toate paginile create ulterior, precum un meniu, nota de subsol sau orice alt element al cărui
prezenta este dorita în mai multe pagini.
Pentru a ad augă pe viitor alte pagini, care să se poată integra în aceasta pagina master
este necesara folosirea controalelor de tip <asp:ContentPlaceHolder … > , iar în locul
acestora, în momentul rulării aplicației o să regăsim informația prezentata de pagina pe c are o
vizualizam, aceasta punând informațiile la dispoziție prin intermediul aceluiași tip de
controale, create în mod automat de Visual Studio .
Relația este prezentata în figura 3.1, în care chenarele albastre reprezintă partea de
informații care, din p artea paginii . aspx o va înlocui pe cea a paginii . master.
La interacțiunea cu elementele unei pagini, sunt căutate rezultatele potrivite
evenimentului creat atât în partea paginii accesate, dar și a paginii .master , trimițând apoi
datele interpretate spre prelucrare în back -end.

Figura 3.1 Pagina .master și .aspx

– 27 –
3.1.1.2 Back -end
Aceasta parte a structurii aplicației ne asigura atât de o prelucrare corecta a datelor
primite de la utilizator, pe serverul de pe care rulează, în momentul în care este primita o
cerere de la acesta, prin declanșarea unui eveniment din cadrul interfeței, sau din partea de
front -end, dar și de o preluare a datelor necesare din baza de date, care se afla tot în back -end,
putând astfel să consideram aceasta parte, a codului C#, și una de legătura intre interfața și
baza de date.

Figura 3.2 Funcționalitate back -end
În figura 3.2 sunt prezentate toate acțiunile care urmează a se produce în partea de
back -end la o simpla cerere primita de la un client, fiind prezentate toate etapele necesare
returnării unui rezultat corect.
Aici este inițializat accesul pe server, se verifica evenimentul care a declanșat cererea,
iar în funcție de condițiile prezente, se produ ce o anumita acțiune care ne va aduce un rezultat.
La sfârșit acest rezultat obținut este trimis înapoi clientului, fiind afișat sub o anumita forma
pe pagina web.
3.1.1.3 Legătura intre back -end și front -end
Atât în figura 3.1 cat și în figura 3.2 sunt prezentate modele de acces de la o structura
la alta, prin interpretarea cererii și trimiterea/primirea răspunsului.
Este important de reținut ca pentru fiecare pagina .aspx se creează o pagina .cs cu
același nume, care implementează toate metodele controalelor regă site în acea pagina, însă
toate acțiunile fiind trimise către server pentru interpretare, daca este folosit tag -ul
runat=”server” acțiunile din figura 3.2, de interpretare a evenimentelor de către back -end, se

– 28 –
produc după un eveniment numit PostBack care a nalizează toata pagina pentru identificarea
evenimentului și trimiterea cererii în locul potrivit, acest lucru putând cauza pierderi de
informații din câmp -urile completate dar neinterpretate (unde este cazul).
Pentru a evita astfel de situații, se pot fol osi controale speciale, care sunt create tocmai
pentru a preveni astfel de situații.
În aceasta aplicație, ContentPlaceHolder -ele din pagina master sunt create într -un alt
control, numit UpdatePanel care interpretează acțiunile clientului direct din browse r-ul
acestuia, și reușește să păstreze toate informațiile prezente pe pagina, în timpul execuției
codului de back -end. Acesta poate fi chiar și personalizat, în cazul aplicației prezentate, este
folosita o animație pentru toate evenimentele care necesita u n timp mai mare de lucru, arătând
utilizatorului ca aplicația lucrează în fundal și pregătește rezultatele.
3.1.2 Structura serviciului de mail -uri
Aceasta aplicație nu are nevoie de o legătura cu utilizatorul final, având doar un rol
adițional adus aplicației w eb, făcând doar o verificare de rutina, programata să se reproducă
zilnic iar apoi procesul se închide automat, nefiind nevoie de niciun tip de interacțiune cu
aceasta, deci nu necesita o parte de front -end.

Figura 3.3 Rolul aplicației consolă
După cum r eiese din figura 3.3 aceasta aplicație necesita doar cod back -end, capabil să
comunice cu baza de date folosita și de aplicația web, de unde să se poată face preluarea
informației necesare.
După preluarea datelor, acestea sunt procesate și verificate, iar unde este cazul este
apelat un client de email, SMTP, care poate trimite mesajele create în urma interpretării
datelor, iar daca mesajul rezultat este trimis mai departe cu succes sau nu, pot apărea doua
acțiuni diferite, fie o înregistrare atât în baza d e date cat și într -un fișier de log -uri a
evenimentului, fie a erorii care a împiedicat procesul.

– 29 –
3.1.3 Structura proiectului de clase
Acest tip de proiect nu are o structura care trebuie urmărita, acesta conținând doar
elementele care se doresc a fi purtate cu ușurința în mai multe proiecte, fără a fi nevoie de
reproducerea codului.

Figura 3.4 Proiectul de clase
Acest proiect, în cazul nostru este structurat în mai multe directoare, care conțin fișiere
cu cod C#, în care sunt definite clase, enumerări sau alte tipuri de obiecte și legătura directa la
baza de date.
În figura 3.4 se poate observa ca acesta este legătura dintre celelalte doua aplicații.
3.1.4 Clase
În aceste proiecte sunt definite diferite clase care ajută la o mai ușoară structurare a
codului, de l a conexiunea la baze de date și preluare și inserare de informații în baza de date
până la crearea de obiecte specifice aplicației și funcții extensibile ajutătoare acestora și cod
folosit pentru a asigura posibilitatea trimiterii de mail -uri.
Toate aceste clase sunt prezentate mai detaliat în subcapitolele ce urmează, fiecare
având diagrama claselor și explicații sau exemple de cod unde este cazul.

– 30 –
3.1.4.1 Baza de date
Aici sunt prezente două clase, în interiorul unui „namespace” comun. Prima clasă
prezentată poar tă denumirea de „MagicValue” pentru că aici sunt stocate datele necesare
conexiunii la baza de date, precum numele, schema și parola, dar și șirul de conectare necesar
funcțiilor prezente în cealaltă clasa care face parte din aceasta categorie, existând o relație de
asociere intre cele două.

Figura 3.5 Diagrama de clase pentru baza de date
În clasa denumita „DAL” sunt prezente toate funcțiile care ajuta la interogarea bazei
de date, pe baza șirului primit ca parametru , care poate conține selecții, inseră ri, actualizări
sau chiar ștergeri în interiorul bazei de date, dar care se folosește și de informațiile preluate
din „MagicValue” care conține informații despre baza de date care trebuie folosită și datele de
autentificare pentru a putea avea acces la ace le date.
Aceste două clase sunt suficiente pentru a acoperi toata aria necesitaților ce pot apărea
în proiectele prezentate, oferind orice posibilitate de acces asupra unei baze de date.
Aceste clase sunt printre cele mai importante, fiind folosite atât de tot restul claselor
prezentate mai jos, cat și direct în proiectul web și cel de mail -uri.

– 31 –
3.1.4.2 Clase pentru popularea listelor
Următoarele clase sunt definite ca și clase statice, care nu creează un obiect anume ce
urmează a fi folosit, scopul acestora este d e a cuprinde unele dintre cele mai apelate metode
folosite din interfața web a aplicației, și anume de populare a câmpurilor de tip listă, din care
poate fi selectată o informație prezentă în baza de date.

Figura 3.6 Diagrama de clase pentru selectori
În figura 3.6 Putem vedea că aceste clase au fost împărțite astfel încât fiecare din ele
să facă referire la unul dintre tabelele bazei de date.
Toate clasele respecta același format, având două funcții proprii, una returnând toate
rezultatele ordonate în or dine alfabetică, iar cealaltă returnând numele unui/unei
anumit/anumite informații din baza de date pe baza id -ului primit ca parametru.
Singura diferența, după cum se poate observa din diagramele de mai sus, se afla în
clasa „CategoriesDetails” aceasta re prezentând subcategoriile, care are nevoie și de numele
categoriei pentru care dorim returnarea tuturor rezultatelor, diferența ce poate fi observata mai
detaliat în figura 3.7.

Figura 3.7 Comparare clasei pentru subcategorii cu cea pentru categorii

– 32 –
3.1.4.3 Clase pentru funcții
În această grupare se află mai multe clase, grupate sub numele de funcții deoarece
acestea nu au o legătura între ele, sau cu celelalte clase, exceptând clasele pentru baza de date,
însă conțin segmente de cod folosite în mai multe par ți ale aplicației web, care fără aceste
clase ar trebui copiat de fiecare data în locurile dorite.
De aceea, am ales segmentarea lor în mai multe clase, precum în figura 3.8, încercând
să le ofer un nume cat mai sugestiv din punct de vedere al funcțiilor p e care le dețin metodele
din interiorul lor.

Figura 3.8 Diagrama claselor de funcții folosite
Aceste funcții au roluri distincte, de la convertirea timpului în format UNIX, care ca o
măsura a timpului măsoară diferența de secunde de la data 1/1/1970, reprezentând numărul
zero, calculând astfel data dorita prin adăugarea sau scăderea unui număr de secunde, până la
funcția de criptare în format MD5 a șirurilor primite, folosite pentru criptarea parolelor, și o
funcție folosita pentru afișarea căsuțelor c u diferite mesaje pe paginile aplicației.
Aici mai sunt regăsite și funcții pentru reducerea dimensiunii unei imagini și
adăugarea ei în baza de date, dar și oferirea de sugestii a numelor de utilizatori căutați, oferind
sugestii ce conțin șirurile introdu se în câmpurile din aplicație în timpul tastării.

– 33 –
3.1.4.4 Clase pentru grafice
Aceste clase sunt folosite pentru a genera graficele dorite, în funcție de filtrele paginii
curente, atât personale, care se referă doar la un anumit tip de task -uri ale persoanei
auten tificate, cat și generale, luând în considerare toate task -urile aflate în baza de date. De
asemenea de aici avem patru grafice construite folosind controale de tip asp:Chart , dar și o
statistică generală, pentru care aveam nevoie de o nouă clasă pentru a putea păstra același tip
de construcție, astfel a apărut și clasa „GeneralChart” care este folosita de clasa responsabilă
cu crearea graficelor.

Figura 3.9 Diagrama de clase pentru grafice
3.1.4.5 Clase pentru task -uri
O altă parte foarte importanta a aplicației este cea care se ocupă de task -uri.
Aici avem o clasa responsabila cu menținerea modelului unui task, care conține toate
atributele pe care acesta trebuie să le dețină, și o metoda de populare a datelor pentru aceste
atribute.
Clasa denumita „Task” moșten ește acest model și ii extinde funcționalitatea prin
popularea elementelor direct din baza de date, pe baza unor id -uri.
Tot în aceasta categorie a task -urilor mai apare și necesitatea unei noi clase ajutătoare,
denumita sugestiv „TaskHelper” care conține o parte mai mare de metode suplimentare care
ajuta în lucrul cu aceste clase. Aceasta este o clasa statica, cu metode extensibile sau normale
care conțin cod mai complex, precum salvarea unui model în baza de date după contracție,
actualizarea informațiilo r din task -uri, etc. Avantajul metodelor extensibile este oferit de
modalitatea ușoara de apelare a lor, adăugând functionalitati noi unor clase deja existente fără
derivarea lor.

– 34 –

Figura 3.10 Diagrama clase task -uri
Cele trei clase prezentate mai sus „Task”, „TaskModel” și „TaskHelper” împreună
creează un mediu complex dar ușor de utilizat și intuitiv.
3.1.4.6 Clase pentru utilizatori
La fel ca și în cazul claselor care împreună creează funcționalitatea task -urilor, clasele
din jurul utilizatorilor au același format, având o clasa model „UserModel”, ce conține toate
atributele necesare unui utilizator, o clasa care moștenește modelul și ii extinde
funcționalitățile, și , la fel ca în cazul task -urilor, avem o clasa ajutătoare „UsersHelper” care
conține metode e xtensibile celorlalte doua clase, cum am văzut înainte.
Privind comparativ figura 3.10 și figura 3.11, conținând diagramele task -urilor și a
utilizatorilor, putem remarca imediat similitudinea în construcție și în utilizare.
După cum se poate observa din d iagrama prezentata, clasa „Users” păstrează toate
atributele populate specifice unui utilizator, dar creează încă un obiect, tot de tip „Users”, care
menține atributele specifice superiorului sau direct, și o metoda de găsire a unui utilizator
după căutare a numelui său în baza de date.

– 35 –

Figura 3.11 Diagrama clase utilizatori
La fel ca în cazul task -urilor, clasa ajutătoare este o clasă statică ce extinde
funcționalitatea celorlalte două clase, prin metode de adăugare utilizator, actualizare sau
trimitere de mail -uri.
3.1.4.7 Clase pentru mail -uri
Și pentru această funcționalitate, de a putea trimite mail -uri utilizatorilor am avut
nevoie de crearea a două clase, pentru păstrarea unui cod ordonat și intuitiv.

Figura 3.12 Diagrama clase mail -uri
Clasa „MailType” conține două enumerări, care conțin tipul de email ce trebuie trimis,
și anume cărei persoane implicate din task (responsabil, inițiator, etc.) și una care conține
motivul trimiterii (adăugare task, delegare, etc.). Cealaltă clasă se ocupa exclusiv de
cone ctarea clientului de mail (smtpClient) și trimiterea mail -ului dorit. În subcapitolul
următor, aceasta legară este explicată mai detaliat, aceste două clase neavând o legătura
directă între ele.

– 36 –
3.1.4.8 Legătura claselor de task -uri, utilizatori și mail -uri

Figu ra 3.13 Diagrama legăturii intre clasele de utilizatori, task -uri și mail -uri
Aici este prezentată o structură mai în detaliu a celor trei clase, iar după cum putem
vedea, toate sunt într -un fel sau altul legate între ele, legătura dintre utilizatori și ta sk-uri
făcându -se prin clasa de tip model a task -urilor și clasa „Users” care moștenește modelul
utilizatorilor, un task având mai multi utilizatori, creând o relație de mai mulți la unu (many –
to-one), mai mulți utilizatori aparținând unui singur task, ace asta fiind o relație de asociere, iar
punctul comun al celor două clase de mail -uri este constituit de clasa ajutătoare a
utilizatorilor, „UsersHelper”, care le folosește la rândul său pe ambele, pentru a putea construi
mesajul specific unui anumit tip de utilizator și specific unei anumite acțiuni, iar apoi pentru a
putea trimite mesajul generat către adresa de email atribuită unui utilizator.
Din figura 3.13 putem stabili că punctul comun al claselor este constituit de clasele
utilizatorilor, care împreun a creează o structură și mai complexa, cu o logica mult mai extinsă
decât luate individual.

– 37 –
3.1.5 Diagrama claselor

Figura 3.14 Diagrama finala a claselor
Aceasta diagrama, din figura 3.14, ne arată situația finala a tuturor claselor și a tuturor
asocierilor dintre acestea, iar după cum putem observa în această figura, toate clasele folosesc
direct sau indirect clasele de acces la baza de date.
Acest lucru este de așteptat în orice proiect de amploare mai mare, în care toate datele
trebuie salvate și prelucra te pentru a putea contura o experiența mai bogata în informații.
3.2 Structura bazei de date
Baza de date este foarte importanta în aplicațiile moderne, iar după cum am văzut și în
subcapitolele 3.1.4 și 3.1.5, o aplicație poate fi în întregime dependentă de c onexiunea la o
baza de date, toate clasele și funcționalitățile având la un moment dat nevoie de a prelua date
din aceasta.
Din acest motiv crearea unei structuri ușor de întreținut, intuitive și stabilirea bună
relațiilor între tabele este extrem de impor tantă.
Dacă facem o comparație între figura structurii bazei de date (figura 3.15) și figura
diagramei de clase (3.14) putem vedeam că se păstrează în foarte mare parte același tip de
asocieri între acestea.
În diagrama bazei de date se pot observa tipuril e de date folosite, cheile primare și
străine ale fiecărui tabel, care permit ștergere cascadată de date, selecții alăturate din mai

– 38 –
multe tabele (join -uri), dar permit și preluarea mai rapidă de date în acest fel, față de o baza de
date în care tabelele n u au nicio legătura de asociativitate intre ele, permițând astfel indexarea
datelor.

Figura 3.15 Diagrama bazei de date
Prin folosirea cheilor primare, apelate sub forma cheilor străine din alte tabele, pe
lângă avantajele amintite anterior ne putem asig ura și de consistenta datelor, spre exemplu
daca în tabelul „LOGS” pe coloana „TASK_ID” care reprezintă o cheie străină a tabelului
„TASKS”, avem proprietatea ca nu accepta valori nule, ne asigura în acest caz ca toate
înregistrările din tabela „LOGS” pot fi asociate cu tabela task -urilor, de asemenea descriind
termenul de ștergere cascadata, odată cu ștergerea unei înregistrări din tabelul „Tasks”, daca
asocierile sunt făcute cum trebuie, vor fi șterse de asemenea toate înregistrările din tabela
„LOGS” ce conțin pe coloana „TASK_ID” id -ul task -ului stres.
Pentru atribuirea cheilor primare, astfel încât acestea să fie unice fără o verificare din
partea programatorului, bazele de date dispun de declanșatoare automate (trigger) care
populează automat aceste câ mpuri, implicit dând valori numerice în ordine crescătoare pe
parcursul popularii tabelelor, mecanism folosit și în interiorul bazei noastre de date.

– 39 –
4 Implementări
În rând urile ce urmează este prezentată implementarea structurii aplicației, în care
numele modulului este o reprezentare ușor de înțeles a funcționalității sale, descriind succint
partea pe care se axează a o implementa.
4.1 Modulele aplicației WEB
Modulele sunt prezentate ca funcționalități finite, pe care le poate accesa utilizatorul
final. Acestea sunt funcționalitățile pe care la momentul începerii proiectului le -am considerat
necesare unei bune funcționări și înțelegeri a scopului aplicației.
4.1.1 Autentificare
Ca în orice aplicație a cărei baze informatice este alcătuita din diverse informații
adăugate de către utilizatorii ei, iar în care identitatea utilizatorului trebuie recunoscuta pentru
a putea garata acestuia un anumit nivel de acces după anumite criterii, după cum ar fi și
autorul informației salvate în baza de date, daca info rmația ii se adresează acestuia sau nu, etc.
Soluția pentru aceasta necesitate este implementarea unei structuri de autentificare, în
care fiecare utilizator este verificat înainte de accesarea aplicației printr -un nume de utilizator
unic și o parola cript ata cu ajutorul algoritmului MD5. După interogarea bazei de date pe baza
datelor de acces furnizate de utilizator, în cazul în care datele au fost completate corect
utilizatorul este redirecționat pe pagina principala a aplicației, iar în caz contrar este rugat să
reverifice datele de acces, sau să își creeze un cont daca nu a făcut deja acest lucru.
În cazul unei autentificări reușite, datele privind utilizatorul, cum ar fi numele
complet, username -ul, dreptul de acces pe site, funcția acestuia, departamen tul, etc. sunt
salvate în cookie -uri, pentru a putea fi folosite ulterior fără a interoga din nou baza de date,
fiind valabile până la părăsirea aplicației, sau până la apăsarea butonului de delogare, care
distruge toate cookie -urile create.
Daca utilizato rul dorește să acceseze o anumita pagina, după distrugerea datelor
salvate, (de exemplu accesează un link către un task pe care dorește să îl verifice) aplicația
stochează aceasta informație în link -ul paginii de autentificare, din care poate prelua apoi
informația, ca în momentul autentificării utilizatorului să fie redirecționat către pagina dorita,
și nu către pagina principala, informație salvata într -o sesiune cu numele de „redirectLink”
cum se poate observa și din codul de mai jos:

– 40 –

Figura 4.1 Prezen tare cod creare link de redirecționare
Cu ajutorul unor stiluri setate în clase CSS și a unor funcții javascript, formularul de
autentificare are un aspect minimal, care conține doar sigla firmei care utilizează aplicația, un
panou cu textul Log in , iar câ nd poziționați mouse -ul deasupra sa să apare formularul cu
câmpurile pentru numele de utilizator, parola și butonul de submit, cum este prezentat în
figura 4.2, cu ajutorul codului javascript prezentat în figura 4.3.

Figura 4.2 Aspect pagina de autentifi care

– 41 –

Figura 4.3 Cod javascript pentru pagina de autentificare
4.1.2 Creare cont
Specificând în rândurile anterioare că accesul la aplicația prezentată se poate face doar
pe baza unei autentificări în prealabil, în mod natural urmează modulul de creare a contu rilor
pentru aplicație.
În acest modul, viitorul utilizator trebuie să completeze anumite date pentru a putea
continua. Datele furnizate în acest moment sunt folosite ca atribute ale utilizatorului, ajutând
alte persoane să identifice mai rapid un utilizat or. Această recunoaștere este utilă pe liniile de
producție, unde pot fi mulți angajați, iar în momentul în care un utilizator primește o sarcină
de la altă persoană își poate clarifica obiectivele sarcinii, dar poate de asemenea constata că
sarcina respec tiva nu ar trebui să ii se adreseze acestuia.
Din acest motiv, datele care trebuie introduse de utilizatori sunt cele prezentate în
formularul din figura 4.4:

Figura 4.4 Formular înregistrare
Date personale cum ar fi numele complet, nume de utilizator, email și o parolă, dar și
date aparținând locului de muncă, precum funcția, departamentul și alegerea superiorului
direct.

– 42 –
Toate câmpurile sunt obligatorii, verificarea făcându -se în partea clientului, prin
adăugarea atributului de „required” căsuțelor de text prezente, iar parolele sunt verificate pe
server pentru a asigura faptul ca parolele sunt identice.
Daca un câmp este lăsat necompletat și se apasă butonul de „Submit” lângă spatiile
necompletate apare un mesaj ca în cel din figura 4.5.

Figura 4.5 Eroare câmp necompletat
Când parolele nu sunt identice în pagina web apare un mesaj de avertizare că acestea
nu se potrivesc, neputând crea un cont pentru utilizatorul prezent pe această pagină.

Figura 4.6 Parole diferite
Dacă în schimb totul decurge bine, utilizatorul este salvat în baza de date și
redirecționat către prima pagina a aplicației, precum în codul următor din figura 4.7.
Din motive de securitate, toate parolele sunt criptate folosind algoritmul MD5 care
returnează un sir de caractere de o lungime fixa de 128 de biți, iar algoritmul folosit pentru
criptarea datelor în format MD5 este prezentat în figura 4.8

Figura 4.7 Salvare cont în baza de date

– 43 –

Figura 4.8 Algoritm MD5 folosit
4.1.3 Pagina de start și layout -ul aplicației
Pagina de start joa că un rol extrem de important într -o aplicație web, deoarece aceasta
constituie prima pagină cu care utilizatorul interacționează după procesul de autentificare /
înregistrare. Deoarece și layout -ul aplicației este foarte important, conținând elementele
vizibile pe toate viitoarele pagini am ales să îl prezint în același modul.
Layout -ul este construit într -un fișier de tip masterpage , cu extensia .master care
conține header -ul, meniul de navigare, și footer -ul site -ului. În locurile uzuale în care se află
în mod normal cod html cu funcționalități sau design specific unui tip de aplicație, se afla în
schimb placeholder -e care sunt ulterior înlocuite de celelalte pagini, marcând doar locul în
care codul scris în celelalte pagini va fi afișat în browser -ul uti lizatorului, ca în figura 4.9, în
afara acestui lucru se poate scrie cod html, css, sau javascript care folosesc atât elemente din
aceasta pagina, dar și cu referința către elemente din alte pagini care folosesc pagina master ca
model structural, pe baza c ăruia își creează zone de conținut care pot completa placeholder –
ele din pagina master.

Figura 4.9 Exemplu folosire placeholder

– 44 –
Pagina master , cea responsabila cu păstrarea aspectului identic pe toate paginile
viitoare, conține o mică animație, care apa re în momentul așteptării unui răspuns din partea
server -ului, pentru a arăta utilizatorului că aplicația a preluat comanda sa și că așteaptă un
răspuns, dar si meniul de navigare, către toate celelalte module ale aplicației, având și o parte
care arată nu mele utilizatorului autentificat în momentul curent, iar în cazul în care un cont de
administrator este autentificat, în meniul menționat mai apare o intrare specifica doar acestuia,
în care poate aduce modificări informaților prezente în baza de date, dar și o pagina care ii
oferă control asupra serviciului de trimis mail -uri, după cum urmează să vedem în capitolele
următoare.
Tot implementat în pagina master a aplicației, se află și un mic buton, care apare doar
în momentul în care distanța derulată în p agina depășește 300 de pixeli, iar prin apăsarea
acestuia putem ajunge înapoi în partea superioară a paginii mult mai ușor, funcție utilă în
momentul căutării unui task într -o lista foarte mare, iar dacă dorim aplicarea unui filtru este
nevoie de întoarcer ea în partea superioara a paginii.

Figura 4.10 Buton reîntoarcere în topul paginii

Figura 4.11 Cod javascript pentru afișarea și ascunderea butonului
Prima pagina oferă la prima vedere situația generală actuală sub formă de grafice.
Primul grafic afișat reprezintă o comparație a numărului de task -uri date și a numărului de
task-uri finalizate, într -o perioadă dată de timp, implicit de la începutul anului până în data
curentă, pentru care se pot aplica mai multe filtre ulterior, urmat de trei grafic e care prezintă
alte informații legate de task -uri, dar doar pentru ultimele patru săptămâni, aducând doar
informațiile mai relevante, urmate de un grafic care arată doar statusul final al tuturor task –
urilor introduse în baza de date.

– 45 –
Se pot selecta doar task-urile de interes personal, în cadrul primului filtru al paginii, în
care se pot cere explicit task -urile tuturor utilizatorilor, sau doar cele personale, în care se
poate opta pentru statutul de inițiator al task -urilor (se iau în considerare doar tas k-urile date
de utilizatorul curent) sau pentru statutul de responsabil (doar task -urile în care utilizatorul
curent a fost ales pentru rezolvarea lor), sau ambele variante.

Figura 4.12 Filtru task -uri (general / personal și statut)
Celelalte filtre existente sunt disponibile după apăsarea butonului de formă acordeon ,
care se deschide sub primul grafic. De aici mai multe opțiuni de filtrare sunt puse imediat la
dispoziția utilizatorului.

Figura 4.13 Filtre pentru task -uri
Daca se d orește se poate face un export al graficelor, filtrate sau nu, apăsând butonul
prezent în coltul din stânga jos al ecranului, care o să deschidă un panou cu mai multe
informații privind exportul.
Exportul se face în format .PDF , asigurând compatibilitatea și posibilitatea de
deschidere a acestora din aproape orice mediu. În interiorul documentelor sunt salvate filtrele
active, dacă există, persoana care a exportat informațiile, dar și data la care s -a efectuat
exportul.

– 46 –
Fișierul exportat este în format peisaj, dacă este prezent doar un singur grafic, pentru a
ocupa mai ușor tot spațiul, de altfel lăsat liber, al fișierului, fiind exportat în format de pagină
A2, iar daca sunt selectate mai multe grafice acesta este orientat în stil portret .
Exportul în forma t .PDF este realizat cu ajutorul librăriei iTextSharp , care poate fi
folosita pentru crearea componentelor din viitorul document PDF.

Figura 4.14 Pași export grafice
4.1.4 Adăugare task -uri
Aplicația având la bază îmbunătățirea procesului de rezolvare a task -urilor și
verificarea mai rapidă a acestora, în următorul modul este implementată structura cu ajutorul
căreia utilizatorii pot crea task -uri, opțiunile pe care le au la dispoziție, și stabilirea
informațiilor care sunt necesare pentru ca informația salvat a să nu fie redundantă.
Această pagină arată precum un formular standard, având informația împărțită în două
coloane, pe cea din dreapta fiind o parte din informațiile personale, salvată în baza de date,
precum numele complet, funcția, departamentul și dat a curentă, informații care nu pot fi
modificate sau șterse de către utilizator, iar în coloana din stânga se afla informațiile care
trebuie completate pentru a putea salva task -ul dorit. De asemenea, aici nu toate câmpurile
prezente sunt obligatorii, cele necesare sunt marcate cu semnul „*”, având aceeași forma de
validare precum elementele de pe pagina de creare a unui cont nou.
Unele câmpuri sunt de tip dropdown , populate din baza de date, iar altele sunt de tip
textbox , în care se poate nota orice inform ație, la alegerea inițiatorului.
Un alt tip de informație este cea a priorității, în care alegerea este împărțită în trei
checkbox -uri exclusive , marcate printr -un cuvânt cheie, priority , care ne asigură că doar un

– 47 –
checkbox poate fi selectat, iar prin sele ctarea altuia, cel de dinaintea sa este deselectat
automat. Exemplu pentru aceasta funcționalitate în codul de mai jos :

Figura 4.15 Checkbox -uri exclusive
Pentru alegerea datei scadente, am ales folosirea unei extensii pentru câmpul textbox ,
și anume am ales un controller de tip calendar, în care se poate alege formatul datei, și în ce
textbox din pagină să se salveze informația selectat din acesta, făcând introducerea unui
format de dată standard mai ușoară pentru utilizator.

Figura 4.16 Cod pentru extensia calendarului

Figura 4.17 Aspectul calendarului în formular
Daca a fost aleasă o dată scadentă mai mică decât data curentă, utilizatorul este
atenționat cu privire la acest lucru, dar daca datele sunt corecte, apare o nouă opțiune de tip
calendar, aceea de a selecta și o data de început mai veche, nefiind posibilă adăugarea unui
task cu o data scadentă mai mică decât cea a celei de început.

– 48 –

Figura 4.18 Alegerea unei date de început
Un alt tip de informație este prezent sub un alt buton de tip acordeon, în care apare
posibilitatea de încărcare a maxim 3 poze, cu nume și o scurta descriere pentru fiecare, care
pot deservi în o mai ușoară înțelegere a problemei și în găsirea unei soluți i mai rapide.
Imaginile sunt rescalate, în așa fel încât dimensiunea finală înainte de introducerea în baza de
date să fie de maxim 50 kilobytes, pentru a nu aglomera baza de date cu informație inutilă,
nefiind nevoie de imagini cu o rezoluție foarte mare pentru a prezenta o problemă.

Figura 4.19 Prezentare cod redimensionare imagini
Dacă toate informațiile sunt completate corect, este generat un mesaj care informează
user-ul ca task -ul a fost creat și adăugat cu succes în baza de date.
De asemenea, după acest pas, atât inițiatorul (utilizatorul curent), cât și responsabilul
și superiorul sau sunt informați prin intermediul unui email despre task -ul tocmai creat,
furnizându -le de asemenea un link de acces, la apăsarea căruia să fie redirecționați direct c ătre
pagina cu detalii a task -ului menționat, nefiind nevoie de o căutare ulterioara a task -ului
tocmai creat.

– 49 –
4.1.5 Vizualizare lista task -uri
Acest modul este de asemenea unul esențial aplicației prezentate, punând la dispoziția
tuturor utilizatorilor o listă cu o serie de informații conținând starea actuala a tuturor task -urile
create.
Aici toate informațiile sunt afișate sub forma unui tabel, în cadrul căruia selectarea
unui rând face o redirecționare către o pagina cu mult mai multe detalii privind task -ul
selectat, cu ajutorul codului prezentat În figura 4.21. Controller -ul folosit este de tip gridview ,
un controller foarte complex ce permite popularea în mod dinamic a unui template stabilit,
acceptând orice fel de alte controller -e în interior sau orice mo dalitate de afișare a informației
sub forma unui tabel. Un alt avantaj al gridview -ului îl reprezintă multitudinea de acțiuni ce
pot fi făcute asupra acestuia și proprietățile de personalizare diverse.

Figura 4.20 Exemplu gridview

Figura 4.21 Redirecțion arecătre task -ul selectat

– 50 –
În plus, aici utilizatorul dispune de un set extins de filtre, care acoperă întreaga plaja a
atributelor task -urilor, precum și modalitatea de sortare a task -urilor, după alegerea câmpului
folosit la sortare, cat și a tipului, în mod crescător sau descrescător. Filtrele sunt pre populate
cu toate informațiile din baza de date, unde este cazul, opțiuni de autocompletare a anumitor
câmpuri, extensii pentru introducerea datelor prin apăsarea datei dorite din calendar, cât și o
informa re cu privire la numărul de task -uri găsite în urma filtrării. În zona filtrelor este un
buton de resetare a acestora, aducând pagina la starea inițială, iar în partea din stânga este
explicată starea task -urilor, (opened / ongoing / done / overdue) în fun cție de statusul din
tabel, completat în format PDCA.

Figura 4.22 Filtre task -uri din gridview
Totodată, pentru păstrarea consistentei utilizării, filtrele selectate rămân salvate la
părăsirea paginii, ca în momentul reîntoarcerii pe pagina aceasta, aces tea reiau automat ultima
formă avuta. Acest lucru este posibil datorita salvării valorilor lor în variabile de sesiune, care
sunt dependente atât de utilizatorul autentificat cat și de browser -ul folosit. Acest lucru ajuta
la o mai ușoară căutare a task -urilor folosind filtrele, în momentul apăsării greșite a unui task,
iar apoi în momentul întoarcerii pe pagina de filtrare, utilizatorul nefiind nevoit să reintroducă
toate detaliile din nou, dar de asemenea după un timp mai îndelungat de la ultima folosire,
când variabilele de sesiune nu mai sunt valide, acestea se resetează, totul revenind la starea
inițială, fără să creeze un inconvenient.
Daca tabelul conține mai mult de 50 de intrări, acesta este paginat implicit, pentru a
reduce încărcarea inutila a prea multor task -uri, care nu pot fi vizualizate în același timp
oricum de către utilizator, daca totuși se dorește oprirea paginării acest lucru este posibil cu
ajutorul unor butoane prezentate în figura 4.23, unde e afișat și stilul butoanelor de modific are
a paginilor.

Figura 4.23 Paginare tabel

– 51 –
Prin apăsarea butoanelor ‚<’ sau ‚>’ suntem mutați o singură pagină în spate, respectiv
în față, dar prin apăsarea butoanelor ‚<<’ sau ‚>>’ suntem redirecționați la prima respectiv
ultima pagină a tabelului.
De asemenea poate fi selectat unul dintre numerele paginilor afișate, pentru a fi
redirecționat direct pe pagina indicată de numărul respectiv.
Asemănător cu pagina principala, unde aveam posibilitatea de a exporta graficele
prezente, aceasta ficționalitate este prezenta și aici, putând salva întreaga informație
prezentată în gridview, în format PDF . Salvarea datelor din gridview permite într -un mod
mai convenabil salvarea datelor deja filtrate, fără a mai recurge la un pas în plus de refiltrare
pentru a tin e cont de acestea în momentul exportării documentului.

Figura 4.24 Salvarea tabelului în format PDF
Butonul de export al datelor este plasat într -un panou care conține mai multe
informații referitoare la datele exportate, având imaginea unei icoane a fi șierelor PDF , după
cum este prezentat în figura 4.25.

Figura 4.25 Export tabel

– 52 –
4.1.6 Vizualizare detalii și editare task
După selectarea unui rând din tabelul prezent în modulul anterior, task-ul
descris în rândul selectat se va deschide într -o nouă pagina de unde se pot vizualiza
informații mai complexe aferente oricărei sarcini înregistrate în aplicație. Informațiile
prezente sunt despărțite în pagin ă în doua secțiuni principale, prima este cea care cuprinde
informațiile care descriu problema, introduse de inițiator, iar în a doua secțiune sunt
informațiile referitoare la pașii de rezolvare a problemei cu mai multe explicații și stadiul
actual al rezolvării problemei, introduse de către responsabil, iar o alt ă secțiune, care este
opțională, cuprinde pozele atașate de inițiator pentru o mai clar ă expunere a problemei, care
poate cuprinde p ână la trei imagini cu nume și descriere proprii.
În prima secțiune pot fi identificate persoanele implicate: inițiatorul și responsabilul,
prioritatea sarcinii: mică, medie sau mare, categoria și subcategoria din care face parte, data
înscrierii cât și data scadentă, locația, linia de producție, echipamentul în cauză și produsul cât
și o descriere a problemei, cum este prezentat în figura 4.26. Toate aceste câmpuri sunt cele
completate de inițiator în momentul adăugării sarcinii în baza de date, informații care nu se
pot modifica în viitor

Figura 4.26 Informații inițiator
Informațiile din a doua secțiune sunt cele introduse de responsabil, acestea putând fi
editate de câte ori este nevoie de către acesta. Aceasta secțiune poate să difere de la un task la
altul, în cazurile în care un responsabil ales nu a studiat încă sarcina să poate confirma că
aceasta aparține de competența sa, dacă acest responsabil a refuzat sarcina și a trimis -o înapoi
inițiatorului, sau altei persoane sau dacă a acceptat task -ul. Tot in această secțiune se vor afla
și modificările de responsabil sau de dată scadentă impuse de inițiator.
În cazul în care responsabilul a acceptat sarcina putem vedea inf ormații ce cuprind
cauza identificată de acesta care stă la baza problemei descrise de inițiator, acțiunile luate
până în prezent pentru remedierea situației, comentarii adiționale care pot fi utile în viitor, și
statusul în formatul PDCA al sarcinii, care este o metoda mai elaborată de a exprima starea

– 53 –
actuala. Nici o căsuța marcată reprezintă faptul ca task -ul accesat este deschis, dar
responsabilul nu a luat nici un pas pentru remedierea problemei, toate căsuțele marcate
reprezintă o sarcina finalizata c u succes, iar orice altceva reprezintă faptul ca responsabilul a
preluat task -ul, dar nu a găsit o soluție, iar căsuțele marcate arată exact în ce stadiu a ajuns, ca
în figura 4.27.
Statusul PDCA are o ordine fixă, neputând bifa unul din elemente până la f inalizarea
celui de dinaintea să, în ordinea prestabilita, iar ultimul stadiu, A, nu poate fi marcat de către
responsabil fără a completa câmpul de acțiuni luate și cel al cauzei care a provocat problema.

Figura 4.27 Informații salvate de responsabil
Un task neacceptat de responsabil prezintă doar acesta informație, ca în figura 4.28, pe
lângă informațiile legate de task furnizate de inițiator, responsabilul neluând nicio decizie pe
baza lor.

Figura 4.28 Task neverificat de responsabil
Un task respins d e responsabil, și întors inițiatorului sau delegat unei alte persoane
care o să devina responsabil este prezentat în figura 3.29, și conține o informație cu privire la
persoana aleasa să se ocupe din acel moment de task, cat și un comentariu care ar trebui să
indice cauza care a dus la respingerea task -ului.

Figura 4.29 Task respins de responsabil

– 54 –
Modelul unui task reprogramat de către inițiator este prezentat în figura 4.30 și conține
ca element nou doar un comentariu scris de către inițiator în care poate justifica alegerea altui
responsabil sau prelungirea datei scadente a unui task existent.
Acest câmp are doar un scop informativ, și nu deservește niciunui alt scop, pentru
crearea de grafice sau alte statistice pe baza informației prezente aici.

Figura 4.30 Task reprogramat de inițiator către alt responsabil sau cu o alta data scadentă
Secțiunea amintită ca opțională conține până la maxim trei poze, pentru a evita
aglomerarea bazei de date, acestea având de obicei dimensiuni mari, fiecare fiind pre zentată
cu un titlu și o scurtă descriere opțională, precum în figura 4.31, iar la apăsarea unei dintre
acestea, se va deschide la dimensiunea întreagă într -un tab nou în browser -ul curent.

Figura 4.31 Secțiunea de imagini
După cum am amintit anterior, a tât inițiatorul cât și responsabilul pot aduce o serie de
modificări task -ului în curs de vizualizare, lucru posibil prin identificarea persoanelor
implicate în task și preluarea datelor din cookie -urile salvate de către browser, pe baza cărora,
în funcție de drepturile de editare, utilizatorului curent ii vor fi prezentate mai multe
posibilități sub forma unor butoane, la apăsarea cărora poate începe modificările dorite.

– 55 –
Din punct de vedere al responsabilului, pe această pagină în momentul primirii unui
task nou, se afla un buton care redirecționează utilizatorul pe o altă pagină unde poate accepta
sau refuza task -ul ales, acțiuni explicate în capitolele următoare.

Figura 4.32 Vizualizare task nou de către responsabilul task -ului
Dacă responsabilul a ales să preia task -ul propus de către inițiator, poate completa
inițial informațiile respective, dacă are deja cunoștințe despre rezolvarea problemei, iar daca
nu, la următoarea vizită a paginii pe care se afla task -ul sau afișarea paginii în secțiunea cu
datele pe care le poate completa acesta sunt la fel ca în figura 4.33.
Tot în aceasta figura este reprezentat procesul prin care utilizatorul poate trece pentru
salvarea noilor date. La apăsarea butonului de editare, toate câmpurile care îi aparțin acestuia
pierd atributul „read only” care permitea doar vizualizarea informațiilor și pot fi editate, iar
acum butonul de editare dispare și este înlocuit de alte două butoane, unul menit pentru
salvarea rezultatelor actuale, iar al doilea pentru anularea modificăril or aduse, în cazul unei
greșeli.
La apăsarea butonului de salvare a task -ului, utilizatorul este întâmpinat de un mesaj
cu informații referitoare la salvarea cu succes a task -ului editat în baza de date, dacă au apărut
erori în încercarea de salvare a noil or informații, iar dacă acesta încearcă să salveze task -ul ca
și complet, marcând toate căsuțele din schema PDCA fără a furniza o cauză a problemei
depistate, în câmpul Root Cause , și fără a completa nici o acțiune din câmpul Actions , acesta
va vedea un me saj de avertizare că task -ul lui nu poate fi salvat ca și complet până la
completarea câmpurilor amintite mai sus, ca în figura 4.34.
Din acest moment utilizatorul trebuie fie să schimbe statusul pe oricare alta stare P,D
sau C sau niciuna, fie să complet eze câmpurile obligatorii pentru salvarea task -ului.

– 56 –

Figura 4.33 Editare și salvare a noilor informații de către responsabil

Figura 4.34 Salvarea unui task ca și complet fără completarea câmpurilor de acțiuni luate și cauza
problemei
Returnarea rezulta tului din figura 4.34 este posibil printr -o verificare simplă în urma
apăsării butonului de salvare a informației, printr -o condiție care verifică stările posibile, iar în

– 57 –
caz de rezultat fals al posibilității de înregistrare a task -ului afișează cu ajutor ul unei funcții
javascript, apelata din codul de C# printr -un manager de scripturi, mesajul corespunzător.
Un exemplu de astfel de cod este prezentat în figura 4.35:

Figura 4.35 Cod pentru returnare mesaj avertizare
Din punct de vedere al inițiatorului, acesta nu are prea mult control direct din
interiorul acestei pagini, în momentul accesării ei acesta având disponibile doar două acțiuni
ale căror funcționalități se extind pe alte pagini ale aplicației, acestea fiind expuse sub forma a
două butoane, unul de ștergere a taskului, iar al doilea de schimbare a responsabilului sau
schimbare a datei scadente având numele de Review task , pentru ca prin revizuirea task -ului
se pot subînțelege ambele acțiuni, prezentate în fig ura 4.36.

Figura 4.36 Butoanele cu acțiuni posibile ale inițiatorului
Administratorul are acces la toate acțiunile prezentate mai sus, indiferent de task -ul
accesat, putând aduce atât modificări din punct de vedere al inițiatorului, cât și din punct de
vedere al responsabilului.
Amintind mai sus de toate modificările posibile asupra unui singur task, a apărut și
necesitatea urmăririi acestor modificări, pentru o înțelegere mai aprofundată a procesului de
rezolvare, pentru a putea vedea numărul de persoane delegate să lucreze la un singur task și
îmbunătățirile sau modificările aduse de fiecare în parte, sau de cate ori a fost nevoie de o
modificare a datei scadente astfel încât inițiatorul task -ului să poată estima pe viitor mai bine
timpul de lucru necesa r și persoana potrivită pentru preluarea unui task asemănător.
Pentru aceasta necesitate am implementat pagina în următorul fel:
La prima accesare a paginii utilizatorul este redirecționat la task -ul activ, preluat din
baza de date unde aferente unui singu r task se pot găsi mai multe log -uri, fiind o tabelă
separată cu o cheie străină care indica spre tabelul de task -uri, de unde daca sunt mai multe

– 58 –
log-uri care indică spre un singur task, în funcție de modificările efectuate până în momentul
curent, doar u na dintre înregistrări poate avea câmpul activ marcat ca pozitiv. Dacă în tabela
log-urilor se afla mai multe înregistrări care duc la același task, datele sunt preluate de
aplicație și utilizatorul care vizualizează pagina poate vedea o listă, care conțin e toate
modificările expuse în formatul: „Data_inregistrarii / data_modificarii (dd/mm/yyyy)
Nume_initiator -> Nume_responsabil” ca în figura 4.37 și în figura 4.38, de unde cum am mai
spus este selectată implicit intrarea activă, ultima modificare.

Figu ra 4.37 Selector din istoricul task -ului

Figura 4.38 Exemplu lista istoric
La apăsarea unui alt element din istoric, utilizatorul este redirecționat către o pagină în
care poate vedea toate modificările aduse de acesta, cauza respingerii unui task sau c auza
reprogramării task -ului de către inițiator, etc. Inițial linkul accesat conține un sir de interogare
care conține id -ul task -ului din baza de date, dar după selectarea altui element din istoric șirul
de interogare conține și id -ul din tabela de log -uri pe baza căruia putem ști cu exactitate
versiunea pe care utilizatorul dorește să o verifice.
Dacă un utilizator are un link eronat către un task, sau un link către un task șters de
către inițiator sau administrator acesta va vedea un mesaj de eroare (fig ura 4.39) în locul
informațiilor descrise în acest capitol.

Figura 4.39 Eroare link invalid

– 59 –
4.1.7 Reprogramare task
În momentul în care inițiatorul sau administratorul apasă butonul de reprogramare a
taskului pe care îl vizionează sunt redirecționați către o a ltă pagină, denumită
RescheduleTask, care primește de asemenea un șir de interogare cu id -ul task -ului pentru care
trebuie preluate informațiile și, ulterior, salvate modificările cu o nouă intrare în tabela de log –
uri cu o referință către task -ul respecti v.
Aici, asemenea paginii de vizualizare a informațiilor, putem vedea toate informațiile
salvate de inițiator inițial, urmate de un formular cu mai multe câmpuri ce trebuie completate
ca cele din figura 4.40.

Figura 4.40 Formular reprogramare task
Aici putem observa că în partea din dreapta sunt salvate automat, de către aplicație,
informații cu referință la data modificărilor și cu persoana care produce aceste modificări, iar
în partea din stânga sunt două câmpuri care trebuie completate.
Primul câmp ob ligatoriu este cel al noii date scadente, care păstrează termenul inițial,
adică calculează diferența dintre prima dată scadentă și data începerii task -ului, și aplică
rezultatul într -o funcție de autocompletare a noii date scadente în mod implicit, care p oate fi
apoi modificat, dar este menit doar pentru a ușura completarea formularului pe viitor. De
exemplu un task pornit pe data de 1 iulie 2017 și cu data scadentă pe 6 iulie 2017 are un
termen de 5 zile, iar daca reprogramare se face în data de 3 iulie 2 017 este completat automat

– 60 –
câmpul cu data scadentă de 8 iulie, păstrând termenul amintit anterior, cu ajutorul codului
prezentat în figura 4.41

Figura 4.41 Cod aplicare automată a propunerii noii date scadente
Al doilea câmp obligatoriu este unul de tip listă, care conține toate persoanele
înregistrate în baza de date, cu posibilitatea de completare a câmpului de text astfel încât se
filtrează doar rezultatele care conțin șirul de caractere introdus, iar alegerea făcută reprezintă
viitorul responsabil al task-ului, care poate fi de asemenea vechiul responsabil dacă se dorește
doar prelungirea datei scadente.
În formular se poate observa și existența unui al treilea câmp editabil de către persoana
care modifică aceste informații, acesta fiind însă unul opți onal și poate conține comentariile
inițiatorului cu privire la modificările aduse, daca acesta consideră că este nevoie de o
justificare.
4.1.8 Acceptare/Delegare task
În capitolul 4.1.6 am descris sumar anumite funcționalități și acțiuni disponibile doar
anumi tor utilizatori în funcție de statutul sau rolul lor în îndeplinirea task -urilor.
Una dintre aceste funcționalități era cea de verificare a task -urilor și de a refuza sau
accepta task -ul pe baza informațiilor prezentate de către inițiator.
În acest capitol o să descriem separat atât procesul de acceptare și pașii necesari, cât și
cel de respingere a task -ului.
La apăsarea butonului de review, descris in capitolul 4.1.6, utilizatorul responsabil este
redirecționat către o pagina care, la fel ca în celelalte cazuri, cuprinde informația salvată de
către inițiator în același format, oferind mai multă consistență informației și o ușurință în
înțelegerea detaliilor, iar în partea inferioara a paginii putem regăsi informațiile din figura
4.42.

– 61 –

Figura 4.42 Accepta re sau refuzare task
De aici ne putem da seama că, pentru fiecare dintre acțiunile disponibile menționate,
trebuie apăsat butonul corespunzător fiecăreia dintre ele. La apăsarea unui buton secțiunea ce
conține aceste informații și cele două butoane va disp ărea și va fi înlocuită de alte formulare,
după cum urmează a fi descrise în subcapitolele următoare.
Toți utilizatorii au posibilitatea de a delega task -uri către orice alta persoana, astfel
încât, daca apare o problemă inițiatorul task -ului care spera ca problema să fie rezolvata se
poate de asemenea baza și pe cunoștințele celorlalți utilizatori, iar acest flux de respingeri
până ce task -ul ajunge la un utilizator ce posedă cunoștințele de rezolvare și implementare a
task-ului, care va accepta task -ul și se va apuca de rezolvarea sa.
4.1.8.1 Acceptare
În figura 4.43 este prezentat stilul formularului care este ulterior completat de
responsabil, cu câmpurile obligatorii marcate prin caracterul „*”, celelalte devenind opționale,
acompaniate din nou de datele utiliz atorului activ.

Figura 4.43 Formular acceptare task

– 62 –
Odată ajuns pe această pagină, utilizatorul responsabil poate de asemenea, pe lângă
completarea datelor caracteristice lui, să aducă și modificări anumitor informații date de
inițiator, cum ar fi modifi carea priorității, pentru că pentru inițiator poate fi o sarcina cu o
importanță majoră, însă responsabilul se poate să fi primit de la altă persoană o sarcină mult
mai importanta ce necesita mai multă implicare decât task -ul curent, dându -i acestuia
posib ilitatea de schimbare a acestei informații pentru a deveni relevantă.
De asemenea acesta poate schimba și data scadentă, cu până la patru săptămâni
diferență din aceleași motive ca cele prezentate mai sus. La schimbarea datei scadente
utilizatorului ii apa re unul din următoarele mesajele prezentate în figura 4.44, în funcție de
noua dată scadentă aleasă.

Figura 4.44 Mesaje schimbare dată scadentă
Restul câmpurilor de text pot fi completate dacă responsabilul a identificat problema,
are anumite informații legate de aceasta sau poate chiar a finalizat deja rezolvarea și
implementarea unei soluții, însă doar la marcarea căsuței „A” din diagrama PDCA câmpurile
de acțiuni și cauze devin obligatorii, ca în cazul editării ulterioare a unui task. Odată salvat de
aici un task, responsabilul nu mai are drept de editare a priorității și a datei scadente, acestea
putând fi pe viitor modificate doar de inițiator sau administrator.
După apăsarea butonului de salvare a task -ului responsabilul este redirecționat pe
pagina de vizualizare și editare a task -ului, unde sunt prezente informațiile aferente task -ului
tocmai acceptat.
4.1.8.2 Delegare
În aceasta secțiune a paginii, după apăsarea butonului de delegare a task -ului va apărea
formularul din figura 4.45 care trebuie completat d e actualul responsabil al task -ului.
Aici utilizatorul are de completat doar două câmpuri, ambele fiind necesare finalizării
salvării informației în baza de date.
Utilizatorul curent trebuie să furnizeze informații cu privire la alegerea noului
responsabil, care poate fi ales din lista ce conține toate persoanele înregistrate în aplicație, iar
în câmpul Declined comment acesta trebuie să specifice de ce a ales să re fuze executarea

– 63 –
task-ului primit și de ce a ales noua persoană ca responsabil, lucruri ce pot fi pe viitor vizibile
din pagina de vizualizare a task -urilor, prin selectarea acestei intrări din istoricul task -ului.

Figura 4.45 Formular delegare responsab il
Această acțiune înregistrează refuzul responsabilului în tabela de log -uri, utilizatorul
fiind și de această dată redirecționat pe pagina de vizualizare task -ului, unde are acces la
istoric de unde se pot regăsi informațiile lăsate de acesta cu privire la persoana aleasă și date
suplimentare lăsate în comentarii, de asemenea, pentru noul responsabil, iar vechiul
responsabil este acum inițiatorul task -ului său, al noului responsabil.
4.1.9 Editare informații cont
Un utilizator al aplicației are posibilitatea de a-și modifica anumite date înregistrate în
momentul creării contului pe baza căruia se putea autentifica ulterior.
Pentru a ajunge la pagina de administrare a contului, utilizatorul trebuie să poziționeze
cursorul deasupra intrării din meniu care specific ă numele contului care este autentificat în
browser în acest moment, și va apărea un submeniu de tip listă ce conține alte două opțiuni, de
administrare a contului sau de deconectare.
Prin accesarea paginii de administrare apare un formular asemănător celui prezentat în
capitolul de creare a unui cont nou, cum se poate regăsi și în figura 4.46.
Diferența este că din această pagină, utilizatorul păstrează în continuare accesul la
meniul principal, iar informațiile de schimbare a parolei sunt ascunse sub o secțiune de tip
acordeon , care se extinde la apăsarea textului “Change password”.
Toate informațiile prezente pe pagină pot fi modificate, cu excepția câmpului cu
numele de utilizator, care in tabela din baza de date este folosit ca si cheie primara unic ă,
asigurându -ne că nu pot exista două conturi cu nume de utilizatori identice.

– 64 –

Figura 4.46 Schimbare informații cont
De aici apar trei posibile rezultate la încercarea de salvare a rezultatelor in baza de
date:
1) Daca nu este adăugată nicio informație in câmpurile care țin de setarea unei noi
parole, se vor salva doar celelalte informații în baza de date
2) Daca sunt modificări și în câmpurile care aparțin modificării parolei, iar textul
completat in ambele este identic se va modifica și parola în baza de da te
3) Daca sunt modificări și în câmpurile care aparțin modificării parolei, iar textul
completat in acestea nu este identic apare un mesaj de avertizare cu privire la acest
lucru și nicio informație modificata nu va fi actualizata în baza de date
Mesajele ac estor trei rezultate posibile sunt redate în figura 4.47.

Figura 4.47 Mesaje după actualizarea informațiilor legate de cont

– 65 –
4.1.10 Setări administrator
În capitolele anterioare am menționat de existența unui cont de administrator în mediul
acestei aplicații, și am prezentat câteva dintre abilitățile sale, care nu sunt regăsite și la alți
utilizatori.
Printre funcționalitățile specifice doar administratorului și prezentate în capitolele
anterioare sunt permisiunile pe care le are asupra tuturor task -urilor, de a modifica
informațiile care ar trebui să fie accesibile doar inițiatorului sau responsabilului, acesta putând
modifica oricare din aceste informații dorește.
Acestea nu sunt singurele atribuții pe care le are un administrator, mai presus de un
utilizator no rmal, ci odată autentificat cu un cont cu drepturi de administrator în meniul de
navigare putem vedea o noua intrare denumita „Administrator settings”, la plasarea cursorului
asupra căruia se mai deschide un submeniu sub forma de lista care ne prezinta alt e doua
pagini la care doar acesta are acces.

Figura 4.50 Comparare meniu administrator cu meniul implicit
După cum se poate vedea și în figura 4.50 administratorul are în continuare acces în
același fel ca ceilalți utilizatori la toate funcționalitățile aplicației, fiecare pagina aflata în
meniu păstrându -și ordinea, însă apare și o opțiune noua în partea din dreapta.
Prin expandarea meniului specific administratorului putem vedeam și celelalte două
pagini amintite anterior, una dedicată modificărilor adu se bazei de date cu privire la informații
de altfel needitabile, cum ar fi funcțiile, departamentele, categoriile de încadrare ale
taskurilor, etc., dar și o metodă de importare a datelor din format csv, în antetul căruia trebuie
specificat câmpul din baza de date căruia ii se adresează datele.
A doua opțiune ne permite verificarea stării serviciului de trimis mail -uri și mai multe
informații despre mail -urile trimise sau despre erorile apărute în încercarea de a le trimite.
În următoarele doua subcapitole se regăsește o descriere mai amplă a acestor pagini,
accesibile administratorului. Dacă se încearcă accesarea acestor pagini de către orice alt
utilizator acesta este imediat redirecționat la pagina de start, verificarea făcându -se din nou pe
baza cookie -urilor salvate de browser.

– 66 –
4.1.10.1 Serviciul de trimis mail -uri
În această pagină administratorul poate vedea statusul curent al serviciului, dacă acesta
din urmă este activ și începe rularea în fiecare zi.
Acest serviciu este desemnat trimiterii de mail -uri doar c u informarea utilizatorilor
când unul din task -urile lor, fie ca și inițiator al task -ului, responsabil sau superior direct al
responsabilului, mai are cinci zile până la data scadentă, ca o avertizare, în ziua în care task -ul
a ajuns la data scadentă, iar după acest termen, aceștia sunt informați o data la trei zile de
depășirea termenului scadent al task -ului, forțând astfel persoanele implicate să ia o decizie cu
privire la finalizarea task -ului, fie prin ajutarea responsabilului, sau prin prelungirea da tei
scadente sau delegarea unui nou responsabil, celelalte mail -uri la adăugarea unui nou task sau
la modificarea informațiilor relevante fiind trimise pe loc, la momentul producerii
schimbărilor.
Acest serviciu este programat să ruleze oricum în fiecare z i, setarea făcându -se cu
ajutorul programului „Task scheduler” din Windows, iar la începutul rulării aplicației, aceasta
verifica în baza de date daca are dreptul de a rula. Administratorul are acces la doua butoane,
de start și de stop, care doar setează acest drept în baza de date, de unde revine și statusul sub
forma de text pentru a evidenția starea curenta, cum este prezentat și în figura 4.51.

Figura 4.51 Starea serviciului de trimis mail -uri
În această figură putem vedea și un hyperlink care ne redirecționează către un director
virtual setat pe server către calea directorului în care se salvează toate log -urile aferente mail –
urilor.
Prin accesarea lui putem vedea un fișier .csv în care sunt salvate toate erorile care au
apărut, iar împă rțite în foldere regăsim toate rapoartele săptămânale ale serviciului de mail –
uri.

– 67 –

Figura 4.52 Structura folder virtual cu log -uri
Log-urile sunt împărțite pe ani, iar în interiorul fiecărui folder se află rapoartele
săptămânale în cazul în care serviciu l a rulat cel puțin o data în săptămâna respectivă, ca în
figura 4.53 și conțin data rulării, id -ul task -ului, inițiatorul, responsabilul și motivul trimiterii
mail-ului ( ex. a expirat de 9 zile ).

Figura 4.53 Log-uri săptămânale
Aceste informații sunt salvate oricum și în baza de date, iar pe pagina dedicată acestui
serviciu putem regăsi informațiile împărțite în două tabele, unul dedicat log -urilor
săptămânale, dar fără gruparea acestora pe săptămâni sau pe ani, iar în al doilea tabel
informații cu pri vire la erori, precum în figura 4.54, în exact același format ca în fișierele .csv,
de asemenea daca un tabel nu conține nici -o informație este înlocuit de un mesaj care

– 68 –
specifica acest lucru, ca în cazul din figura 4.54 în care nu avem nicio înregistrare în tabelul
de erori, și nici în fișierul .csv aferent acestuia.

Figura 4.54 Varianta WEB a log -urilor
4.1.10.2 Editare informații din baza de date
În această pagină avem acces la informații needitabile de niciun alt utilizator, cum ar fi
adăugarea, modificarea sa u ștergerea oricărei informații din baza de date care poate fi folosită
la crearea sau modificarea contului utilizatorilor, precum funcțiile, departamentele, etc. dar și
informațiile care ajuta la o mai buna încadrare a task -urilor, precum categoriile, sub categoriile
fiecărei categorii, liniile de producție, etc. (figura 4.55)
O altă opțiune regăsită aici este cea de import a altor task -uri salvate în format .csv.
Aceasta funcție are menirea de a face trecerea mai ușoară de la orice alt format care poate
exporta datele la aceasta aplicație, printr -un simplu import al vechilor date, astfel încât la
începerea utilizării aplicației toate vechile date sunt prezente aici. (figura 4.56)

Figura 4.55 Aspect pagina de modificare informații din baza de date

– 69 –
După cum se poate vedea în figura 4.55 toate informațiile sunt trecute în tabele,
despărțite pe categorii, de unde informațiile existente se pot modifica sau se pot șterge, dar
există și opțiunea de a adaugă noi informații în tabelul respectiv, care sunt automat sa lvate și
în baza de date, putând fi utilizate imediat de către utilizatori, iar câmpurile care au fost
modificate vor avea efect asupra tuturor înregistrărilor care au referința către acestea, de
exemplu daca o subcategorie X devine subcategoria Y, în toat e task -urile în care până în acest
moment puteam regăsi în descriere subcategoria X o să regăsim doar noul nume al
subcategoriei.
La fiecare modificare a unei informații utilizatorul este anunțat de statusul modificării,
succes sau eșec prin intermediul că suțelor de mesaje.
Cât despre importul fișierelor, această secțiune este ultima din pagină și este singura
care deține un avertisment pentru a nu se folosi în cazul în care nu se cunoaște exact formatul
fișierului acceptat ca sursă pentru import cum se poa te observa din figura 4.56.

Figura 4.56 Zona de import a datelor vechi
Pentru a deveni un fișier valid, acesta trebuie să fie de format .csv, coloanele despărțite
prin caracterul virgula „ , ”, iar rândurile prin tasta enter.
Acest fișier trebuie să conț ină următoarele titluri de coloane, în orice ordine, iar pe
rândurile următoare să fie completate corespunzător, după cum urmează:
1) Responsible -> numele de utilizator al persoanei responsabile
2) Status -> aici se vor trece opened(neînceput), ongoing(în curs) sau closed(închis)
nu în format PDCA
3) Source Details -> numele subcategoriei de încadrare, categoria putând fi preluată
automat pe baza subcategoriei
4) Place -> locația
5) Production Line -> linia de producție
6) Equipment -> numele echipamentului

– 70 –
7) Product -> numele produsului
8) Problem Description -> descriere problemei
9) Start Date -> data de început zi/luna/an (zz/ll/aa)
10) Due Date -> data de sfârșit(scadentă), numărul săptămânii (ex. CW 30, care
înseamnă săptămâna calendaristică cu numărul 30)
După selectarea unui fișier care corespunde acestui format pe ecran va apărea mesajul
din figura 4.57, iar pentru verificarea rezultatelor, după finalizarea importului trebuie apăsat
butonul de verificare a rezultatelor, care v -a afișa doar task -urile care nu au putut fi introduse
în baza de date, și un motiv pentru acest lucru, precum în figura 4.58.

Figura 4.57 Mesaj finalizare import

Figura 4.58 Rezultat import cu task duplicat
Și după importul acestor fișiere, responsabilul și superiorul său direct sunt anunțați
printr-un mail de existenta unui nou task, însă în câmpul destinat inițiatorului va apărea contul
administratorului, care nu este reamintit de acest lucru.
4.2 Serviciul de trimis mail -uri
Aplicația WEB prezentată în capitolul anterior are un rol foarte importa nt fiind
responsabilă de fiecare interacțiune cu utilizatorul, cât și de stocare a informațiilor în baza de
date și prezentarea acestora în diferite forme finite, precum tabele ale căror informații pot fi
cu o foarte mare ușurință filtrate după necesitați, dar și grafice sugestive cu privire la statusul
sarcinilor din baza de date către utilizatori.
Ceea ce lipsește acestui tip de aplicație, este posibilitatea de a rula anumite comenzi la
intervale orare fixe, pentru a putea stabili un serviciu a cărui sco p este de a trimite atenționări

– 71 –
persoanelor implicate în task -uri care sunt pe punctul de a ajunge la data scadentă, sau chiar
au trecut de această dată, prin intermediul unui mesaj de tip email.
Analizând opțiunile disponibile, am ales realizarea acestui serviciu prin implementarea
codului necesar acțiunilor urmărite într -o aplicație de tip consola (“ Console application ”) care
după executarea acțiunilor este închisă automat.
Codul din figura 4.59 arată modul în care baza de date este interogată pentru a pr elua
informații cu privire la dreptul de rulare al serviciului, setat din aplicația web de către
administrator. Dacă rezultatul stocat în baza de date este unul pozitiv, 1, este apelată o metodă
denumita “ DoStuff ” care primește ca parametru data actuală a sistemului, pe baza căreia poate
calcula timpul rămas până la data scadentă a task -urilor active sau de cat timp a trecut acest
termen, putând lua astfel decizii de trimitere de mail -uri pentru anumite task -uri, care se
încadrează în cerințele noastre.
Toate funcțiile apelate pe viitor salvează in fișiere log și într -o tabelă din baza de date
toate acțiunile, iar in cazul unor erori neașteptate, cu ajutorul blocurilor try catch se salvează
si erorile atât într -un fișier separat cât si într -o tabelă separată din baza de date.

Figura 4.59 Codul funcției Main() al serviciului de mail -uri
În figura 4.60 este prezentat codul dedicat preluării din baza de date a task -urilor ce o
să ajungă in termen de cinci zile la data scadentă, iar apoi pentru fiecare dintre a cestea
apelează o metoda care o sa se ocupe de trimiterea mail -urilor, care primește ca parametrii
contul responsabilului, al inițiatorului si id -ul task -ului din baza de date.

– 72 –

Figura 4.60 Selectare task -uri cu data scadentă peste cinci zile
În figura 4.61, pe același principiu ca înainte, sunt selectate toate task -urile ce au
depășit data scadentă, iar apoi verificate, iar daca diferența dintre data scadentă si data curentă
reprezintă un număr de zile multiplu de trei, atunci se trimite din nou o avert izare specifică.
Putem observa in metoda folosită apariția unui nou parametru, care specifica numărul
de zile trecute de la data scadentă, care este folosit in compunerea mesajului ce urmează a fi
trimis mai departe.

Figura 4.61 Selectarea task -urilor ca re au depășit data scadentă
În figura 4.62 observam un cod asemănător cu cel din figura 4.60, singura diferență
fiind că metoda folosită aici selectează doar task -urile a căror dată scadentă înregistrată în
tabela din baza de date corespunde cu data curentă.

– 73 –

Figura 4.62 Selectarea task -urilor cu data scadentă egala cu data curentă
În figura 4.63 putem observa modul în care este construit mesajul ce urmează a fi
înregistrat, modul în care existența directoarelor si a fișierelor necesare sunt verifica te, iar
dacă acestea nu există sunt create.

Figura 4.63 Cod creare log -uri după trimiterea mail -urilor

– 74 –
Tot aici putem vedea că după salvarea datelor in baza de date si in fișierul de log -uri
specific, în funcție de data calendaristică, fișierul este înch is pentru a nu bloca accesul la
acesta, iar daca in interiorul acestei funcții este detectata o eroare, aceasta este de asemenea
înregistrata în baza de date apelând metoda cu același nume, dar care primește un singur
parametru, care în cazul nostru este r eprezentat de mesajul de eroare returnat chiar de
aplicație, aceste informații fiind vizionate doar de către administratorul aplicației, nu a fost
nevoie de o personalizare a mesajelor înregistrate aici pentru a deveni mai ușor de înțeles
pentru un utiliza tor normal, acesta neavând acces la informație oricum.
În figura 4.64 putem vedea si metoda care se ocupă de înregistrarea log -urilor de
eroare, care este destul de asemănătoare cu metoda prezentata anterior.

Figura 4.64 Cod creare log -uri cu erori

– 75 –
În ac eastă metodă sunt de asemenea verificate existenta directoarelor în care urmează
să fie salvata informația, cât si a fișierului în care se va scrie mesajul de eroare și data la care
s-a produs aceasta, iar în cazul în care acestea lipsesc, sunt create, îns ă putem observa ca aici
exista un singur fișier ce conține aceste informații, spre deosebire de metoda anterioara care
împărțea datele in diferite fișiere in funcție de anul si numărul săptămânii curente. De
asemenea aceasta funcție salvează mesajul atât i n baza de date, pentru a putea fi disponibile
direct din aplicația web de către administrator, dar si in fișierele de log -uri salvate direct pe
server.
Cele doua funcții sunt foarte asemănătoare, deservind într -un fel sau altul același scop
final, cu o inf ormație prelucrata puțin diferit.

Figura 4.65 Cod trimitere mail
În figura 4.65 este prezentat codul folosit pentru trimiterea mail -urilor prin intermediul
unei adrese de gmail creată special pentru această aplicație. Clientul smtp care ne asigură
conexi unea dintre aplicație și contul de Gmail trimite datele de autentificare, iar apoi folosind
clientul, trimite mai departe mail -ul dorit.
4.3 Aplicația de clase comune
Deoarece aplicația constă, după informațiile prezentate până acum, în două proiecte de
tipuri diferite, dar care împreună ajută la îndeplinirea unui singur scop final, cu mai multe
funcționalități, care, prin folosirea unui singur tip de proiect nu ar putea fi posibil sau ar
îngreuna foarte mult implementarea aplicației în forma actuală.
Fiind vor ba după cum am spus de două proiecte care deservesc același scop, este
normal ca acestea sa aibă nevoie de aceleași tipuri de obiecte, clase sau chiar funcții.
Pentru a evita duplicarea codului, toate clasele folosite în aplicație se afla într -un
proiect s eparat, de tip „ Class library ”. Acest tip de proiect este foarte util în astfel de

– 76 –
momente, generând un fișier .dll care poate fi folosit de mai multe proiecte în același timp, iar
aducând o modificare acestui proiect, aceasta este de asemenea prezentă ime diat în toate
celelalte proiecte.
Acest lucru permite optimizarea codului funcțiilor comune sau a claselor prezente aici,
necesitând o singură modificare, reducând foarte mult timpul de lucru. Fără această
posibilitate fiecare modificare trebuia făcută în ambele proiecte dacă se dorea păstrarea unei
anumite consistențe a codului, sau într -un caz mai rău, la depistarea unei probleme ce afecta
ambele proiecte.
Adăugarea acestui tip de proiect ca referință se poate face foarte simplu din interiorul
aplicației „Visual Studio ”, mai ales daca toate proiectele se afla în aceeași „ soluție ”.
Pașii necesari sunt, la fel ca în figura 4.66, următorii:
1) Click dreapta pe proiectul în care dorim introducerea referinței către proiectul de
tip „class library ”
2) Navigăm spre meniul „ Add” din lista apăruta
3) Căutăm opțiunea „ Reference ”
4) Din noua fereastră apărută, putem observa un nou meniu în partea stângă a
acesteia, iar de aici căutam meniul „ Projects ” pentru a putea vedea toate proiectele
care pot împarți resursele
5) La apariția unui nou submeniu, sub câmpul „ Projects ” căutam și apăsam pe
opțiunea „ Solution ” pentru a reduce lista proiectelor la cele care se regăsesc în
aceeași soluție ca proiectul în care dorim adăugarea de referințe
6) Din lista din mijlocul ferestrei se lectam proiectul dorit, în cazul de fata proiectul
denumit “ _Utilities ”
7) Apăsam tasta OK
După urmarea acestor pași, toate obiectele din interiorul proiectului referit sunt
disponibile și în proiectele în care este referit acesta.
În acest proiect sunt difer ite clase care ajuta la o mai ușoara structurare a codului în
celelalte proiecte, de la conexiunea la baze de date și preluare și inserare date în baza de date
până la crearea de obiecte specifice aplicației și funcții extensibile ajutătoare acestora și co d
folosit pentru a asigura posibilitatea trimiterii de mail -uri.
Toate clasele au fost prezentate în capitolul trei, iar structura fișierelor în directoare
este prezentata în figura 4.67.

– 77 –

Figura 4.66 Adăugare proiect ca referința

Figura 4.67 Fișier ele proiectului

– 78 –
5 Concluzii
Obiectivul lucrării a fost de a îmbunătăți procesul de producție din fabrici, prin
implementarea unui sistem de înregistrare și verificare a task -urilor digital.
Din câte am putut observa, principala problemă în sistemele actuale este reprezentată
de lipsa de comunicare intre angajați, iar prin intermediul unui sistem capabil de a notifica
părțile implicate la producerea unei modificări majore, în comparație cu schimbul de
informație direct intre angajați, task -urile au put ut fi finalizate și verificate mai rapid, iar în
momentul unor probleme asemănătoare, toate informațiile de remediere a ei erau deja salvate
în baza de date, oferind un suport în plus, astfel rezolvând în principal problema lipsei de
comunicare.
Am abordat o soluție aparent simplă, care păstra pașii deja cunoscuți și folosiți de
către persoanele implicate în acest proces, dar am implementat -o într -aplicație web accesibilă
tuturor, creând o interfață comună și intuitivă, astfel încât să devină ușor de utiliz at, poate
chiar într -un mod mai natural decât al vechiului proces.
Avantajele aduse de această implementare sunt portabilitatea, compatibilitatea și
modul ușor în care aplicația poate fi accesată și utilizată.
Pentru a putea fi capabil să utilizeze aplica ția, fiecare angajat putea face acest lucru
după crearea unui cont rapid.
Am reușit, așa cum am menționat anterior, păstrarea modelului deja cunoscut de către
angajați, și anume modelul PDCA, în care o sarcină poate parcurge următoarele stări:
1. Plan (P) – stadiul de planificare a unei rezolvări
2. Do (D) – stadiul în care se încearcă rezolvarea problemei
3. Check (C) – stadiul de verificare a problemei după implementarea rezolvării
găsite
4. Act (A) – verdictul final, în cazul în care în urma ultimei verificări a fos t
constatată eliminarea problemei
Folosind aceste stări, într -un format grafic intuitiv, ușurința de familiarizare cu
aplicația de către utilizatori a crescut, convertind modelul deja cunoscut de aceștia într -unul
identic, dar digital.
Pentru a asigura un nivel de securitate, de fiecare dată când un utilizator accesează
pagina cu detalii specifice unui task, sunt folosite datele furnizate în momentul autentificării
care sunt comparate cu datele prezente în informațiile task -ului salvat, oferindu -i, dacă este
cazul, acces la modificări în cadrul acelui task, care diferă în funcție de statutul său, spre

– 79 –
exemplu un responsabil nu poate șterge un task primit de la o alta persoană, însă primește
drepturi de modificare a câmpurilor cu informați i ce trebuie completate de acesta.
În cazul necesitații unui raport asemănător cu celui generat conform vechii metode de
planificare a sarcinilor, acest lucru poate fi făcut extrem de rapid și de ușor din interfața
aplicației, existând un buton dedicat de exportare a datelor, atât grafice cât și a tabelelor, și
aici reducând din nou timpul pierdut de o persoană desemnată să prelucreze datele din format
scris pentru a genera aceste rapoarte.
Daca pe viitor apar necesitați de modificare a informațiilor, precu m numele
departamentelor sau a funcțiilor angajaților, acest lucru este posibil prin contul de
administrator creat, care are acces la aceste funcții.
Toate obiectivele inițiale au fost atinse în acest proiect, oferind o metodă alternativă,
digitală, a unei metode cunoscute de planificare, oferind un mediu mai sigur de prelucrare a
informației, posibilitatea de a exporta toate datele în același format ca acela al vechii metode
de planificare, și de notificare a persoanelor implicate în task -uri la fiecare mo dificare majoră
sau la apropierea, atingerea și depășirea datei scadente.

– 80 –
6 Webliografie și bibliografie
[1] Informații Visual Studio, https://msdn.microsoft.com/en –
us/library/fx6b k1f4(v=vs.90).aspx , (data accesării: 03.05.2017).
[2] Informații Visual Studio
generalizate ,https://en.wikipedia.org/wiki/Microsoft_Visual_Studio (data accesării:
11.06.2017).
[3] Documentație C# , https://msdn.microsoft.com/en -us/library/z1zx9t92.aspx , (data
accesării: 04.05.2017)
[4] Introducere în C#, https://d ocs.microsoft.com/en -us/dotnet/csharp/csharp , (data
accesării: 12.06 .2017)
[5] Despre C#, https://en.wikipedia.org/wiki/C_Sharp_(programming_language) , ( data
accesării: 13.06 .2017)
[6] Arhitectura .NET, http://www.c -sharpcorner.com/UploadFile/puranindia/net –
framework -and-architecture/ , ( data accesării: 13.06 .2017)
[7] Informații arhitectura .NE T, https://en.wikipedia.org/wiki/.NET_Framework , ( data
accesării: 13.06 .2017)
[8] Ghid .NET, https://docs.microsoft.com/en -us/dotnet/standard/ , (data
accesării:02.06.2017 )
[9] Discuții diferențe și relații în .NET,
https://softwareengineering.stackexchange.com/questions/44810/relationship –
between -c-net-asp-asp-net-etc, (data accesării: 12.06 .2017)
[10] Ce este ASP .NET și Web Forms, https: //docs.microsoft.com/en -us/aspnet/web –
forms/what -is-web-forms , (data accesării: 04.05.2017)
[11] Introducere JavaScript, https://www.quirksmode.org/js/intro.html , (data accesării:
04.05.2017)
[12] Informații JavaScript, https://developer.mozilla.org/en –
US/docs/Web/JavaScript/About_JavaScript , (data accesării: 04.05.2017)
[13] Standard CSS, https://www.w3.org/standards/webdesign/htmlcss , (data accesării:
04.05.2017)
[14] Informații CSS, https://en.wikipedia.org/wiki/Cascading_Style_Sheets , (data
accesării : 04.05.2017)
[15] Bootstrap, http://getbootstrap.com/ , (data accesării: 04.05.2017)
[16] Structura fișiere Bootstrap,
https://www.packtpub.com/mapt/book/web_development/9781784395179/2/ch02lvl1s
ec13/the -bootstrap -file-structure , (data accesării: 10.06.2017)
[17] Aplicații de tip consola, https://en.wikipedia.org/wiki/Console_application , (data
accesării: 04.05.2017)
[18] Despre Class Library, https://msdn.microsoft.com/en –
us/library/gg145045(v=vs.110).aspx , (data accesării: 06 .05.2017)

– 81 –
[19] Diferențe Class Library și Shared Project,
https://stackoverflow.com/questions/30634753/wha t-is-the-difference -between -a-
shared -project -and-a-class -library -in-visual -st, (data accesării: 06 .05.2017)
[20] Introducere în Oracle,
https://docs.oracle.com/cd/B19306_01/server. 102/b14220/intro.htm , (data
accesării:02.06.2017 )
[21] Comparare baze de date, https://stackoverflow.com/questions/4954076/differences –
between -mysql -and-oracle -db, (data accesării:02.06.2017 )
[22] Oracle SQL Developer, https://en.wikipedia.org/wiki/Oracle_SQL_Developer , (data
accesării: 03.05.2017).
[23] Mod funcționare IIS,
https://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/29f
ab1cf -8983 -4f62 -bff5-356057630f17.mspx?mfr=true , (data accesării: 10.06.2017)
[24] Introducere IIS, https://www.iis.net/learn/get -started/introduction -to-iis, (data
accesării: 15.06 .2017).
[25] Informații IIS, https://en.wikipedia.org/wiki/Internet_Information_Services , (data
accesării: 15.06 .2017).
[26] Task Scheduler, https://en.wikipedia.org/wiki/Windows_Task_Schedule r, (data
accesării: 15.06 .2017).
[27] Ben Albahari , Joseph Albahari, C# 6.0 in a Nutshell, Editura: O’Reilly Media, Inc.,
1005 Gravenstein Highway North, Sebastopol, CA 95472.
[28] G. Andrew Duthie, Matthew MacDonald , ASP.NET in a Nutshell, 2nd Edition, Editura:
O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.