Asist.dr. Vasile Silviu Laurențiu [603360]

1
UNIVERSITATEA DIN BUCUREȘTI
FACULTATEA DE MATEMATICĂ ȘI INFORMATICĂ
INFORMATICĂ

LUCRARE DE LICENȚĂ

Coordonator științific:
Asist.dr. Vasile Silviu Laurențiu

Student: [anonimizat] 2016 –

2
UNIVERSITATEA DIN BUCUREȘTI
FACULTATEA DE MATEMATICĂ ȘI INFOR MATICĂ
INFORMATICĂ

Sistem de gestionare a activităților în
cadrul unei firme IT

Coordonator științific:
Asist.dr. Vasile Silviu Laurențiu

Student: [anonimizat] 2016 –

3
CUPRINS
CUPRINS ………………………….. ………………………….. ………………………….. ………………………….. …….. 3
CAPITOLUL 1 – INTRODUCERE ………………………….. ………………………….. ………………………….. 5
1.1. Servicii de gestionare a tehnologiei informatice ………………………….. …………………………. 5
1.2. Indicatori Cheie de performanță ………………………….. ………………………….. ………………….. 8
1.3. Metodologia Agilă ………………………….. ………………………….. ………………………….. ………. 10
CAPITOLUL 2 – TEHNOLOGII UT ILIZATE ÎN DEZVOLTAREA APLICAȚIEI …………….. 13
2.1. HTML ………………………….. ………………………….. ………………………….. ………………………….. . 13
2.1.1. Prezentare și istoric ………………………….. ………………………….. ………………………….. …… 13
2.1.2. Versiuni, dezvoltare, HTML5 ………………………….. ………………………….. ………………… 14
2.2. CSS ………………………….. ………………………….. ………………………….. ………………………….. ….. 18
2.2.1. Prezentare și dezvoltare ………………………….. ………………………….. …………………………. 18
2.2.2. Bootstrap ………………………….. ………………………….. ………………………….. …………………. 20
2.3. JavaScript ………………………….. ………………………….. ………………………….. ……………………… 22
2.3.1. Prezentare și istoric ………………………….. ………………………….. ………………………….. …… 22
2.3.2. jQuery ………………………….. ………………………….. ………………………….. …………………….. 25
2.3.3. Ajax ………………………….. ………………………….. ………………………….. ……………………….. 26
2.3.4. Chart.js ………………………….. ………………………….. ………………………….. ……………………. 29
2.4. Servere web ………………………….. ………………………….. ………………………….. …………………… 29
2.4.1 . Prezentare și istoric ………………………….. ………………………….. ………………………….. …… 29
2.4.2. Protocolul HTTP ………………………….. ………………………….. ………………………….. ……… 30
2.4.3. Serverul Apache ………………………….. ………………………….. ………………………….. ………. 32
2.5. PHP ………………………….. ………………………….. ………………………….. ………………………….. ….. 33
2.5.1. Prezentare și istoric ………………………….. ………………………….. ………………………….. …… 33
2.5.2. MCV – Model -View -Controller, CodeIgniter ………………………….. ……………………….. 36

4
2.5.3. FPDF ………………………….. ………………………….. ………………………….. ………………………. 39
2.6. MySQL ………………………….. ………………………….. ………………………….. …………………………. 39
2.6.1. Prezentare și istoric ………………………….. ………………………….. ………………………….. …… 39
2.6.2. MySQL și PHP ………………………….. ………………………….. ………………………….. ………… 41
CAPITOLUL 3 – DESCRIEREA APLICAȚIEI ………………………….. ………………………….. ………. 43
3.1. Motivarea alegerii ………………………….. ………………………….. ………………………….. …………… 43
3.2. Scopul aplicației ………………………….. ………………………….. ………………………….. …………….. 43
3.3. Realizarea aplicației ………………………….. ………………………….. ………………………….. ………… 44
3.4. Structura aplicației ………………………….. ………………………….. ………………………….. ………….. 45
3.4.1. Structura logică ………………………….. ………………………….. ………………………….. ………… 45
3.4.2. Arhitectură ………………………….. ………………………….. ………………………….. ………………. 47
3.4.3. Structura bazei de date ………………………….. ………………………….. ………………………….. . 48
3.5. Utilizarea aplicației ………………………….. ………………………….. ………………………….. …………. 52
3.5.1. Tutorial de utilizare ………………………….. ………………………….. ………………………….. ….. 52
3.5.2. Scenariu de utilizare ………………………….. ………………………….. ………………………….. …. 54
CAPITOLUL 4 – CONCLUZIE ………………………….. ………………………….. ………………………….. … 59
BIBLIOGRAFIE ………………………….. ………………………….. ………………………….. ……………………… 60

5
CAPITOLUL 1 – INTRODUCERE
În domeniul tehnologiei informației cerințele pieței vor fi întotdeauna într -o continuă
creștere. Motiv pentru care nu e de mirare căutarea în mod constant a unor abordări inovatoare
pentru gestionarea mediilor de lucru în cadrul departamentelor din acest domeniu. În același timp
și în aceeași măsură, se dorește furnizarea continuă a serviciilor ad -hoc, dar și contabilizarea
activelor la un moment dat și a modificărilor pe parcursul unei perioade anterior determinate.
De aceea devine din ce în ce mai greu s ă se găsească o cale de mijloc care să
mulțumească toate cerințele. Iar în ultimii ani s -au făcut eforturi în acest sens, creându -se diverse
aplicații care să susțină aceste nevoi.
Adesea piața avea de oferit o aplicație care să rezolve una sau două cerin țe, însă când vine
vorba despre domeniul informatic, cerințele depășesc cu mult oferta. Multe firme caută o
aplicație care să le poată monitoriza și gestiona în mod corect evenimentele survenit e în cadrul
firmei astfel încât în urma utilizării lor să poată trage anumite concluzii, să poată eficientiza
procesele pe care le desfășoară. Dar odată ce exist ă o măsură aplicabilă evenimentelor, următorul
pas este cuantificarea actestor acțiuni, fie prin activitățile în sine, fie prin ore sau orice altceva, pe
scurt numiți indici.
Implementarea unui astfel de sistem a fost problematică, iar multe softuri ofereau jumătăți
de măsură. Motiv pentru care punerea cerințelor, din punct de vedere al utilizatorilor, la un loc au
condus la crearea unei aplicații, SmarTicket.
1.1. Servicii de gestionare a tehnologiei informatice
Fie că vorbim despre o nouă aplicație, o nouă caracteristică a unei aplicații, rezolvarea
unui incident neprevăzut sau schimbarea unui element de configurare schimbările se petrec în
mod constant. În cazul domeniului de tehnologia informației (TI) aceaste schimbari au loc la
nivelul întregului departament. Ritmul alert în care au loc aceste schimbări determină
departamentele informatice să reacționeze cel puțin la fel de rapid. Ca urmare, scopul final este
înțelegerea deplină a efectelor urmate de schimbările survenite, minimizarea impactului negativ
asupra serviciilor puse la dipozitia clienților, reducerea costurilor de întreținere ale serviciilor și
sporirea productivității și profitabilității afacerii. Î n întâmpinarea acestora, soluția optimă este

6
adesea implementarea unei strategii de Gestiune a Serviciilor Informatice (eng. Information
Technology Service Management – ITSM).
Gestionarea Serviciilor Informatice este un termen general care descrie o abor dare
strategică pentru proiectarea, livrarea, gestionarea și îmbunătățirea modului în care tehnologia
informației este utilizată în cadrul unei organizații. Scopul fiecărei strategii de Gestionare a
Serviciilor Informatice este de a se asigura că procesele , oamenii și tehnologia sunt la locul și
momentul potrivit, astfel încât organizația poate îndeplini obiectivele sale de afaceri.
În termeni simpli, Gestionarea Serviciilor Informatice este o practică centrată pe procese
destinată să alinieze livrarea serv iciilor tehnologice cu nevoile întreprinderii, evidențiind
beneficiile pentru clienții interni și externi organizației. Astfel, are loc o schimbare de paradigmă
în gestionarea serviciilor informatice. Acestea încetează sa mai fie tratate ca mulțimi de
comp onente individuale, accentul fiind pus în special pe livrarea serviciilor ca un tot unitar care
satisfac nevoile utilizatorilor. Scopul final al unei strategii de Gestionare a Serviciilor Informatice
este de a obține performanțe, urmărind obiectivele organ izației. Acestă schimbare de paradigmă
de la abordarea serviciilor în mod tradițional la o nouă strategie de gestionarea a lor poate fi
decrisă prin următoarea diagramă [30]:
TI tradițională Gestiunea Serviciilor Informatice
Concentrare pe tehnologie Conc entrare pe procese
Tehnică de ”stingere a incendiilor” Prevenție
Reactiv Proactiv
Utilizatori Clienți
Produse centralizate, internalizate Produse distribuite, externalizate
Procese izolate, închise Procese integrate, la nivel de întreprindere
Procese la cerere, ad -hoc Procese repetitive, de încredere
Procese informale Procese standardizate, bune practice
Perspectivă internă departamentului de TI
asupra proceselor si produselor Perspectivă de afaceri asupra proceselor si
produselor
Orien tat spre operațiune Orientat spre serviciu

Originile strategiei de Gestionare a Serviciilor Informatice au fost în jurul anilor 1990,
odată cu dezvoltarea treptată a Librăriei de Infrastuctură a Tehnologiei Informatice (LITI, eng.

7
Information Technology Infrastructure Library – ITIL), un set de cărți care prezentau bune
practici de urmat în cadrul organizației.
Librăria de Infrastuctură a Tehnologiei Informatice este un cadru de lucru care conține
bune practici, cunoscut anterior sub denumirea de Bibliot eca Infrastructurii TI. În prezent este
considerată cea mai populară sursă de informare și consultare în utilizarea strategiilor de
gestionare. Librăria de Infrastuctură a Tehnologiei Informatice vine în sprijinul persoanelor și a
organizațiilor care dores c să abordeze o strategie de Gestionare a Serviciilor Informatic e pentru a
realiza schimbări.
La baza Librăriei de Infrastuctură a Tehnologiei Informatice stau următoarele concepte:
 nu urmărește furnizarea de produse informatice, propriu -zis; furnizează servicii bazate pe
procese informatice, care să sprijine procesele de afaceri;
 clienții sunt consumatori ai tehnologiei informației ca serviciu, și nu sunt consumatori ale
ieșirilor sau componentelor informatice;
 tehnologia informației trebuie să fie gesti onată ca un serviciu.

În cadrul unei firme de programare abordarea unei strategii de Gestionare a Serviciilor
Informatice nu va aduce întotdeauna inovație, pe cât va aduce structură și o mai bună organizare
a timpului angajaților, a resurselor hardware si financiare de care dispune firma respectivă și
posibilitatea analizării datelor pentru îmbunătățiri acolo unde au loc.
În prezent, probabil majoritatea firmelor de tehnologia informației fac deja unele activități
de gestionare a serviciilor informatice, doar că nu total sau nu conform principiilor care stau la
baza strategiei. Astfel, oricare sau toate dintre următoarele activități se regăsesc in Gestionarea
Serviciilor Informatice:
 răspuns și rezolvare a problemelor de infrastructură, aplicație sau întâm pinate de
utilizatorul final – reprezintă gestionarea incidentelor;
 furnizarea de programe sau infrastructură, permiterea accesului la rețea – reprezintă
îndeplinirea cererii;
 asigurarea tutorialelor pentru utilizatorii finali in cazul programelor noi – reprezintă
îndeplinirea cererii;
 gestionarea controlată a schimbărilor în infrastructură sau aplicații – reprezintă controlul
schimbării;

8
 monitorizarea rețelei, a infrastructurii și a disponibilității aplicației – reprezintă gestiunea
evenimentelor;
 planific area schimbărilor viitoare ca urmare a apariției noilor tehnologii sau a
modificărilor specificațiilor – reprezintă capacitatea de gestionare sau chiar gestionarea
cererii;
Principiile de la baza strategiilor de gestionare a serviciilor informatice aduc un plus
practicilor curente prin implementarea unor standarde. Astfel activitățile care produc
inconsistență și nu sunt realizate într -un mediu controlat, acum devin organizate și interconectate
când este cazul. Standardele neclare devin formalități prin imp lementarea documentației și
respectarea bunelor practici stabilite apriori, astfel activitățile își însușesc bunele practici
existente în domeniu. Ajustarea proceselor să fie repetitive transformă timpul petrecut anterior cu
muncă manuală în timp util dezv oltării. Prin urmare, adoptarea acestor strategii asigură
încadrarea în cele mai bune practici și stau la baza optimizării activităților firmei.
1.2. Indicatori Cheie de performanță
Când vine vorba despre o strategie de Gestionare a Serviciilor Informatice, exi stă anumite
standarde sau măsurători în funcție de care se stabilește performanța acesteia. Aceste standarde
sunt cunoscute drept indicatori de perfomanță(eng. Key Performance Indicator – KPI).
Adesea performanța reprezintă pur și simplu realizarea repetat ă și periodică a unor
obiective operaționale definite apriori (de exemplu, zero elemente de configurare defecte, sută la
sută satisfacția clientului, etc) sau uneori, performanța este definită în termeni de progres către
obiectivele strategice stabilite an terior. Prin urmare, alegerea indicatorilor de performanță se
bazează in special pe o bună înțelegere a ceea ce este important pentru organizație. De multe ori
ceea ce este important depinde de măsurarea performanței departamentului; de exemplu
indicatorii de perfomanță utili în cazul evaluării vânzărilor vor fi diferiți față de indicatorii de
performanță corespunzători departamentului informatic. Din nevoia de a înțelege importanța,
diverse tehnici de a evalua stadiul actual al afacerii și al activităților sale cheie sunt asociate cu
selectarea indicatorilor de performanță. Aceste evaluări conduc adesea la identificarea
potențialelor îmbunătățiri, astfel încât indicatorii de performanță sunt în mod obișnuit asociați cu
inițiative de îmbunătățire a performan ței. O modalitate foarte comună de a alege indici de
performanță este de a aplica o startegie de gestion are.

9
Anterior am precizat că indicatorii de performanță diferă în funcție de afacere și
obiectivele acesteia. O reprezentanță auto ar putea lua în consi derare numărul de un anumit
model de mașini vândute ca un indicator de performanță, care ar urmări perfomanța vânzărilor
modelului respectiv în piața și anul curent, în timp ce o firmă de tehnologia informația ar putea
lua în considerare procentul de inci dente soluționate în limita Acordului Privind Calitatea
Serviciilor (eng. Service Level Agreement – SLA) în anul cure nt ca indicator de performanță.
Etapele -cheie în stabilirea identificatorilor de performanță sunt:
 existența unui proces de afaceri de pred efinit;
 existența cerințelor pentru acesta;
 considerarea unei măsurători cantitativă / calitativă a rezultatelor și compararea cu
obiectivele stabilite;
 posibilitatea investigării și intervenției asupra proceselor sau resurselor pentru a atinge
obiective p e termen scurt sau neprevăzute.
Indicatorii cheie sunt metode de evaluare periodică a performanțelor organizațiilor, a
departamentor și a angajaților. Prin urmare, indicatorii de performanță sunt cel mai frecvent
definiți într -un mod care sunt ușor de înțe les, sunt semnificativi și măsurabili. Indicii ai căror
definiții îngreunează îndeplinirea lor din cauza unor factori ce nu pot fi controlați de către
organizație sau de către persoanele responsabile sunt adesea ignorați.
Este foarte important ca indicii d e performanță să urmeze criteriile SMART (specific,
măsurabil, accesibil, relevant, timp). Astfel, măsura are un scop specific pentru afaceri, este
măsurabil pentru a obține într -adevăr performanță, normele definite trebuie sunt accesibile
(realizabile), î mbunătățirea unui indice trebuie să fie relevantă pentru succesul organizației și în
cele din urmă acesta trebuie să aibă loc progresiv din punctul de vedere al perioadelor de timp în
care se urmărește obținerea rezultatelor. Pentru a putea fi evaluați, in dicii au drept corespondent
valori -țintă, umărind ca valoarea măsurii să poate fi evaluată precu m așteptărilor sau nu.
Exemple de indici de performanță în cadrul operațiunilor din domeniul informatic:
disponibilitatea elementelor de configurare, media timp ilor de așteptare în caz de eșec, media
timpilor de soluționare a incidentelor, incidente neplanificate, media timpilor de livrare a
sarcinilor de lucru, numărul de clienți noi/vechi, media orelor petrecute pe lună muncind versus
media banilor cheltuiți in cadrul unui proiect, data de livrare estimată versus data ac tuală de
livrare a proiectului.

10
Totusi, indicatorii de performanță pot duce, uneori, la consecințe nedorite ca urmare a
angajaților care lucrează la măsurătorile date în detrimentul calității mun cii lor. De exemplu,
măsurarea productivității proiectului unei echipe în numărul de commituri făcute poate încuraja
în mod greșit comiterile pentru modificări ce nu își au rostul ca fiind individuale, ceea ce duce la
îngreunarea urmăririi dezvoltării proi ectului și la timp p ierdut pe o versionare inutilă.
Prin abordarea unei strategii de Gestionare a Serviciilor Informatice și stabilirea unor
indici de perfomanță se urmăresc sporirea productivității firmei si reducerea costurilor de orice
tip. Astfel, ind icii de performanță sunt stabiliți atât la nivelul firmei, cât și la nivelul echipelor și
individual. Scopul stabilirii indicilor de perfomanță indiviuali trebuie să tindă spre performanța
dorită la nivelul întregii organizații. Un astfel de exemplu este s tabilirea ca indice a numărului de
ore petrecute rezolvând incidente să fie sub orele petrecute în dezvoltarea unui produs. În acest
mod, un indice individual conduce la atingerea mai multor indici la nivelul organizației: creșterea
productivității, reduce rea costurilor pe suport și creșterea încrederii clienților în produsele pe care
le dezvoltă respectiva firmă.

1.3. Metodologia Agilă
Dezvoltarea de software sub metodologia Agila respectă o serie de principii de dezvoltare
în cadrul cărora cerințele si im plementările reies din colaborarea dintre echipele de dezvoltatori
din diferite arii ale proiectului. Aceasta promovează abilitatea de a adapta planificarea inițială,
dezvoltarea evolutivă, livrarea înainte de termen și îmbunătățirea continuă a acesteia și
încurajează adaptabilitatea și flexibilitatea în fața schimbărilor. Metodologia Agila, în sine, nu a
definit nicio metodă specifică pentru a realiza ceea ce promovează, dar multe metode au fost
acceptate si recunoscute ca fiind Agile.
Metodologia Agila a apărut în anul 2001, dezvoltată de 17 programatori in Utah, în urma
apariției metodelor de dezvoltare ușoare, opuse trendului precedent de programare grea,
repectând modelul programării în cascadă. Sloganul metodologiei publicat in Manifestul pentru
Dezvol tarea Agilă de Software, apărut în anul 2001, este: ”Noi scoatem la iveală modalități mai
bune de dezvoltare de software prin experiență proprie și ajutându -i pe ceilalți.”. Astfel,
metodologia este compusă din 12 principii esențiale care pun clientul pe p rimul loc în orice etapă
a dezvoltării programelor, promovează livrarea timpurie și acceptarea faptului ca procesul de

11
dezvoltare poate fi unul îndelungat, incurajează comunicarea între oamenii de afaceri și
dezvoltatori, dar și între dezvoltatori, promove ază comunicarea in conexiune invers ă și
simplitatea în programare.
Metodele Agile se concentrează, în principal, pe diferite aspecte ale ciclului de viață al
programului în curs de dezvoltare. Cele mai multe metode promovează dezvoltarea, munca în
echipă, colaborarea și procesul de adaptabilitate pe tot parcursul ciclului de viață al proiectului.
Unele se concentreză mai multe pe practici (de exemplu programarea extremă, programare
pragmatică, modelarea agilă), în timp ce altele se concentreză pe gestionare a proiectelor (de
exemplu Scrum). Printre metodologiile Agile se întâlnesc și abordări care oferă o acoperire
completă pe durata ciclului de viață de dezvoltare (de exemplu metoda de dezvoltare a sistemelor
dinamice – DSDM), dar cele mai multe dintre ele s unt potrivite începând din faza cerințelor de
specificație înainte (de exemplu dezoltare condusa de caracteristici – FDD). Astfel, se poate
observa o diferență clară între metod ele Agile din această privință.
Cele mai agile metode de dezvoltare împart proi ectele și noile caracteristici în sarcini mai
mici, pe o perioadă minimă și nu implică în mod direct planificarea pe termen lung. Iterațiile
reprezintă termenele scurte, care de obicei durează între una și patru săptămâni. Fiecare iterație
implică o echipă compusă din membri cărora le corespund diferite funcții: planificare, analiză a
cerințelor, proiectare, codare, testare unitară și de testare de conformitate. La sfârșitul iterației un
produs funcțional este prezentat clienților. Acest lucru minimizează r iscurile globale de eșec și
permite proiectului să fie ușor adaptabil la schimbărilor ce pot interveni. Deși o iterație nu adăugă
suficientă funcționalitate pentru a crea un produs finit ce poate fi scos pe piață, obiectivul acesteia
este de a avea o versi une curată, lipisită de probleme de programare la sfârșitul fiecărei iterații.
Multiple iterații pot fi necesare pentru a obține un produs finit sau pentru a dăugarea de
caracteristici noi.
De asemenea, o caracteristică comună în metodologiile agile este se dința zilnică, numită
in metodologii stand -up sau scrum . Astfel, într -o foarte scurtă ședință, fiecare membru al echipei
raportează ceea ce a făcut în ziua precedentă în sprijinul procesului de îndeplinire al scopului
iterației respective în cadrul echipe i lor, ceea ce urmează să facă în ziua curentă urmărind același
scop, precum și orice probleme pe care le -au întâmpinat sau le pot întâmpina în dezvoltare.
Adăugând metodologia Agilă strategiei de Gestionare a Serviciilor Informatice și indicilor
de perfor manță se obține un mediu de lucru axat pe productivitate și pe un raport productivitate –
cost supraunitar. Astfel, mediul de lucru este controlat ca urmare a principiilor Librăriei de

12
Infrastuctură a Tehnologiei Informatiei, ținut întotdeauna în parametrii optimi de funcționare prin
implementarea iterațiilor și țintește spre progres prin introducere indicilor de performanță.

13
CAPITOLUL 2 – TEHNOLOGII UTILIZATE ÎN
DEZVOLTAREA APLICAȚIEI
2.1. HTML
2.1.1. Prezentare și istoric
La sfârșitul anilor 1980, Tim Ber ners – Lee , fizician la CERN ( Organizația Europeană
pentru Cercetare Nucleară ), împreună cu inginerul de sisteme de date Robert Cailliau, a lucrat la
un prototip și a reușit să creeze o modalitate de a partaja documente pe internet destinată
comunicării între oamenii de știință, numit Enquire. Acest soft a pus bazele a ceea ce cunoaștem
noi azi drept WWW (World Wide Web). Înaintea acestei dezvoltări, comunicarea prin
intermediul Internetului era limitată la utilizarea textului simplu, folosind tehnologii simpliste
precum e -mail-ul, conversații pe forumuri care foloseau Usenet sau trimiterea și primirea
fișierelor text prin FTP(Protocol de Transfer al Fișierelor, eng: File Transfer Protocol). HTML
(HyperText Markup Language) folosea un model stocat pe un s erver central, care permitea
transferul către o stație de lucru locală și posibiliatea de a fi vizualizat într -un browser. Astfel,
creștea accesibilitatea conținutului și totodata posibilitatea de a îmbogăți pe cât posibil acest
conținut prin formatare ma i sofisticată sau adăugare de imagini.
Prima descriere publică a HTML a fost un document numit "Taguri HTML". HTML
utilizează un set predefinit de elemente pentru a defini tipurile de conținut. Elementele conțin
unul sau mai multe taguri, care conțin sau e xprimă conținut . Tagurile sunt entități închise între
paranteze unghiulare care închid conținutul între ele, iar în plus, tagul de închidere începe cu o
bară oblică. Prima apariție pe internet documentului a fost la sfârșitul anului 1991 și a aparținut
lui Tim Berners -Lee. Documentul descrie 18 elemente cuprinse în proiectul inițial, o versiune
simplă a limbajului. Cu excepția a puține taguri, HTML este derivat apropiat al SGML (Standard
Generalized Markup Language), o sintaxă complexă pentru marcarea sau legarea de continut în
documente. Dintre cele 18 taguri inițiale, în HTML4 se regăsesc 11, iar începând cu HTML5 se
încearcă îndepărtarea completă de SGML.
HTML este în primul rând un limbaj de marcare. Sensul cuvântului „marcare” a fost dat
de către edito ri, care marcau manuscrisele, de obicei, folosind un creion albastru, atunci când
dădeau instrucțiuni pentru revizii. Însă acum „marcaj” înseamnă ceva puțin diferit: este un limbaj

14
cu sintaxă specifică având scopul de a da instrucțiuni unui browser Web pen tru cum să afișeze o
pagină. De menționat este că HTML separă tot ceea ce ține de conținut (cum ar fi cuvinte,
imagini, conținut audio sau video, etc) de ideea de prezentare (care înseamnă strict instrucțiuni
pentru afișarea fiecărui tip de conținut). Limb ajul asigură formatarea corectă a textului și a
imaginilor, astfel încât browserul să le poate afișa în mod corect, după cum au fost destinate. Fără
a HTML, un browser nu ar ști cum să se afișeze textul sau orice alt element în mod corect.Astfel,
acesta of eră o structură de bază a paginii, pe care CSS (Cascading Style Sheets) este suprapus
pentru a estetiza.
HTML este format dintr -un set de elemente care definesc semnificația semantică a
conținutului lor. Elementele sunt definite de cele două etichete de de schidere, închidere și de
conținutul dintre ele (de exemplu <p> Acesta este un paragraf </p> ). Anumite elemente au un
sens foarte precis, fie prezintă strict o imagine, un început de pagină sau o listă neordonată. Altele
sunt mai puțin specifice și tind s ă cuprindă mai multe alte elemente specifice: o secțiune din
pagină sau secțiune de tip articol. Pe lânga acestea, există și cele folosite strict din motive tehnice
pentru identificarea informațiilor din pagină și pentru analiza SEO (Search Engine Optimiz ation).
Indiferent de tipul lor, într -un fel sau altul, toate elemente le HTML au o valoare semantică.
La rularea codului HTML, browserul nu afișează tagurile așa cum sunt ele scrise, ci le
interpretează pentru a afișa coținutul paginii, scopul lui general fiind de a citi documente și de a
le transpune in pagini web. Despre elementele HTML se poate spune că sunt pietrele de temelie
ale site -urilor web deoarece este un limbaj care permite încorporarea de imagini și obiecte, un
limbaj care oferă un mijloc de a crea documente structurate și care poate fi ușor modelat prin
intermediul altor limbaje de programare web. În prezent, HTML, alături de alte limbaje web, face
parte din standardul international stabilit de către W3C (World Wide Web Consortium) pentru
Design și Aplicații Web.
2.1.2. Versiuni, dezvoltare, HTML5
De la apariție până în prezent, HTML a fost și este un limbaj în continuă evoluție.
Păstrând scopul acestui limbaj în minte, este de înțeles ca nu stagnează mult timp înainte de a fi
publicat un set revizuit de standarde și specificații pentru a crește gradul de accesibilitate și
eficiență al site -urilor atât pentru utilizatori, cât și pentru dezvoltatori.
 HTML 1.0

15
 A fost prima versiune a HTML lansată. La vremea respectiva, nu erau mulți
oameni imp licați în crearea de site -uri web, iar limbajul în sine era foarte limitat.
Capabilitățile sale erau reduse, permițând doar simpla afișare a unui text într -un
browser. Însă atunci, asta era tot ceea ce se căută la un astfel de limbaj.
 HTML 2.0
 A inclus to ată specificația originalului 1.0, adăugând, în mod normal, câteva
caracteristici noi. HTML 2.0 a fost accesptat ca standard pentru proiectarea site –
urilor până în ianuarie 1997, reprezentând un efort susținut al IEFT (Internet
Engineering Task Force) și a definit pentru prima dată mai multe caracteristici de
bază ale HTML.
 HTML 3.0
 Din ce în ce mai mulți oameni se implică în dezvoltarea HTML și în timp ce
standardele anterioare au oferit unele abilități decente, încă exista o cerere pentru
mai multe abilit ăți și taguri cu scopul de a îmbunătăți și aspectul. Astfel, Dave
Raggett împreună cu un grup de dezvoltatori au propus HTML 3.0. Din cauza
ritmului lent în care s -au mișcat browserele să implementeze noile propuneri,
proiectul lui Dave nu a fost realizat. Din acest moment a fost observata nevoia de
modularizare atât în utilizare cât și în implementare.
 HTML 3.2
 Tagurile specifice fiecărui browser au continuat să apară. Atfel, a devenit evident
că era necesar un standard. În acest scop, W3C (World Wide Web Consortium) a
fost înființat în anul 1994 pentru a standardiza limbajul și pentru a -i urmări
evoluția în direcția cea bună. Prima lor lucrare, cu numele de cod WILBUR , a
devenit mai târziu cunoscută sub numele de HTML 3.2. Acasta a reprezentat o
schimbare totală a standardelor existente, împărțind pe o perioadă mai îndelungată
viitoare schimbări majore ale limbajului. Tagurile specifice unor anumite
browsere, nu au ajuns în noul standard. În scurt timp, standardul propus de W3C a
prins si a devenit standar dul oficial în ianuarie 1997, iar astăzi toate browserele îl
susțin pe deplin.
 HTML 4.0
 A reprezentat o adevarată evoluție atât a limbajului, cât și a standardelor. A fost
propus de W3C în decembrie 1997 și a devenit standardul oficial în luna aprilie

16
1998. În aceasta nouă versiune a limbajului, accentul a picat în special pe
adăugarea functionalității estetice prin introducerea de foi de stil CSS (Cascade
StyleSheets).
 HTML 4.01
 A apărut la scurt timp, conținând actualizări minore ale HTML 4.0 și soluții pentru
probleme cunoscute din versiunea anterioară.
 HTML 5
 A fost publicat în octombrie 2014 de către W3C cu scopul de a optimiza limbajul,
adăugând suport pentru surse noi multimedia și în același timp menținându -l ușor
de citit de către oameni și ușor de înțeles de către calculatoare și alte dispozitive
(browsere, interpretoare, etc). Limbajul extinde și îmbunătățește marcajele
disponibile pentru documente și introduce noi marcaje și posibilitatea utilizării
API-urilor (Application Programming Interface s) pentru aplicațiile web complexe.
Din aceleași motive, HTML5 devine un candidat pentru aplicații mobile de tip
cross -platform, deoarece include caracteristici proiectate specific pentru
dispozitivele mici, cum ar fi smartphone -uri și tablete.
 De asemene a, multe caracteristici noi sintactice sunt incluse. Pentru a include și
manipula surse noi multimedia apar tagurile <video>, <audio>, pentru conținut
grafic specializat apare elementul <canvas> care adăugă și suport pentru Grafice
Vectoriale Scalabile (SV G – Scalable Vector Graphics), iar elementele de tip
MathML sunt incluse pentru formule matematice. Mai mult, pentru a îmbogăți
conținutul semantic al documentelor apar noi elemente de structură pagină, cum ar
fi <main> <section>, <article>, <header>, <foo ter>, <aside>, <nav> și <figure>.
Noi atribute sunt introduse, unele elemente si atribute sunt eliminate, iar altele,
cum ar fi <a>, <cite> și <menu> suferă modificări, redefiniri sau standardizări.
 HTML5 păstrează compatibiliatea cu versiunea anterioară, HTML4, utilizată în
masă la momentul actual, adăugând noi funcționalități, reguli de securitate și
validare și o mai bună integrare cu CSS și limbajele de scripting. De asemenea,
API-urile și Document Object Model (DOM) reprezință acum părți fundamentale
ale specificațiilor HTML5.
Document Object Model (DOM) (figura 2.1 [25]) este o convenție destinată tuturor
platformelor și limbajelor pentru prezentarea și manipularea obiectelor de tip HTML, XHTML

17
(Extensible Hypertext Markup Language), și XML (Extensible Markup Language) în documente.
Nodurile fiecărui document din tipurile enumerate anterior sunt reprezentante într -o structură
arborescentă numită arborele documentului. Orice obiect din arborele documentului poate fi
selectat și modificat prin diverse met ode puse la dispoziție de CSS sau JavaScript.

Figura 2.1

Istoria arborelui DOM începe în aceeași vreme cu apariția limbajului JavaScript și
războiul rece purtat între cele două mari companii ale anilor 1990, furnizoare de browsere
Micr osoft și Netscape. Vremea respectivă a dat naștere arborelui DOM clasic (eng: legacy DOM)
datorită limitării tipurilor de elemente accesibile. Formularul, ancora și elemente de imagine
puteau fi referențiate începând cu rădăcina documentului și continuând pe linia ierarhică a
arborelui. Un nume din ierarhia arborelui putea fi chiar numele elementului sau un indice al

18
elementului în cauză dintre toate elementele traversate. De exemplu, un element text de intrare
dintr -un formular era accesibil fie direct dup ă nume (document.numeFormular.numeIntrare),
unde numele erau date în tagul fiecăriua în atributul de nume sau cunoscând faptul că elementul
de selectat se afla în primul formular al paginii, prima intrare text din formulat, accesarea se
făcea cu aju torul indicilor ( document.forms[0] .elements [0]). Astfel, încă de pe atunci
era posibilă validarea conținutului la nivel de client.
Următoarea versiune de DOM a luat naștere în urma evoluției limbajelor de scripting care
permiteau schimbări HTML fără a reîncărca întreaga pagină, odată cu apariția HTML Dinamic.
Această versiune a fost cunoscută sub numele de DOM Intermediar. În anii următori W3C a adus
împreună marile companii Microsoft și Netscape și alte câteva companii pentru a lucra împreună
la dezvoltarea unui standard de scripting acceptat de toate browserele, cunoscut sub numele de
ECMAScript (European Computer Manufacturers Association Script). Din acel moment W3C a
început lucrul la un DOM Standardizat și a lansat mai multe versiuni care adăugau din ce în c e
mai multe posibilități. În prezent, utilizat și recunoscut de către toate browserele este DOM 3 din
anul 2004 și se lucrează la DOM 4.
2.2. CSS
2.2.1. Prezentare și dezvoltare
Fișierele de stil au existat de pe vremea SGML, într -o formă sau alta încă din anii 1980.
Însă CSS a fost creat special pentru paginile web. Dezvoltarea sa a început mai târziu, iar prima
propunere de CSS în fața World Wide Web Consortium a fost în anul 1994 aparținând lui Håkon
Wium Lie. În jurul aceleiașă perioade, au fost înainta te mai multe tipuri de foi de stil destinate
webului. Una dintre cerințele pe care un astfel de limbaj trebuia să le respecte a fost posibilitatea
ca foile de stil sa poata proveni din diferite surse de pe Internet. După mai multe discuții și votări,
în an ul 1996 a fost stabilit primul standard ai foilor de stil web, CSS1 avându -i ca autori pe
Håkon Wium Lie și Bert Bos. CSS1 a respectat cerința impusă de W3C prin implementarea ideii
de cascadă care permitea influențarea aceluiași document HTML de mai mult e fișiere CSS.
CSS1 permitea schimbarea fontului, a culorii, modificarea spațierii și a marginilor și
introduce ideea de clase si identificatori. În anul 1998 apare CSS2 care introduce noi concepte de
manipulare a poziției elementelor, a textului și a int roduce tipul media în limbajul de stilizare. În
anii următori, a existat o variantă CSS2.1 care își propunea rezolvarea unor probleme din CSS2

19
însă nu a ajuns niciodată să fie publicată. Niciuna dintre versiunile prezentate nu mai sunt
susținute de standar dul W3C. În prezent, standardul este stabilit de către CSS3. Dezvoltarea sa a
început în aceeași perioadă cu CSS2.1, însă acesta a fost creat modular, spre deosebire de
varsiunile anterioare, păstrând în acelși timp compatibilitatea cu acestea. Deși multe din modulele
sale sunt încă în lucru, CSS3 este standardul curent de foi de stil destinate webului, cunoscut sub
numele de CSS.
Cascading Style Sheets (CSS) este un limbaj, reprezentat printr -o foaie de stil, folosit
pentru a descrie aspectul prezentării u nui document scris într -un limbaj de marcare. Cel mai des
este folosit pentru a stabili aspectul paginilor web și interfețelor scrise în HTML. Însă limbajul
poate fi aplicat oricărui document de tip XML (Extensible Markup Language) sau SVG oferind și
supor t pentru redare audio. Împreună cu limbajul HTML, CSS este o piatra de temelie a
dezvoltării web, fiind folosită în aproape toate site -urile cu scopul de a crea pagini web
antrenante din punct de vedere vizual sau interfețe pentru aplicații web și aplicați i mobile.
Scopul CSS este în primul rând de a separara conținutul documentului de prezentarea sa,
mai exact ceea ce ține de aspect, culori sau font. Această separare poate îmbunătăți accesibilitatea
conținutului. În același timp, oferă mai multă flexibilit ate și control în specificarea
caracteristicilor de prezentare și foarte important, permite mai multor pagini HTML să folosească
aceeași formatare prin specificarea regulilor CSS într -un fișier separat cu extensia css. Astfel, se
urmărește modularizarea pr in reducerea complexității și a repetării în conținutul structural.
Limbajul vine în ajutorul HTML prin accesibilatea pe care o oferă. Prin separarea
formatării de conținut, apare posibilitatea prezentării aceleiași pagini în stiluri diferite, cu metode
de redare diferite, cum ar fi pe ecran, în format tipărit, prin voce (conținut citit cu voce tare de
browser) sau prin dispozitive tactile bazate pe Braille. Fiind un limbaj puternic din punct de
vedere al regulilor pe care le poate aplica paginilor, acesta introduce ideea de fluiditate a
prezentării prin abilitatea de a se adapta în mod dinamic la momentul vizualizării diferit pe
dispozitive de diverse dimensiuni sau cu diverse sisteme de operare. În plus, stilul paginii poate
fi ușor modificat prin specif icarea unei alte căi împreună cu un alt fișier cu extensia css, aflat pe
server sau local. Modificările aduse stilului grafic al unuia sau mai multor documente care
folosesc aceeași foaie de stil, pot fi aplicate rapid și ușor, prin editarea câtorva linii în fișierul
CSS. În prezent, standardul specifică utilizarea fișierelor CSS separat de fișierele de HTML
întocmai pentru a permite modularizarea lor și pentru a facilita schimbările care pot interveni.

20
Specificațiile actuale ale CSS descriu foarte bine un sistem de prioritate pentru a stabili
regulile care se aplică în cazul în care mai mult de o singură regulă este atribuită unui anumit
element. De aici pornește și ideea de cascadă, în sensul în care fiecare regulă pornește de la
general la specific, iar prioritatea urmează același sens previzibil: cea mai mare prioritate in
cadrul fișierelor CSS separate o au regulile aplicate la nivelul elementului în mod specific. Însă,
în cazul adăugării regulilor în pagina HTML, aceste reguli vor avea cea mai mare pri oritate,
indiferent de ceea ce există în fișierul CSS. În general, cu excepția a puține taguri care au declarat
stilul în interiorul tagului, cuprinderea regulilor de CSS într -un fișier separat este considerată o
bună practică.
Sintaxa CSS este simplă și pe înțelesul oricui, folosind o gamă limitată de cuvinte numite
selectori pentru a specifica reguli de stilizare. O foaie de stil conține mai multe reguli
reprezentată prin selectori având fiecare un bloc declarativ închis între acolade. Selectorii pot fi
oricare dintre tagurile de HTML (toate paragrafele – p, toate listele neordonate – ul, toate titlurile
de nivel unu – h1), atribute de tip clasa sau id (.clasa care poate conține mai multe elemente, #id
care este atribuit unic unui element) ale acestora sa u elemente din HTML dependente de poziția
pe care o ocupa în arborele documentului (ultimul copil al unei liste ordonate – ol:last -child).
Pentru a include o foaie de stil în documentul HTML, trebuie precizată calea fișierului CSS,
împreună cu tipul relați ei la începutul fișierului HTML, în secțiunea de header (<link
href="calea/spre/fișierul.css" rel="stylesheet">).
În prezent, specificația CSS este menținută de către World Wide Web Consortium care
pune la dispoziția dezvoltatorilor un validator de documen te CSS alături de validatorul pentru
HTML.
2.2.2. Bootstrap
Odată cu dezvoltarea HTML și CSS, au apărut nevoi noi ale dezvoltatorilor și soluții
pentru acestea: cadrele de lucru (framework) web destinate proiectării frontend pentru site -uri si
aplicații we b, mai exact cadrele de lucru CSS. Acestea sunt cadre de lucru care simplifică
procesul de stilizare și îl standardizează folosind limbajul CSS. Adesea, pe langa CSS cadrele de
lucru frontend conțin și funcționalități mici scrise în JavaScript sau jQuery, dar accentul pică în
special pe partea de aspect și nu pe funcționalitate. Printre caracteristicile acestor cadre de lucru
se numără module și unelte care vin în sprijinul dezvoltatorilor, precum fonturi speciale, stilizare
de elemente (butoane, formulare, câmpuri, etc), părți ale intefeței paginii, adesea animate (carusel
de imagini, taburi, ferestre modale, etc), cadre din interfață (cutii, containere, etc).

21
Bootstrap este un cadru web destinat frontend gratuit și open -source pentru proiectarea
site-urilo r web si aplicatiilor web. Conține părți scrise în HTML și în special șabloane de design
bazate pe CSS pentru tipografie, elemente precum formulare și butoane, navigare și alte
componente de interfață, precum și câteva funcționalități, extensii opționale s crise în JavaScript .
Spre deosebire de multe alte cadre de lucru web, Bootstrap se adresează doar dezvoltării
frontend.
Bootstrap, inițial numit Twitter Blueprint, a fost dezvoltat de Mark Otto și Jacob
Thornton la Twitter, la mijlocul anului 2010, ca un cadru de lucru pentru a mai bine închega
uneltele interne de dezvoltare frontend. Înainte de apariția Bootstrap, diverse biblioteci erau
utilizate pentru dezvoltarea interfeței, ceea ce a creat inconsistențe și dificultăți de întreținere.
Câteva luni după ce a început dezvoltarea, la Twitter a avut loc prima săptămână de hacking și
dezvoltarea proiectului a explodat, dezvoltatori de toate nivelurile de calificare lucrând la el, fără
a avea nicio ghidare externă. Atfel, Twitter Blueprint a devenit Bootstrap și a fost ghidul de stil
pentru dezvoltarea internă în cadrul companiei mai bine de un an, înainte de a fi publicat, în anul
2011, și continuă să fie utilizat în aceeași manieră și astăzi.
Un an mai tărziu, în 2012, dezvoltarea a ajuns la Bootstrap2 care i ntroducea sistemul de
grilă pe 12 coloane foarte utilizat în prezent, împreună cu schimbări la componentele deja
existente și compomente adaptive în functie de dimensiuni, browser și sistem de operare. În 2013,
a fost anunțat Bootstrap3 care a adus la ceea ce exista deja o abordare a dispozitivelor de tip
mobil și a reîmprospătat designul. Anul 2015 a adus versiunea alpha a Bootstrap4, versiunea
Bootstrap scrisă în limbajul de scripting Sass (Syntactically Awesome Stylesheets). Sass este un
limbaj de script ing, care este interpretat la nivelul CSS și care extinde CSS. SassScript este
limbajul de scripting în sine. Sass este format din două sintaxe, dintre care cea de -a doua este
folosită extensiv, SCSS (Sass CSS), folosind sintaxa CSS.
Bootstrap este un sist em modular și este conceput dintr -o serie de foi de stil de tip Less în
care sunt implementate diferitele componente ale sale. O filă de stil numită bootstrap.less include
mai multe componente ale foilor de stil. Less este un limbaj dinamic care poate fi c ompilat în
CSS și poate rula atât pe server, cât și pe partea de client. Prima versiune de Less a fost scrisă în
Ruby, dar s -a renunțat complet la acesta, iar în prezent Less este scris în JavaScript. Less oferă
mecanisme noi precum variabile, funcții, ope ratori și foarte important este că acesta este rulat în
timp real prin legătura cu JavaScript (less.js).

22
Începând cu versiunea Bootstrap2, este pusă la dispoziția dezvoltatorilor o opțiune
specială de a personaliza configurația în documentație. Mai mult d ecât atât, dezvoltatorul alege în
baza unui formular componentele dorite și poate ajusta, dacă este necesar, valorile diverselor
opțiuni pentru nevoile sale. Pachetul generat ulterior include deja foaia de stil CSS pre -construite
conformă specificațiilor d ate.
Pachetul Bootstrap oferă un set de foi de stil, care conțin definiții de stil de bază pentru
toate componentele cheie HTML. Acestea asigură un aspect uniform și modern pentru formatare
elementelor care conțin text, tabele și formulare. Pe lângă elemen tele HTML obișnuite, Bootstrap
adaugă alte elemente de interfață utilizate în mod obișnuit, în special animate. Printre acestea se
numără butoane cu funcții avansate (grup de butoane, butoane drop -down, butoane de navigare,
navigare prin breadcrumbs, etc), etichete, capabilități avansate de tipografie, imagini de font (de
exemplu Font Awesome, o gamă de fonturi și miniaturi creată special pentru Bootstrap în Less și
Sass), mesaje de avertizare. Componentele sunt implementate sub formă de clase CSS, care
trebuie să fie aplicate anumitor elemente HTML din pagină. De asemenea, Bootstrap vine cu mai
multe componente JavaScript sub formă de adiții scrise în jQuery. Ele oferă elemente
suplimentare de interfață, cum ar fi caruselele. Acestea extind funcționalitățil e deja exitente ale
unor elemente de interfață. În versiunea Bootstrap2, următoarele adiții JavaScript sunt acceptate:
ferestre modale, meniu alegere dată, meniu dropdown, taburi, ponturi, alerte, buton, colaps,
carusel și multe altele.
2.3. JavaScript
2.3.1. Prezentare și istoric
JavaScript este un limbaj de programare de nivel înalt, dinamic, weak -typed și interpretat
și este standardizat în specificația ECMAScript (European Computer Manufacturers Association
Script). Alături de HTML și CSS, acesta este u nul dintre cele trei mari tehnologii de bază în
dezvoltarea conținutului web. Aproape toate site -urile utilizează JavaScript și toate browserele
moderne oferă suport pentru acest limbaj. Limbajul JavaScript este un limbaj bazat pe prototipuri
și conține fu ncții de primă clasă, ceea ce îl transformă într -un limbaj multi -paradigmă. De
asemenea are suport pentru programarea orientată pe obiecte, imperativă și funcțională.
Limbajul JavaScript este folosit și în medii din afara lumii Web, cum ar fi lucrul cu
documente PDF, și aplicații desktop. Rapiditatea și robustețea limbajului au dus la dezvoltarea

23
mașinilor virtuale (MV) în JavaScript și a platformelor construite pe ele sporind astfel
popularitațea limbajului pentru aplicațiile web pe partea de server. Îns ă, pe partea de client,
JavaScript este utilizat ca limbaj interpretat, cu excepția unor browsere moderne care
compilarează fișierele js la momentul rulării. Fiind ușor integrabil, limbajul JavaScript a luat
amploare și ca urmare poate fi utilizat în dezvo ltarea de jocuri, crearea de aplicații desktop și
mobile, precum și în programarea pe partea de server cu posibiliatea rulării în timp real, cum ar fi
Node.js.
JavaScript a fost creat în mai, anul 1995 de către Brendan Eich, care lucra în acea vreme
la Net scape, în doar zece zile. Limbajul a avut mai multe nume pe parcursul dezvoltării: numele
original a fost Mocha, ales de Marc Andreessen, fondatorul Netscape. În luna septembrie, 1995
numele a fost schimbat la LiveScript, apoi în luna decembrie a aceluiași an, după ce a fost
licențiat de către Sun, i -a fost dat numele pe care îl poartă și astăzi de JavaScript. Redenumirea la
JavaScript a fost oarecum o mișcare de marketing, de introducere pe piață deoarece limbajul Java
era foarte popular atunci. De aici și confuzia care ține chiar și în prezent între cele două limbaje
cum că ar avea o legătură; cele două sunt complet diferite deoarece au la bază ideologii total
diferite.
În anul 1996, Netscape a prezentat JavaScript la ECMA pentru a obține standardizarea
limbajului astfel încât furnizorii de browsere sa îl poată implementa după modelul Netscape.
Astfel a apărut standardul ECMAScript în anul 1997, îmbunătățit pe parcursul anilor în
ECMAScript 2, în 1998, respectiv ECMAScript 3 în anul 1999, care a devenit baz a a ceea ce este
JavaScript. În prezent, standardul este ECMAScript 6, publicat în anul 2009.
Microsoft a încercat prin propriile implementări de VBScript și JScript lansate în 1996 să
creeze ceea ce Netscape reușise. JScript era chiar o încercare de copie a JavaScript obținută prin
procesul de inginerie inversă, integrată în Internet Explorer 3 și în Internet Information Server
(IIS). Deși atât Netscape Navigator, cât și Internet Explorer ofereau suport pentru CSS, HTML și
scripting, cele două browsere nu ofereau deloc consistență. Dezvoltatorii de produse funcționale
în Netscape nu reușeau să își facă proiectele să ruleze pe Internet Explorer și viceversa. Totul din
cauza implementării diferite pe care cele două browsere le abordau. Ca urmare a războiului rece
dintre cei doi funizori, a apărut și ideea de a specifica faptul că site -ul este funcțional doar într -un
anumit browser, printr -un logo. Odată cu prograsul JavaScript, Microsoft părea să sprijine
limbajul prin implementarea propunerilor ECMAScript 3 î n limbajul JScript.net. Totuși, în timp

24
ei nu au depus niciun efort pentru a implementa JavaScript în browserul lor, Internet Explorer. În
prezent, JavaScript este funcțional chiar și pe Internet Explorer.
Cu timpul, JavaScript a devenit una dintre cele ma i populare limbaje de programare web.
Deși la început, a fost privit ca o piedică în dezvoltarea web din cauza războiului dintre Netscape
si Microsoft, iar mulți programatori profesioniști au comentat la adresa limbajului care avea ca
public țintă autori a l site -urilor web și în general amatori. În timp ce popularitatea JavaScript era
încă disputată, comunitatea de dezvoltatori au început să lucreze cu noul limbaj. Astfel în anul
2005 a avut loc apariția Ajax din partea lui Jesse James Garrett. Lucrarea sa prezenta utilizarea
JavaScript drept coloana vertebrală a unei noi tehnologii de a aduce date în pagină, ca proces de
fundal, fără a fi nevoie de a reîncărca întreaga pagină. Astfel JavaScript a revenit în lumina
reflectoarelor și a dus la promovarea limba jului prin crearea altor librării precum jQuery, Dojo
sau Mootools. Rezultatul final a fost o creștere în număr a cadrelor de lucru și a bibliotecilor,
îmbunătățirea practicilor de programare JavaScript și creșterea utilizării limbajului JavaScript în
afara browserelor, după cum reiese din popularitatea utilizării JavaScript pe partea de server.
O utilizare comună a JavaScript este de manipula comportamentul paginii HTML pe
partea clientului, cunoscut ca HTML Dinamic (DHTML, eng: Dynamic HTML). Scriptul de
JavasScript este fie încorporate, fie inclus în pagina HTML cu scopul de a interacționa cu
Document Object Model (DOM). În general, se practică ambele metode deoarece unele
funcționalități necesită folosirea JavaScript încorporată în pagina HTML. Însă o bu nă practică, la
fel ca în cazul CSS, este de a separa comportamentul paginii de pagina în sine si de a inlcude
fișierul cu extensia js. Câteva exemple simple de întrebuințări sunt:
 Animația aplicată elementelor din pagină: dispariție cu temporizare prin de colorare,
redimensionare, mutare la suprapunerea cursorului și multe altele
 Conținutul interactiv: jocuri ăn browser, redarea audio și video
 Prima validare a valorilor de intrare ale unui formular înainte de a fi transmise serverului
 Colectarea de informaț ii despre obiceiurile utilizatorului și despre site -urile vizitate de
acesta cu scopul de analiză comportamentului pe internet, de urmărire a anunțurilor cu
grup țintă, de personalizare a ofertelor în funcție de comportament sau în alte scopuri
analitice
 Cum JavaScript poate rula local în browser, acesta poate răspunde la acțiunile
utilizatorului rapid, fiind mai ușor receptiv: poate detecta apăsarea tastelor individuale și

25
acționa în baza unor reguli, poate face apeluri în fundal către server fără a reîncă rca
pagina
Codul sursă JavaScript este interpretat și executat de un motor JavaScript. Primul astfel de
motor a fost creat de către Brendan Eich, pentru browser Netscape Navigator. Motorul, cu nume
de cod SpiderMonkey, a fost implementat în C. În timp, ace sta a fost actualizat pentru a se
conforma la ECMAScript. Un alt motor JavaScript este motorul Rhino, creat în primul rând de
Norris Boyd, o implementare în Java. Ambele motoare sunt conforme ultimului standard.
Pentru că JavaScript este singuraul limbaj pentru care majoritarea browserelor oferă
suport, aceasta a devenit o limbaj țintă pentru multe cadre de lucru din alte limbaje de
programare, chiar dacă JavaScript nu a fost niciodată creat cu acest scop.
2.3.2. jQuery
jQuery este o bibliotecă JavaScript cross -platform concepută pentru a simplifica
scriptingul pe partea de client în cazul paginilor HTML. La momentul actual, jQuery este cea mai
populară bibliotecă de JavaScript, cu un procentaj de utilizare de aproximativ 65% în primele
zece milioane de sit e-uri dintre cele mai frecventate site -uri web (potrivit Libscore, o alta
bilbliotecă JavaScript). jQuery este o librărie gratuită, open -source sub licența MIT (licența MIT
permite reutilizarea codului în cadrul aplicațiilor proprii cu o condiție: toate co piile aplicației
lansate vor include o copie a termenilor de licență MIT și o notificare privind drepturile de autor).
Așa cum am precizat anterior, dezvoltarea bibliotecilor JavaScript au început în anul
2005. După o perioadă de dezvoltare, jQuery a fost lansat inițial în ianuarie 2006 la BarCamp în
New York de autorul său, John Resig. Biblioteca poartă influențe ale cssQuery, o alta bibliotecă
anterior lansată de către Dean Edwards. Librăria jQuery este în prezent menținută de către o
echipă de dezvoltato ri condusă de Timmy Willison. Așa cum JavaScriptul are propriul motor, și
jQuery are motorul său de selectori, Sizzle, pr oiect condus de Richard Gibson.
Sintaxa jQuery este proiectată special pentru a facilita navigarea în document, selectarea
elementelor DOM, crearea animațiilor, administrarea evenimentelor, și pentru a dezvolta aplicații
Ajax. Pe lăngă utilizarea sa în aplicații, jQuery oferă dezvoltatorilor resurse pentru a crea module
proprii având la bază biblioteca JavaScript. Acest lucru permite dezv oltatorilor să creeze animații
proprii și efecte speciale avansate. Abordarea modulară a bibliotecii jQuery permite crearea de
pagini web dinamice puternice și aplicații web.
Setul de caracteristici jQuery include selecții de elemente din arborele document ului
(DOM), parcurgere și manipulare. Acesta sprijinit de motorul de selectori (Sizzle), au creat un

26
nou stil de a programa, prin fuzionarea algoritmilor cu structurile de date din DOM. Acest stil a
influențat arhitectura altor cadre de lucru JavaScript pr ecum YUI și Dojo, iar mai târziu, a dus la
crearea standardului API pentru selectori.
jQuery, este în primul rând o librărie de manevrare a elementelor DOM. Reamintind,
despre DOM se poate spune că este o reprezentare arborescentă de structura a tuturor el ementelor
unei pagini web, iar jQuery vine în sprijinul simplificării sintaxei pentru identificarea, selectarea
și manipularea acestor elemente. Cel mai adesea, jQuery este folosit pentru identificarea unui
element din document caracter izat de o anumită pr oprietate ( cum ar fi toate elementele de tip
paragraf – tagul p), pentru schimbarea uneia sau mai multora dintre atributele sale (font,
dimensiune, poziție) sau pentru răspunsul la evenimente (apăsarea unei taste, încărcarea paginii).
Librăria jQuery oferă metode de manipulare a evenimentelor care vin în plus selecției de
bază a elementelor. Astfel, posibilitatea creării unei funcții cu apel invers (callback) este
facilitată, atribuirea evenimentului și definirea acestei funcții realizându -se într -un singur pas în
cod. jQuery este utilizat cu precădere în combinație cu JavaScript, făcând mai ușoară selecția
elementelor.
Printre avantajele utlizării jQuery se regăsesc:
 Prin ușurința selectării elementelor, lucrului cu elementele și manipularea evenimentelor,
jQuery încurajează separarea JavaScript de HTML
 jQuery promovează claritatea codului, folosind funcții succinte și clare
 Elimină posibile incompatibilități între browsere, motorul Sizzle ocupându -se de
diferențele posibile dintre browsere oferind o interfa ță consistentă
 Este un limbaj extensibil, astfel evenimente, elemente sau metode noi pot fi adăugate fără
probleme, modularizate și apoi reutilizate ca module.
2.3.3. Ajax
Ajax (JavaScript și XML Asincron, eng: Asynchronous JavaScript and XML) reprezintă
un mulțime de tehnici de dezvoltare web, folosind alte tehnologii web pe partea de client pentru a
creea aplicații web asincrone. Folosind Ajax, aplicațiile web pot trimite date către server și pot
prelua date de la server în mod asincron, mai exact procesu l de trimitere sau preluare se
desfășoară în fundal, fără a fi necesară o reîncărcare a afișajului și comportamentului paginii
curente.
În anii 1990, majoritatea site -urilor web se bazau integral pe pagini HTML. Atfel, fiecare
acțiune a utilizatorulu neces ita reîncărcarea completă pe server a unei pagini. Acest proces a fost,

27
desigur, catalogat drept ineficient din punct de verede al experienței utilizatorului: tot conținutul
paginii a dispare, iar apoi a reapare. De asemenea, un alt mare dezavantaj era fap tul că de fiecare
dată când browserul reîncărca o pagină în cadrul căreia apărea o schimbare. Asfel, la cea mai
mică schimbare, tot conținutul trebuia să fie retrimis. Acest lucru plasa de obicei o muncă
suplimentară serverului limitând clar performanța.
Astfel, a început lucrul la o modalitate de a elibera serverul de ceea ce avea de încărcat în
mod constant. În 1996, primul tag introdus pentru a aduce conținut asincron a fost tagul iframe
introdus prin Internet Explorer. În 1998, echipa Microsoft Outlook a implementat prima
componentă de tip XMLHTTP în scriptul care rula pe partea clientului. Mai târziu, în anul 1999,
Microsoft a utilizat tehnologia anterior introdusă de iframe pentru a actualiza în mod dinamic
știrile și cotațiile bursiere de pe pagina d e casă din Internet Explorer, și a implementat controlul
XMLHTTP ActiveX în versiunea de Internet Explorer 5. Ulterior acesta a fost adoptat și de
Mozilla, Safari, Opera și alte browsere ca obiectul JavaScript de tip XMLHttpRequest. Mai
târziu, Microsoft a adoptat modulul XMLHttpRequest în cadrul Internet Explorer 7. Versiunea
ActiveX este încă acceptată în toate versiunile curente de Internet Explorer, mai puțin în ultimul
produs al lui Microsoft, Edge. Utilitatea cererilor către server realizate pe fundal de tip HTTP, cât
și întreaga ideea de tehnologie web asincronă a rămas neclară, până a apărut folosită în aplicații la
scară largă, precum Outlook Web App și mai târziu Oddpost.
O mișcare cel puțin îndrăzneață a venit din partea Google. Acesta a implement at la scară
largă, conform stadardelor impuse, un Ajax funcțional pe toate browserele prin Gmail (2004),
respectiv Google Maps (2005). În octombrie 2004 lansarea publică în faza beta a kayak.com a
fost printre primele utilizări la scară largă în cadrul une i aplicații de e -commerce a utilizării a
ceea ce dezvoltatorii lor au numit la acel moment dat „acel lucru xml http” (eng. „the xml http
thing”).
Termenul în sine de Ajax a fost prezentat publicului larg în anul 2005 de Jesse James
Garrett într -un articol intitulat „Ajax: O nouă abordare a aplicațiilor Web”, bazat pe tehnicile
utilizate de Google în paginile sale.
În anul 2006, W3C a lansat primele specificații ale obiectului XMLHttpRequest într -o
încercare de a stabili un standard oficial al Ajax pe web. C ea mai recentă schiță a ceea ce
înseamnă obiectul XMLHttpRequest a fost publicată în anul 2014.
Toate cererile Ajax sunt declanșate în mod automat de cod JavaScript. Astefel, codul
trimite o solicitare împreună cu niște date către o adresă și așteaptă un r ăspuns de la aceasta. În

28
momentul în care primește un răspuns, o funcție de apel invers (callback) este automat declanșat
să se ocupe de răspuns sau de funcția de succes, cum mai este cunoscut conceptul. Deoarece
cererea este asincronă, restul codului HTML sau JavaScript continuă să execute, în timpul în care
cererea Ajax încă este în curs de procesare. Această etapa face imperativă existența unui apel
invers pentru a gestionarea răspunsul cererii.
Însă, din păcate, diferite browsere implementează API -ul pe ntru Ajax în mod diferit. În
general, aceasta însemna că este sarcina dezvoltatorilor să țină cont de toate implementările din
browsere pentru a se asigura că Ajax funcționează indiferent de platforma în care este utilizat.
Din fericire, jQuery, prin motor ul său, oferă suport Ajax, care nu suferă din cauza diferențelor de
browser. Acesta oferă atât o metodă completă, implementată in jQuery ( $.ajax () ), precum și
metode mai simple caracteristice apelurilor Ajax ( $.get(), $.load()).
Cele mai multe apleuri jQuery de tip Ajax nu folosesc XML, ignorând x -ul din Ajax. În
general, comunicarea se realizează cu HTML, transportând date HTML simple sau codate ăn
JSON (Object Notation JavaScript).
JSON (JavaScript Object Notation) este un format standard de text lizi bil care conține
date transmise sub formă de obiect compus din perechi de forma atribut și valoare. Este unul
dintre cele mai comune formate de date utilizate pentru comunicarea asincronă între browser și
server prin apelurile de tip Ajax.
Douglas Crockfor d a specificat inițial formatul JSON. Acesta este definit de două
standarde concurente, RFC și ECMA. Standardul ECMA descrie doar sintaxa permisă, în timp ce
RFC prevede și o serie de considerații semantice și de securitate.
JSON este un format de date ind ependent de orice limbaj. Acesta derivă din JavaScript,
dar recent, abilitatea de a genera și analiza date în format JSON este disponibilă în mai multe
limbaje de programare, extensia fișierelor de tip JSON fiind json.
În concluzie, Ajax nu este o singură tehnologie, ci mai bine zis un grup de tehnologii. Mai
precis, combinația HTML si CSS poate fi folosită pentru marcaje și informații de stil. Arborele
documentului este accesat cu JavaScript pentru a afișajul dinamic și interactiv. Iar JavaScript și
obiect ul XMLHttpRequest creeaza o metodă asincronă de schimb de date între browser și server
cu scopul de a evita încărcări complete de pagini.

29
2.3.4. Chart.js
Chart.js este o bibliotecă JavaScript utilizată în crearea graficelor animate și interactive
pentru a fi incluse în paginile web. Aceasta utilizează elementul canvas din HTML5 și este
adaptiv dimensiunii ecranului dispozitivului. În general, folosirea librăriei Chart.js nu este
problematică în browserele care implementează HTML5, deoarecere această librări e funcționează
doar în contextul elementului canvas. La fel ca marea majoritate a bibliotecilor JavaScript, este
gratuită și sub licență MIT.
Biblioteca oferă mai multe tipuri de grafice, pr ecum grafice linie, cu bare, de tip radar,
plăcintă și gogoașă. Pe lângă opțiunile pe care le oferă standard, permite dezvoltatorilor să
extindă aceste tipuri de grafice și să scrie altele noi în funcție de nevoile lor.
Fiind vorba despre o librărie JavaSc ript, pentru a fi utilizată, trebuie inclusă în partea de
header a paginii web. Între taguri speciale de scripturi, obiectul de tip grafice va aparține clasei
Chart și va fi vizibil în pagină după atașarea lui unui element canvas prin identificator. În par tea
de definire a graficului vor fi iterate datele de intrare, de obicei transmise printr -un JSON. Astfel,
odată cu încărcarea paginii, graficul va fi încărcat si diponibil vizualizării. Cu ajutorul bibliotecii
Chart.js se pot face tot felul de grafice, av ând culori și comportament diferite în funcție de
definiția pe care o scrie dezvoltatorul.
2.4. Servere web
2.4.1. Prezentare și istoric
O definiție foarte simplă și potrivită chiar și vremurilor mai îndepărtate este că un server
web este un calculator car e ruleaza site -uri web și care are capacitatea de a primi și de a răspunde
cererilor de tip HTML venite din partea clienților printr -o conexiune HTTP (HyperText Transfer
Protocol). Vremurile de acum, însă au adăugat noi posibilități, serverul răspunzând at ât prin
conținut, cât și prin servicii.
Pe lângă tipuri de server folosite strict pe partea de Internat, există și servere web folosite
doar în cadrul unei rețele locale. Astfel de servere se găsesc în sistemele inteligente pentru case
având ca scop monito rizarea casei sau chiar în dispozitive care pot fi partajate prin intermediul
rețelei locale, cum ar fi imprimantele. Acestea nu mai necesită programe adiționale specifice pe
partea clientului, deoarece ele se ocuapă de culegerea datelor și transmiterea lo r.
Mai mult decât atât, un server web poate fi de două feluri: static sau dinamic.

30
 Un server web static constă într -un calculator cu HTTP instalat care doar trimite fișierele
interpretate. În principal, este utilizat în cazul paginilor simple (HTML, CSS , JavaScript)
limitând destul de mult posibilitățile utlizatorului de a avea interacțiuni mai speciale.
 Un server web dinamic înglobează toate capacitățile unui server static având în plus un
interpretor PHP, o baza de date sau altele. Denumirea de server dinamic derivă din faptul
că pe masura ce utilizatorii trimit diverse cerințe către site, server -ul web actualizează
informația înainte de a o trimite sub formă de răspuns către browser.
Odată cu dezvoltarea HTML, începând din 1990, Tim Berners -Lee a luc rat la două mari
proiecte: scrierea unui client destinat World Wide Web (utilizând pentru prima dată și termenul
de browser) și primul server web, numit ulterior CERN HTTPD implementat în C, care a rulat pe
un calculator NeXT sub sistemul lor de operare Ne XTStep. Mai târziu, între anii 1991 și 1994,
datorită simplitătii și eficacitătii tehnologiilor existente când venea vorba despre navigare pe
World Wide Web (WWW) și partajare de date și fișiere, mutarea serverului și pe alte platfome a
devenit mai accesib ilă. Ușor acesta a fost răspândit în lumea organizațiilor științifice, a
universităților și chiar în rândul industriilor. Anul 1994, a fost anul în care creatorul HTML, Tim
Berners -Lee, s -a hotărât să constituie World Wide Web Consortium (W3C) care avea ca singur
scop standardizarea dezvoltării a tot ceea ce ține de lumea web, de la HTML la servere.
În prezent, cele mai folosite servere web sunt [23]:
 Apache 2.0 și nginx (PHP)
 TomCat (Java)
 IIS (.NET).
2.4.2. Protocolul HTTP
HTTP sau HyperText Transfer Prot ocol este protocolul standard utilizat pentru transferul
de date între partea de client și partea de server.
Protocolul face parte din clasa protocoalelor simple de cerere -răspuns executate de obicei
prin TCP (Protocol de Control al Transmisiei, eng: Tran sfer Control Protocol – pentru a primi
confirmarea transmiterii datelor). Sunt specificate mesajele trimise de clienti serverului, respectiv
ce răspunsuri primesc înapoi. Așa cum toate tehnologiile ce țin de Internet sunt într -o continuă
evoluție, se poate spune și despre protocoul HTTP că evoluează. Dacă în mod tradițional HTTP
era un protocol al nivelului aplicație datorită TCP, în prezent a devenit o punte de comunicare
între procesele diferitor rețele și sisteme. Atfel, comunicarea poate avea loc la niv el de aplicație –
server cum se întâmplă în cazul antivirusului care comunică serverului cerința de a descărca

31
actualizări. Iar aplicațiile în acest sens nu se opresc aici considerând capabilitățile tehnologiilor
din ziua de astăzi și nici dezvoltarea HTTP.
Inițial un server permitea o singură conexiune HTTP căreia îi trimitea răspunsul, închidea
conexiunea și abia apoi relua acest proces pentru următoarele cereri. Ulterior odată cu apariția
TCP, conexiunea rămânea deschisă până când își primea răspunsul chia r și ultima cerere din
coadă.
Protocolul permite interacțiunea prin mai multe metode disponibile dintre care doar
primele trei sunt folosite uzual în web:
 GET: cere serverului să trimită pagina spre a fi citită
 HEAD: este o metodă GET care cere serverului doar headerul paginii
 POST: este utilizată cu precădere în cazul trimiterii formularelor, încărcând date pe server
și trimițând un status al operației (reușit sau nu)
 PUT: scrie o pagină pe server, dacă are drepturile suficiente
 DELETE: șterge o pagină de pe server, dacă are drepturi
 TRACE: este folosită în general pentru depanarea problemelor cererii
 CONNECT: permite conectarea la server folosind intermediari
 OPTIONS: permite clientului să întrebe serverul de header și metodele unei pagini
Toate cererile primesc un răspuns. Răspunsurile au o codificare specifică astfel încât să fie clar
oricui und e a intervenit o problemă [ 2]:

Codificare Descriere Exemple
1xx Informație 100 = serverul a preluat cererea
2xx Succes 200 = cererea a avut succes; 204 = nu exi stă conținut
3xx Redirectare 301 = pagină mutată; 304 = pagina din cache încă validă
4xx Eroare client 403 = pagină restricționată; 404 = pagină negăsită
5xx Eroare server 500 = eroare internă de server; 503 = încercați mai târziu

32
2.4.3. Serverul Apac he
Apache este un server web HTTP, disponibil marii majorități a sistemelor de operare
cunoscute, cu un rol foarte important în tot ceea ce ține de progresul programarii web. Apache a
fost și încă este folosit în majoritatea proiectelor dezvoltate în mediu l web.
În jurul anului 1992, în cadrul NCSA (The National Center for Supercomputing
Activities) a fost demarat un nou proiect pentru crearea unui browser atractiv din punct de vedere
grafic, numit Mosaic, care în scurt timp a ajuns cel mai popular browse r. Parte din proiectul
respectiv a însemnat și scrierea unui nou server sub tutela lui Rob McCool, numit NCSA HTTPd,
care introducea CGI (Common Gateway Interface) permițând asftel creerea site -urilor dinamice.
Dar odată cu plecarea lui Rob McCool din NCSA , în anul 1994, serverul nu a mai avut parte de
aceeși dezvoltare. În acea perioadă are loc înființarea organizației Apache care încep să lucreze la
continuarea proiectului lui Rob. După o ultimă versiune publicată în anul 1995 de către NCSA,
aceștia au în cetat dezvoltarea. Datorită faptului că marea majoritate a site -urilor funcționau pe
NCSA HTTPd, a avut loc o trecere instantă la noul server Apache care era promițător și avea
același cod la bază. Din anul 1995 până în prezent, Apache este pe primul loc d intre toate
serverele utilizate
Astfel Apache a luat naștere pentru a fortifica versiunile de NCSA HTTPd păstrând
funcționale toate patch -urile publicate și pentru a le îmbunătăți. Inițial grupul Apache a fost
format doa din opt membri. În jurul numelui se găsesc mai multe legende. Oficial, numele a fost
ales în onoarea tribului de americani nativi, Apache. Dar în vremea respectivă se vehicula că
numele ar veni de la faptul ca este un server creat din bucăți puse împreuna (eng: „A PAtCHy”
server). Mai târzi u ia naștere și Fundația Apache (eng: Apache Software Foundation – ASF), din
motive legale, dar și pentru a putea avea obiective stabilite legat de tot ceea ce ține de Apache.
Două dintre cele mai importante inovații aduse de echipa de dezvoltare de la Apa che au
fost găzduirea virtuală (virtual hosting), care practic constă în posibilitatea de a avea mai multe
site-uri rulând simultan pe același server și ideea de „server -side includes” care permite
interpretarea unor scripturi pe partea de server, utiliza t vast în cazul limbajelor web.
Serverul Apache este oferit gratuit și open -source, ceea ce înseamnă că este și extensibil.
Motivul pentru care este atât de popular este că pe lânga performanțele pe care le oferă, permite
dezvoltatorilor să îl modeleze aș a cum vor ei. Serverul se pretează site -urilor de diferite
dimensiunile și tipuri. De la rularea unei singure pagini personale până la site -uri mari care
primesc vizite în rândul milioanelor în mod regulate. Permite utilizarea cu scopul de a trimite

33
simple fișiere sau cu scopuri mai complexe, precum o aplicație care generează răspunsuri
personalizate în cazul fiecărui vizitator. Apache devine o soluție pentru orice situație care implică
protocolul HTTP.
2.5. PHP
2.5.1. Prezentare și istoric
Limbajul PHP (Hy pertext Preprocessor, care este de fapt un acronim recursiv) este un
limbaj de scripting gratuit și open -source utilizat pe scară largă destinat dezvoltării de aplicații
web și oferind posibilitatea de a fi integrat în codul HTML al paginii.
Capabilitățile limbajului îl fac un limbaj plăcut dezvoltatorilor web datorită naturaleții cu
care este implementat. Spre deosebire de alte limbaje utilizate în web, unde paginile HTML
trebuie codate în nativ, PHP permite simple inserții în codul HTML pentru o mai simpl ă
manipulare a datelor. Codul inserat în HTML este închis între taguri specifice PHP (<?php ?>),
taguri între care orice cod PHP este valid și utilizabil.
PHP este în primul rând un limbaj utilizat pe partea de server. Acesta genereaza
conținutul HTML pe care ulterior îl trimite spre client, colecteaza date din formulare pe care le
introduce în baza de date sau analizează și utilizează prăjiturelele (cookies). Astfel, procesele
executate în spatele paginii afișate nu vor fi niciodată accesibile din partea clientului, oferind un
plus de securitate aplicației. Fiind un limbaj de scripting, utilizarea sa nu se rezumă doar la web.
Cele trei mari categorii de produse în care poate fi utilizat PHP sunt:
 În primul rând, practic scopul pentru care a fost creat, scr ipting în domeniul web pe partea
serverului. Pentru a fi complet funcțional, sunt necesare trei componente: analizatorul
PHP, server web, în general utilizat este serverul Apache și un browser. Astfel, chiar și pe
propriul calculator se poate obține un med iu complet funcțional web. Serverul Apache va
rula constant în fundal, iar browserul va fi folosit pentru a vizualiza paginile trimise către
client.
 altă utilizare este în linia de comandă. Dacă din ecuația anterioară scoate compomenta de
server, scriptul PHP va rula în continuare. În general, în acest mod se utilizează scripturile
recurente după un anumit program, sau cronuri pentru Linux și task scheduler pentru
Windows sau pentru crearea unor analizatoare lexicale.

34
 A treia utilizare, destul de putin folo sită este creare aplicațiilor desktop. Pentru aceasta
există extensii speciale care necesită o cunoaștere amănunțită a limbajului, însă este
fezabil.
În prezent, trendul dictează din ce în ce mai mult folosirea cadrelor de lucru pentru
realizarea proiectel or mai eficient, bine structurat și curat din punct de vedere al fișierelor și al
codului. Sub acest aspect PHP are o gama destul de variată de oferit, marea majoritate fiind cadre
de lucru care respectă modelul MVC (Model -Prezentare -Control, eng: Model -View-Controller).
Printre cele mai populare la momentul actual se numără Laravel, Symfony, CodeIgniter.
Limbajul PHP din ziua de astăzi este succesorul unui produs anterior cunoscut drept
PHP/FI (Personal Home Page/Forms Interpreter). Dezvoltat în anul 1994 de către Rasmus
Lerdorf, prima versiune de PHP a fost doar un set de fișiere de Common Gateway Interface
(CGI) scrise în binar în limbajul C. Pentru Rasmus Lerdorf, principala utilizarea a PHP era de a –
și vizualiza numărul de vizite pe CV -ul lui de pe web, motiv pentru care inițial a primit
denumirea de Personal Home Page Tools, cunoscut pe scurt ca Tools PHP. Însă, Rasmus a dorit
să dezvolte mai mult limbajul, motiv pentru care l -a rescris complet. Noua versiune de PHP
permitea lucrul cu bazele de date și astfel oferea dezvoltatorilor opțiunea de a crea aplicații web
dinamice. Lansarea PHP către publicul larg a avut loc în anul 1995, moment în care orice
dezvoltator putea participa la dezvoltare. La scurt timp dupa lansare, i -a fost schimbat numele
doar în FI (Interpretor de Formulare, eng: Forms Interpreter).
În versiunea FI se regăsesc multe din funcționalitățile pe care PHP le oferă în ziua de
astăzi. Atunci variabilele urmăreau modelul Perl, limbajul recunoștea în mod automat variabilele
folosite în form ulare și inlcudea sintaxa HTML. Întreg limbajul urmărea linia limbajului Perl,
însă mult simplificat. Deși era loc de îmbunătățire, în scurt timp FI a fost apreciat ca instrument
CGI, dar încă nu reușise sa ajungă să fie apreciat ca limbaj. La sfărsitul ac eluiași an, Rasmus
Lerdorf a lansat o nouă versiune a limbajului, rescris aproape complet, sub denumirea de PHP
(Personal Home Page Construction Kit). Această versiune a fost acceptată cu ușurință de către
programatori deoarece devenise un limbaj de script ing adevărat, iar arhitectura sa aducea mult cu
C. Totodată, după succesul de pe sistemele de operare UNIX, a început dezvoltarea limbajului și
pe sistemul de operare Windows.
Anul 1996 a adus o nouă versiune de PHP, sub numele de PHP/FI sau PHP/FI 2.0. Lu crul
cu bazele de date a fost mult facilitat și a fost introdusă posibilitatea dezvoltatorilor să își scrie
propriile funcții. Acesta a fost momentul în care limbajul a fost acceptat ca limbaj de programare.

35
Un an mai târziu, motorul de parsare era total r escris, odată cu ieșirea limbajului din faza beta.
Anii următori i -au adus o creștere în popularitate, însă limbajul progresa din ce în ce mai puțin
pentru că deși contribuiau mai mulți, doar unul, Rasmus Lerdorf, avea cea mai mare implicare.
În continuar e, PHP 3.0 este versiunea cea mai asemănătoare prezentului. Atunci Rasmus Lerdorf
împreună cu Andi Gutmans și Zeev Suraski au început rescrierea completă a limbajului pentru a -i
adăuga funcționalități care începeau să fie cerințe obligatorii. Limbajul era diferit, astfel și
numele a fost complet diferit. A rămas PHP, dar acum acronimul venea de la Hypertext
Preprocessor și era un acronim recursiv stânga. Această versiune s -a bucurat de succes pentru că
includea lucrul cu bazele de date, protocoale, API -uri, introducea programarea orientată pe
obiecte și posibilitatea dezvoltatorilor de a extinde limbajul.
La versiunea PHP 4.0 lansată în anul 2000, dezvoltarea a început încă din anul 1998.
Această versiune a optimizat nucleul anterior și a pregătit motorul s ă poată suporta cerințe mult
mai complexe posibile datorită funcționalităților din versiunea anterioară. Noul nucleu s -a numit
motorul Zend (provenit din numele celor doi dezvoltatori Zeev și Andi). Printre funcționalitățile
noi, s -a numărat și suportul ad ăugat pentru sesiunile HTTP și o perfomanță superioară versiunii
anterioare.
Următoarea versiune care a adus schimbări majore a fost PHP 5.0 în anul 2004. Motorul a
fost în continuare păstrat și adus la versiunea 2.0. Începând de la această versiune, echip a de
dezvoltatori a crescut cu mult, motic pentru care limbajul este continuu ținut în dezvoltări,
adăugandu -se constant noi funcționalități.
PHP 6.0 a fost mai mult un pas intermediar între versiuni care a adus ceea ce era
important în atenția dezvoltato rilor. Inițial această versiune trebuia să ofere suport caracterelor
Unicode prin adăugarea librăriei Iternational Components for Unicode (Componentele
Internaționale pentru Unicode – ICU). Însă o schimbare de așa amploare implica rescrierea
completă a nuc leului limbajului. Planul era ca odată cu această regândire a codului să fie
introduse și alte noi funcționalități. Însă din cauza lipsei dezvoltatorilor care să înțeleagă ideea
proiectului și să se implice, proiectul a fost prea mult prelungit, încât apăr use PHP 5.3, iar în
privința Unicode nu se rezolvase nimic. Astfel, întreaga ideea a fost abandonată și proiectul
închis.
Versiunea următoare și cea curentă de PHP este 7. Din cauza saltului peste versiunea 6.0,
au apărut ambiguități în cărți legate de ace astă denumire. Numită intern PHPng (PHP următoarea
generație, eng: PHP next generation), această versiune și -a propus să rescrie, cu scopul de a

36
optimiza, întreg motorul Zend, dar fără a pierde nimic din compatibilitatea pe care o oferea la
momentul curent . Astfel a apărut motorul Zend 3, care a fost o împrospătare completă a vechiului
motor, sporind performanța unora dintre site -uri cu aproape 100%. Pe lângă noul motor, PHP 7.0
a inclus multe modificări și dezvoltări.
Odată cu creșterea în popularitate și în număr, în cadrul dezvoltatorilor care lucrează
pentru proiectul PHP, există o regulă de a face în fiecare lună cel puțin o funcționalitate nouă
utilă dezvoltării, lucru încurajator pentru viitorul limbajului. Cert este ca PHP este un limbaj de
succes fi ind utilizat vast în aplicațiile web.
2.5.2. MCV – Model -View -Controller, CodeIgniter
Odată cu progresul tehnologic al mediului web, a crescut cererea și nevoia modularizării
sistemului de dezvoltare a aplicațiilor web. Iar din partea utilizatorilor, se si mțea nevoia unor
interfețe mai prietenoase. Astfel, deși conceputul apăruse cum mult timp în urmă, destul de târziu
a fost complet conturat. Astăzi, MVC (Model -View -Controller) (figura 2.1 [ 35]) reprezintă o
întreagă arhitectură destinată facilitării dezvol tării aplicațiilor web și creării interfețelor
îndependent de logică, întâlnită în ingineria programelor. După cum îi spune și numele, MVC
presupune separarea celor trei mai compomente care alcătuiesc o aplicație:
 Model: cuprinde tot ceea ce ține de model area datelor, de la extragerea lor din diverse
surse până la prelucrarea lor în urmărirea unei anumite logici. Izolarea aceste componente
de restul aplicației este importantă în cazul în care apar modificări la nivel structural al
datelor sau oranizațional . Astfel, se poate evita schimbarea întregii aplicații, printr -o
simplă modificare a modelului.
 View: poate fi înțeles prin tot ceea ce ține de prezentare, de partea grafică a aplicației.
Aceasta este legată de celelalte două componente printr -o relație de comunicare directă,
scopul ei fiind de a primi datele din model și oranizarea din controller pentru a le afișa
utilizatorului. Izolarea acestei componente a venit din nevoia de a separa interfața de
aplicație pentru a fi cât mai ușor de modificat sau impl ementat noi opțiuni.
 Controller: poate fi văzut ca fiind panoul central de control. De aici vin directivele atât
către model cât și către view după preluarea lor de la utilizator. Acesta este cel care ține
toate componentele actualizate: dacă în model apar schimbări, controllerul cere
actualizarea datelor și trimiterea lor corectă către view, la fel și dacă e necesără încărcarea
unor noi date în view, controllerul preia această comandă și o trimite modelului pentru a fi
executată. De aici rezultă și necesit atea de a fi o componentă separată.

37
Mediul MVC este un mediu rotund deoarece exită o fluidi tate continuă între componente.

Figura 2.1

În cazul oricărei acțiuni din partea dezvoltatorului sau al utilizatorului, componentele
comunică între ele și produc rezultatul dorit.
Anterior am prezentat un cadrul de lucru frontend, Bootsrap. Cadrele de lucru nu se
rezumă doar la anumite componente. Marea majoritate dintre cele de pe piață din prezent sunt
adresate toturor componentelor, fiind bazate pe arhite ctura MVC. În ciuda capabilității lor, atenția
publicului larg asupra lor a fost inspirată de apariția Ruby on Rails (cadru de lucru MVC pentru
limbajul Ruby). PHP este un limbaj în jurul căruia s -au dezvoltat multe astfel de cadre de lucru,
însă în contin uare lucrarea va prezenta unul dintre ele: CodeIgniter.
CodeIgniter este un cadru de lucru creat pe baza oferită de arhitectura MVC, utilizat în
scrierea de aplicații web în PHP. Scopul sau, din punct de vedere al definirii drept cadru de lucru,
este de a putea facilita dezvoltarea unei aplicații prin uneltele pe care le pune dezvoltatorului la
dispoziție: de la o foarte bună organizare a fișierelor din punct de vedere logic (poate fi catalogat
drep MVC ierarhic deoarece fiecare componentă are propriul dire ctor în care se află toate
fișierele sale, pentru un grad ridicat de lizibilitate), până la variate biblioteci cu funții ajutătoare
(pentru formulare, pentru validări simple dar și complexe împotriva exploatării și multe altele).
Lansat în anul 2006, sub t utela EllisLab, cadrul de lucru s -a bucurat de aprecieri și o
creștere rapidă a popularității. Este un produs oferit și menținut gratuit, sub licentă MIT adresat
utilizării în mediul web cu PHP pe absolut orice platforma sau sistem de operare.

38
Principala trăsătură a sa pentu care a fost și încă este lăudat este rapiditatea pe care o oferă
comparativ cu alte cadre de lucru vast apreciate. Pe lângă numeroasele aprecieri ale
dezvoltatorilor, în anul 2008, la frOSCon (Free and Open Source Software Conference – o
conferință anuală ținută pentru discuția diverselor subiecte din lumea programării și a produselor
open -source), părintele limbajului PHP, Rasmus Lerdorf și -a exprimat sentimentele de apreciere
față de CodeIgniter. Dintre toate cadrele de lucru de la vr emea respectivă, i -a plăcut cel mai mult
deoarece este mai rapid, mai ușor și aduce cel mai puțin cu un cadru de lucru („because it is
faster, lighter an d the least like a framework” [6 8] ).
CodeIgniter este ușor de instalat și ajută foarte mult dezolvatori i în configurare, deoarece
este flexibil și foarte bine structurat. Pentru a avea un mediu complet funcțional, o aplicație web
necesită un server pe care să poată rula, o baza de date la care să se poată conecta și un browser
în care să se poată vizualiza. Cadrul de lucru oferă suficiente biblioteci pentru a face lucrul cu
baze de date, formulare și multe alte mai accesibil și poate fi extins prin adăugarea unor librării
noi. Un alt avantaj al utilizării acetui cadru de lucru este lipsa nevoii unei sintaxe specifice în
funcție de componenta în care se lucrează, de exemplu în view se pot folosi clasicele taguri PHP
fără a fi nevoie de un motor separat de interpretare a unor reguli diferite.
Funționalitatea la un nivel foarte abstractizat al CodeIgniter este descrisă în u rmătoarea
diagramă [ 65]:

După ce sunt preluate instrucțiunile cererii, ruterul decide dacă cerea poate fi executată
prin reîncărcarea unei pagini anterior încarcate (caching) sau dacă trebuie să trimită mai departe
spre controller. În primul caz, pagina este afișată rapid, din memorie fără a fi necesară
reprocesarea datelor. În al doilea caz, înainte de a ajunge în controller, datele trimise prin HTTP

39
trec printr -un sistem de securitate, iar apoi sunt procesate în mod normal. După ultimul pas de
logică datele ajung în view în fața utilizatorului și sunt salvate în chache pentru viitoare acțiuni.
2.5.3. FPDF
În cazul lucrului cu date sau cu rapoarte, foarte util într -o aplicție web este sa existe o
metodă prin care acestea pot fi obținute în cla r, formatate corespunzător și cât mai actuale. În
ajutorul acestei nevoie, au apărut diverse biblioteci care permit formatarea datelor extrase din
baza de date și aranjarea lor corectă într -un document. Una dintre aceste bilbioteci este FPDF.
FPDF (Free P DF) este o bibliotecă scrisă în PHP, care nu presupune nicio altă dependință,
utilizată pentru crearea de documente PDF. Permite dezvoltatorului sau utilizatorului, în funcție
de aplicație, să aleagă metrici, formate ale paginii și ale tabelelor generate, fontul și culorile
textului sau să afișeze imagini. Mai mult decât atât, librăria oferă suport pentru caractere
aparținând mai multor limbi, pe lângă caractere standard. Odată cu includerea librariei, aplicația
poate genera documente PDF.
Deși există mu lte opțiuni pentru generarea documentelor PDF, nu doar în PHP, ci și în
JavaScript, este important de ținut minte motivul și așteptările dezvoltatorului de la o astfel de
unealtă. În general, FPDF este ales pentru că are o licență permisivă, este gratuit ș i datorită
scrierii librăriei în cod nativ PHP oferă o performanță superioară față de alte produse.
2.6. MySQL
2.6.1. Prezentare și istoric
De la simple pagini HTML care odată reprezentau universul web, timpul a dictat mari
schimbări în paradigma de progra mare. Aplicațiile web au început ușor să ia amploare prin
adăugarea de funcționalități. Însă odată cu noile funcționalități s -a mărit brusc și volumul de date
procesate și păstrate. Astfel, s -a dezvoltat nevoia utilizării bazelor de date în aplicațiile web .
În primul rând, o bază de date este o colecție de date structurate și stocate într -un sistem.
Iar nevoia unei baze de date a apărut în momentul în care datele de procesat erau prea multe
pentru a fi stocate în format fișier și parsate de fiecare dată pe ntru căutare, inserție sau ștergere.
Pe lângă acest fapt, manipularea datelor era foarte costisitoare din punct de vedere al timpului
într-un asemenea caz. Bazele de date au dat soluția acestei probleme, fiind create pentru a
optimiza orice operațiune apli cată datelor, de la inserție până la manipularea unei singure

40
înregistrări. Mai mult decât atât, structura oferită de bazele de date relaționale ale lui E. F. Codd
au făcut mai clară reprezentarea datelor.
Bazele de date relaționale se bazează pe modelul relațional înspirat din algebra mulțimilor
și logica predicatelor, împărțind datele în tabele sau mulțimi cu relații declarate între ele ce
permit accesarea mai simplă și rapidă. Modelul definește logica de la nivelul bazei de date până
la nivel de coloană și permite relații de cardinalitate între tabele și constrângeri aplicate tabelelor.
Însă o bază de date fără putere de o administra nu însemna nimic. Astfel, au apărut programe prin
care putea fi specificată atât structura cât și comportamentul unei baze de date numită sistem de
gestionare a bazelor de date (SGBD, eng: DBMS – Database Management System).
Pentru interogarea unei baze de date a apărut limbajul SQL (Structured Query Language).
SQL a luat naștere în anul 1974 în cadrul IBM, sub tutela Donald Chamberlin și Raymond Boyce
și purtând numele de SEQUEL, funcționarea sa fiind limitată doar bazelor de date IBM. Câțiva
ani mai târziu, actuala companie Oracle, în vremea aceea Relational Software, a pus la un loc
ideile IBM cu teoria lui Codd și a creat astfel un nou limbaj, SQL. În anul 1986 a fost pentru
prima dată standardizat și de atunci a suferit mai multe modificări.
Printre primele baze de date se găsea mSQL (mini SQL) apărută în jurul anului 1994.
Practic, mSQL a fost concepută de către David Hughes ca o interfață a Postgres, un sistem de
gestionare a bazelor de date care nu putea fi interogat folosind SQL, cu scopul de a reduce
costurile deoarece vremea respectivă nu avea de oferit implementări SQL ieftine. Cu timpul
mSQL a fost în continuare dezvoltat până a devenit un SBGD însă puțin limitat. Totuși, în anii
aplicațiilor dinamice a fost un pion important deoarece multe aplicații îl aveau la bază. Până la
finalul anului 1999, mSQL scăzuse mult, fiind înlocuit de succesorul său MySQL. În preze nt,
încă mai există pe piață oferind suport pentru mai multe limbaje, dar nu este foarte utilizat.
MySQL (My Structured Query Language) a pornit de la baza oferită de mSQL. Ideea
inițială a fost de a crea un SBGD utilizând mSQL, și un nouă metodă numită I SAM (Indexed
Sequential Access Method) folosită pentru indexarea și accesarea datelor rapid. Dar,
perfomanțele nu au fost pe măsura așteptărilor, ceea ce a cerut o nouă interfață SQL păstrând
anumite caracteristici ale mSQL. Scopul a fost de a oferi utiliz atorilor o trecere ușoară între
mSQL și MySQL, o mișcare de marketing care a dat rezultate. MySQL a fost creat de către două
persoane: Monty Widenius, după a cărui fiica a fost și denumit, împreună cu partenerul său
David Axmark. Interfața a fost scrisă î n limbajele de programare C/C++, iar parserul lexical este

41
o versiune a parselui yacc. Astăzi MySQL este disponibil pe apoape toate sistemele de operare și
pe mașinile virtuale.
Oferta Oracle inlude versiunea open -source (MySQL Community Server) sau versiu nea
cu bani (Enterprise Server), deși ambele sunt bazate pe același cod. Fiind sub tutela Oracle,
MySQL a fost continuu menținut și dezvoltat până la versiunea curentă de 5.7. MySQL oferă un
nivel înalt de securitate a datelor, implementând politică de par ole și expirare a lor pentru fiecare
utilizator, o putere mai mare administratorilor asupra utilizatorilor și conexiuni securizate. Din
punct de vedere al motorului de stocare, MySQL utilizează în principal InnoDB recunoscut
pentru performanța sa, însă ofe ră mai multe posibilități dezvoltatorilor: MyISAM, MEMORY,
CSV și multe altele. Pe lângă performanțe foarte bune, MySQL oferă dezvoltatorilor posibilitatea
de scalare, un aspect important în ziua de astăzi. Un alt plus este partea administrativă care
neces ită foarte puțin timp din partea dezvoltatorilor, MySQL având un sistem bine pus la punct
de vedere al configurării și disponibilității.
Este utilizat cu precădere împreună cu limbajul PHP și serverul Apache, existând chiar un
acronim în acest sens LAMP ca re prescurteaza sisteme utilizate cel mai des împreună în cazul
aplicațiilor web dezvoltate cu MySQL: Linux, Apache, MySQL, PHP/Perl/Python. Popularitatea
lui vine și din faptul că este oferit gratuit de către actualul deținător, Oracle.
În cadrul pieței, MySQL este bine cotat de către utilizatori, fiind răspandit în lumea
aplicațiilor web și foarte apreciat de către cei care au lucrat cu el. Logoul reprezentativ al MySQL
este un delfin numit, chiar de către dezvoltatorii care îl utilizează, Sakila.

2.6.2. MySQL și PHP
Utilizarea MySQL împreună cu un limbaj utilizat cu precădere în universul web introduc
un nou concept, acela de baza de date web. Cu ceva timp în urmă, când datele erau mai puțin
salvate și volumul lor era uneori neglijabil, aplicațiile web iși permiteau să ignore o componentă
de stocare a datelor. În acel moment, aplicația era disputată de două mari componente: server și
browser, unde browserul trimitea o cerere, serverul procesa cererea și trimitea răspuns înapoi
browserului, reprezentat gr afic în figura 2.1 [67].
Ulterior, au apărut din ce în ce mai multe date odată cu introducerea unui server de baze
de date. Cererea va pleca de la browser și va trece prin toate componentele sau nu, va fi procesată
de fiecare în parte, iar primul răspuns va veni din partea MySQL trimis înapo i în pagină pe
același drum până înapoi în browser. Nu toate cererile ajung la MySQL, deoarece pot exista și

42
cereri care nu doresc încărcarea de date extrase din tabelă, ci folosesc cachingul sau deloc date
(figura 2.2 [67]).

Figura 2.1

Figura 2.2

PHP și MySQL au fost întotdeauna o combinație favorită a dezvoltatorilor PHP, după
cum am menționat mai devreme acronimul LAMP. Iar prin PHP, sunt incluse și toate cadrele de
lucru scrise pentru acest limbaj. Unul din tre motivele utilizării celor două este simplitatea
configurării relației dintre ele, altul ar fi extensia nativă din PHP pentru MySQL, MySQLi. Însă
poate cel mai bun motiv este existența unui SBGD scris în PHP pentru manipularea datelor din
MySQL: phpMyAd min.
Creată de către Tobias Ratschiller și preluat de către phpMyAdmin Project, ideea a fost de
a scrie o interfață pentru MySQL în PHP după modelul MySQL Webadmin, începută în anul
1998, numită phpMyAdmin. Ulterior, după preluarea produsului, dezvoltat orii au început să o
utilizeze din ce în ce mai mult și chiar să dezvolte noi funcționalități. phpMyAdmin oferă o
interfață web prietenoasă, administrarea și monitorizarea bazelor de date MySQL și MariaDB și
funcționalități destinate dezvoltatorilor cum ar fi reprezentarea grafică a modelului baze de date.

43
CAPITOLUL 3 – DESCRIERE A APLICAȚIEI
3.1. Motivarea alegerii
Domeniul tehnologic este într -o continuă dezvoltare, atât din punct de vedere tehnologic,
cât și din punct de vedere al resurselor umane. Dac ă până nu demult nevoia unei organizări stricte
în cadrul unei firme nu își făcea simțită prezența, în ultimii ani un control mai bun asupra
activităților desfășurate a devenit imperios.
Ideea aplicației a pornit de la observarea unei nevoi pentru un sist em de organizare a
activităților diferit de ceea ce se găsește pe piață. Mai mult decât atât, un sistem care să poată fi
oferit printr -o singură aplicație compactă.
Mulți se pot regăsi în descrierea activității unei firme care se desfășoară în mod haotic .
Din lipsa unei organizări stricte, există neșansa de a strica o funcționalitate bună sau de a cauza o
relație conflictuală între componente. Mai mult decât atât, destul de des se întâmplă ca din dorința
de a fi la zi cu tehnologia pe care cineva o dezvol tă să dea peste cap un sistem întreg deoarece
versiunea respectivă nu se potrivește. Pentru a evita astfel de întâmplări costisitoare atât în bani
cât și în timp se impun aplicațiile de administrare a serviciilor informatice.
Alegerea acestei aplicații s -a bazat mult pe actualitatea temei. Iar tema va deveni din ce
în ce mai dezbătută luând în considerare faptul că în prezent o firmă poate însemna chiar
continente diferite. În acest caz, utilizarea unei aplicații de gestionare a serviciilor informatice
reprezintă mai mult decât o alegere a firmei, este o necesitate.
3.2. Scopul aplicației
Aplicația SmarTicket își propune să se alinieze restului aplicațiilor care urmăresc structurarea
activităților unei firme. Printre aceste aplicații se numără Jira, SmartC loud Control Desk, Wrike,
HP Service Manager și multe altele. Înclinarea firmelor către una sau alta vine din motive mai
mult subiective cum ar fi costurile sau producători cu care deja colaborează. Scopul aplicației
SmarTicket se conturează în jurul funcț ionalităților specifice domeniului oferite într -o singură
aplicație, spre deosebire de ceea ce are piața de oferit:
 Are o interfață care oferă suficente informații și este ușor de utilizat
 Opțiunile și comenzile sunt clare și necesită doar puțină instruire a utilizatorilor

44
 Separă cele două tipuri de evenimente posibile: incidente (probleme, erori cum ar fi
servere picate, lipsa funcționalității sau funcționalitate greșită și altele) și schimbări (cum
ar fi upgrade -uri, resintalări, recablări și altele)
 Oferă posibilitatea de a urmări dezvoltarea evenimentelor
 Este utilă în urmărirea împlinirii țelurilor personale sau la nivel de departament
 Capacitatea de a împărți evenimentele de tip schimbare în iterații de dimensiuni diferite
stabilite anterior
 Oferă secu ritate prin tipurile de utilizatori
 Colectează date de mai multe tipuri pentru a crea statistici pe fiecare componentă
Astfel, obiectivul principal al SmarTicket este de a eficientiza procesul implementării
noilor funcționalități în cadrul unei firme și d e a structura și evidenția, prin intermediul
statisticilor, incidentele neplanificate ajutând utilizatorii să găsească o soluție constructivă pe
termen lung pentru a evita noi ocurențe.
3.3. Realizarea aplicației
În primul rând aplicația a fost gândită din punctul de vedere al unui utilizator. Pe lângă
întrebarea „Ce vreau de la aceasta aplicație?” pentru care răspunsul este enunțat în scop, aplicația
fiind adresată oamenilor tehnici apare și întrebarea „Cum vreau să dezvolt această aplicație?”.
Prin următo arele argumente, cât și prin descriere aplicației per total se obține răspunsul pentru
această întrebare.
SmarTicket a fost dezvoltat în PHP, utilizând drept cadrul de lucru CodeIgniter. Alegerea
limbajului a fost destul de dificilă, considerând posibilit ățile pe care le au de oferit limbajele de
programare web. Dar dintre toate balanța înclină spre PHP deoarece este un limbaj ajuns cu
siguranță la maturitate, un limbaj nu ușor, dar ușor de înțeles deoarece este fluent și ușor
integrabil, oferă o performan ță foarte bună apreciată de către mai toți dezcvoltatorii și nu în
ultimul rând pentru că oferă invățăceilor o documentație excelentă. Cât despre CodeIgniter,
alegerea a fost făcută urmând aceleași principii pentru alegerea limbajului. Un cadru de lucru
dezvoltat de câțiva ani pentru care dezvoltarea nu mai merge în direcția rezolvării erorilor de bază
ci înspre noi funcționalități, ușor de configurat și de lucrat cu el, bine organizat și oferind o
documentație foarte puternică.
Serverul pe care rulează ap licația este serverul Apache, iar pentru partea de baze de date
în completarea trioului descris de LAMP, MySQL. Ambele alegeri au venit în mod natural odată

45
cu alegerea limbajului de programare. Deși exista loc de artificiu în această alegere, pentru o
aplicație în care disponibilitatea și stabilitatea sunt foarte importante, o rețetă care nu a dat greș
niciodată este rețeta potrivită.
După stabilirea tehnologiilor principale, dezvoltarea SmarTicket a avut loc folosind două
programe distribuite gratuit:
 PhpStorm – IDE (mediu de dezvoltare integrat, eng: Integrated Development
Environment) oferit de JetBrains gratuit studenților. Scopul unui IDE este de a simplifica
procesul de dezvoltare oferind dezvoltatorilor un mediu organizat al tuturor fișierelor,
supo rt pentru cadre de lucru, unelte specifice limbajului de programare și posibilitatea
integrării celorlalte componente în timpul dezvoltării. PhpStorm oferă în plus editarea în
timp real ceea ce face schimbările să fie afișate imediat ce au fost efectuate, fără nevoie de
salvare
 XAMPP – pachet de dezvoltare pentru PHP. Pachetul conține tehnologii și unelte care
sunt puse la dispoziția dezvoltatorilor imediat cea fost instalat. Aplicația a folosit
componenta Apache pentru partea de server, MySQL pentru partea de server și bază de
date și interfața phpMyAdmin pentru administrarea bazei de date.
3.4. Structura aplicației
3.4.1. Structura logică
Aplicația îmbină două mari componente: gestionarea evenimentelor de tip incident sau
schimbare, care este componenta pr incipală a aplicației, și gestionarea iterațiilor. Vorbind despre
un produs adresat atât părții de infrastructură, cât și dezvoltării de programe, iterațiile pot fi
modificate conform standardelor firmei. Fiind adresată utilizării interne, administratorul va fi cel
care se va ocupa constant de cod și de administrarea bazei de date, iar aplicația va avea două
tipuri de utilizatori: utilizatori simpli, angajați ai diferitor departamente și utilizatori șefi de
departamente, rolurile lor fiind puțin diferite.
Pentru prima componentă aplicația a fost gândită să împartă cele două tipuri posibile de
evenimente după logica de manipulare a fiecăruia.
 Evenimentele de tip incident

46
 Au număr unic de indentificare, pot fi create de către oricine și semnalează o
eroare în sistem, o problemă în infrastructură sau o implementare greșită a unei
sarcini.
 Deoarece un incident este un eveniment neprevăzut, acestea nu vor fi incluse în
iterații propriu -zis, ci doar din numărul lor pentru statistici.
 Odată creat, el va fi atribui t unui grup și unei persone din grupu l respectiv spre a fi
rezolvat. Pentru a evita confuziile, persoana căruia i -a fost atribui va primi un
email care va conține identificatorul incidentului, descrierea și o adresă pentru a fi
vizualizat.
 După rezolvare s tarea incidentului va fi modificată de către cel căruia îi aparține în
închis.
 Toate incidentele, indiferent de starea în care se află vor fi disponibile
utilizatorilor pentru vizualizare, filtrare sau realizare d e statistici în funcție de ele.
Pe ramura incidentelor se vor putea accesa statistici privitoare la utilizatorul curent
și la grupul acestuia luând în considerare toate incidentele anului fiscal respectiv.
 Evenimente de tip schimbare
 Au număr unic de identificare în sistem, pot fi create de către orice utilizator și au
rolul de a anunța și valida schimbările din punct de vedere al infrastructurii,
rețelisticii sau programelor .
 Schimbările pot fi de mai multe feluri în funcție de amploarea pe care o au. Astfel,
schimbările foarte mari vor necesita aprobarea din partea șefului de departament
pentru a putea fi implementate în continuare și un timp suficient, înainte de a fi
puse în practică, de comunicare restului utilizatorilor posibil impactați.
 Schimbările vor fi parte principală a iterațiilor con siderându -se doar cele care
încep și se termină în cadrul iterației respective.
 Odată creată, o schimbare va fi atribuită unui grup și unei persoane din grupul
respectiv împreună cu o sarcină de lucru asociată aceleiași persoane sau nu, în
funcție de cine va realiza schimbarea respectivă. Astfel, schimbarea poate veni din
partea unui anga jat, dar implementat de către un altul. În plus, odată atribuită, la
fel ca în cazul incidentelor, un email va fi trimis către persoana respectivă
conținând descrierea, id entificatorul și o adresă la care poate fi accesată. Această
acțiune este valabilă atât pentru schimbări, cât și pentru sarcinile de lucru.

47
 După primirea aprobării, după caz, schimbarea va fi mutată în starea de progres
urmând ca după implementare și veri ficare persoana care a creat -o să o închidă.
 Toate schimbările vor fi utilizate în statisticile personale sau ale grupului și vor
putea fi vizualizate și filtrate, indiferent de stadiul în care se află. Ca în cazul
incidentelor, în cazul statisticilor gene rale vor fi luate în considerare toate
schimbările din anul fiscal curent.
Partea de iterații, după cum apare mai sus va fi specifică schimbărilor. Fiind un mediu de
lucru care combină infrastructura cu programele, lungimea perioadei recomandate va fi de p atru
săptămâni. Astfel, utilizatorii vor putea vizualiza progresul și ceea ce a rămas de făcut în cadrul
iterației respective prin intermediul afișării directe a schimbărilor dar și prin statistici calculate în
funcție de numărul lor, numărul incidentelor și date istorice.
Prin stocarea datelor legate atât de incidente, cât și de schimbări vor putea fi setate
anumiți indici de performanță pentru fiecare angajat. Nu doar numărul lor va însemna ceva, ci și
acțiunile pe care le -au întreprins cu scopul minimiză rii numărului de incidente și eficientizării
sistemului.
Pe lângă aceste două mari componente, aplicația va permite utilizatorilor să:
 Vizualizeze elementele de configurare în detaliu dar și statistici legate de funcționalitatea
lor
 Vizualizeze toți utiliz atorii cu posibilitate de filtrare după departament, șef, nume, grupuri
de care aparțin sau roluri
 Vizualizeze toate activitățile indiferent de tip aflate în diferite stadii de implementare
 Vizualizeze propriul profil în care vor găsi informații despre cum sunt ei stocați în baza de
date.
3.4.2. Arhitectură
Aplicația este dezvoltată folsind cadrul de lucru CodeIgniter. Ca urmare a acestui lucru,
este construită în jurul arhitecturii MVC, dar folosește la fel de bine și componente oferite prin
CodeIgniter.
Astfel, SmarTicket este alcătuit din mai multe fișiere împărțite logic în concordanță cu funcția
pe care o îndeplinesc. Implementarea cadrului de lucru presupune respect area unor reguli care vin
în spr ijinul dezvoltării. Respectând arhitectura MVC, SmarTic ket este alcătuită din

48
 Controller – conține câte un fișier cu extensia php care îndeplinește rolul de controller
pentru fiecare funcționalitate cuprinzând metode pentru fiecare acțiune a utilizatorului :
incident, schimbare, utilizator, metodologie agilă și altele
 Model – conține fisiere PHP cu metode pentru extragerea infomațiilor din baza de date
pentru fiecare controller, relația între controller și model fiind de unu la unu.
 View – conține toate fișierele PHP utilizate în afișarea paginilor. O pagină a a plicației
poate conține mai multe fișiere view , iar în general toate paginile utilizează același fișier
pentru partea de header (începutul paginii) și același fișiere de footer (sfârșitul paginii),
între ele găsindu -se fișierele specifice paginii respectiv e. Astfel, relația view -controller
este de mai multe la unu.
În plus, aplicația utilizează modulele oferite de CodeIgniter pentru validarea intrărilor din
formulare împotri va exploatărilor. Un alt modul CodeIgniter este utilizat pentru validării logării
utilizatorilor, extinzând limbajul PHP, oferindu -i abilitatea de a face apeluri cu conexiune inversă
(callback) pentru validarea intrărilor de la utilizatori cu ceea ce există în baza de date.
În afara fișierelor de tip view, aplicația folosește și alte resu rse precum fișiere de tip
JavaScript, less și min pentru cele de CSS. Acestea sunt grupate sub directoarele pe care le
reprezintă. Pentru CSS sunt fișierele Bootstrap, ală turi de alte fișiere CSS utilizate în aplicație, iar
pentru JavaScript sunt Boostrap. js pentru mici funcționalități oferite de Bootstrap, Chart.js pentru
reprezentarea grafică a statisticilor și alte fișiere JacaScript utilizate în aplicație.
3.4.3. Structura baze i de date
Baza de date utilizată în aplicație este foarte importantă deoarec e în ea sunt păstrate datele
despre utilizatori și toate acțiunile pe care aceștia le întreprind.
Poartă același nume cu aplicația, smarticke t. Printre tabelele cele mai importante se
numără:
 Tabela de schimbări: changes
 Tabela de incidente: incidents
 Tabela de utilizatori: employees , care conține datele uzuale despre angajati
 Tabela de sarcini de lucru: tasks
 Tabela de grupuri/departamente: groups , conține toate grupurile (sinonime cu
departamentele) din firmă

49
În tabela de schimbări sunt stocate toate sc himbările împreună cu toate codurile
referitoare la schimbarea respectivă:
 Descrierea schimbării : scurtă descriere a schimbării
 Descrierea implementării schimbării : pasii principali ai implementării
 Codul tipului schimbării:
 standard – nu necesită timp în plus pentru comunicare utilizator ilor și nici
aprobabrea ș efului ;
 minoră – necesită minim o zi înainte de implementare pentru comunicare, dar nu
necesită aprobarea superiorului ;
 majoră și seminificativă – necesită minim două zile pentru comunicare și
aprob area șefului, diferențele între cele două fiind impactul pe care îl au asupra
firmei
 Codul statutului:
 nou – schimbare nou creată;
 aprob – schimbare care așteap tă să fie aprobată de către șef ;
 progr – schimbare ca re se află în curs de realizare ;
 cmplt – schimbare finalizată și inchisă
 Comentarii de încheiere: scurtă descriere a ceea ce s -a schimbat și rezultate
 Codul riscului:
 niciun risc – e o schimbare stand ard care nu implică niciun risc ;
 scăzut – deși e o schimbare mică implementarea implică un grad red us de risc ;
 mediu – este o schimbare de propoții medii care poate implica mai multe elemente
de configurare sau persoane, riscul va fi inclus în comunicarea către utilizato ri de
către persoanele adecvate ;
 ridicat – este o schimbare mare, la grad poate chia r experimental ce necesita
atenție sporită sau implica mai mulți oameni sau departamente
 Codul impactului: impactul este în directă legătură cu riscul, un impact mai mare
presupune un risc sporit. Impactul poate fi :
 niciun impact – schimbarea nu va afecta n imic, este un a simplă ;
 mai mul ți utilizatori – există posibilitatea ca implementarea să afecteze mai multe
persoa ne;
 departament – schimbarea este p osibil să afecte un departament ;

50
 întreaga firmă – este o schimbare de proporții mari a cărei implementări poate
afecta toată firma .
 Motiv : scurtă descriere a motivului schimbării
 Codul urgenței de implementare :
 normal – acceptă perioada normală de aș teptare înaintea implementării ;
 break -fix – o soluție rapidă pentru a rezolva o problemă gr avă din producție,
ignoră orice perioadă de aștep tare fiind implementată imediat ;
 întărziat – este o schimbare implementată cu întârziere, dar care respectă
perioadele impuse de tipul schimbării
 Marcator pentru aprobarea șefului: populat cu Y dacă s -a obți nut aprobarea șefului și N
este valoarea implicită la creere pentru marcând lipsa aprobării
 Codul a ngajatul ui căruia i -a fost atribuită sarcina de lucru
 Marcator de testare efectuată : populat cu Y dacă schimbarea implementată a permis
testarea, N implici t
 Codul g rupul ui de care aparține angajatul care creează schimbarea
 Codul an gajatul ui care creează schimbarea
 Superiorul angajatului care creează schimbarea
 Data creării schimbării : este data luată din sistem și introdusă odată cu inserția în baza de
date
 Data de începere a implementării : data care este specificată de cel care creează
schimbarea pentru când să înceapă dezvoltarea, respectând limitele impus de tipul
schimbării
 Data de sfărșit a implementării : data la care se va încheia schimbarea. În funcție de
aploarea ei poate fi de la jumătate de oră până la o zi întreagă de lucru
 Codul e lementul ui de configurare afectat : poate fi o stație desktop sau laptop, un server,
poate face parte din rețea, dezvoltarea aplicației sau altele
 Descriere a riscului impl icat de schimbare: scurtă descriere a ceea ce s -ar putea întâmpla
și metode de a reveni la implementarea anterioară
 Codul celui care a raportat incidentul : câmp populat cu codul celui care este l ogat pe site
în momentul creării schimbării

51
În continuare, f iecărei schimbări îi este atribuită o sarcină de lucru, salvate în tabela
pentru sarcini împreună cu restul detaliilor necesare:
 Ore implementare : orele necesare pentru implementarea schimbării
 Codul grupul căruia i -a fost atribuită sarcina de lucru
 Codul angajatului căruia i -a fost atribuită sarcina
 Descriere a sarcinii de lucru : scurtă descriere clară
 Data creă rii sarcinii de lucru : data sistemului
 Data închiderii: se închide odată cu închiderea schimbării
 Codul celui care l -a raportat: codul celui logat la momentul creării sarcinii de lucru
Similar cu tabela de schimbări, în tabela de incidente sunt stocate incidentele cu toate
datele necesare aferente:
 Soluț ie: scurtă descriere a soluției găsite pentru rezolvarea incidentului
 Codul statutului : spre d eosebire de schimbări, în cazul incidentelor apar doar două
situații. Coduri posibile sunt :
 nou – incident nou creat ;
 cmplt – populat odată cu închiderea incidentului .
 Descriere : scurtă descriere a comportamentului observat și a elementului de configurare
afectat
 Codul impactului : în cazul incidentelor, impactul este izolat de risc, având în vedere că
nu poate fi vorba de risc odată ce o eroare a avut loc. Câmpul pentru impact este destinat
unei observații obiective pentru cât de gravă este eroarea surveni tă. Poate fi vorba despre
mai mulți utilizatori, un întreg departament sau întreaga firmă
 Codul urgenței : este în strânsa legătură cu impactul pe care îl are incidentul. Pe măsură ce
impactul crește, direct proporțional crește și urgența soluționării incid entlui. Dar în
general, incidentele au setată o singură urgență, break -fix, pentru a trece peste perioadele
de implementare
 Codul angajatului căruia îi este atribuit
 Codul grupului de care aparține angajatul căruia i -a fost atribuit
 Superiorul angajatului
 Codul elementului de configurare : la fel ca în cazul schimbărilor, incidentele pot avea loc
pe aceleași elemente, fie că este vorba despre server, stație personală, rețea sau altele
 Data creerii incidentului : data sistemului

52
 Data închiderii incidentului : data la care este soluționat și închis de către cel căruia îi
aparține
 Codul celui care a raportat incidentul : codul angajatului logat la momentul creării
incidentului
Pentru realizarea statisticilor și a interațiilor sunt suficiente informațiile precizate mai sus.
Statisticile sunt create dinamic utilizând informațiile venite din baza de date, iar interațiile sunt
stabilite de date calendaristice.
Astfel, baza de date reprezintă o foarte importantă componentă a aplicației, prin cereri
către ea realizându -se toate operațiunile realizate de utilizatori.
3.5. Utilizarea aplicației
3.5.1 . Tutorial de utilizare
Utilizarea aplicației începe cu un scurt instructa j al utilizatorilor. Acest pas educativ
urmărește uniformizarea descrierilor pe care utilizatorii le tr ec în câmpurile aferente. Deși
schimbarea sau incidentul conțin în formular suficiente detalii, o bună practică este utilizarea
unui șablon când vine vorba de descrieri. De exemplu în cazul unui incident o descriere potrivită
ar fi „SERV001 – Nu permite co nexiunea utilizatorilor”, fiind clar specificat elementul de
configurare, serverul cu denumirea respectivă, și problema întâmpinată. În același mod, o
descriere pentru o schimbare „SERV001 – Instalare FP2” implică instalarea nivelului doi al unui
pachet pe serverul a cărui nume este specificat.
Un alt motiv pentru instructajul angajaților este să le fie explicate relațiile dintre toate
codurile de completat și sensul acestora. De exemplu o schimbare semnificativă nu poate fi
implementată fără a aștepta o p erioadă minimă de comunicare către utilizatori deoarece poate
implica o perioadă în care elementul de configurare sa nu fie accesibil. La fel de bine nu poate fi
vorba de o schimbare cu risc ridicat și niciun impact. Deși multe sunt clare aplicând o logică
simplă, nu toate se încadrează în această logică și au nevoie de explicații pentru a fi corect
implementate de către utilizatori.
Odată ce lucrurile de bază au fost explicate și asimilate, aplicația începe cu pagina de
logare unde fiecare utilizator se lo gheaza cu parola folosită și pentru sistemul de operare de pe
stațiile personale. Fiind vorba despre o aplicație internă, se realizează integrarea sistemelor.

53

După logare, toți utilizatorii vor fi redirecționați către pagina de start a aplicației:

Pagina de start este o interfață prietenoasă oferind multe informații și facilitând navigarea
în aplicație pentru utilizatori. Cele două navigatoare vor fi disponibile în mod constant indeferent
de acțiunea întreprinsă, excepție fiind doar pagina de logare.
Pagina de start sau Panoul de control va afișa în primul rând statutul curent al
utilizatorului logat: numărul de activități de tip schimbare în desfășurare compus din schimbările
deschise și de sarcinile deschise și atribuite utilizatorului logat, numărul de schimbări și sarcini
complete, numărul de incidente în total, deschise sau închise , respectiv numărul de modificări
deschise sau închise ale utilizatorului logat.
În continuare, apar informații grupate logic în felul următor:

54
 Activități în desfășurare: unde vor apărea listate incidentele și schimbările deschise
atribuite utilzatorului logat
 Incidente ale departamentului în desfășurare
 Schimbări ale departamentului în desfășurare
 Sarcini de lucru ale departamentului în desfașurare
Pe lângă aceste informa ții utilizatorii au la dispoziție un panou de comenzi rapide pentru a
crea incidente și schimbări disponibil doar în pagina de start.
Odată ce pagina de start a devenit clară, navigarea în restul aplicației devine mult mai
simplă. Meniul lateral oferă toat e opțiunile posibile din aplicație într -un singur pas. Fie că este
vorba de vizualizare a tuturor schimbărilor sau a orelor petrecute pe diferite activități, meniul face
simplă și la îndemână navigarea.
3.5.2 . Scenariu de utilizare
Pentru o înțelegere mai bună a capabilităților aplicației, cât și a simplității cu care poate fi
utilizata, urmeaza prezentarea unui scenariu de utilizare: crearea și vizualizarea unei schimbări.
Considerâm că acum deschidem aplicația. Primul pas este logarea în sistem după cum este
prezentat în tutorialul de utilizare. Următorul pas este de a selecta Schimbare noua din cadrul
panoului de comenzi rapide:

55
Selectarea acestei comenzi ne va duce la pasul următor în ecranul de creare a unei noi
schimbări:

În fereastra pentru schi mbare nouă, apar toate câmpurile spre a fi completate. Accesul exte
restricționat în cazul identificatorului schimbării care este generat automat, în cazul statului
schimbării, automat trecut ca nou , în cazul câmpului de aprobare manager deoarece acesta es te un
pas realizat separat și în cazul comentariilor de închidere a schimbării, care vor fi completate la
momentul final când va deveni și câmpul editabil . În continuare, utilizatorul are la dispoziție mai
multe meniuri dropdown populate cu informații din baza de date pentru a evita introducerea de
către utilizator a date diferite decât cele corecte:
 Panoul de informații generale: tip schimbare, urgență și element de configurare.
 Panoul de sarcini și planificare: atribuit gruplui și atribuit lui
 Panoul de implementare: grup, solicitant, risc și impact
Pe lângă meniurile dropdown, se pot observa câmpurile text care trebuie completate de
utilizator conform standardului stabilit prin instructaj, câmpurile de descriere, numele sarcinii de
luru și motivul schim bării.
Ultimul tip de câmp este câmpul de selecție a datelor din cadrul panoului de sarcini și
planificare relizat cu ajutorul Bootstrap.js permițând alegerea datei și a orei de implementare.

56
Este foarte important sa fie respectate regulile, altfel, datel e introduse nu vor fi valide și refuzate
ca atare.
În cazul schimbărilor la care testarea poate fi efectuată se bifează campul de testare
efectuată.
Odată completat, formularul este trimis către baza de date prin butonul de loghează. După
salvare, un mesaj de succes va fi afișat în colțul drept al eranului iar utilizatorul va fi redirectat
către pagina de vizualizare a schimbării create:

Imediat ce schimbarea nou creată este validată de aplicație și ajunge în baza de date, se va
trimite automat și câte un email pe ntru persoana căreia i -a fost atribuită sarcina de lucru, către
persoana care a creat schimbarea , dar și către șefii lor de departament dacă schimbarea se
încadrează în limi tele impuse de aplicație de tipul schimbării . Astfel se evită confuzi i și
posibilități de ignorare a evenimentului creat , iar evenimentul este aprobat de șeful direct al celui
care a creat schimbarea.
Pe lângă emailurile trimise la creere, utilizatorul a cărui schimbare este are obligația de a
comunica mai departe p ersoanelor competente schimbarea ce va avea loc. Acest lucru este valabil
pentru schimbările mari care necesită oprirea unor elemente de configurare, actualizarea lor cu
versiuni mai noi sau alte tipuri de schimbări ce pot afecta direct utilizatorii. Fie că este vorba
despre o întârziere în programul normal sau chiar o eliminare a unu i program învechit sau al unui

57
element de configurare depășit, persoa nele care se ocupă de comunicare au obligația de a anunța
mai departe utilizatorii.
În general, o bună practică , pentru a avea siguranța că toate schimbările sunt cunoscute
utilizatorilor , este de a ține o ședință săptămânală la nivelul departmentului în primul rând cu toți
angajații departamentului , iar mai apoi la nivelul tuturor departamentelor doar cu șe fii lor. În
aceast e ședinț e vor fi prezentate și dezbăute schimbările mari care urmează să aibă loc pentru a
asigura o bună comunicare la nivelul întregii firme.
Revenind, din pagina de vizualizare a schimbării , unde acum toate câmpurile au devenit
needitabile, poate fi accesată sarcina de lucru creată pentru această schimbare. Până la aprobarea
șefului, nicio altă comandă nu va fi disponibilă, iar statutul va rămâne nou. După aprobarea
șefului, câmpul va fi bifat, statutul se va schimba la progr (în proces de realizare), iar utilizatorul
deținător al schimbării, neaparat, va putea închide schimbarea odată efectuată. Orice alt utilizator
va putea vizaliza schimbarea și sarcina de lucru, dar nu va putea loga mai departe schimbarea.
Noua schimbare poate fi vizualizată atât în pagina de vizuali zare a schimbărilor, în pagina
de start în numărătoarea de la începutul paginii, cât și în calculele executate pentru obținerea
statisticilor unde apare o schimbare cu statutul nou:

Odată executată, statutul schimbării va deveni cmpl și ruta ei se va opr i în acel punct,
fiind disponibilă doar pentru vizualizare și statistici.

58
În cazul creării noilor incidente, situația este similară formularul pentru incidente
conținând mai puține câmpuri:

Similar, regulile de integritate se păstreaza, iar utilizatorul căruia îi este atribuit incidentul
îl poate rezolva.
Scenariile de utilizare pot fi destul de variate în funcție de utilizatorul care le efectuează,
însă odată cu instructajul utilizatorilor, aplicația devine o unealtă extrem de utilă în organizarea
activ ităților unei firme.

59
CAPITOLUL 4 – CONCLUZIE
Domeniul informatic va fi întotdeauna într -o continuă schimbare. Ceea ce se scrie astăzi,
ceea ce se rezolvă astăzi va avea mâine un nou sens mai bun, mai optimizat și mai popular. Cert
este că este vorba de spre o lume dinamică, o lume care nu doarme și care vrea să crească. Și de
ce nu, doar dezvoltatori sunt, iar dorința de a realiza lucruri mari cu siguranță există.
Aplicația SmarTicket este o aplicație destinată gestionării activităților în firmele TI care
soluționează multe dintre cerințele actuale, cel mai important lucru fiind faptul că le oferă pe
toate într -un pachet frumos și ușor de implementat. Deși soluții sunt multe, o aplicație care să le
face pe toate nu este ușor de găsit.
Folosind tehnologii dezvoltate și ajunse la un echilibru pe care multe altele ar vrea să îl
atingă, aplicația promite un mediu stabil și pe care orice utilizator se poate baza. Mai mult decât
atât, SmarTicket poate fi foarte ușor extins, fiind loc suficient pentru funcțional ități noi, după
nevoile fiecărei firme de dezvoltare. Un alt plus al tehnologiilor în care este dezvoltată este faptul
că toate sunt foarte bine documentate, încât permit oricărui neavizat o întelegere cel puțin
superficială a logicii implementate.
O conc luzie foarte importantă este că sistemele de gestionare a activității în firmele din
domeniul informatic sunt absolut necesare pentru o dezvoltare armonioasă, lipsită de erori și
conflicte. Iar aplicația prezentată vine în sprijinul acestei nevoi, asigurân d prin logica sa o
administrare corectă a evenimentelor și chiar impărțirea lor cu scopul de a putea extrage date și
de a stabili anumite țeluri la nivel individual sau la nivelul departamentului.
Dacă necesitatea administrării corecte a evenimentelor est e clară, extragerea de date va
spori eficiența dezvoltării deoarece un sistem care produce mereu erori poate fi identificat în
acest mod și schimbat sau modificat. Iar țelurile sunt extrem de importante pentru a ști
întotdeauna care este scopul final urmăr it, atât personal unde are un efect motivațional, cât și la
nivelul întregii echipe menținând astfel o atmosferă corectă, armonioasă și mereu antrenantă.
În concluzie, utilizând tehnologii accesibile precum JavaScript și derivatele sale, HTML
și CSS, aspec tul aplicației este unul plăcut, simplu de utilizat și interactiv . Prin tehnologiile
următorului nivel, PHP și MySQL logica și funcționalitatea aplicației sunt asigurate, iar prin
Apache aplicația capătă viață. Toate aceste tehnologii, puse la un loc au fo st soluția așteptărilor
pe care domeniul informatic le au de la un sistem de gestionare a activităților.

60
BIBLIOGRAFIE
[1] Agile Methodology, „The Agile Movement”, 2002
[2] Andrew S. Tanenbaum, David J. Wetherall, „Computer Networks, Fifth Edition”,
Editura Pearson, 1988
[3] Ben Laurie, Peter Laurie, „Apache: The definitive Guide, Third Edition” , Editu ra O'Reilly
& Associates, Inc., 2013
[4] David Flanagan, „JavaScript: Th e De finitive Guide, Sixth Edition”, Editura O’Reilly
Media, Inc., 2005
[5] Gabriel Vasile, „ITSM, abordare no ua pentru o lume in sch imbare”, Market Watch, 2011
[6] Glenn E. Krasner, Stephen T. Pope, „A Description of the Model -View -Controller User
Interfa ce Paradi gm in the Smalltalk -80 System”, Editura ParcPlace Systems, Inc., 2011
[7] Kavin Tatroe, P eter MacIntyre, Rasmus Lerdorf, „Programming PHP, Third Edition”,
Editura O’Reilly Media, Inc., 2012
[8] Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham,
Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern,
Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave
Thomas, „Principle s behind the Agile Man ifesto”, 2005
[9] Luke Welling, Laura Thomson, „Dezvoltarea aplicațiilor Web cu PHP și MySQL”,
Editura Teora, 2010
[10] Martin Fowler, „GUI Architectures”, 2006
[11] Mehdi Achour, Friedhelm Betz, Antony Dovgal, Nuno Lopes, Hannes Magnusson, Georg
Rich ter, Dam ien Seguy, Jakub Vrana, „PHP Manual”, PHP Documentation Group, 2014
[12] Michael Kofler, „The Definitive Guide to MySQL 5”, Editura Apress, 2008
[13] Rich Bowen, Cooper McGregor, „Introduction to the Apache Web Server”, 2001
[14] Ryan Benedetti, Ronan Cranley, „Head First jQuery”, Editura O’Reilly Media, Inc., 2005
[15] World Wide Web Consortium, „A Short History of JavaScript”, 2016
[16] World Wide Web Consortium, „HTML5”, 2010
[17] World Wide Web Consortium, „What is CSS?”, 2005
[18] http://dev.mysql.com/doc/refman/5.7/en/optimization.html
[19] http://dev.mysql.com/doc/refman/5.7/en/what -is.html
[20] http://fontawesome.io/

61
[21] http://getbootstrap.com/about/
[22] http://its.ucsc.edu/itsm/index.html
[23] http://news.netcraft.com/archives/2016/02/22/februa ry-2016 -web-server -survey.html
[24] http://usablica.github.io/front -end-frameworks/compare.html?v=2.0
[25] http://wp2x.com/html5
[26] http://www.chartjs.org/docs/
[27] http://www.codeignite r.com/user_guide/
[28] http://www.fpdf.org/
[29] http://www.indicatorideperformanta.ro
[30] http://www.itsm.info/ITSM.htm#overview
[31] http://www.json.org/
[32] http://www.pnmsoft.com/resources/bpm -tutoria l/key -performance -indicators/
[33] http://www.startups.ro/analize/ce -sunt-indicatorii -cheie -de-performanta
[34] http://www.yourhtmlsource.com/starthere/historyofhtml.html
[35] https://commons.wikimedia.org/w/index.php?curid=10298177
[36] https://developer.chrome.com/apps/app_frameworks
[37] https://developer.mozilla.org/en -US/docs/Web/Guide/HTML/HTML5
[38] https://developer.mozilla.org/en -US/docs/Web/ JavaScript/Guide/Introduction
[39] https://developer.mozilla.org/en -US/Learn /Common_ questions/What_is_a_web_server
[40] https://docs.phpmyadmin.net/en/latest/
[41] https://en.wikipedia.org/wiki/Agile_software_development
[42] https://en.wikipedia.org/wiki/Bootstrap_(front -end_framework)
[43] https://en.wikipedia.org/wi ki/Cascading_Style_Sheets
[44] https://en.wikipedia.org/wiki/Document_Object_Model
[45] https://en.wikipedia.org/wiki/HTML
[46] https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
[47] https://en.wikipedia.org/wiki/IT_service_management
[48] https://en.wikipedia.org/wiki/JavaScript
[49] https://en.wikipedia.org/wiki/Less_(stylesheet_language)
[50] https://en.wikipedia.org/wiki/Model%E2 %80%93view%E2%80%93controller
[51] https://en.wikipedia.org/wiki/MSQL
[52] https://en.wikip edia.org/wiki/MySQL

62
[53] https://en.wikipedia.org/wiki/NCSA_HTTPd
[54] https://en.wikipedia.org/wiki/Performance_indicator
[55] https://en.wikipedia.org/wiki/PHP
[56] https://en.wikipedia.org/wiki/Sass_(stylesheet_language)
[57] https://lear n.jquery.com/about -jquery/
[58] https://learn.jquery.com/ajax/
[59] https://ro.wikipedia.org/wiki/SQL
[60] https://www.apachefriends.org/ro/about.html
[61] https://www.jetbrains.com/phpstorm/
[62] https://www.sysaid.com/resources/what -is-itsm
[63] https://www.w3.org/Consortium/
[64] https://www.w3.org/DOM/
[65] http://www.codeigniter.com/user_guide/overview/appflow.html
[67] http://193.226.51.37/web/curs/curs5.pdf
[68] https://en.wikipedia.org/wiki/CodeIgniter#cite_note -7