Automatizarea Colectarii Si Analizei Metricilor de Colectie

LUCRARE DE LICENȚĂ

Automatizarea colectării și analizei metricilor de colecție

din cadrul unei organizații

CUPRINS

Capitolul 1 – INTRODUCERE

1.1. Tema lucrării

1.2. Conținutul lucrării

1.3. Motivația alegerii temei

Capitolul 2 – ANALIZA DE SISTEM

2.1. Domeniul aplicației

2.2 Metrici de colecție

2.2.1. Noțiuni teoretice

2.2.2. Caracteristicile metricilor

2.2.3. Importanța metricilor într-o organizație

2.2.4. Colectare, stocare, analiză

2.2.5. Metrici de interes

Capitolul 3 – TEHNOLOGII ȘI UNELTE UTILIZATE

3.1. Tehnologii

3.1.1. Tehnologia Cloud Computing

3.1.2. ReSTful Web Services

3.1.3. PHP 5.4

3.1.4. MySQL

3.1.5. HTML 5.0, JQuery, Javascript și CSS

3.2. Unelte utilizate

3.2.1. Jira

3.2.2. Crucible

3.2.3. Active Campaign

3.2.3. Get Satisfaction

3.2.4. Google Analytics

Capitolul 4 – PROIECTAREA APLICAȚIEI

4.1. Analiza specificațiilor

4.2. Modelarea software a aplicației cu ajutorul UML

4.3. Arhitectura generală a aplicației

4.4. Parametri de configurare și acces

Capitolul 5 – IMPLEMENTAREA MODULELOR APLICAȚIEI

5.1. Bibliotecile colectoare

5.1.1. Detalii de implementare

5.2. Modulul Collector

5.3. Modulul Controller

5.4. Modulul de stocare a datelor

5.5. Modulul de analiză a datelor

5.6. Afișarea in interfață

5.6.1. Descrierea meniurilor

Capitolul 6 –TESTAREA și INTEGRAREA APLICAȚIEI

6.1. Testarea aplicației

6.2. Integrarea modulelor

Capitolul 7 – DEZVOLTĂRI VIITOARE ȘI CONCLUZII

7.1. Dezvoltări viitoare

7.2. Concluzii finale

BIBLIOGRAFIE

Capitolul 1 – INTRODUCERE

Tema lucrării

Lucrare de față abordează tema metricilor de colecție din cadrul unei companii și a modului în care acestea sunt extrase, stocate, analizate și reutilizate pentru a putea fi folosite în stabilirea performanțelor individuale și de echipă.

Structura lucrării se fundamenteză pe două direcții principale. Prima direcție este cea de documentare privind metricile de colecție, utilizarea lor și elaborarea unor statistici obiective cu acestea prin intermediul unei interfețe grafice. A doua, este direcția de implementare practică a noțiunilor prezentate.

Noțiunea de interfață studiază comunicarea dintre om și mașina de calcul, mașină care desemnează aparatura caracterizată de utilizabilitate. Utilizabilitatea este așadar trăsătura principală a unei interfețe și determină gradul de acceptare al clientului, față de un produs software , fapt ce face ca aplicațiile implementate să fie ușor de folosit și cât mai des utilizate în organizații, indiferent de competențele de calcul a persoanelor ce dispun de interfața implementată. În termeni unanimi acceptați utilizabilitatea unei interfețe, în inginerie este descrisă prin cuvintele “user-friendly”.

De la serviciul personal și până la director, toată lumea poate accesa interfața grafică și poate trage concluzii pe baza unor date obiective din organizație.

Procesul dezvoltării unei aplicații de o mare amploare care să centralizeze date din diverse medii, să le stocheze în format unificat și să le utilizeze ulterior, impune specificarea unei probleme, verificarea certitudinilor și analiza detaliată a complexității algoritmilor folosiți, cât și analiza problemei din perspectivă resurselor de dezvoltare. Etapele esențiale pentru garantarea calității aplicației și a performanțelor soluțiilor implementate, constituie obiectivul întreg al lucrării de diplomă ”Automatizarea colectării și analizei metricilor de colecție din cadrul unor organizații” și vor fi dezbătute în întreaga documentație.

Lucrarea se fundamentează pe conceptele de interfață grafică și metrică de colecție, și dorește implementarea în diverse limbaje de programare, cu tehnologii evolutive, a unui sistem live-monitor (monitorizator în timp real), pentru gestionarea cât mai eficientă a personalului, proiectelor și direcțiilor de urmat în cadrul organizațiilor. În adaptarea tehnologiile evolutive, s-a pornit de la studiul metricilor și a diverselor medii de lucru și s-a dezvoltat ulterior interfața grafică live-monitor, urmărind îndeaproape modul de lucru cu toate tehnologiile implicate: Jira, Crucible-FishEye, Google Analytics, Get Satisfaction, Confluence, în încercarea de a rezulta “interfața grafică cu utilizatorul” cât mai utilizabilă și “user-friendly” (prietenoasă utilizatorului).

Procesul dezvoltării unui produs software și etapele parcurse de un produs până la lansarea sa pe piață implică participarea dedicată a întregii echipe de dezvoltatori, urmând ca la final, evaluarea să centralizeze atât opiniile clienților despre produsul utilizat, cât și feedback-ul echipei.

Conținutul lucrării

O sinteză cu caracter de specificații funcționale a ceea ce se va implementa ca și suport practic al lucrării de față se poate formula astfel: ”În cadrul organizațiilor se definesc diferite metrici de performanță pentru grupuri de lucru și persoane individuale. Aceste metrici sunt păstrate în diverse locații și utilizate ulterior în cadrul companiilor în direcții precum: bug tracking, task distribution etc. Se dorește dezvoltarea unei aplicații web care sa permită specificarea metricilor cheie pe baza cărora se extrag datele, cât și a modulelor de analiză după diverse criterii de prelucrare.” .

În acest sens, capitolul 2 al lucrării – Analiza de sistem, abordează aspecte teoretice cu privire la metrici, semnificația acestora, cum sunt utilizate, care este relevanța prelucrării lor precum și noțiuni generale privind tehnologiile și uneltele de dezvoltare software ale prezentei lucrări.

Capitolul 3 – Tehnologii și unelte utilizate, descrie în manieră teoretică și totodată argumentativă necesitatea tehnologiilor prezente în aplicația software finală, precum și rolul fiecărei tehnologii în colectarea, stocarea și analiza metricilor din cadrul organizației. Capitolul începe cu încadrarea aplicației în domeniul dezvoltării software incluzând și noțiuni teoretice de management al dezvoltării software al aplicației finale și servește drept suport teoretic fundamental în ceea ce privește noțiunile cu care se va opera în prezenta lucrare.

Capitolul 4 – Proiectarea aplicației, încearcă să ofere o soluție obiectivă a ceea ce s-a prezentat în capitolul anterior și pornește de la un model de schiță a aplicației, apoi dezvoltă noțiuni care sta la baza unei aplicații web grafice consistentă și cât mai utilizată. Capitolul descrie pe cât se poate de în detaliu, modelarea UML (Unified Modelling Language) a aplicației, arhitectura generală a aplicației, precum și detalii referitoare la parametrii de acces în interfață.

Capitolul 5 – Implementarea modulelor aplicației, oferă atât o imagine teoretică cât și preponderent practică asupra a ceea ce s-a realizat în lucrare și descrie în detaliu fiecare modul al aplicației finale. Se va ține cont de modul de funcționare al fiecărui modul, cum interacționează modulele ca și părți funcționale independente cât și ca întreg, de configurarea fiecărui modul printr-un fișier de configurare sau prin respectarea unor reguli, dar și de timpii de execuție și de răspuns ai aplicației. Este cel mai complex capitol al lucrării, deoarece se acoperă aât noțiunile teoretice din capitolele anterioare, cât și aspecte de funcționare ale aplicației, capturi sugestive, rezultate ale rulării aplicației dar și detalii asupra aplicației finale rulată pe un server local.

Capitolul 6 – Testarea și integrarea aplicației, este structurat pe două subcapitole esențiale în livrarea unui produs software final către un beneficiar (client, organizație etc.), fiecare dintre subcapitole operând cu câte o noțiune teoretică care este descrisă în introducerea subcapitolului, urmată de soluția practică de integrare și testare a aplicației finale.

Capitolul 7 – Dezvoltări viitoare și concluzii, prezintă în maniera subiectivă a autorului rezultatele colectării, stocării și analizei metricilor din cadrul unei organizații, justificând necesitatea aplicării acestor procese asupra unor date, în vederea raportării permanente la concret a situației/evoluției unei firme.

Motivația alegerii temei

Am aplicat pentru o temă de licență în co-tutelă, deoarece doream să intru în contact cu cultura organizațională din cadrul unei firme și să iau contact cu tehnologii noi, pe care să mi le însușesc și să le integrez cu succes, atât în lucrarea de diplomă, cât și într-un posibil loc de muncă pe viitor. Consider că acest lucru a reprezentat un pas important în dezvoltarea mea și că numai lucrând efectiv, am putut exploata cunoștințele teoretice deținute și mi-am însușit altele noi, într-un domeniu nou, dinamic și cât mai exploatat în ultima perioadă – cloud computing.

Alegerea temei a reprezentat o provocare pentru mine, pe care am fost dispus să o înfrunt, convins fiind de capacitatea mea de a învața și de ambiția mea de a reuși, bazându-mă totodată pe înțelegerea, suportul și ajutorul S.C. 4PSA S.R.L. .

Consider că tema pentru care am optat mi s-a potrivit, deoarece dispun de elemente teoretice și practice ințiale în scopul demarării și finalizării ei, iar tema reprezintă o temă de actualitate în industria IT&C Software și cea de management organizațional. Mi s-a oferit șansa de a mă dezvolta în acest domeniu, învațând direct de la specialiști. De asemenea, pasiunea mea pentru organizare, firea analitică și minuțiozitatea m-au motivat ca rezultatul obținut să fie nu numai funcțional, ci și integrat în activitatea firmei. Am avut încredere totodată, în capacitatea mea de integrare în echipă, datorită numeroaselor proiecte școlare pe care le-am desfășurat în timpul facultății.

Un alt motiv de a aplica pentru tema menționată, a fost acela că, nu am avut până acum ocazia să particip la un proiect software de la începutul său, până la etapa de testare finală și am fost interesat să fac parte din procesul de dezvoltare al unei aplicații.

Mulțumiri speciale companiei 4PSA S.R.L. reprezentată de domnul Bogdan Cârstoiu pentru suportul acordat în elaborarea lucrării, prin punerea la dispoziție a tehnologiilor firmei și a suportului tehnic necesar dezvoltării interfeței dinamice de afișare a metricilor – scopul final al prezentei lucrări.

Capitolul 2 – ANALIZA DE SISTEM

2.1. Domeniul aplicației

Domeniul din care face parte lucrarea este cel de Dezvoltare software orientată spre

servicii web.

Domeniul de Dezvoltare software ( engleză Software Development/ SD) este cunoscut și sub denumirile de proiectare software, dezvoltare de aplicații software și constituie o serie de pași ce trebuie parcurși în vederea realizării unui produs software.

”Sub accepțiune universală, domeniul de dezvoltare software, implică activitatea de programare/ codare și se canalizează pe mentenanța și testarea produsului final, dar în termeni generali include toate etapele ce trebuie parcurse de la concepția cerințelor unei aplicații până la manifestarea software finală, ideal planificată și prezentată într-un proces structurat”.

Softul poate fi dezvoltat pentru o varietate de scopuri, dar cele mai întâlnite trei scopuri în domeniu se orientează către satisfacerea nevoilor clienților/utilizatorilor.

Necesitatea unei mai bune calități a procesului de Software development a crescut exponențial în ultimii ani, și datorită acestui lucru este necesară o delimitare clară între stagiile de dezvoltare ale unui produs, care în domeniul ales, sunt următoarele:

Analiza problemei

Cercetarea de piață (comunicare cu clientul – adunarea cerințelor aplicației)

Colectarea cerințelor tehnice pentru furnizarea celei mai bune strategii de afacere

Schițarea unui plan sau al unui design pentru soluția bazată pe software

Implementarea efectivă a aplicației

Testarea aplicației

Deployment sau seria de activități care fac aplicația finală gata de utilizare

Mentenanță și fixarea de defecte

Figura 2.1 – Ciclul de viață al dezvoltării produselor software

Domeniul software are prea multe dimensiuni care nu pot fi combinate ții software și constituie o serie de pași ce trebuie parcurși în vederea realizării unui produs software.

”Sub accepțiune universală, domeniul de dezvoltare software, implică activitatea de programare/ codare și se canalizează pe mentenanța și testarea produsului final, dar în termeni generali include toate etapele ce trebuie parcurse de la concepția cerințelor unei aplicații până la manifestarea software finală, ideal planificată și prezentată într-un proces structurat”.

Softul poate fi dezvoltat pentru o varietate de scopuri, dar cele mai întâlnite trei scopuri în domeniu se orientează către satisfacerea nevoilor clienților/utilizatorilor.

Necesitatea unei mai bune calități a procesului de Software development a crescut exponențial în ultimii ani, și datorită acestui lucru este necesară o delimitare clară între stagiile de dezvoltare ale unui produs, care în domeniul ales, sunt următoarele:

Analiza problemei

Cercetarea de piață (comunicare cu clientul – adunarea cerințelor aplicației)

Colectarea cerințelor tehnice pentru furnizarea celei mai bune strategii de afacere

Schițarea unui plan sau al unui design pentru soluția bazată pe software

Implementarea efectivă a aplicației

Testarea aplicației

Deployment sau seria de activități care fac aplicația finală gata de utilizare

Mentenanță și fixarea de defecte

Figura 2.1 – Ciclul de viață al dezvoltării produselor software

Domeniul software are prea multe dimensiuni care nu pot fi combinate în cadrul aceluiași framework. Un mecanism bun de a asigura consistența softurilor dezvoltate este acela de modelare UML (Unified Modelling Language) prin diagrame de clase care să descrie în mod generic, vizual, ceea ce se întâmplă în aplicație.

Modulele aplicației dezvoltate pornesc cu modelarea software prin diagrame de clase, apoi sunt implementate și integrate pentru obținerea scopului final – colectarea, stocarea și analiza metricilor extrase.

2.2 Metrici de colecție

2.2.1. Noțiuni teoretice

Se cunoaște faptul că, de-a lungul existenței sale, omul a avut mereu nevoie de repere pe care le-a considerat apoi ca puncte de plecare pentru acțiunile sale viitoare. Există permanenta necesitate de a ne raporta la ceva, de a obține certitudini asupra a ceea ce am întreprins. În cadrul organizației se definesc diverse metrici pentru măsurarea acestor certitudini.

În termeni generali, noțiunea de metrici se poate defini prin parametrii sau măsurile de evaluare cantitativă utilizate pentru măsurare, comparare sau pentru a urmări performanța de producție. Analiștii pot folosi măsurătorile pentru a compara performanța între diferite companii, în ciuda multor variații între firme.

O paradigmă foarte cunoscută privind metricile, este aceea conform căreia lucrurile măsurabile pot fi ușor sau mai ușor gestionate. A măsura și ulterior a gestiona un sistem de metrici într-o organizație presupune cunoașterea standardelor după care se face măsurarea, precum și înțelegerea acestor standarde.

De asemenea, există adesea tendința de a evita utilizarea unui sistem de metrici în cadrul unei organizații, pentru că nu avem certitudinea exactității acestor date. În acest sens, există o distincție clară între termenul de numărare și cel de măsurare.

Numărarea este procesul la finalul căruia putem determina cu exactitate un număr sau o valoare pentru un anumit indicator. De cealaltă parte, procesul de măsurare presupune efectuarea unor comparații succesive cu niște valori considerate a fi normale, pentru a verifica gradul de certitudine, sau repetare a unor valori ce vor fi ulterior considerate corecte. Măsurarea se bazează pe observații, iar măsurătoarea este cu atât mai relevantă cu cât indică un progres.

În domeniul Inteligenței Artificiale, există numeroși algoritmi de căutare ai unor concluzii, într-un mediu caracterizat de incertitudini. Pentru a găsi valoarea certă e nevoie de metrici. La fel ca și în Inteligența artificială, domeniul afacerilor este și el caracterizat de incertitudini – de la condițiile evoluției pieței, la criza economică sau la neseriozitatea partenerilor de afaceri, toate aceste variabile constituie incertitudini ce pot pune în pericol activitatea unor organizații. Evoluția în sens pozitiv a activității acestor firme depinde de deciziile pe care managerii le iau în condițiile de incertitudine. Reducerea incertitudinilor favorizează luarea de decizii cât mai bune, astfel încât afacerea să progreseze.

Știm adesea că măsurătorile nu sunt întotdeauna precise și pentru aceasta trebuie să definim praguri, tendințe, metrici și nu neapărat numere exacte. Ceea ce caracterizează mediul de afaceri actual este nevoia companiilor de a se adapta schimbărilor și a avea o dinamică pozitivă într-un mediu concurențial. Măsurarea a devenit cu atât mai importantă în organizații cu cât fiecare organizație progresează. Managementul prin metode agile sau utilizarea unor metrici în cadrul companiilor favorizează convingerea managerului că afacerea prosperă și oferă o siguranță că ceea ce s-a implementat prin produsele firmei respectă standardele proprii de calitate în fața clienților.

Am discutat despre metrici, însă nu există exemple concrete ale acestora. Pentru a veni în sprijinul înțelegerii metricilor, aș porni de la necesitatea superiorilor de a ști întotdeauna cum au evoluat lucrările la un anumit proiect, cum s-au alocat resursele etc. . Este așadar nevoie de cunoașterea timpilor de execuție, a unui volum de muncă, de gestiunea resurselor disponibile, astfel încât deciziile manageriale luate în organizație să fie în cunoștință de cauză și raportate corespunzător la context, cu minimizarea cât mai eficientă a incertitudinilor.

2.2.2. Caracteristicile metricilor

Metricile de colecție cu care lucrarea operează ca și noțiuni fundamentale, sunt valori esențiale pentru gestionarea unei organizații de succes. Pentru a putea fi gestionate, metricile trebuie întâi sa fie măsurabile, acestea fiind trăsăturile fundamentale ale metricilor de colecție.

Utilizarea metricilor a devenit astfel, o modă în cadrul organizațiilor în plină dezvoltare, adaptate în permanență la schimbare și care folosesc în etapele de dezvoltare a produselor software metode agile de management.

Dezvoltarea pe bază de metrici necesită criterii prestabilite, o scară comun acceptată de toți membrii organizației și care să le stabilească o valoare pozitivă în raport cu tot ceea ce se dezvoltă în organizație. În acest sens, dezvoltatorul trebuie să cunoască cum să colecteze datele care evoluează în metrici și să le poată urmări. Un alt criteriu important în manipularea metricilor este modul de utilizare a indicatorilor de îmbunătățire a performanțelor membrilor organizațiilor în care metricile sunt utilizate.

Dacă ne gândim la o scară comună de valori într-o organizație, trebuie să precizez că aceste valori trebuie sa fie în primul rând eficiente. Eficiența survine dintr-o valoare, valoare care este o măsură standard și are sens atunci când este folosită într-o condiție. Aceasta reprezintă o măsurare a unei anumite probleme sau subiect, proces sau inițiativă. Măsurătorile făcute cu metricile trebuie să aibă efecte semnificate și impact pozitiv în evoluția organizației și a membrilor săi. Problema semnificației metricilor, a cerințelor funcționale elaborate precum și a modelului aplicației în detaliu, vor fi expuse în secțiunile care urmează ale prezentei lucrări.

2.2.3. Importanța metricilor într-o organizație

Implementarea și utilizarea unui sistem de metrici sunt importante pentru o organizație și constituie avantaje ale progresului companiei care le implementează și utilizează. Pentru a-și arăta valoarea pe care o aduc odată cu colectarea lor, metricile, trebuie colectate pe seturi și vor furniza statistici relevante odată cu finalizarea colectării fiecărui set.

Importanța metricilor se vede în revizuirea unor obiective ale afacerii, în determinarea unui nou set de metrici care trebuie colectate, în faptul că prin colectarea succesivă de metrici, procesul de măsurare a acestora devine ciclic, se rafinează și ia amploare.

Un sistem de metrici este cu atât mai important în companie cu cât implementarea sa cu succes este un rezultat al unui proces continuu, când rezultatele a două prelucrări succesive a metricilor furnizează același rezultat și când metricile furnizează informații utilizate nu numai de echipa de management, ci și de către angajații companiei, indiferent de nivelul lor ierarhic.

Una dintre cele mai importante funcții ale unei metrici o reprezintă faptul că indică performanța ( atât individuală, cât și a echipei).

Printre caracteristicile metricilor care au impact și accentuează importanța lor în cadrul unor organizații, se pot enumera:

Oferă suport în determinarea și rafinarea produselor și serviciilor;

Permit urmărirea numărului de utilizatori pe zone demografice;

Furnizează dovezi dacă utilizatorii sunt mulțumiți de calitatea unui produs sau serviciu

Furnizează dovezi ale impactului asupra cunoașterii utilizatorilor, atitudinilor, sau comportamentelor;

Compară produsele și serviciile altora (benchmarking);

Raportarea cu regularitate de metrici prezentate în mod clar este un element esențial al
comunicărilor adresate părților interesate;

În ceea ce privește durabilitatea, valori adecvate sunt critice în competiție pentru menținerea și finanțarea prin granturi, investiții sau generarea de venituri;

2.2.4. Colectare, stocare, analiză

Lucrarea de față se dezvoltă pronind de la cuvintele cheie din titlul său, anume conceptele teoretice de colectare, stocare și analiză ale metricilor. Pentru o cât mai bună înțelegere ale conceptelor expuse, se va detalia fiecare termen urmărind implicațiile acestuia asupra unui sistem de metrici și respectiv asupra organizației.

Colectarea metricilor presupune identificarea acelor criterii, cerințe care trebuie să fie îndeplinite ca o condiție de progres a organizației. Procesul de colectare a metricilor implică identificarea corespunzătoare a metricilor utile în organizație, precum și preluarea efectivă a datelor din diverse medii. Preluarea datelor s-a făcut adesea de către om, însă în contextul prezentei lucrări, se va implementa o colectare prin intermediul unei biblioteci specifice fiecărui mediu, automatizată. Procesul de colectare al metricilor este cel mai important și are cel mai mare impact asupra deciziilor viitoare ale companiei. Cu cât metricile sunt identificate corect încă din faza incipientă, cu atât consumul de resurse este mai redus, timpii de performanță sunt mai buni, iar metodele agile de management sunt din ce în ce mai eficiente.

Criterii la colectarea metricilor sunt: specificul afacerii companiei, tipul de proiecte dezvoltate, care este strategia de dezvoltare a companiei etc. . Responsabilii cu calitatea sunt cei care împreună cu echipa de management selectează ce tip de metrici trebuie colectate și măsurate constant astfel încât obiectivele companiei să fie îndeplinite.

Stocarea metricilor reprezintă etapa intermediară prin care metricile sunt identificate în diverse medii și furnizează date numeroase. Datele furnizate în raport cu metricile dorite, sunt înmagazinate în diverse medii, și sunt centralizate pentru prelucrări ulterioare. Stocarea datelor trebuie să se facă în medii ascunse utilizatorilor, și niciun factor intern organizației, sau mai ales extern nu trebuie să poată acționa asupra modificării datelor. În funcție de datele stocate și de metricile de interes, se trece la etapa de analiză a datelor.

Etapa de analiză a datelor reprezintă faza finală, de filtrare, astfel încât prin aplicarea unor calificative/punctaje asupra metricilor să se obțină în final, niște statistici cât mai obiective. Analiza datelor dă informații asupra progresului, dă avertismente în cazul unor nereguli și permite ajustarea unor valori nerealiste în cazul apariției lor. Această ultimă etapă reprezintă scopul colectării și stocării metricilor.

Trebuie precizat că în contextul stocării și analizei metricilor, metricile capătă accepțiunea universală de date, astfel încât stocarea și analiza metricilor sunt echivalente cu stocarea și analiza datelor.

2.2.5. Metrici de interes

Cunoaștem acum ceea ce reprezintă metricile, ce operații se pot executa cu acestea și importanța lor. Precum am discutat în subcapitolul precedent, responsabilii cu calitatea sunt cei care stabilesc împreună cu echipa de management ce metrici sunt relevante în organizație și mai ales care metrici să fie selectate astfel încât rezultatele să indice progresul companiei. Nu este însă suficient să conturăm în linii marii ceea ce ne-ar putea interesa în materie de metrici. Trebuie să ținem o evidență a metricilor colectate, pentru ca la următorul set, să ne putem raporta la trecut în tendința de evoluție a organizației.

Câteva dintre metricile de colecție ce se pot defini în cadrul organizației și care sunt cel mai frecvent utilizate în mediul de afaceri, se regăsesc în tabelul 2.1. Metrici de interes într-o organizație.

Tabelul 2.1. – Metrici de interes într-o organizație.

Tabelul 2.1. reprezintă un exemplu formal de metrici care contribuie la stabilirea performanțelor în cadrul unor companii. Reluarea exemplelor de metrici este necesară pentru fiecare mediu de colectare utilizat în aplicație. Explicarea fiecărui mediu se va face în capitolul 3 al prezentei lucrări.

Momentan, o listă orientativă a metricilor utilizate în întreaga aplicație este prezentată în tabelul 2.2. – Lista metricilor din aplicație, fără precizarea mediului din care metricile sunt colectate. Un tabel complet al metricilor din aplicația web finală, ținând cont de mediul de colectare, este prezentat în Anexa 4 – Lista completă a metricilor din aplicație.

Tabelul 2.2. – Lista metricilor din aplicație

Capitolul 3 – TEHNOLOGII ȘI UNELTE UTILIZATE

3.1. Tehnologii

3.1.1. Tehnologia Cloud Computing

Tehnologia cloud computing este utilizată în prezenta lucrare pentru testarea, codarea și mentenanța aplicației, și va furniza pentru produsul final un serviciu ca și serviciu ( în engleză – Service as Service sau SaS). Cloud-ul utilizat este reprezentat de serverul de testare/lucru și este de tip privat, pus la dispoziție de către 4PSA S.R.L..

Arhitectura sistemului cloud computing, în termeni generici poate fi reprezentată astfel:

Figura 3.1 – Diagrama serviciului cloud computing

3.1.1.1. Descriere generală

Pentru a înțelege mai bine conceptul de cloud computing (tradus prin computer în nori), voi porni de la un exemplu simplu, uzual.

În loc de a instala o suită de software-uri pentru fiecare computer, se poate încărca o singură cerere/ aplicație care să fie folosită de orice utilizator existent, cât și de noi utilizatori, fără a avea resurse redundante. Această cerere ar permite lucrătorilor să se conecteze într-un serviciu prin cereri bazate pe servicii web care găzduiesc toate programele de care utilizatorii ar avea nevoie. Mașinile de la distanță deținute de companie, permit în ziua de astăzi stocarea de servicii de orice fel, folosite în munca lor, de la e-mail, procesare de text până la programe complexe de analiză a datelor. Stocarea programelor, aplicațiilor și uneltelor firmei se face pe niște servere fizice, locale sau adesea aflate la distanță, accesul la orice resursă făcându-se precum am spus, pe bază de cereri la serverul care găzduiește aplicația. Este cazul mailului pe care îl verificăm zi de zi. Tehnologia așa cum a fost descrisă prin întreg exemplul enunțat se numește cloud computing.

Dacă până acum cinci ani, organizațiile mari preferau închirierea unui spațiu în cloud de la câțiva dezvoltatori, în prezent organizațiile aflate în ascensiune și-au construit propriul nor (cloud), cu care operează în activitatea de zi cu zi. Este și cazul prezentei lucrări care își motivează utilizarea tehnologiei cloud computing în dezvoltarea aplicației finale, prin faptul că metricile sunt stocate în medii diferite, fiecare mediu aflat pe câte un server, iar resursele interfeței grafice finale sunt accesate prin cererile serviciului web ReST și ulterior afișate în browser.

Referitor la motivația alegerii tehnologiei, este important de evidențiat că într-un sistem de cloud computing, există o schimbare semnificativă a volumului de muncă. Calculatoarele locale nu mai au de-a face toate munca grea atunci când vine vorba de aplicațiile care rulează. Rețeaua de calculatoare care alcătuiește norul accesează resursele comune de pe serverele aflate în companie sau în orice altă țară. De asemenea, resursele hardware și software necesare utilizatorului vor scădea. Singurul lucru de pe computerul utilizatorului care ne preocupă și care trebuie să fie capabil să ruleze software-ul din coud, este interfața sistemului de cloud computing (exemplu – un browser web, sau o interfață asemănătoare).

Atunci când vorbim despre un sistem de cloud computing, este util să-l împarțim în două secțiuni: partea din față (frontend) și partea din spate (backend). Cele două părți se conectează între ele printr-o rețea, de obicei prin Internet. Partea frontală este partea de utilizator de computer, sau client. Capătul din spate este secțiunea "nor" al sistemului.

Partea frontală include computerul clientului (sau rețeaua de calculatoare) și aplicația necesară pentru a accesa sistemul de cloud computing. Nu toate sistemele de cloud computing au aceeași interfață de utilizator. Servicii cum ar fi e-mailul sau browsere web existente, cum ar fi Internet Explorer sau Firefox au interfețe diferite, deși ambele operează cu tehnologia cloud computing. Alte sisteme au aplicații unice, care oferă acces la rețea pentru clienți. În partea din spate a sistemului sunt diferite calculatoare, servere și sisteme de stocare a datelor, care creează "nor" de servicii de calcul. De obicei, fiecare aplicație va avea propriul server dedicat. Așadar, un server central administrează sistemul, monitorizează cererile de trafic și clienții, pentru a se asigura totul merge bine. De cele mai multe ori, servere nu rulează la capacitate maximă. Pentru a evita această situație unele companii utilizează o altă tehnică, cea de virtualizare a serverelor (mai multe servere, fiecare rulând pe câte un sistem de operare independent).

În cazul în care o companie de cloud computing are o multime de clienți, nu e probabil să fie o cerere mare pentru o mulțime de spațiu de stocare. Unele companii necesită sute de dispozitive de stocare digitale. Sisteme de cloud computing au nevoie de cel puțin de două ori numărul de dispozitive de stocare pentru a păstra informațiile tuturor clienților săi stocate. Un sistem de cloud computing trebuie să facă o copie a informațiilor tuturor clienților săi și să le păstreze pe alte dispozitive. Accesarea copiilor se face prin intermediul serverului central.

Urmărind necesitățile utilizării unui astfel de sistem în nor (cloud), se pot evidenția cu ușurință două dintre problemele actuale și cele mai stringente ale utilizării cloud computing. Prima problemă ar fi cea de siguranță a datelor – datele trebuie să nu poată fi accesate din exterior în special dacă se utilizează un cloud privat, cum este cazul aplicației finale dezvoltate. A doua problemă este legată tot de datele din diverse medii de pe server și se referă la protecția acestor date în situațiile în care apar erori, sau serverele sunt mutate fizic în altă locație. De altfel, o practică în buna asigurare a siguranței datelor o reprezintă mutarea serverelor în diferite locații, de regulă saptămânal. Mutarea serverelor ar trebui să se facă fără a fi necesară reconfigurarea lor după mutare.

Avantaje ale tehnologiei cloud computing exploatate prin aplicația finală dezvoltată:

Clienții – angajații companiei vor putea accesa aplicațiile și datele de oriunde în orice moment. Aceștia ar putea avea acces la sistemul de calcul de tip nor folosind orice computer conectat la Internet.

Datele nu s-ar fi limitat la un hard-disk de pe computerul unui utilizator sau chiar rețeaua internă a unei corporații. Acest lucru ar putea aduce costuri hardware reduse. Sisteme de cloud computing ar reduce nevoia de hardware avansat pe partea de client. Managerii companiilor nu ar trebui să cumpere cel mai rapid computer cu cât mai mult necesar de memorie, deoarece sistemul de cloud va avea grijă de aceste nevoi.

În schimb, se poate utiliza chiar și un terminal de calculator ieftin. Terminalul ar putea include un monitor, dispozitive de intrare, cum ar fi o tastatură și mouse-ul și puterea de procesare suficient pentru a rula middleware-ul necesar pentru conectarea la sistemul de nor.

Nu ar avea nevoie de un hard disk de memorie internă mare pentru a stoca toate informațiile de pe un computer la distanță.

Companiile nu trebuie să cumpere un set de software sau software licențe pentru fiecare angajat.

Serverele și dispozitivele de stocare digitale ocupă spațiu. Unele companii închiriază spațiu fizic la servere pentru a stoca fie și baze de date, deoarece nu au la dispoziție propriul sistem de cloud. Cloud computing oferă acestor companii posibilitatea de stocare a datelor pe hardware-ul altcuiva, eliminând nevoia de spațiu fizic pe front-end.

Corporațiile ar putea economisi bani cu suportul IT.

3.1.1.2. Configurarea serverului de dezvoltare și a mașinii de lucru

Precum s-a evidențiat încă din specificațiile funcționale ale lucrării, scopul principal este cel de realizare a unei interfețe grafice cu utilizatorul care să permită afișarea de statistici și diverse rapoarte privind metricile colectate. Lucrul în cadrul unei companii de profil tehnic a impus respectarea unor cerințe de proiectare specifice portofoliului de produse ale firmei și implicit utilizarea limbajului PHP 5.4 și a unor tehnologii adiacente, ce vor fi descrise mai pe larg în prezentul capitol, în secțiunile ce urmează.

Serverul de dezvoltare pe care aplicația finală s-a proiectat rula pe cloudul privat al companiei și era un server cu drepturi limitate, utilizat în principal pentru testarea aplicațiilor.

Rularea scripturilor scrise în limbajul PHP a presupus instalarea pachetelor adiacente pe mașina de CentOS 5.3, dar și editarea unor fișiere locale de configurare pentru rularea de pe server. Principalele setări făcute au permis utilizarea serverului direct din browser și implicit evitarea de comenzi lungi specifice Linux.

Configurarea mașinii de Linux a presupus configurarea samba pentru a distribui fișierele de lucru în mașina de Windows folosită. Pentru aceasta, s-a editat fișierul de configurare de la calea /etc/samba/smb.conf și s-a adăugat o înregistrare la calea de lucru. Calea de lucru considerată este acolo unde serverul este instalat, dar și locul în care toate fișierele php vor fi de asemenea stocate. Înregistrarea de adăugat în fișierul /sbm.conf va fi precum în figura 3.2.

Figura 3.2 – Editarea fișierului /etc/smb.conf

Ulterior se setează o parolă corespunzătoare serviciului samba prin smbpasswd –a root și se repornește serviciul prin /etc/init.d/smb restart .

Lucrul cu fișierele php se poate face direct din Windows, prin maparea corespunzătoare a locației de pe server unde se găsesc fișierele, pe unul dintre discurile mașinii de Windows. Acest lucru poate fi făcut executând următorii pași:

Cu clic dreapta pe My Computer se selectează Map Network drive

Se alege discul pe care dorim să mapăm (de exemplu W:/)

În fereastra deschisă, se va trece ip-ul mașinii de Linux și numele proiectului precum s-au definit în samba. De exemplu: \\192.168.x.x\[myproject]

Se trec utilizatorul și parola așa cum s-au definit în samba, în fereastra ce s-a deschis și se conectează la server.

Lucrul cu fișierele și rularea acestora se face direct pe serverul de dezvoltare ce lucrează cu tehnologia cloud computing. Fișierele se pot edita direct în mașina de Linux utilizând o conexiune prin putty-openSSH.

3.1.2. ReSTful Web Services

3.1.2.1. Caracteristici

ReST standuri pentru Representational State Transfer. (Acesta este uneori scris "ReST".) Se bazează pe un model client-server, cacheable – și în aproape toate cazurile, protocolul HTTP este utilizat. ReST este un stil de arhitectură pentru proiectarea aplicații în rețea. Ideea este că, mai degrabă decât folosind mecanisme complexe, cum ar fi CORBA, RPC sau SOAP pentru a conecta între mașini, HTTP este mai simplu de folosit pentru a efectua apeluri între mașini. În multe situații, World Wide Web în sine, este bazat pe HTTP, și poate fi privit ca o arhitectură bazată pe ReST.

Aplicațiile ReST folosesc cereri HTTP pentru a posta date (crearea și/sau actualizare), de citire a datelor (de exemplu, fac interogări), și ștergerea datelor. Astfel, ReST utilizează HTTP pentru toate cele patru metode CRUD (Create / Read / Update / Delete).

ReST nu este un "standard". Nu va exista niciodată o recomandare a consorțiului W3C pentru acesta. Una dintre motivațiile principale de alegere a lucrului cu ReST pentru aplicația proiectată este datorat fapului că ReST nu are o formă fixă pentru cererile pe care clienții le trimit. Se pot furniza și construi propriile cereri ReST pentru accesarea de diverse resurse, situate la locații diferite (pe același server).

De asemenea unul dintre avantajele utilizării ReST în întreaga aplicație dezvoltată este acela că interfețele mediilor de colectare a metricilor permit și au deja implementate funcții specifice pentru accesarea resurselor, fapt ce a facilitat atât colectarea corectă a resurselor cu metricile, cât și reducerea timpului în care metricile au fost colectate.

Deși ReST furnizează metodele standard de CRUD, în aplicația proiectată interesul s-a îndreptat doar asupra metodelor GET și PUT, ținând cont că principala funcționalitate implementată prin ReST a fost cea de colectare a metricilor.

O prezentare teoretică a Representational State Transfer ar porni de la o definiție ușor pragmatică a REST: Set de principii care definesc modul în care se presupune că standardele Web, cum ar fi HTTP și URI-uri, pot fi folosite. Dacă se respectă modul de accesare al resurselor și implicit principiile cheie ale REST, rezultatul va fi un sistem care exploatează arhitectura Web-ului în avantajul clientului.

Pe scurt, cele cinci principii-cheie sunt:

Dă fiecărui "lucru" o identitate – prin asocierea de URI

Unește lucrurile împreună – rezultatele reprezintă o resursă sau o colecție de resurse

Utilizează metode standard – de regulă, și de altfel și în aplicația proiectată, s-au utilizat noțiuni de programare orientată pe obiecte, iar metodele de accesarea ale resurselor sunt construite în funcții de clasă cu denumiri standarde, corelate cu scopul lor. (exemplu: metoda getX(){construcție cerere tip GET} etc. ).

Resursele au mai multe reprezentări – dintre cele disponibile cu care s-a lucrat în aplicație: JSON, XML, Array etc.

Comunicația e stateless – apartidă, insemnând că la cereri multiple, serverul nu trebuie să fie conștient de starea clientului, ci trebuie să furnizeze rezultate corespunzătoare cererii primite, neinteresându-ne acțiunile trecute sau cele viitoare.

3.1.2.2. Resurse și URI-uri

Standardul ReST provine de la denumirea din engleză pentru Representational State Transfer. Pentru a înțelege ce înseamnă resursele și identificarea acestora prin identificatori de resurse unic, se ia în considerare o aplicație socială web-based simplă.

Un utilizator vizitează pagina de start a aplicației prin tastarea adresei în browser.

Browser-ul depune o cerere HTTP către server.

Serverul răspunde cu un document HTML care conține unele link-uri și forme.

În funcție de tipul de utilizator, informația este structurată într-o formă și se prezintă forma drept răspuns.

Browser-ul prezintă o cerere HTTP către server.

Serverul procesează cererea și răspunde cu o altă pagină. Acest ciclu continuă până când utilizatorul se oprește din navigare.

Cu excepția câtorva cazuri, cele mai multe site-uri și aplicații web-based urmează același model.

Ceea ce utilizatorul tipărește în browser de la începutul interacțiunii anterioare este un Uniform Resource Identifier (URI). Un alt nume frecvent utilizat pentru aceasta este un Uniform Resource Locator (URL). URI este un termen mult mai generalizat pe care îl putem folosi pentru a ne referi la o locație (URL) sau un nume. Un URI este un identificator de resursă. În cele mai multe cazuri, URI-urile sunt opace pentru clienți.

La rândul său, o resursă este ceva ce poate fi identificată printr-un URI. În prima etapă a fluxului precedent, URI introdus de utilizator este adresa unei resurse care corespunde la o pagina web. Într-un site tipic static, fiecare pagină web este o resursă.
În a patra etapă, partea de server care actualizează statutul utilizatorului este o altă resursă.

Documentul HTML pe care serverul îl returnează către client este o reprezentare a resursei. O reprezentare este o încapsulare a informațiilor de resurse, codificate folosind un format, cum ar fi XML, JSON, sau HTML. O resursă poate avea unul sau mai multe reprezentări. Cele mai multe site-uri web și aplicații folosesc de obicei format HTML cu text / HTML ca tip de suport.

Clienții folosesc Hypertext Transfer Protocol (HTTP) să înainteze cereri pentru resurse și a obține răspunsuri. În prima etapă, clientul depune o cerere de preluare a resursei de tip GET pentru a prelua un document HTML. În a patra etapă, clientul depune o cerere POST pentru a actualiza starea de utilizator. Aceste două metode sunt parte a interfeței uniforme a HTTP-lui. Utilizarea unei interfețe uniforme face cererea și răspunsurile vizibile. În plus față de aceste două metode, această interfață este formată din alte metode cum ar fi opțiunile, HEAD, PUT, DELETE, TRACE, și Connect.

HTTP este un protocol între clienți și resurse. În acest protocol, cu excepția cazului când veți defini noi metode pentru a extinde HTTP, lista metodelor și semantica lor este fixă. Aceste semantică este independentă de resurse. Acesta este motivul pentru HTTP este numit o interfață uniformă. La servicii în care apelurile de procedură sunt la distanță (RPC) sau servicii web SOAP, semantica fiecărei cereri are forme specifice.

Iată câteva exemple de URI-uri care să ilustreze modul în care putem accesa una sau mai multe resurse aflate pe un server.

URI-urile identifică în mod evident "elemente" individuale. La început, lucrurile identificate par a fi diferite – la urma urmei, URI-urile nu identifică un lucru, ci o colecție de lucruri. Aceste colecții sunt de fapt resurse, care precum se observă în modul de construcție a URI-urilor, sunt caracterizate de câte un element de identificare. Beneficiile de a avea un sistem unic de denumire, la nivel global unificat se aplică atât pentru utilizarea Web în browser și în comunicația de la mașină-la-mașină.

Detalii referitoare la modul de reprezentare a datelor se vor discuta în subcapitolul 3.2 – Medii de colectare, pentru fiecare din mediile de colectare ale metricilor în parte.

Figura 3.3 – Arhitectura serviciului REST

3.1.2.3. Metode CRUD ReST

Precum am evidențiat în secțiunea anterioară a prezentului capitol, ReST furnizează metode CRUD clasice pentru accesarea resurselor. HTTP este un protocol la nivel de aplicație, care definește operațiunile de transfer drept reprezentări de resurse, între clienți și servere. În acest protocol, metode cum ar fi GET, POST, PUT și DELETE sunt operațiuni asupra resurselor. Acest protocol elimină necesitatea de a inventa metode specifice, cum ar fi la modul general – exemplu: createOrder, getStatus, updateStatus, etc.; Protocolul HTTP permite să puteți beneficia de infrastructura HTTP în mare măsură în care se poate utiliza HTTP ca protocol la nivel de aplicație. Cu toate acestea, o serie de tehnici, inclusiv SOAP și unele cadre web Ajax folosesc HTTP ca protocol de mesaje de transport.

Ceea ce ne interesează din punct de vedere al aplicării metodelor sunt siguranța și idempotența resurselor. Siguranța și idempotența sunt garanții pe care un server trebuie să le furnizeze clienților, la punerea în aplicare a anumitor metode.

3.1.2.3.1. Siguranța funcțiilor

Siguranța unei resurse rezidă din faptul că serverul furnizează același răspuns în condiții concurente, iar resursele nu pot fi distruse prin diverse metode, la trimiterea unei cereri către server.

3.1.2.3.2. Idempotența

Idempotența unei metode semnifică faptul că cererea are același rezultat, chiar dacă resursele sunt înscrise mai multe ori, sau doar o dată, cu aceiași metodă sau cu metode diferite.

În accepțiune universală metodele de CRUD ReST se folosesc după descrierea și proprietățile lor, detaliate în tabelul 3.1 – Metode ReST.

3.1.3. PHP 5.4

PHP (acronim pentru: PHP Hypertext Preprocessor), este un limbaj server-side de scripting încorporat. Acest lucru înseamnă că acționează într-un document HTML pentru a conferi o capacitate de generare de conținut pe bază de cerere de la client. Puteți converti site-uri într-o aplicație web, evitând situația în care site-urile sunt doar o colecție de pagini statice cu informații care nu pot fi actualizate chiar atât de des. În prezent există atât de multe alte opțiuni de creare a unei aplicații web, cum ar fi ASP, Cold Fusion, Perl, Java, Python etc. însă avantajul PHP asupra tuturor acestor tehnologii menționate derivă din simplitatea, aproape naturală în folosința bazelor de date și independența de platformă.

PHP funcționează într-un mod similar cu JSP și ASP: secțiunile script sunt incluse între tagurile <?php ..? > și sunt încorporate într-o pagină HTML. Aceste scripturi sunt executate pe server înainte ca pagina să fie trimisă la browser, astfel încât nu există nicio problemă de compatibilitate a browser-ului pentru paginile PHP. Spre deosebire de ASP, totuși, PHP este independent de platformă, și există versiuni pentru diferite versiuni de Windows, Unix și Linux, și pentru un număr mare de servere de web, inclusiv Apache. Factorul decisiv este faptul că este gratuit și open-source.

3.1.3.1. Utilizarea limbajului în aplicație

Pentru aplicația web dezvoltată s-a folosit versiunea 5.4 a limbajului PHP, care față de versiunea anterioară aduce câteva funcționalități în plus, fără a altera funcțiile cunoscute și fără a revoluționa în mod trivial limbajul cunoscut. Utilitatea limbajului PHP într-o astfel de aplicație, care să colecteze din diverse medii de colectare date și să le furnizeze clienților ulterior pentru stocare și analiză, este dată de caracteristicile marcate și prezentate mai jos.

Colectarea datelor

Primul pas în proiectarea unei aplicații web, de obicei, dar nu întotdeauna, presupune colectarea de orice fel de date de la utilizator. Acest lucru este de obicei realizat cu un formular HTML. Utilizatorul furnizează tipuri de informații sub formă câmpuri, și apasă un buton de trimitere. Browser-ul formatează aceste tipuri de date și trimite o cerere la serverul de web.

Pentru ca serverul de web să "intre în acțiune" și să execute un program de server, browser-ul web trebuie să facă o copie de rezervă a datelor de la utilizator și emite o solicitare HTTP la serverul de web. O cerere HTTP constă în URL-ul pentru pagina respectivă sau la un script pe care utilizatorul dorește să îl acceseze, prin datele din formular, precum și orice antet de informații suplimentare (informații browser, lungimea și tipul cererii). O cerere este de obicei generată de browser-ul web și fiecare cerere trebuie să precizeze ce metodă va fi folosită de cererea trimisă. Cele mai frecvent utilizate metode HTTP sunt HEAD, GET, POST. De trimiterea cererilor și furnizarea răspunsurilor către clienți este responsabil serviciul web ReST, care a fost descris în prezentul capitol al lucrării. Deoarece nu se dorește specificarea direct în aplicație a unor parametri prin care să manipulăm interfața aplicației, în locul formularelor web, se va substitui pe cât posibil absența lor cu fișiere de configurare cu structură cunoscută, care să facă același lucru – să preia datele și să își formuleze cererile ReST la Api-urile bibliotecilor colectoare, pentru a furniza ulterior rezultatele dorite.

Definirea funcțiilor și variabilelor

În aplicația web proiectată se utilizează funcții definite de dezvoltator cu denumire sugestive, în concordanță cu scopul fiecăreia dintre funcții. Variabilele folosite în interiorul claselor sunt de regulă globale, însă se folosesc toate tipurile de declarații ale variabilelor, după cum urmează: variabilele de clasă sunt declarate global, variabilele de funcții local și adesea modifică atribute ale clasei utilizate, în mod controlat, iar pentru instanțele de șablon Singleton se folosesc declarații statice.

Vectori

Vectorii asociativi sunt definiți în PHP sub forma de $a = array ( $index1 => $valoare1, …). Se preferă reținerea metricilor colectate în variabile de tipul vector asociativ, deoarece permit manipularea lor cu ușurință, datorită numeroaselor funcțiile ale limbajului. PHP 5.4 permite definirea vectorilor prin $array = [ $index => valoare], fără a mai utiliza cuvântul rezervat array înaintea declarării perechilor de indecși și valori.

Cu ajutorul funcțiilor limbajului, sunt implementate sortări ale variabilelor de tip vector, navigarea în interiorul acestora și retragerea de valori cu funcții next(), reset(), end(), dar și stocarea în baza de date de care este responsabilă modulul de stocare al metricilor, se realizează mai ușor cu ajutorul vectorilor, în funcție de indecșii acestora și câmpurile bazei de date. De asemenea, răspunsul unei cereri ReST la clienții specifici bibliotecilor colectoare ale aplicației, poate fi ușor transformat din json în vector asociativ și invers prin funcții specifice limbajului json_encode(vector), ce va furniza o reprezentare json și json_decode(json), ce va furniza o reprezentare tip vector asociativ a datelor.

OOP – Programarea orientată pe obiecte

Programarea orientată pe obiecte permite programatorilor să se refere la variabile legate și care funcționează ca entități singulare numite obiecte sau instanțe. OOP-ul din PHP include trei principii de bază din programarea orientată pe obiecte, care se regăsesc în toate limbajele orientate pe obiecte și au aceiași semnificație.

Concepte bază ale programării orientate pe obiecte utilizate și în aplicația web proiectată sunt: ❑ abstractizare

❑ încapsulare

❑ moștenire.

O clasă este un șablon care definește variabile și funcții ale unui obiect. Variabilele de clasă sunt denumite proprietăți. Funcțiile de clasă sunt denumite metode. Metodele clasei și proprietățile sunt referite folosind operatorul ->, spre deosebire de Java sau C# în care referirea la o proprietate sau o metodă a unei instanțe se facea prin operatorul `.` (punct). Constructorii sunt metode speciale, care sunt executate ori de câte ori este creată o instanță. Constructorii în php sunt definiți prin cuvântul cheie __construct(), față de Java și C# în care constructorii erau creați prin construirea unei metode de aceeași nume ca și clasa. O clasă poate moșteni proprietăți și metode la o clasă declarată anterior, cu ajutorul cuvântului cheie `extends`. Această clasă nou creată este cunoscută sub numele de clasă copil.

Noțiunile folosite în aplicația prezentată de programare orientată pe obiecte sunt similare limbajelor Java, C# etc. și nu voi mai insista asupra lor.

Ceea ce intervine nou în materie de OOP față de conceptele prezentate, sunt șabloanele de proiectare software de tipul Singleton și Factory Pattern.

Design patterns (Șabloane de proiectare)

Generarea de colectori similari și utilizarea unui tipar de proiectare software a aplicației, de la modelarea UML până la transpunerea în cod a diagramelor de clasă a presupus și folosirea unor șabloane de proiectare care fac accesibile metode de creare și ciclu de viață al obiectelor, având grijă și de integrarea modulelor, dar și de ocuparea memoriei cu variabile de clasă.

În implementare s-au utilizat următoarele șabloane de proiectare, după cum urmează:

Metoda Factory Pattern, aplică principiul de polimorfism în generarea de obiecte de tipul colector.

Metoda Factory combinată cu modelul Abstract Factory s-a folosit pentru a genera clase creator care instanțiază seturi de obiecte legate – a se vederea AbstractCollector.php.

Metoda Singleton este folosită pentru a genera o singură instanță de tipul unei clase. S-a folosit pentru mai toți colectorii, știind că este indicat ca modulul de colectare al metricilor să permită colectarea de la o singură instanță de tipul Api al mediului de colectare respectiv.

Alte caracteristici ale limbajului folosite în aplicație sunt, după cum urmează:

Manipularea șirurilor de caractere și citirea din fișiere prin funcții specifice ale limbajului;

Lucrul cu directoare și fișiere imbricate prin directive de procesare specifice.

3.1.4. MySQL

3.1.4.1. Caracteristici

MySql este un sistem de management al bazelor de date relaționale. O bază de date este o colecție structurată de date. Pentru a adăuga, accesa și a permite accesul la datele stocate într-o bază de date aflată în calculatorul clientului sau pe un server, este necesar să fie implementat un sistem de management al bazei de date, precum MySql server. O bază de date relațională stochează datele în tabele separate, mai degrabă, decât să pună datele la comun într-o singură tabelă. Ar fi fost și cazul aplicației dezvoltate, însă din cauza faptului că metricile trebuie colectate din toate mediile odată, iar funcția de Insert în baza de date se efectuează tot o singură dată pentru o întreagă colecție de date, s-a preferat utilizarea unei baze de date non-relațională, cu o singură tabelă.

SQL provine de la limbaj stucturat de cereri (în engleză, Structured Query Language) și este definit drept un limbaj de încredere, rapid și ușor de folosit. Într-un mediu de dezvoltare constant, MySql Server de astăzi, oferă un set de funcții bogat ca și complexitate și ajutător utilizatorului. Viteza de conectare la baza de date și mecanismul de securitate cu care vine instalat în cazul bazei de date pe un server sau pe un server local, fac din MySql Server un candidat potrivit pentru accesarea bazelor de date. MySql este open-source (disponibil gratis pe internet) lucru ce constituie un nou avantaj. MySql Server lucrează cu un mecanism client-server, care este constituit din server multi-threading ce suportă diferite backend-uri (mecanisme descrise în tehnologia cloud cu care s-a lucrat în aplicație).

Printre alte avantaje ale alegerii tehnologiei MySql pentru baza de date implementată se mai pot enumera: scalabilitatea și flexibilitatea, performanța înaltă, disponibilitate înaltă, suport pentru tranzacții și cereri, protecția datelor, mecanism de management, open-source. Unul dintre motivele de alegere ale tehnologiei MySql implementate prin aplicație, pe lângă respectarea cerințelor funcționale ale lucrării derivă din modul de interacțiune din PHP 5.4 cu MySql astfel încât datele să poată fi stocate, interogate și afișate. În figura 3.6. se prezintă modul în care MySql interacționează cu PHP în vederea operațiilor menționate.

Figura 3.6. – Interacțiunea PHP cu MySql

3.1.5. HTML 5.0, JQuery, Javascript și CSS

3.1.5.1.HTML 5.0

HTML5 este cea mai recentă evoluție a standardului care definește HTML-ul. Termenul reprezintă două concepte diferite. Pe de o parte, este o nouă versiune a limbajului HTML, cu noi elemente, atribute, și comportamente, dar și un set mai mare de tehnologii, care permite dezvoltarea de aplicații mai diversificate și mai puternice.

Proiectat pentru a fi utilizat de către toți dezvoltatorii web, HTML5 pune la dispoziție o documentație destul de completă despre numeroase resurse ale tehnologiilor sale, clasificate în mai multe grupuri, pe baza funcției lor.

Dintre avantajele HTML 5, utilizate și în aplicația web proiectată, aș putea menționa:

Semantica: permițând descrierea personalizată de conținut.

Conectivitate: permițând comunicarea cu serverul în moduri noi și inovatoare.

Deconectare și Stocare: permite paginilor web să stocheze date pe partea de client, la nivel local și să opereze operații de deconectare mai eficiente.

Multimedia: permit integrarea de video și audio și ale resurse multimedia.

Grafica 2D/3D și Efecte: permit o gamă mult mai variată de opțiuni de prezentare.

Performanță și Integrare: furnizează o optimizare de viteză mai mare și o mai bună utilizare a hardware-ul computerului.

Dispozitiv de acces: permite utilizarea diferitelor dispozitive de intrare și de ieșire.

Styling: autorii au permisă scrierea de teme mai sofisticate.

3.1.5.2. Jquery

JQuery este un tip de bibliotecă Javascript (alaături de Prototype, Ext Core și moo.fx, etc.), concepută pentru a face documentele Javascript mai accesibile și mai ușor de utilizat. JQuery simplifică sintaxa Javascript și relativ oferă o mai bună interacțiune între JavaScript și alte limbaje de dezvoltare web. JQuery oferă acces ușor la modelul DOM și permite crearea de animații, widget-uri și segmente web dinamice (AJAX) mai ușor, în comparație cu utilizarea de limbaj Javascript singur. JQuery este, de asemenea, cea mai populară bibliotecă JavaScript, utilizată în prezent de zeci de site-uri foarte populare.

JQuery este extrem de popular, deoarece permite realizarea unor serii de funcții, simple,dar și complexe, folosind o cantitate minimă de cod. JQuery este utilizat de obicei pentru a pune în aplicare orice element din modelul DOM într-un mod mai simplu și, de asemenea, pentru funcționalitate Ajax. Chiar și funcții complexe evidente, cum ar fi blocuri de text expandat (precum s-a utilizat și în panoul central al aplicației proiectate), poate fi realizat cu doar câteva linii de cod, folosind JQuery.

JQuery este extrem de versatil și compatibil și funcționează pe toate cele mai recente versiuni de browsere populare. Dar, de asemenea, este posibil ca o sursă să se încarce făcându-se referire la o locație online pe serverele Google. O altă caracteristică remarcabilă a JQuery este capacitatea de a implementa funcționalitatea AJAX. Ajax permite realizarea mai multor funcții într-un mod elegant, fără a părăsi sau de a reîncărca pagina. Acest lucru permite un mediu de pagini web dinamice ca sarcini care pot fi rulate pe pagină, în fundal, fără o reîncărcare a paginii dorită. Astăzi, JQuery este utilizat pe scară largă în mai multe site-uri web, deoarece este o alternativă rapidă și elegantă și permite implementarea funcționalităților Ajax. Anumite caracteristici extrem de personalizate cerute de un dezvoltator web pot face ca JQuery să fie insuficient în realizarea unor pagini cu anumite specificații, dar fiind un limbaj de nivel foarte înalt, open source, comunitatea din spatele bibliotecii este puternică și, astfel, este necesar ca uneori o simplă căutare pe internet să rezolve problemele legate de cerințe.

3.1.5.3. Javascript

JavaScript este unul dintre limbajele de programare relativ simple, constând, de obicei, din bucăți mici de cod care fac paginile web mai interactive pentru utilizatori. Astfel, utilizatorii au nevoie de un browser web care acceptă JavaScript și, de asemenea, trebuie să fie activat javascript în browser-ul utilizatorului. Astăzi, aproape fiecare site folosește fragmente de JavaScript pentru a încorpora anumite caracteristici pentru webmaster și / sau utilizatorul site-ului.

În timp ce Javascript precum sugerează și numele, nu are nicio conexiune la popularul limbaj Java, fișierele Javascript sunt complet diferite de limbajele de programare. La rândul lor, aceste fișiere sunt folosite pentru scopuri diferite și cuprind o sintaxă cu totul diferită.

Inițial cunoscut sub numele de LiveScript, limbajul a fost ulterior intitulat ca Javascript printr-un acord propus de Netscape (dezvoltatorii de Javascript) de Sun Microsystems ca o cascadorie de branding.

Microsoft a luat pe Javascript și a dezvoltat o sintaxă similară cu Javascript cunoscută sub numele de JScript care să funcționeze cu Internet Explorer. În timp ce ideea inițială a fost de a dezvolta o versiune identică a Javascript pentru utilizarea de browsere populare Internet Explorer, limbajele au fost oarecum diferite.

Unele dintre cele mai frecvente utilizări ale JavaScript pe site-uri sunt: pentru a personaliza aspectele grafice ale unei pagini web și pentru a crea jocuri cu funcționalități de bază. Mai multe servicii populare utilizează Javascript pentru a gestiona o mare parte din cererile lor de web.

În aplicația web dezvoltată, bucățile de cod Javascript sunt utilizate pentru a anima conținutul și a adăuga efecte grafice vizuale conținutului, în colaborare cu bucăți de cod HTML 5, PHP și biblioteca Jquery. O parte din fișierele Javascript pentru funcțiile folosite sunt încărcate de la locații diferite, furnizate de google online și fără cost.

3.1.5.4. CSS

CSS este un format de fișier text simplu, utilizat pentru formatarea conținutului de pe paginile web. CSS vine de la Cascading Style Sheet și este folosit de paginile web pentru a păstra informațiile în formatul de afișare corectă. Fișiere CSS pot ajuta la definirea fontului, dimensiunea, culoarea, spațierea, marginile și amplasarea informațiilor HTML pe o pagină web, și pot fi de asemenea folosite pentru a crea un aspect continuu de-a lungul mai multor pagini ale unui site web.

Fișiere CSS sunt structurate de programatori pe site-uri de întrebări și soluții software, pentru a furniza soluții programatorilor începători. Fișierele CSS permit unui singur fișier să conțină toate setările de afișare, și ajută la simplificarea HTML-urilor, permițând proiectarea multor aspecte de pagină.

În aplicația proiectată fișierele CSS folosite cuprind reguli de formatare ale elementelor de pe pagini și ajută la păstrarea unui format comun pentru elemente cu identificator comun, cât și așezarea în pagină și la echilibrarea conținuturilor.

3.2. Unelte utilizate

3.2.1. Jira

Jira este un sistem de monitorizare a bugurilor, îmbunătățirilor etc. pentru dezvoltatorii și inginerii în asigurarea calității. Fiind instalat pe serverul de dezvoltare, utilizarea sa se face direct din browser, prin simplu apel al paginii web interne a companiei: http://jira.4psa.me.

Metricile extrase din acest mediu de colectare până la urmă țin de defecte asupra produselor existente, sesizate și raportate în această bază de date comună.

Accesul la JIRA putea fi făcut de către fiecare utilizator în parte de pe propriul calculator, nefiind necesară instalarea uneltei pe fiecare dintre calculatoarele angajaților, acest lucru constituind un avantaj deja evidențiat al utilizării tehnologiei cloud computing. Colectarea metricilor dorite s-a putut face cu ușurință. Dezvoltatorii produsului Jira, punând la dispoziție o documentație vastă privind structura URI-urilor ReST pentru accesarea resurselor, precum și informații de configurare a uneltei folosite. Pentru următoarele referințe privind colectarea metricilor, voi folosi denumirea interfeței uneltei de Jira ReST Api.

Documentația, la fel ca și unealta în sine sunt open-source ,versiuni ale Jira fiind disponibile pe baza unui cont utilizator de companie, iar trecerea la o versiune superioară a produsului presupune reinstalarea versiunii noi pe server, și reînnoirea licenței programului. Din punct de vedere al accesării resurselor, documentația versiunii 5.0 cu care s-a lucrat în aplicația web dezvoltată este disponibilă pe site-ul: https:// developer.atlassian.com/static/rest/jira/5.0.html.

API-ul ReST JIRA oferă acces la o serie de resurse care sunt accesibile prin intermediul URL-uri normale. Răspunsul lui JIRA este în formatul JSON. Deoarece cererile ReST sunt construite pe aceleași tehnologii ca web-ul în sine, în general, nu aveți nevoie de biblioteci complicate să-l folosească. De fapt, puteți începe explorarea JIRA ReST API-ului pur și simplu prin intermediul browser-ului web.

Figura 3.7 – Captură Jira API

API-ul ReST JIRA oferă acces la resurse (persoane de date) prin căi URI. Pentru a utiliza un API REST, aplicația va face o cerere HTTP și va analiza răspunsul. JIRA API-ul ReST folosește JSON ca format de comunicare, și metodele standard, cum ar fi HTTP GET, PUT, POST și DELETE. URI-urile JIRA ReST API pentru accesarea resurselor vor avea următoarea structură: http://host:port/context/rest/api-name/api-version/resource-name .

În prezent, există două nume disponibile API, care vor fi discutate mai jos: auth – pentru operațiunile legate de autentificare și API – pentru orice altceva. Pentru scopul lucrării s-a lucrat cu versiunea API. Versiunea curentă API este 2. Cu toate acestea există o versiune simbolică, numită ”latest”. De aceea, în colectarea metricilor cu ajutorul metodelor HTTP și cereri REST, o cerere poate fi formulată astfel: http://host:port/context/rest/api/latest/resource-name .

Metricile colectate din acest mediu vor fi discutate în prezentarea aplicației de la capitolul următor al prezentei lucrări.

3.2.2. Crucible

Crucible, asemeni Jira este dezvoltat de Atlassian Company și reprezintă o soluție de revizuire a codului pentru echipele de dezvoltatori. Această unealtă permite echipelor de dezvoltare să identifice defecte majore, pentru a îmbunătăți arhitectura codului, sau a discuta îmbunătățirile dorite, fără a fi nevoie de întâlniri particulare.

Interfața ReST FishEye / Crucible oferă o modalitate simplă de a face cereri HTTP. FishEye/Crucible ReST API oferă accesul la resurse (persoane de date) prin căi URI. Pentru a utiliza un API REST, cererea clientului va face o cerere HTTP și va analiza răspunsul. În mod implicit, formatul de răspuns este XML. Însă, se poate solicita formatul JSON în loc de XML.

Deoarece API-ul ReST se bazează pe standarde deschise, se poate folosi orice limbaj de dezvoltare web pentru a accesa API-ul. Un exemplu de utilizare penru colectarea unor date prin cereri HTTP din Crucible, ar fi un gadget care oferă informații cu privire la apariția unei schimbări recente la un cod sursă, sau listele de comentarii deschise. Crucible ReST API-uri oferă următoarele capacități:

Răsfoirea modificărilor la codul sursă.

Extragerea unei liste de proiecte din Crucible.

Preluarea informațiilor despre un utilizator sau cel ce a introdus codul.

Căutarea pe baza unor criterii personalizate.

Crearea sau manipularea comentariilor codului.

URI-urile Crucible ReST API pentru accesul la o resursă vor avea următoarea structură: http://host:port/webcontext/rest-service/resource-name-v1.

Figura 3.8 – Captură Crucible API

Astfel, un exemplu de format JSON întors cerere ReST pentru extragerea tuturor comentariilor din Crucible s-ar putea formula ca: / rest-service/search-v1/reviews termen = <value> & maxReturn = <value>? , iar o reprezentare disponibilă JSON pentru cererea depusă are forma:

{
  "ReviewData": [{
    "ProectCaracteristiciPlan": "CR-FOO",
    "Nume": "Exemplu revizuire.",
    "Description": "Descrierea sau o declarație de obiective pentru exemplul de revizuire.",
    "Autor": {
      "Username": "Joe",
      "DisplayName": "Joe Krustofski",
      "AvatarUrl": "http://foo.com/avatar"  }, ….

3.2.3. Active Campaign

Active Campaign permite comunicarea oficială cu clienții și partenerii companiei prin scrisori de informare.

Figura 3.9. – Captură ActiveCampaign API

Active Campaign mai este numit și serviciul de marketing prin email-uri, și permite utilizatorilor să-și transmită mesaje sub formă de campanii sau scrisori de informare și, în special, grupurilor definite de clienți.

Api-ul acestei unelte este recomandat pentru orice funcționalitate adițională interfeței principale a utilizatorului. Această unealtă oferă o listă de metode accesibile Api-ului, împreună cu descrierile detaliate, aferente oricărui parametru, cât și exemple cu cod actual.

Active Campaign Api furnizează tutoriale și exemple. Api-ul ReST al acestei unelte este implementat de către furnizorii acestui mediu de lucru și necesită autentificare cu un cont valid în interiorul site-ului, sau prin intermediul unui URL valid la api-ul Active Campaign. Cerințele minime de conectare includ: deținerea unui cont valid, fie chiar și trial (inactivat, perioadă de testare), familiaritatea cu concepte de programare și practici de programare și abilitatea de a trimite cereri HTTP la server.

Pentru a obține parametrul Api Url și cheia necesare autentificării la mediul de colectare Active Campaign, trebuie să accesați secțiunea Admin, Your Settings și secțiunea API.

Api-ul Active Campaign este bazat pe serviciul web ReST și furnizează metode variate de cereri HTTP la server, în vederea obținerii informațiilor din interfața api-ului. O listă de cereri care pot fi făcute prin metode ReST și metricile de care acestea depinde, sunt disponibile pe site-ul official activecampaign.

3.2.3. Get Satisfaction

Este platforma de relații cu clienții a companiei 4PSA. Prin intermediul său se asigură un feedback constant de la clienți asupra produselor deja aflate în producție. Get Satisfaction este platforma prin care nu doar clienții sunt conectați cu compania, ci clienți comuni companiei pot împărtăși idei, pot pune întrebări referitoare la produsele companiei, pot raporta un defect și își pot exprima mulțumirile sau nemulțumirile față de serviciile companiei.

Figura 3.10. – Captură GetSatisfaction API

Mediul Get Satisfaction a fost preferat în locul blog-ului intern al companiei și a devenit în scurt timp platforma comunității ”4psa”. Datele din interiorul Api-ul acestei unelte sunt structurate sub forma unei colecții de resurse, în care resursele sunt reprezentate de companii, persoane, subiecte de discuție și produse. Pentru fiecare dintre aceste resurse, trebuie să putem accesa metrici relevante, lucru exploatat prin aplicație web dezvoltată. Îmbunătățiri și actualizări recente ale Api-ului ReST pentru Get Satisfaction sunt prezentate pe un site dedicat.

3.2.4. Google Analytics

Google Analytics API pus la dispoziție de Google, permite vizualizarea de grafice după diverse metrici precizate, pentru diverse site-uri urmărite.

Figura 3.11. – Captură Google Analytics API

Platforma Google Analytics este furnizată de Google ca și serviciu ce permite măsurarea de interacțiuni între utilizatori, în interiorul unui site urmărit, având în vedere accesările de pe diferite medii și dispozitive. Platforma oferă toate resursele necesare colectării, stocării, procesării și raportării asupra acestor interacțiuni.

Google Analytics oferă o simplă și puternică interfață Api prin intermediul căreia se pot extrage rapoarte cu datele din Google Analytics. Sarcinile de raportare a datelor și de extragere a acestora se fac în mod automat direct din interfața serviciului Google Analytics. Api-ul platformei de la Google, cuprinde două subramuri, anume Core Reporting Api și Management Api. În aplicație s-au utilizat cereri la acest serviciu din ambele subramuri, însă cu precădere din secțiunea de Core Reporting Api, ce permite accesarea de metrici și dimensiuni predefinite, standard.

Structura cererilor ReST la Google Analytics, se bazează pe autentificarea cu un cont de email valid și pe id-ul de utilizator ce poate fi obținut dintr-un tool online, denumit Query Explorer, în care este generat automat, după permisiunea accesului la contul de Google Analytics asociat. Nu este așadar necesar doar un cont de mail valid, ci și activarea serviciului Analytics pe acel cont. Accesarea interfeței web sau a Api-ului Google Analytics se face la adresa http://analytics.google.com. Fiecare interogare la acest Api, utilizând serviciul ReST, deziderent al aplicației proiectate, se face prin specificarea id-ului de utilizator, prin autentificarea cu contul de email asociat, prin precizarea unui interval de raportare, sub formă de date de început și sfârșit și prin precizarea a cel puțin unei metrici. Se pot aplica filtre, dimensiuni, și segmente asupra datelor extrase, ori în același tool online Query Explorer, ori prin intermediul resurselor puse la dispoziție de serviciul web Rest, câteva exemple de cereri și structura cererilor, fiind accesibile online utilizatorului.

Capitolul 4 – PROIECTAREA APLICAȚIEI

Analiza specificațiilor

Automatizarea colectării, stocării și analizei metricilor de colecție în cadrul unor organizații presupune retragerea metricilor specificate din diverse framework-uri cu care organizația 4PSA lucrează în termenii programării orientate pe obiecte cu ajutorul limbajului PHP 5.4, îmbinându-le cu tehnologia cloud computing.

Pentru realizarea obiectivelor propuse prin întreaga aplicație web ce reprezintă de astfel, scopul final al lucrării prezente, se vor parcurge etapele dezvoltării software prezentate și se vor modela diagrame UML de clase pentru fiecare modul independent al aplicației. Integrarea modulelor sa va face odată cu testarea unitară a fiecărui modul, concomitent cu asigurarea mentenantibilității aplicației finale.

Pentru a trece la detalierea modelării în ansamblu a aplicației finale – subcapitolul 4.2 al prezentei lucrări, este necesar să revenim asupra specificațiilor funcționale din capitolul introductiv, formulate astfel: În cadrul organizațiilor se definesc diferite metrici de performanță pentru grupuri de lucru și persoane individuale. Aceste metrici sunt păstrate în diverse locații și utilizate ulterior în cadrul companiilor în direcții precum: bug tracking, task distribution etc. Se dorește dezvoltarea unei aplicații web care să permită specificarea metricilor cheie pe baza cărora se extrag datele, cât și a modulelor de analiză după diverse criterii de prelucrare.

Prin analiza specificațiilor definite se observă clar direcțiile de lucru în proiectarea aplicației web finale, acestea vizând cuvintele cheie cu care lucrarea operează și anume: metrici de colecție, medii de colecție, colectare, stocare și analiză a metricilor extrase după criterii definite. Fiecare dintre cuvintele cheie pe baza cărora specificațiile sunt construite, au fost explicate în capitolul 3 al lucrării și vor fi reluate cu explicații adiționale atât pentru fiecare modul în parte, cât și în prezentarea arhitecturii generale a aplicației.

Un rezumat a ceea ce s-a implementat în aplicația web finală se poate formula, pe baza cerințelor funcționale, după cum urmează:

Aplicația permite afișarea de rapoarte atât pentru fiecare mediu de colectare în parte, cât și statistici detaliate.

Datele sunt dinamice, în sensul în care o modificare a parametrilor într-un mediu de colectare este imediat sesizată în interfață, în momentul rulării unui modul de control, responsabil cu colectarea și stocarea datelor.

Utilizatorul nu trebuie să fie conștient de ceea ce se află în spatele aplicației și nu poate aduce modificări de niciun fel aplicației web proiectate.

4.2. Modelarea software a aplicației cu ajutorul UML

Pentru a trece la modelarea software a aplicației și la prezentarea soluției de implementare a interfeței web, sunt necesare câteva noțiuni teoretice, punctuale despre UML. Astfel, Unified Modelling Language sau prescurtat UML, este un limbaj ce permite construirea de aplicații software pornind de la specificații funcționale și producând diagrame cât mai explicite cu ceea ce se întâmplă în aplicație.

În cadrul organizațiilor de profil IT, UML a devenit un instrument de lucru nu doar interesant, cât și foarte utilizat, în special pentru faptul că o modelare vizuală a elementelor ajută la obținerea unei imagini de ansamblu mult mai profundă decât o pot exprima uneori niște cerințe. UML ajută așadar la modelarea în domeniul software, la realizarea documentelor de specificații și la modul general, asigură o comunicare mai bună între inginerii proiectanți ce participă la același proiect.

În domeniul ingineriei software există două direcții principale din punct de vedere al căruia un sistem proiectat poate fi reprezentat sau modelat: modelarea comportamentală și modelarea structurală. În ”Automatizarea colectării, stocării și analizei metricilor de colecție din cadrul unei organizații”, s-a folosit o modelare structurală a fiecărui modul independent al aplicației și s-au implementat diagrame de clase cu relațiile asociate între acestea. Metricile colectate sunt sub formă de obiecte, fapt ce a favorizat alegerea unei modelări cu diagrame de clasă, în sensul unei programări orientate pe obiecte.

Arhitectura generală a aplicației

Deoarece cerințele funcționale și detaliile implementării aplicației au fost deja formulate, este relativ ușor să definim în sensul modelării software, un model general de arhitectură pentru aplicație, urmând ca ulterior să detaliez fiecare modul. Modelul întreg al arhitecturii aplicației este prezentat în figura 4.1. – Arhitectura aplicației, și arată toate modulele independente care fac aplicația funcțională, cât și relațiile dintre module.

Figura 4.1. – Arhitectura aplicației

Arhitectura generală a aplicației suprinde modulele de colectare, stocare și analiză a datelor, dar și modulele intermediare prin care datele trec înainte să fie afișate în interfață.

Primul modul al aplicației web este reprezentat de bibliotecile colectoare. Acestea sunt responsabile cu extragerea/colectarea efectivă a metricilor, specificate prin intermediul cerințelor funcționale ale aplicației. Pentru fiecare bibliotecă se definesc clase specifice și metode care să permită întegrarea mediului de colectare cu modulul proiectat prin cererile ReST. Toate bibliotecile colectoare sunt scrise în limbajul PHP 5.4 utilizând Zend Framework.

Înainte de a fi stocate, metricile sunt colectate de modulul colector, al doilea modul independent al aplicației. Modulul colector integrează prin intermediul unei interfețe UML comune, toate bibliotecile colectoare și este responsabil cu generarea clienților pentru accesarea metricilor.

Partea de stocare a metricilor este realizată parțial de modulul SQL Database, care cuprinde baza de date a aplicației, cu o tabelă unică în care sunt stocate după criterii bine stabilite, în format unificat datele extrase sunt forma unor vectori de caracteristici/metrici.

Analiza metricilor este asigurată de modulul Data Analyzer, responsabil cu analiza datelor precum însuși îi spune și numele. Acest modul implementează clase specifice pentru prelucrare în sensul statisticilor matematice/probabilistice a datelor extrase din modulul SQL Database.

Următoarele două module apărute în arhitectura generală sunt începute și încă neimplementate în interfața web finală. Pentru integrarea lor sunt necesare permisiuni la servere adiționale ale companiei 4PSA pentru care s-au colectat metricile, servere la care nu dețin acces.

Modulul Interfață este reprezentat de scopul final al lucrării și constituie interfața generală a aplicației în care se permite atât vizualizarea unor date din metricile colectate, deja analizate, dar și accesul la niște statistici mai detaliate, pentru echipa de management sau dezvoltatori. Acest modul, așa cum am descris în propoziția anterioară se poate împărți în două submodule: TV Dashboard și KPI Dashboard, ambele permit afișarea în timp real a statisticilor referitoare la metricile extrase de clienții colectorilor.

Descrierea aplicației poate fi facută prin intermediul precizărilor despre fiecare modul independent din arhitectura generală a aplicației. În sens preliminar descrierii fiecărui modul, voi menționa câteva dintre convențiile utilizate în proiectarea software a aplicației finale referitoare la modul de funcționare al fiecărui modul.

Funcționarea fiecărui modul este asigurată de niște date de configurare care vor fi extrase prin funcții specifice PHP din cadrul unei fișiere text.conf, reprezentate sub forma de câmp = valoare;

Fiecare modul are o clasă autoloader care permite încărcarea în momentul execuției a fiecărei clase din modulul respectiv;

Aplicația este dezvoltată în sens invers al afișării statisticilor finale, pornind de la colectarea datelor și finalizându-se cu analiza lor;

Metricile dorite sunt specificate atât prin cerințele functionale ale lucrării, cât și prin modulul de colectare al datelor;

Proiectarea fiecărui modul încearcă să respecte arhitectura fiecărui modul în parte, astfel încât la integrarea lor să nu existe dificultăți;

Utilizatorul final al aplicației nu poate interacționa în niciun fel cu metricile extrase. El nu poate preciza metrici, nu poate modifica comportamentul aplicației și nu poate accesa modulele inferioare ale aplicației – poate doar să vizualizeze statisticile;

Se va introduce un modul suplimentar de Controller, care să genereze în mod automat la execuție câte un client specific fiecarui colector și care, la rularea sa, stochează automat datele extrase în modulul de SQL Database;

Clienții fiecărui API (în cazul meu, bibliotecile colectoare) sunt generați de un CollectorFactory și sunt de tipul Singleton. În acest sens, vom implementa pentru fiecare șablon de proiectare (engleză design pattern) utilizat funcții specifice de tip constructor;

Accesul la metrici se face folosind serviciul web ReST (Representational State Transfer – bazat pe cereri HTTP) și se va consulta modul de construcție al fiecărei cereri la bibliotecile colectoare în funcție de metricele dorite. Se va consulta documentația online a dezvoltatorilor de la Atlassian;

Standardele PHP de codare a aplicației sunt conforme cerințelor firmei și sunt strict confidențiale.

Parametri de configurare și acces

Partea de configurare a unor fișiere cu câmpuri bine definite, intitulate sugestiv și accesate de câte o clasă în parte în funcție de necesități, reprezintă o etapă preliminară în proiectarea aplicației. Construirea unui modul de configurare intitulat Config, care să conțină câte un fișier cu câmpuri setate pentru fiecare bibliotecă colectoare, sau pentru orice modul, ușurează rularea aplicației și justifică de ce utilizatorul final nu trebuie neaparat să cunoască valorile câmpurilor pentru a avea acces la statistici.

Astfel, în funcție de necesitatea la conectare, se folosesc aceste fișiere de configurare în care valorile dorite pentru asigurarea conexiunii să fie de tipul câmp = valoare. Fiecare fișier e parsat în interiorul unor metode specifice fiecărei clase, care are nevoie de configurare, iar informațiile sunt reținute în niște elemente de tip vector, în care câmpurile devin indecși, iar valorile asigură conexiunea la mediul din care se face colectarea.

Nu toate fișierele de configurare vor avea aceiași structură, însă acest lucru nu afectează funcționalitatea aplicației, deoarece fiecare modul/ clasă știe de unde să-și extragă informațiile utile la o simplă rulare a aplicației finale.

Pentru a porni partea de colectare a metricilor a fost uneori nevoie și de utilizarea unor unelte online, care să asigure corectitudinea parametrilor dați în fișierele de configurare, cum e cazul Google Analytics. Tabelul 4.1. – Parametri de acces, specifică ce valori sunt necesare a fi cunoscute la asigurarea conexiunii cu mediul colector, și url-ul paginii la care se face conectarea. Nu toate valorile sunt furnizate pentru asigurarea confidențialității unor date.

Tabelul 4.1. – Parametri de acces

De asemenea, fiecare fișier de configurare este definit în clasa colector a fiecărui mediu de colectare printr-o constantă de forma CONF_PATH_X, unde X este numele sau prescurtarea colectorului. Lista fișierelor de configurare este prezentată în tabelul 4.2. – Lista fișierelor de configurare.

Tabelul 4.2. – Lista fișierelor de configurare

Capitolul 5 – IMPLEMENTAREA MODULELOR APLICAȚIEI

5.1. Bibliotecile colectoare

Sunt reprezentate de biblioteci colectoare, scrise în limbaj PHP5.4 utilizând un framework specific Php – Zend, care ajută la stabilirea conexiunii cu mediul de colectare și stabilesc principiile și metricile pentru/după care se face colectarea.

Precum am evidențiat, bibliotecile colectoare sunt specifice fiecărui framework intern companiei și conțin clase și metode pentru accesarea metricilor dorite din fiecare mediu în parte. Interacționează direct cu modulul colector, care este responsabil și de crearea clienților specifici care se autentifică la fiecare mediu, prin token-uri reprezentate de encriptarea specifică a numelui de utilizator și a parolei.

Metricile dorite pentru fiecare dintre biblioteci, precum și mediile din care se extrag datele sunt următoarele:

Jira

Este sistemul de monitorizare a bugurilor, îmbunătățirilor etc. pentru dezvoltatorii și inginerii în asigurarea calității. Din Jira, suntem interesați de defecte și de caracteristicile lor – lista defectelor în lucru/rezolvate/închise, date referitoare la cine a semnalat defectul, cine este responsabil cu rezolvarea lor, timpii de rezolvare etc. .

Crucible – Fisheye

Crucible – FishEye reprezintă software-ul intern de recenzii. Ajută dezvoltatorii să realizeze revizii rapide pe codul scris de ceilalți dezvoltatori. Obiectele de interes sunt recenziile cu caracteristicile lor – data începerii recenziei, proiectul, persoanele a căror cod este revizuit, persoana responsabilă de recenzie etc. .

Confluence

Reprezintă wiki-ul intern al companiei și este organizat în spații și pagini – de tip pagină simplă sau blog post. Obiectele de interes din Confluence sunt spațiile publice, personale precum și paginile de orice tip. Despre acestea dorim să cunoaștem data creerii, autorul, numarul de comentarii, spațiul din care o pagina face parte etc. .

Google Analytics

Google Analytics API, pus la dispoziție de Google, permite vizualizarea de grafice după diverse metrici precizate, pentru diverse sit-uri urmărite. Din Google Analytics dorim să extragem datele de pe graficele generate din GoogleAnalytics, într-un interval de timp precizat.

Get Satisfaction

Este platforma de relații cu clienții a companiei. Prin intermediul său se asigură un feedback constant de la clienți asupra produselor deja aflate în producție. Subiectul de bază din GetSatisfaction îl reprezintă un subiect. Fiecare subiect face parte dintr-o companie, produs, categorie de subiect. În funcție de acestea, dorim datele disponibile despre subiecte.

Active Campaign

Permite comunicarea oficială cu clienții și partenerii companiei prin scrisori de informare. Ne interesează orice dată despre aceste scrisori.

Un tabel general al metricilor extrase a fost prezentat în Tabelul 2.2. – Lista metricilor din aplicație și se regăsește și în Anexa 4 a prezentei lucrări.

5.1.1. Detalii de implementare

Raportarea la implementarea modulului de colectare a datelor, nu presupune descrierea la modul general a fiecărei biblioteci colectoare, deoarece putem considera fiecare bibliotecă drept un singur modul independent. Pentru a se putea interfața la modulul Collector al aplicației, bibliotecile colectoare sunt definite de un șablon de proiectare setat pe baza unor principii generale, așa cum au fost menționate în subcapitolul de analiză a specificațiilor.

În acest sens, bibliotecile colectoare sunt construite folosind aceleași convenții, pornind de la modelarea UML, și până la implementarea cliențior aplicației sau a cererilor ReST la Api-ul fiecărui mediu colector. Ținând cont de considerentele enunțate, voi enunța câteva reguli pe baza cărora s-a implementat în cod PHP fiecare bibliotecă.

Pentru a face referire la modul în care s-a făcut implementarea, este necesară cunoașterea structurii ierarhice a directoarelor pentru bibliotecile colectoare. În implementarea efectivă Php a bibliotecilor, s-a construit directorul ThirdParty care conține toate bibliotecile colectoare.

Figura 5.1. – Structura ierarhică a fișierelor pentru bibliotecile colectoare

Fiecare bibliotecă este controlată de fișierele CollectorFactory.php și Configure.php care rețin detalii de configurare și modul în care clienți specifici fiecărei biblioteci sunt inițializați, atunci când aplicația se rulează. Fișierul CollectorAutoloader.php este folosit de toate bibliotecile și permite înregistrarea unui domeniu al unui director sau al unei fișier php, în momentul în care este necesar importul unui director/fișier în alt fișier php.

Funcția de autoload a fișierului care realizează importul fișierelor php în alt fișier, pentru a evita include-urile php specifice, multiple, în fiecare fișier al unei biblioteci, are următoarea formă:

public static function autoload($name){

$retval = false;

if (strpos($name,self::NAME_SPACE) === 0) {

$parts = explode("_",$name);

array_shift($parts);

$expected_path = join(DIRECTORY_SEPARATOR, array(self::$base_dir, join(DIRECTORY_SEPARATOR,$parts) . ".php"));

if (is_file($expected_path) && is_readable($expected_path)) {

require $expected_path;

$retval = true;

}

}

return $retval;

}

După realizarea importurilor de fișiere necesare, se execută de către modulul collector, scriptul Configure.php, care conține metode pentru extragerea valorilor câmpurilor din fiecare fișier de configurare al unei biblioteci. Fiecare bibliotecă va avea acces doar la propriile setări de configurare din fișierul denumit sugestiv x.conf, unde x este prescurtarea folosită în prezenta aplicație pentru colectorul care accesează fișierul. Modul în care fișierele de configurare sunt denumite va fi reluat în explicarea fiecărui colector.

Fișierul CollectorFactory.php, este cel care inițializează practic colectarea metricilor. Acest lucru este realizat prin inițializarea fiecărui Api al mediului de colectare, prin utilizarea unui șablon de proiectare utilizat în programarea orientată pe obiecte, anume Factory Design Pattern. Este important de precizat de asemenea că instanțele fiecărei biblioteci colectoare inițializate cu factory pattern, sunt de tipul Singleton, deoarece nu dorim conectarea în aplicație de mai multe ori, cu același tip de client la mediul de colectare, lucru util în neînregistrarea metricilor duplicat sau în evitarea datelor redundante.

CollectorFactory este derivat din interfața CollectorApi și știe cum să inițializeze fiecare instanță de tipul Singleton, prin intermediul metodei makeCollector($objType), unde tipurile obiectelor inițializate sunt definite intern, ca și constante, precum urmează:

CONST COLLECTOR_JIRA = "jira";

CONST COLLECTOR_GETS = "getSat";

CONST COLLECTOR_CONFL = "confluence";

CONST COLLECTOR_CRU = "crucible";

CONST COLLECTOR_AC = "active";

CONST COLLECTOR_GA = "google"; .

Constructorul fiecărei biblioteci, de tip privat, specific șablonului de proiectare Singleton, apelează metode din propria bibliotecă pentru construirea unui Client care utilizează funcții php curl, pentru asigurarea integrării cererilor ReST cu Api-ul uneltei de colectare.

Sunt importante aici atât setările parametrilor CURL, cât și modul de reprezentare în care rezultatul unei cereri este furnizat. Pentru bibliotecile colectoare, în aplicație s-a preferat utilizarea unei forme de reprezentare a răspunsului furnizat de o cerere, de tipul json, deoarece manevrarea obiectelor construite cu această reprezentare poate fi ușoară. Tipul json este convertit în vector de elemente cu metricile obținute, care pot fi ușor stocare ulterior, după câmpurile vectorului care stochează metricile extrase.

De altfel, specificarea unei anumite metrici și colectarea sa, se face apoi prin intermediul unor clase, intitulate sugestiv după fiecare mediu, în funcție de obiectele de interes. Dacă spre exemplu, pentru Jira suntem interesați de Issues (în traducere scăpări, defecte), Clasa Issue.php va fi responsabilă de implementarea unor metode pentru fiecare din metricile extrase. Metodele implementate vor fi de tip accesor (getter) și vor extrage dintr-un json convertit în vector, acele câmpuri precizate ca metrică de colecție.

Dacă se dorește data cea mai recentă de aducere a unei modificări asupra unui defect Jira, se va folosi o funcție de tipul:

public function getUpdated(

{

if (isset($this->result['Updated'])) {

return $this->result['Updated'];

}

} .

Modulele de biblioteci colectoare interacționează cu serverul pe care mediile de colectare sunt instalate și pot retrage metrici specifice pentru fiecare tip de obiect dorit. Interacțiunea fiecărei biblioteci cu mediul de colectare se face precum am spus, prin protocolul HTTP și cereri ReST. Un model de cerere ReST pentru retragerea obiectelor din Crucible se poate formula astfel:

public function getAllReviews(){

return $this->api(self::REQUEST_GET,

"/rest-service/reviews-v1/filter/allReviews/details.json", array(), false)->getReviews();

}

, precum și signatura metodei o sugerează, metoda este responsabilă cu retragerea tuturor obiectelor de tip Revizie/Review din mediul de colectare. Importanța exemplului oferit este în remarcarea modului în care o cerere este construită, pe baza considerațiilor teoretice prezentate în capitolul anterior al lucrării.

Detaliile de implementare precizate anterior sunt valabile pentru fiecare bibliotecă colectoare, deoarece toate respectă același șablon de implementare, fapt ce facilitează integrarea tuturor bibliotecilor colectoare cu următorul modul al aplicației, modulul Collector.

5.2. Modulul Collector

Modulul Collector sau modulul de colectare al datelor, este responsabil cu generarea clienților pentru fiecare API, și cu extragerea metricilor precizate. Colectarea datelor era și responsabilitatea bibliotecilor colectoare, diferența între modulul de colectare a datelor și bibliotecile colectoare, fiind că modulul Collector este cel care este responsabil de întregul proces de colectare a datelor, bibliotecile colectoare ajutând la colectarea de metrici particulare. Dacă am prioritiza rolul fiecărui modul în procesul de colectare, aș putea spune că în timp ce bibliotecile colectoare se ocupă de extragerea de metrici specifice și implementează o interfață de colector, modulul Collector este cel ce dictează procesul de colectare după anumite reguli. Modelul UML al acestui modul este prezentat în anexa 1 – Modelul UML al modului Collector, a prezentei lucrări.

Modulul de colectare al datelor este alcătuit din directoare precum Config, CollectorApis și fișierele comune bibliotecilor, anume CollectorFactory și CollectorApi.

CollectorAPI este interfața componentei colector. Aceasta este implementată de fiecare bibliotecă colectoare și reprezintă puntea de legatură între cele două module detaliate pănâ acum. Importanța interfeței comune nu este doar de a integra bibliotecile colectoare, ci de o construi prin intermediul metodei makeCollector($tip) un exemplu de API, pe baza parametrului $tip. Clasa CollectorAPI este implementată de CollectorFactory, care suprascrie, de asemenea, metoda makeCollector($tip). Totodată, interfața colectorului este implementată de o clasă abstractă AbstractCollector, din care derivă și CollectorApi.

JiraCollector, GetSatisfactionCollector, ConfluenceCollector și orice alt colector utilizat direct de către fiecare bibliotecă, poate fi definit ca XCollector, unde X este numele întreg al cadrului/mediului de colectare. Toți XCollectors sunt cazuri de șablon de proiectare Singleton, generați de makeCollector($tip) metodă a clasei CollectorFactory.

De asemenea, toate clasele XCollector definesc printr-o constantă, calea fișierului de configurare pe care îl folosesc. Generic, vom folosi o convenție pentru denumirea fișierelor de configurare de tipul CONF_PATH_X = ”x.conf”, unde X este abrevierea bibliotecii de colectare așa cum s-a definit în orice situație în care numele bibliotecii este invocat. Calea către fișierele de configurare, după convenția menționată anterior are structura definită în tabelul 4.2. – Lista fișierelor de configurare. Toate aceste fișiere vor fi grupate în directorul Config/Collector.

Pentru a stoca ulterior metricile colectate și a anticipa modul în care datele colectate sunt stocate într-o bază de date, este necesar un atribut al fiecărui XCollector, declarat protected, care să rețină în interior, pe diverse câmpuri, metricile colectate. O justificare a folosirii unei astfel de variabile ține strict de stocarea datelor. Nu e foarte scalabil să avem câte o tabelă pentru fiecare API din care se colectează obiectele cu metrici, pentru că, practic la fiecare nou modul, mai adăugăm încă un tabel și creștem și complexitatea la analiza metricilor. O soluție mai eficientă este să avem o singură tabelă , generică cu ”n” câmpuri și fiecare clasă colector să țină o mapare internă a parametrilor pe câmpurile bazei de date. Tot în virtutea eficienței aplicației, maparea trebuie să fie sub forma de variabilă vectorizată, multidimensională, definit în fiecare clasă colector  și într-un format standard, documentat.

Putem de asemenea, să anticipăm și modulul de analiză al datelor, lucru de altfel luat în considerare în aplicație, iar câmpurile acelui parametru vector, să fie și ele ordonate după o prioritate, ale cărei criterii aparțin exclusiv programatorului. În cazul aplicației dezvoltate, pentru mediul de Jira eficiența unui angajat este mai importantă decât numele defectului sesizat, astfel încât maparea pe câmpurile bazei de date va începe cu date ale eficienței și nu neapărat cu numele defectului. Analog se va proceda și pentru ceilalți colectori.

Un exemplu de mapare internă pe câmpurile bazei de date, pentru colectorul de Get Satisfaction, ar arăta precum urmează:

protected $_internalMapping = array(

"subject" => 'param1',

"created" => 'param2',

"updated" => 'param3',

"author" => 'param4',

"type" => 'param5',

"numberOfComments" => 'param6',

"people participating" =>'param7'

); .

Când facem referire la conectarea/integrare cu un mediu de colectare este important să avem în vedere și erorile ce pot apărea în diverse situații: când nu s-a găsit o anumită metrică specificată, când nu s-a putut realiza conexiunea cu mediul de colectare, când cererea ReST trimisă clientului fiecărui mediu nu este corect formulată etc. . De aceea, modulul Collector va defini și utiliza un director de ErrorHandling care este răspunzător pentru furnizarea codurilor de eroare și de mesaje de eroare corespunzătoare pentru fiecare clasă a modulului de colectare, de fiecare dată când este cazul.

Vom defini o eroare drept o pereche de constante (EXC_CODE_x, EXC_MSG_x) în clase intitulate după numele bibliotecii care folosesc codurile și mesajele de eroare, de tipul (abreviere bibliotecă colectare)Exception.php. Aceste clase pentru definirea tuturor erorilor dintr-un mediu trebuie să conțină și o metodă de tratare a unei erori, intitulată errorHandler, care să transmită mesaje corespunzătoare dezvoltatorului, la apariția unor evenimente neprevăzute. Pe lângă clasele JiraException, GetSatisfactionException etc., specifice fiecare câte unui colector, este necesară implementarea unei clase CollectorException care să trateze erorile care sunt comune tuturor claselor XCollector. Toate clasele ce definesc și tratează excepții vor fi clase copil ale clasei CollectorException, care extinde clasa pachetului Exception definit de PHP 5.4. Metoda de tratare a erorilor va fi scrisă doar în clasa CollectorException, pentru celelalte clase, aceasta va fi moștenită. Pentru o mai bună grupare a structurii de fișiere, directorul ErrorHandeling se va găsi în interiorul directorului CollectorApis și va fi folosit de modulul de colectare al datelor.

Un lucru necesar în implementarea codurilor de eroare este utilizarea unei combinații de cifre care să semnaleze prezența unei erori specifice la un anumit mediu. Acest lucru se poate realiza la modul unei convenții prin care, erori specifice ale unui mediu sa definească EXC_CODE_y (codul de eroare) ca un identificator comun din două cifre urmat de o numărare în sens crescător a erorilor sesizate. Convenția de denumire a codurilor de eroare se face la nivelul fiecărei clase de tratare a excepțiilor, prin intermediul unor constante denumite EXC_CODE_y, unde y este abrevierea unui anumit tip de eroare, iar denumirea sa este lăsată la aprecierea dezvoltatorului. Un exemplu de coduri de eroare pentru JiraException, îl poate constitui secvența:

CONST EXC_CODE_JFIELD = '1101';

CONST EXC_CODE_JPARAM = '1102';

CONST EXC_CODE_JOBJ = '1103';

CONST EXC_CODE_JQRY = '1104';

CONST EXC_CODE_JRES = '1105';

CONST EXC_MSG_JFIELD = 'Jira field not found!';

CONST EXC_MSG_JPARAM = 'Expected parameter Array instead of Object given!';

CONST EXC_MSG_JOBJ= 'Expected parameter Object instead of Array given!';

CONST EXC_MSG_JQRY= 'Please specify your search criteria!';

CONST EXC_MSG_JRES= 'No issues were found to match your search!';

Convenția de denumire a codurilor de eroare pentru fiecare clasă colector, este definită în figura 5.2. – Convenție coduri eroare.

Figura 5.2. – Convenție coduri eroare

Metoda publică toSingleFormat($mapArray: array ()) este suprascrisă în fiecare clasă colector și returnează pentru fiecare colector, vectorul asociat $mapArray. În primul rând, ne asociem fiecărui element al variabilei interne de mapare pe câmpurile bazei de date câte o valoare generică "param", notată crescător în funcție de câte metrici sunt de interes pentru fiecare obiect extras de tipul unui anume colector. Din vectorul $_internalMapping cu valorile param, se construiește un extractedArray. ExtractedArray este dat ca parametru al
metodei toSingleFormat, și se obține prin cererile ReST la o anumită bibliotecă, rezultatul cererilor poate fi Jira_Issue, o pagină din Confluence, un subiect din GetSatisfaction etc..

Fiecare colector conține metode specifice pentru un obiect extras care conține date despre măsurătorile de care suntem interesați: getCampaign(), getReview(), getReport(), etc., iar aceste metode sunt accesate prin clienții fiecărui Api, și aparțin bibliotecilor colectoare.
Metoda toSingleFormat construiește un obiect de interes cu metricile cerute de tipul vector, cu indecși numere naturale, iar prin funcția array_combine() a limbajului php, rezultatul final va fi o combinație de vectori _internalMapping și rezultatul cererilor ReST, astfel încât în final, metoda să returneze un vector de forma ”param1” => valoare etc. . Acest lucru va garanta că rezultatele metodei acesteia, accesate din oricare colector, vor fi vectori cu indecși similari, încât stocarea oricărui astfel de vector în baza de date comună, să se facă după indecși, unde indecșii sunt câmpurile tabelei comune, iar valorile sunt luate ca atare.

Pe lângă funcțiile de clasă prezentate anterior, fiecare colector conține o metodă de setare, numită setup(), ce primește drept parametru un șir de caractere, $query. Acest $query va fi construit pe baza unui fișier de configurare ce aparține de următorul modul al aplicației, și pe baza lui se va realiza inițializarea api-ului fiecărui mediu de colectare, și se vor executa metode de colectare specifice pentru fiecare Api creat. Așadar, metoda setup retrage din mediul de colectare aferent fiecărui colector, un anumit obiect specific, căruia i se precizează și i se cunosc metricile, pe baza unei cereri la Api-ul curent. Rezultatele cererii la Api, vor fi apoi convertite în formatul necesar stocării, de către modulul de stocare, în baza de date cunoscută de modulul următor al aplicației, modulul de control. Sunt situații când o cerere trimisă la server pentru un anumit colector/api va furniza un rezultat nul. Trebuie avută în vedere o asemenea situație și implementat un mecanism de tratare a erorilor similar mecanismului de erori al fiecărui colector în parte. Metoda setup se poate apela din exterior și fără precizarea șirului după care se face căutarea în Api-ul curent, parametrul metodei fiind implicit nul. Însă, de inițializarea colectorului și a întregii aplicații se va ocupa modulul Controller.

5.3. Modulul Controller

Modulul de colectare al datelor are nevoie de un submodul de Controller, introdus ulterior în aplicație. Acest submodul este cel care pune în execuție tot procesul de colectare-stocare al metricilor. Utilitatea unui modul suplimentar a fost sesizată ulterior, ținând cont că de la început am dorit ca un utilizator să nu poată fi conștient de ceea ce se ascunde în spatele aplicației. Metricile așadar, nu sunt vizibile la exterior, însă prin intermediul controllerului pot efectua diverse activități.

Modelul UML al acestui modul interacționează atât cu modulul de colectare al datelor, cât și cu cel de stocare și le controlează pe toate acestea, în sensul în care modulul Controller este singurul care știe în ce tabelă din baza de date se stochează obiectele cu metricile extrase, poate inițializa colectorii, poate construi cereri și poate rula stocarea datelor.

Arhitectura generală a modulul de control, este prezentată în diagrama UML din anexa 2 – Modelul UML al Controller-ului, de la finalul prezentei lucrări.

Prin intermediul modulului controller, trebuie să inițializez instanța de colector și accesez implicit api-urile fiecărei biblioteci colectoare de metrici. Îmi pot seta în fișiere distincte de configurare niște criterii cu rol de filtru, pe care le parcurg în funcții specifice modulului de controller. Pe baza fișierelor de configurare specifice, extrag valorile parametrilor de configurare pentru filtre aplicate pe fiecare collector și apelez intern o funcție de setup($query) care îmi caută într-un colector specificat obiectele cu proprietățile din filtru și le stochează automat în baza de date, ca și valori neprelucrate.

Funcția de setup este implementată la nivelul fiecărui clase colectoare și trebuie rescrisă pentru fiecare mediu în parte, deoarece în interiorul acesteia, se construiesc clienții fiecărui API și se realizează autentificarea propriu-zisă la fiecare mediu de colectare. Nu este neapărat nevoie ca această funcție să fie apelată cu un parametru de tip șir de caractere, reprezentând o cerere la API-ul fiecărui mediu de colectare, deoarece mediile sunt diferite și nu toate mediile permit o anumită filtrare a rezultatelor obținute drept răspuns la o cerere ulterioară ReST.

Până la proiectarea aplicației finale, s-a sesizat că singurele medii care furnizează un răspuns prin solicitarea unei cereri la crearea de client Api, sunt mediile de Jira și de Active Campaign, pentru toate celelalte medii, este mai sigur și mai favoarea noastră să nu filtrăm rezultatele, ci să obținem toate obiectele cu metricile precizate.

Modulul de control furnizează cererea pentru mediul de Jira pe baza căreia se face căutarea în API poate permite aplicarea unui filtru. Metoda numită buildCollectorQuery returnează un șir de caractere după care să se facă o filtrare a tuturor rezultatelor obținute de client, de forma: ” project = INT-PROJ and assignee=johnd and reporter = anned and resolution= fixed order by updatedDate ASC”, asemănător unei cereri MySql.

Câteva porțiuni relevante din acestă funcție sunt prezentate, după cum urmează:

if (( ($_key != 'CTRL_TBNAME') && ($_key != 'CTRL_RUNTIME') && …

&& ($_key != 'ORDER BY')) && ($_val != '') ){

$query .= " $_key = $_val and ";

}else { $query .= '';}

}

$query = substr($query, 0, -5);

if(($_key == 'ORDER BY') && (!empty($this->_params['ORDER BY']))){

$query .= " ".$_key . " " . $_val;

}else {''};

return $query;

}

Făcând referire la fișiere de configurare, structura acestora nu diferă foarte mult de ceea ce s-a prezentat în cadrul modulului de colectare al datelor. De fapt, se încearcă structuri similare, astfel încât funcția care preia valori din aceste fișiere să fie singulară și să furnizeze un vector cu câmpurile din toate fișierele de configurare ale acestui modul, și cu valorile corespunzătoare. Directorul care găzduiește toate aceste fișiere este tot cel de Config, utilizat și de modulul de colectare al datelor, însă gruparea fișierelor pentru Controller se va face în subdirectorul Controller. Fișierele din acest director vor respecta și standardele de denumire pentru fișierele de configurare utilizat în întreaga aplicație, anume pentru fiecare mediu, fișierul corespunzător are denumirea (numele_mediului)Ctrl.conf – de exemplu jiraCtrl.conf, acCtrl.conf etc..

Asemeni fiecărui modul al întregii aplicații, și modulul de control, trebuie să definească și să trateze excepții/erori apărute în cazul unei conectări greșite la un mediu de colectare sau chiar la baza de date, sau în cazul în care câmpuri ale fișierelor de configurare nu sunt definite. Pentru aceasta, modulul trebuie să conțină o clasă denumită ControllerException.php, care să descrie prin constante de tipul EXC_CODE și EXC_MSG, mesaje și coduri de eroare. La fel ca și în cazul modulului de colectare, se va atribui un indicator controller-ului, astfel încât fiecare cod de eroare definit printr-o constantă va incepe cu combinația de cifre 00, urmate de o numărare crescătoare din două cifre a erorilor apărute, începând cu 01. Astfel, primul cod de eroare va fi 0001 și codurile vor continua crescător. Clasa de tratare a excepțiilor este clasă copil a pachetului PHP/Exception.

În esență, motivația introducerii ulterioare a unui astfel de modul este bazată pe observația clară conform căreia este mai indicat să delegăm responsabilitatea inițializării Api-urilor mediilor colectoare, rularea lor cu un anumit șir de caractere care să-mi genereze niște rezultate concludente conținând metricile și inițializarea stocării metricilor, decât să implementăm metode separate, pentru fiecare tip de colector în parte, cât și pentru modulul de stocare. Tot din același considerent, în modulul de control al aplicației s-a preferat reținerea tuturor parametrilor de configurare din orice mediu sau fișier al aplicației pentru acest modul, în interiorul unui singur vector asociativ, astfel încât manipularea acestui vector după semnificația acordată a indecșilor săi să fie ușoară și intuitivă în cazul unor dezvoltări ulterioare.

5.4. Modulul de stocare a datelor

Modulul de stocare al datelor este responsabil cu stocarea datelor neprelucrate într-o tabelă universală. Toate datele neprelucrate stocate în baza de date sunt converite la un format unificat (ales drept vector) ținând cont de maparea internă a parametrilor din bibliotecile colectoare, precum s-a discutat anterior.

Întreg modulul este constituit din clasa DataStorage.php și DataStorageException.php, fișiere ce țin cont atât de operațiile de efectuat asupra datelor colectate, cât și de aruncarea de excepții potrivite tratării lor.

Modelul OOP – din anexa 3 a lucrării, pentru modulul de stocare al datelor (DataStorage) nu este responsabil pentru crearea/ștergerea de tabele. Există o schemă bine cunoscută pe baza căreia, baza de date este implementată și nici un alt utilizator nu are nici permisiunea de a modifica tabela de stocare a metricilor. În acest sens, se configurează în linie de comandă baza de date în care metricile sunt stocate, precum și tabela în care datele sunt ținute.

Baza de date se va crea direct pe serverul de testare al companiei 4PSA, folosind următoarele comenzi linux:

> cd /etc/voipnow/

> vi .sqldb

După vizualizarea conținutului fișierului de configurare al bazei de date, se retrag din acest fișier informațiile utile în vederea construirii modulului de stocare. Cum conținutul fișierului deschis are forma main:1c0e0ff911:e36c12ce75 , se intuiesc detaliile de conectare astfel:

username: 1c0e0ff911

password: e36c12ce75

server: 192.168.14.XXX

Crearea tabelei de stocare, denumită metrics, se face prin cererea CREATE TABLE specifică MySql:

CREATE TABLE metrics (
id INT NOT NULL AUTO_INCREMENT,
param0 VARCHAR(100), param1 VARCHAR(100), param2 VARCHAR(100), param3 VARCHAR(100), param4 VARCHAR(100), param5 VARCHAR(100), … , param26 VARCHAR(100), PRIMARY KEY(id) );

Lucrul cu baza de date se va putea face acum direct de pe server, prin următoarele comenzi linux:

mysql -u 1c0e0ff911 -pe36c12ce75

mysql> use sqlDB;

mysql> show tables;

mysql> describe metrics;

mysql> SELECT * FROM metrics;

mysql> DELETE FROM metrics;

Fiecare colector are integrat precum s-a descris în modulul de colector, o variabilă privată de tip tablou, care reține metrici ale unui obiect în câmpuri mapate pe câmpurile bazei de date. Astfel, indiferent de mediul de colectare, datele vor fi stocate în tabela metrics, după câmpurile vectorului, cu valorile reținute în fiecare obiect extras.

Se pot adăuga ulterior câmpuri suplimentare, tabelei în care metricile sunt extrase, lucru de altfel făcut în următorul modul al aplicației și aceste câmpuri vor servi doar la prelucrările aduse asupra metricilor.

Asemenea modulelor anterioare, și modulul de stocare al datelor este grupat într-un director din structura directoarelor aplicației, intitulat /Storage. Acest modul conține doar două clase php și are la bază un fișier de configurare. Dacă la proiectarea modulului, fișierul de configurare era de preferat să se afle în același director de /Storage, la introducerea modulului de control al aplicației, se preferă mutarea fișierului de configurare al bazei de date în directorul /Config/Controller.

Am precizat în subcapitolul referitor la modulul Controller, faptul că denumirea fișierelor de configurare poartă numele prescurtat al modulului care folosește acel fișier. Astfel, parametri de configurare ai bazei de date, retrași prin comenzile linux de mai sus, din fișierul sqlDb.conf, justifică afirmația conform căreia Controllerul e cel care face legătura modulului de colectare al metricilor cu modulul de stocare al datelor și că modulul de control este singurul care știe în ce tabelă sunt stocate metricile și cum să acceseze baza de date.

Asemănător celorlalte module ale aplicației, parametri de acces la baza de date sunt extrași mai apoi din fișierul de configurare al bazei de date, în niște constante ale clasei de DataStorage. În majoritatea cazurilor în care se încearcă accesul la baza de date, pot apărea erori referitoare la conectare. De aceea, DBSERVER trebuie să fie specificat ca localhost în fișierul de configurare al bazei de date, pentru a evita mesajele de avertizare generate de metode precum mysqli_connect/new mysqli. Celelalte câmpuri ale fișierului de configurare sunt definite potrivit scopurilor lor DBSERVER = CHANGEME, DBUSER = CHANGEME, DBPASS = CHANGEME, DBNAME = CHANGEME. Toate valorile din fișierele de configurare ale fiecărui modul, sunt definite implicit prin valoarea CHANGEME, urmând ca înlocuirea lor cu valorile potrivite de conectare să se facă în funcție de parametri de acces la fiecare modul, colector sau bază de date.

Se poate intui că la crearea unei instanțe de tipul bazei de date, constructorul clasei DataStorage primește drept parametru o cale către fișierul de configurare al bazei de date, fișier aflat în directorul /Config/Controller al aplicației. Este necesară și prezența unui destructor privat care să închidă conexiunea la baza de date la finalul oricărei operații asupra datelor stocate.

În scopul de a preveni introducerea aceleași valori în tabel trebuie definită o cheie unică. De exemplu, pentru bibliotecile colectoare se va folosi drept cheie unică, un câmp de tabel care deține data la care a fost creat fiecare obiect de tip colector, conținând metricile cu prioritatea cea mai mare stabilită de dezvoltator. Parametrul de mapare internă al fiecărui colector trebuie să fie comandat în acest sens, adică să conțină data creerii pentru fiecare obiect colector pe poziția param2 din tabelul de stocare, dacă este posibil.

La ceilalți colectori, acest câmp distinctiv pentru evitarea înregistrărilor duplicat, poate fi după caz, un șir de caractere, o dată calendaristică sau o valoare numerică. Pe lângă restricțiile impuse asupra datelor duplicat la operații de inserare în baza de date, trebuie avut în vedere, de asemenea, și aruncarea de excepții specifice în fiecare modul proiectat.

Figura 5.3 – Baza de date

Înainte de prezentarea clasei de excepții specifice modulului de stocare al datelor, trebuie să înțelegem modul în care datele sunt stocate. Modulul de stocare al datelor este implementat într-un mod cât mai general cu putință, pentru a nu avea griji la inserarea datelor din orice mediu, chiar și a unei date exterioare. Pe lângă metodele de constructor, destructor trebuie să avem funcții care să poate retrage informații referitoare la stadiul în care baza de date se află.

Trebuie de asemenea precizat că stocarea în baza de date este implementată în cod, astfel încât toate obiectele convertite în format unic, ales array (tablou sau vector) să fie stocate în baza de date. Pentru un alt tip de format ales, stocarea va eșua.

Metoda privată _getCredentials($path), va prelua valorile câmpurilor pentru parametri de configurare de la fișierul specificat. Pentru cereri de interogare asupra câmpurilor bazei de date, se va folosi metoda publică sqlQuery($query), care oferă metode de acces asupra datelor ce sunt stocate în baza de date, prin intermediul unor clauze SQL cunoscute de tipul: Insert, Delete, Update. În esență, metodă sqlQuery($query), rulează o cerere MySql la baza de date, după niște criterii predefinite de construcție ale acelei cereri. Dacă se va studia în detaliu implementarea modulului de stocare al datelor, se va observa că această metodă sqlQuery, este folosită de toate celelalte metode care au nevoie să trimită o cerere la baza de date, pentru a obține un rezultat, fie el vector asociativ, obiect sau rezultat boolean de tipul true/false.

Este important de specificat că nu se va implementa nicio metodă de ștergere a înregistrărilor din tabela metrics, deoarece suntem interesați în analiza datelor stocate, nu în înlăturarea lor. Rezultatul acestei metode, poate fi un obiect sau o valoare logică, în cazul în care cererea transmisă este incorectă. Aproape toate metodele care au legătură directă cu datele stocate apelează această metodă pentru a furniza interogarea bazei de date. De înregistrările duplicat se ocupă metoda sqlUpdateDb(), iar operațiile de Delete revin direct dezvoltatorului, fiind permise doar pe server, prin intermediul comenzilor linux.

De asemenea, suntem interesați în asigurarea protecției datelor stocate. Suntem cu toții familiari cu sql injection și atacurile posibile asupra unei baze de date. Pentru tipul de atac menționat, se va implementa o funcție de clasă sqlString, care să realizeze mysqli_real_escape_string(), după fiecare valoare introdusă în câmpurile bazei de date.

Așa cum am precizat, modulul de stocare al datelor, trebuie să respecte un format general încât să poată fi utilizat nu doar de către aplicația dezvoltată, ci de către orice utilizator din exterior, în scopul stocării unor date, cu toate că acest lucru nu este nici evident și nici permis prin aplicație.

Pe lângă metodele prezentate, ale modulului de stocare, ar fi interesant ca utilizatorul, sau interfața aplicației să permită impunerea de filtre de tipul – doar un singur rezultat furnizat la o cerere, sau toate rezultatele disponibile. Astfel, metode cu denumire a căror scop e lesne de evidențiat, precum sqlQueryFetchAllResults sau sqlQueryFetchOneResult sunt implementate. De asemenea, am menționat că rezultatul metodei care se ocupă efectiv de rezultatul unei cereri la baza de date, poate fi o coloană, un obiect, un vector sau un rezultat boolean fals, în caz de eșec. De aceea, metode precum sqlFetchObject() sau sqlFetchRow sunt implementate. Diferența dintre a furniza la cerere un singur rezultat, sau a furniza toate rezultatele disponibile, constă într-o porțiune de cod de două rânduri, în care, dacă rezultatul este unul singur, vom apela metoda sqlFetchRow o singură dată, iar în cazul în care rezultatele furnizate la cerere, sunt multiple, metoda sqlFetchRow se va apela pentru fiecare rând în parte, iar rezultatul final va fi ținut la rândul său într-un vector.

Alte metode ale clasei DataStorage.php permit în funcție de caz extragerea rezultatului pe coloanele tabelei, a unui singur rezultat cu niște cerințe specificate sau a tuturor rezultatelor unei cereri.

Figura 5.4 – Interogări pentru unul sau mai multe rezultate din baza de date

Cea mai complexă metodă și cea care oferă numele modului de stocare, este metoda sqlUpdateDb() și stochează datele de la mediile colectoare pe principiul eliminării duplicatelor. Clauza MySql de Insert pentru medii în care rezultatele ce trebuie stocate, aflate deja în format unificat – vector, vor fi de forma: INSERT into metrics (`param1`,`param2`,`param3`, … , `param25`) VALUES ( 1,2,3,4,….25), ( … ), ( … ) ON DULICATE KEY UPDATE `param1` = VALUES(`param1`), …; . Viitoarele îmbunătățiri ale modului de stocare al datelor poate include adăugarea la cererea de Insert construită și a unei clauze where, implicit definită în signatura metodei printr-un șir vid. Acest lucru ar presupune lucrul cu clauze preparate, și nu s-a luat în considerare acest aspect la proiectarea aplicației finale.

Portabilitatea datelor extrase poate fi asigurată oricând prin intermediul unui backup la baza de date, lucru realizabil printr-o comandă linux aferentă.

Figura 5.5. – Backup la baza de date

Submodulul de atenționare în cazul apariției unor erori este derivat din pachetul /PHP/Exception și respectă aceleași standarde de proiectare ca și toate clasele de excepții prezentate în lucrare. Se definesc prin constante specifice coduri de eroare și mesaje aferente acestora și sunt aruncate excepții oriunde nu sunt respectate anumite criterii de proiectare.

5.5. Modulul de analiză a datelor

Modulul de analiză al datelor este modulul cel mai important în construirea interfeței grafice finale și este capabil să filtreze și să analizeze datele neprelucrate, din tabela MySql în care metricile sunt stocate.

Pentru proiectarea acestui modul trebuie să fac referire la modurile de funcționare ale modulului de control, care decid în ce manieră să fie executată aplicația pentru a afișa datele de interes. Am spus pentru modulul controler, că are două moduri de funcționare, definite în interiorul unui fișier de configurare și că, în funcție de valoarea acelui parametru de configurare, modulul va ști ce date trebuie extrase și prelucrate. Aplicația finală s-a proiectat pentru modul KPI, în care s-au folosit pentru prelucrarea datelor niște indicatori cheie de performanță.

KPI, în accepțiune universală, este un termen din managementul organizațiilor care își definesc niște criterii considerate importante și care ajută la progresul colectiv și individual. La prima vedere, am putea spune că acest termen este similar termenului de metrică de colecție, însă atribuirea acestei conotații ar fi greșită. În realitate, un KPI, sau un indicator cheie de performanță reprezintă mai mult decât o metrică. Pentru ca datele din mediile de colectare să fie valoroase pentru întreprindere trebuie ca analiza lor să se facă în sensul KPI.

Decizia cum că o metrică se poate califica drept un indicator cheie de performanță, aparține echipei de management a companiei, iar aceste companii trebuie să înțeleagă termenul de KPI cât și faptul că datele sunt interschimbabile și se pot transforma adesea din indicator cheie în metrică și invers, în funcțiile de interesele companiei pe termen lung sau scurt.

Un lucru important de precizat despre KPI ar fi faptul că, dacă un indicator cheie de performanță este o metrică, nu orice metrică se poate defini drept un indicator cheie de performanță. Altfel zis, nu toate metricile sunt foarte importante încât să fie considerate indicatori cheie. Fără indicatori cheie de performanță reali, o organizație nu va maximiza eforturile angajaților și nu-și va construi activitatea zilnică în jurul unei căi de succes. În esență, un KPI reprezintă comunicarea dintre un management eficient cu direcțiile de urmat în management. Pentru ca o metrică să devină un indicator cheie de performanță, trebuie să reflecte obiectivele organizaționale, să fie decisă drept fiind importantă în companie de către echipa de management, să furnizeze oricând un nou context , să se aplice la toate nivelurile organizatorice și mai ales să conducă la o decizie.

Indicatoarele de performanță (KPI) solide ne dau timp pentru a reacționa atunci când ceva important este pe cale să se întâmple. Nu se poate folosi orice fel de metrică pentru aceasta. Este nevoie de un efort întreținut, continuu pentru ca metricile considerate cheie în performanță sa reflecte cu adevărat încotro ne îndreptăm într-o companie. Nu se iau toate măsurătorile de pe o listă și se crează grafice la întâmplare. Este nevoie pentru colectare, de ani de preluări de date (luând în calcul și variațiile sezoniere și ciclice), atunci trebuie să facem analize masive, pentru a vedea ceea ce este cu adevărat important, și ce anume ne prezic în mod constant schimbările din organizație.

Făcând referire la modul de funcționare al modului de analiză, aș putea menționa că nu necesită o modelare UML specifică, datorită faptului că, prin proiectarea modulelor anterioare, avem o imagine de ansamblu asupra modului de comunicare între module.

Toată analiza datelor implementată în aplicație, se face într-un sens matematic, de aplicare ale unor formule matematice care să convertească anumite valori la niște etaloane de referință sau prin intermediul cererilor Sql, care să retragă date din baza de date generică.

Prelucrările matematice asupra datelor sunt realizate fie în interiorul cererilor, fie asupra unor variabile interne modului de analiză, care sunt apoi preluate direct în aplicația web proiectată. Pentru fiecare mediu colector se vor defini variabile și metode specifice, cât și clase analizatoare cu denumirile aferente prescurtare_nume_colector_statistics.php, care să apeleze acele metode și să ajute la proiectarea de grafice.

Modulul are o metodă generală prepareData, care va selecta toate înregistrările din baza de date generală și le va pregăti pentru analizare. Pe lângă aceasta, constructorul acestei clase DataAnalyser.php, ce reprezintă modulul de analiză al datelor, va crea atât o instanță de analizator, cât și o instanță a bazei de date la care se trimit cererile.

Este important ca la analiză să existe un reper legat de mediul de proveniență al datelor stocate în baza de date. Pentru aceasta, se va modifica baza de date a aplicației în sensul în care, pe câmpul param0 se va reține la fiecare inserare a unei date, numele/prescurtarea pentru mediul de colectare al acelui rând de tabelă. Dacă metricile colectate pentru un obiect de tipul Api vor proveni din jira, param0 al tabelei pentru acel rând din tabelă va avea valoarea ”jira”.

Precum discutam în cazul indicatorilor cheie de performanță, ceea ce-i diferențiază de simplele metrici, este faptul că acestora li se asociază de către echipa de management a organizației, o anumită importanță. În aplicație, această importanță a indicatorilor extrași, presupune modificarea bazei de date și în sensul în care, avem câmpuri suplimentare care sunt setate în raport cu valorile alor câmpuri dintr-un anumit mediu de colectare. De exemplu, în Jira defectele pot avea diferite rezoluții și stări. Ele pot fi rezolvate, nerezolvate, noi etc. . Acest lucru nu ne spune însă nimic despre importanța acestei metrici și nici nu transformă metrica precizată într-un indicator cheie de performanță. Ar fi mai interesant să cunoaștem ce valoare îi putem atribui unui câmp ”Resolved”, astfel încât să îmi faciliteze obținerea unui raport de defecte rezolvate comparativ cu cele încă noi pentru un anume utilizator etc..

Atribuirea importanței unui indicator se va face direct în baza de date a aplicației, prin intermediul unor cereri Sql și se vor formula ținând cont și de param0, adică mediul din care provin datele. Luând tot cazul Jira și exemplul anterior, atribuirea ”importanței” metricei ”resolution”, pentru un defect s-ar putea realiza prin: Update metrics SET param26 = ”3” where param10 like ”New” and param0 like ”jira”. Semnificațiile fiecărei modificări se vor afișa în interfața aplicației, ca o legendă la graficele cu statistici disponibile. Pentru exemplul analizat și tot pentru metrica rezoluție a unui defect jira, vom avea: Resolution: 0 – N/A, 1 – Dupplicate, 2 – Cannot Reproduce, 3 – New, 4 – Reopened, 5 – Fixed.

Un exemplu de metodă specifică prelucrării unei metrici ar putea constitui partea de cod:

public $unresolved;

public function getUnresolved(){

foreach($this->_allData as $_key => $_val){

if(isset($_val['param11'])){

$query = "Select COUNT(param11) as unresolved FROM metrics WHERE param11 != 'Fixed'";

$opened = $this->_dbInstance->sqlQueryFetchOneResult($query);

$this->unresolved = $opened['unresolved'];

}

}

return $this->unresolved;

}

Se observă că fiecare metodă după care se face analiza datelor, are nevoie de trimiterea unei cereri la baza de date din care va prelua un set de date cu care va opera ulterior. Pentru ca de fiecare dată când este apelată o metodă să nu fie necesar să creem o nouă instanță a bazei de date, se va prefera și se va utiliza o variabilă de clasă globală, inaccesibilă din exterior și care să nu-și modifice valoarea pe parcursul analizei datelor. Operațiile pe baza de date se vor face atunci, operând doar cu acea variabilă.

Din punct de vedere al încărcării variabilelor în memorie, acest modul ocupă cel mai mult spațiu, datorită numeroaselor variabile php în care se rețin metricile de interes, considerate indicatori cheie, ce vor fi ulterior afișate în interfață.

5.6. Afișarea in interfață

Tema proiectului m-a pus în postura de a explora resursele mediilor de lucru, și totodată, să cercetez cu atenție, modul în care funcționează o interfață grafică într-o companie, dar și cum se face aplică în mod practic noțiuni de management al organizației, astfel încât aplicația să afișeze operații elementare asupra unor metrici considerate KPI-uri.

În ceea ce privește utilitatea interfeței obținute, aș putea spune că nu cuprinde o mare gamă de funcții folosite și că, în momentul de față, o putem deservi doar domeniului de management organizațional modelat prin automatizarea procesului de prelucrare al unor date relevante pentru organizație. Utilitatea aplicației, ar deriva din meniul Statistics, care este intuitiv și foarte ușor de folosit și execută operații de afișare a metricilor de interes din aplicația web dezvoltată.

Din punct de vedere al organizării informațiilor pe panoul frontal al interfeței și al structurii aplicației web, aceasta este impărțită în meniuri sugestive, ce afișează informații dintr-o anumită sferă. O imagine de ansamblu asupra aplicației web proiectate este prezentată în Anexa 5 – Interfața aplicației web.

Partea mai complicată în dezvoltarea interfeței web, este cea de implementare a operațiilor asupra metricilor, urmărind totodată asigurarea modulelor independente cât și asigurarea funcționalității interfeței finale.

Dacă ar fi să menționez câteva dintre trăsăturile aplicației, acestea ar fi:

Ușor de folosit;

Pune în practică teoria privind proiectarea aplicațiilor web, a proiectării software și a metricilor de colecție;

Evidențiază resursele fiecărei tehnologii sau uneltele folosite;

Include resursele mediilor de colectare într-o interfață destul de plăcută utilizatorului;

Butoanele sunt intuitive.

Pentru a înțelege modul în care aplicația funcționează, trebuie descrise în detaliu ce anume s-a implementat prin interfață, cât și modul în care datele afișate sunt preluate.

Aplicația proiectată cu toare resursele descrise în capitolele anterioare, realizează o contorizare a tuturor metricilor și permite utilizatorilor din interiorul companiei să acceseze statistici considerate semnificative despre activitatea lor și a echipelor din organizație.

Din punct de vedere al realizării practice a aplicației s-au implementat paginile acesteia cu resursele tehnologiilor Javascript, Jquery, HTML 5.0, ReST Web Services, PHP 5.4 și s-a lucrat Eclipse Zend Framework, încercându-se o exploatare eficientă a tehnologiilor, cu scopul final al afișării de statistici cu metricile colectate.

Pe lângă criteriul utilizării tuturor modulelor în momentul rulării aplicației, trebuie ținut cont de criteriul integrării aplicației în activitatea firmei 4PSA, urmărindu-se un aspect funcțional, plăcut, și profesional. Toate resursele de natură grafică: figuri, sigle și link-uri oficiale legate de organizație sunt utilizate cu acordul prealabil al reprezentanților firmei.

Deoarece accesul la serverele companiei este îngrădit de criteriile de confidențialitate, cât și pentru protecția datelor companiei de terți utilizatori, aplicația poate fi rulată și simulată ca și funcționalitate completă pe un server local, deși toată proiectarea acesteia s-a desfășurat pe cloud-ul privat la organizației 4PSA S.R.L.. Întreaga aplicație web proiectată constituie directorul /Web al proiectului php dezvoltat și cuprinde fișiere structurate după tehnologia folosită, pentru ca modificările ulterioare să fie ușor de identificat și de actualizat. De asemenea, se optează pentru o structură organizată de directoare, respectând principii de organizare internă ale companiei și chiar și o organizare proprie a muncii de dezvoltator.

De asemenea, aplicația web furnizată ca soluție este scrisă aproape integral în limba engleză, ținând cont că toată documentația firmei, cât și soluțiile software oferite de aceasta, sunt dezvoltate integral în limba engleză.

5.6.1. Descrierea meniurilor

Ca în orice aplicație web existentă, aplicația proiectată rulează de pe serverul local, deschizându-se cu pagina Home, constituită dintr-un fișier index.html. Pagina afișată va fi meniul Home al aplicației. Rularea pe serverul local se face prin instalarea unui program wampp (Windows-Apache – MySql – Php) pentru Windows, iar baza de date folosită va fi o bază de date duplicat a celei folosite de companie, din același motiv al confidențialității datelor și a protecției lor. Această bază de date este importantă în phpmyadmin, pe serverul local, iar rularea aplicației se face direct din browser, de la adresa: http://localhost:89/bogdant_linux/Licenta/Web.

Din punct de vedere al datelor afișate, meniul Home nu este foarte reprezentat în aplicație. Toate butoanele pentru meniu sunt definite într-o listă nenumerorată html și sunt descrise ca și formatare în fișierul /css/style.css asociat tuturor paginilor aplicației. Toate paginile meniului vor avea astfel același efect stabilit pentru apăsarea pe un buton de meniu, aceiași culoare pentru butoanele meniurilor, același font și vor încorpora în prezentarea lor același header și footer.

Meniul Home va afișa o pagină în care se precizează că toate elementele ce țin de afișare vor fi introduse în aplicație. În rest, pagina cuprinde porțiuni comune de cod cu celelalte meniuri, a căror prezentare o voi face în cadrul meniului Home, fără a reveni ulterior la detalierea acestor porțiuni.

Stilurile de formatare și modul în care informația este prezentată în pagină țin de funcțiile limbajului Javascript și în special de bibliotecile Jquery și Ajax. În aplicație o parte dintre fișierele cu funcții pentru aceste biblioteci sunt open-source și se regăsesc pe site-uri oficiale ale furnizorului de servicii internet, Google. Importul acestor fișiere cu funcții asupra unor elemente din pagină identificate după id, sau prin simpla atribuire a unei clase în tagul unui element html, se va face în head-ul (porțiunea head a unei pagini html), prin referire fie la link-ul de la o adresă internet, fie la un fișier cu extensia .js, stocat local în calculatorul personal. Un exemplu de includere a acestor fișiere aflate la o adresă web, sau în calculatorul personal se face după caz, astfel: <script src="js/Myriad_Pro_300.font.js" type="text/javascript"></script>.

De asemenea, și foile de stil asociate paginii se vor încărca tot în această secțiune de head, a documentului html, prin: <link href="style.css" rel="stylesheet" type="text/css" />.

O altă porțiune comună de cod tuturor paginilor din aplicație este cea în care sunt încărcate siglele mediilor de colectare, cât și imaginea stilizată a roboților grafici, iar încărcarea acestora se face ca și diviziuni ale paginii separate, care au asociat un stil definit local, în aceiași pagină html. Acestea se încarcă în css-ul documentelor html și au asociate și funcții specifice Jquery pentru animații.

Figura 5.6. – Prezentarea meniurilor

Imaginile din dreapta sus a aplicației se incarcă printr-un simplu tag html <img src=”…”/> din directorul /images și sunt personalizate pentru fiecare meniu în parte, pentru meniul de contact lipsind o imagine asociată, însă.

Sigla companiei, din partea stângă a paginii conține un link către pagina principală a aplicației, indiferent de meniul în care ne aflăm la o simplă navigare. Siglele din partea centrală, asociate mediilor de colectare a metricilor, conțin link-uri către adresele web interne companiei, fie către site-uri web care nu sunt stocate pe un server local al organizației și pot fi accesate online, cum ar fi cazul Google Analytics sau Get Satisfaction. Celelalte link-uri fac referire direct la serverele companiei și funcționalitatea lor nu poate fi disponibilă, fără accesul la servere.

Fiecare meniu are asociat un efect de tranziție al mouse-ului care la trecerea peste un buton al meniului să execute un efect grafic asupra acelui buton. Efectul consă în schimbarea unor imagini din css-ul documentului și definirea unei clase ”active” pentru un buton, căreia i se asociază atât reguli css pentru fiecare buton în parte cât și o funcție javascript care să permită acel efect de tranziție al mouse-ului. O bucată de cod asociată la navigarea prin meniurile aplicației cu o simplă mișcare a mouse-ului:

#header .row-2 ul li.m3 a {width:117px;font-size: 16px;color: #FA870C;text-shadow: 0.01em 0.01em #000;font-weight:bold; background:url(images/m3.png)}

#header .row-2 ul li.m3 a:hover,

#header .row-2 ul li.m3 a.active {background:url(images/m3-act.png)}

O parte dintre fișierele javascript folosite în aplicație sunt disponibile online și sunt proprietatea companiei Adobe. Termenii legali de folosire a acestor fișiere, precum și condițiile de utilizare permit utilizarea acestor fișiere în scopuri necomerciale.

Fiecare pagină pe care se poate face un expand, sau prin care navigăm cu un simplu scroll al mouselui se folosește un plugin Jquery, care face prezentă apariția unui buton. Butonul are rol de Back to top – în traducere, înapoi la începutul paginii, și execută această funcție prin intermediul unui fișier javascript importat, și a unei funcții jquery. Funcția responsabilă cu acest efect face o parsare a documentului pentru care se apelează după numele tagului html care depășește dimensiunea paginii și va muta cursorul la o poziție relativă, setată printr-un calcul matematic asociat. Funcția se rezumă la secțiunea de cod următoare și îmbină elemente de jquery cu cele de css:

$(window).scroll(function() {

var sd = $(window).scrollTop();

if(typeof document.body.style.maxHeight === "undefined") {

$(containerIDhash).css({

'position': 'absolute',

'top': sd + $(window).height() – 50

});}

De asemenea, printre setările generale ale paginilor proiectate, se preferă utilizarea de headere de text cunoscute h1, h2, h3 etc., pentru porțiunile de titluri din pagini și se personalizează aceste headere, prin intermediul foii de stil a documentelor html.

Secțiunea de meniu din dreapta paginii va apărea indiferent de meniu și este partea interesantă a aplicației, cea răspunzătoare de trasarea graficilor cu metricile. Graficile se trasează în funcție de datele înregistrate într-un tabel, prin intermediul unei cereri la baza de date unde metricile sunt stocate. DataAnalyser, sau modulul de analiză al datelor va furniza aceste metrici, iar apelul fișierelor cu aceste grafice considerate relevante pentru activitatea organizației, se face printr-un link direct la fișierele de pe server, denumite în funcție de numele mediului de colectare xGraphs.php, unde x este numele colectorului. Aceste fișiere vor conține propria foaie comună de stil și sunt încadrate în aplicație ca și foi independente. Modulul de simulare prezentat prin aplicația proiectată nu va include o serie de date numeroase, deoarece toate operațiile asupra metricilor stocate în baza de date, se fac pe un eșantion mic, pentru a nu altera datele din mediile de stocare.

Trasarea graficelor este responsabilitatea Jquery și Javascript care pun la dispoziție o serie de funcții specifice necesare implementării acestor fișiere statistice. În cazul Jira, unde datele sunt numeroase, graficile pot apărea însă un pic distorsionate, la fel cum și în cazul în care o metrică depinde atât pe axa coordonatelor, cât și a ordonatelor de aceleași valori, pentru aceleași puncte, graficele pot să nu genereze nimic. Evitarea acestei situații ține de dezvoltări ulterioare a aplicației și nu s-a luat în calcul în interfața proiectată. La fel ca și headerul documentului, această secțiune de grafice rămâne afișată pe toată durata navigării în interfață.

Alături de elementele comune și celorlalte pagini proiectate, pagina de Home mai cuprinde și o secțiune de Recent Updates, unde vor fi trecute notificări cu privire la ultimile modificări aduse interfeței. Modificările se trec în taguri definite ca și diviziuni din documentul html asociat paginii de index și au definite, la fel ca majoritatea elementelor din pagină, stiluri de formatare css specifice. Pentru fiecare pagină a aplicației, este disponibilă ora ultimei modificări, calculată printr-o funcție javascript.

Meniul Statistics, prezintă TV Dashboard-ul aplicației, așa cum apar rezumate, pe fiecare mediu de colectare în parte o serie de statistici rapide. Fiecare mediu are asociat un tabel cu dimensiune fixă, cu câmpuri grupate pe arii de interes pentru organizație și care conține text și numere obținute prin metricile colectate.

Figura 5.7. – Meniul Statistics

În mod normal, la rularea aplicației pe serverul companiei, statisticile rapide s-ar putea modifica în timp real, cu fiecare rulare a modulului de control, care comunică atât cu modulul de colectare prin inițializarea api-urile din bibliotecile colectoare, cât și cu modulul de stocare, prin stocarea datelor și retragere de statistici relevante. Deoarece lipsa de permisiuni de acces la serverul companiei a impus rularea aplicației pe un server local, statisticile din meniul asociat, Statistics vor apărea ca și conținut static. O simplă studiere a codului din spatele aplicației web, ar motiva afirmația conform căreia conținutul fiecărui tabel este dinamic, fiecare informație din celula unui mediu/ widget din aplicație, făcând apel la o metodă specifică din modulul de analiză al datelor.

Pentru Jira, spre exemplu, celula tabelului Sales Management Overview, este implementată la nivel de cod astfel:

<tr>

<th id='th' bgcolor='#C0C0C0 '>Sales Management (<font color='#007488' size='4'

style='text-shadow: .5px .5px #000000;'>Project Based</font>)

</th>

</tr>

<tr>

<td align='right'>;

<?php

print "<pre><font size=1.9875>";

$analyse->getNextRelease();

$analyse->getNewTasks();

$analyse->getClosedTasks();

?>

</td>

</tr>

Toate tabelele cu Widget-urile (dispozitive rapide), pentru fiecare mediu de colectare sunt grupate într-un panou de tip flip-flow, care se poate extinde sau minimiza, în funcție de necesitatea urmăririi acestor informații de conținut.

Panoul de tabele cu statistici rapide realizează această funcție de minimizare/ extindere prin apelul unui script jquery și mai precis, prin intermediul funcției slideToggle() din același fișier Statistics.php.

Pe lângă aceste statistici, meniul Statistics al aplicației reproduce elementele comune menționate în prezentul capitol, la prezentarea meniului Home.

Meniul Environment, cuprinde o porțiune de text statică și elementele comune tuturor paginilor aplicației proiectate.

Figura 5.8. – Meniul Environment

În funcție de mediul de colectare, o listă a tuturor metricilor este prezentată. Scopul este acela al centralizării metricilor într-o singură pagină, pentru ca la adăugări ulterioare de metrici, să se cunoscă metricile deja implementate. Am precizat anterior în proiectarea aplicației, că responsabilitatea colectării metricilor, cât și cea a afișării lor în interfață aparține exclusiv programatorului. Clientul nu trebuie să fie conștient de modul în care se realizează toate operațiile din spatele aplicației, însă o listă a metricilor din aplicație este interesantă.

Meniul Contact, este meniul de informații suplimentare asupra implementării proiectului. Atât pentru organizație, cât și pentru utilizatorii aplicației, este interesant de cunoscut cine s-a ocupat de proiect, pentru delegarea responsabilităților și tragerea la răspundere în cazul unor defecțiuni. Pentru fiecare persoană implicată, sunt precizate responsabilitățile din cadrul proiectului, numele cu legătură către adresa de e-mail a persoanei, cât și funcția din cadrul companiei, la momentul desfășurării proiectului. Asupra imaginilor persoanelor din echipa de dezvoltare s-a aplicat un efect de hover, din css-ul aplicației, sub forma:

.col-1 img {

height: 110px;

width: 85px;

-webkit-transition: all 1s ease;

-moz-transition: all 1s ease;

-o-transition: all 1s ease;

-ms-transition: all 1s ease;

transition: all 1s ease;

}

.col-1 img:hover {

width: 120px;

height: 140px;

}

O captură a tuturor paginilor din aplicație, precum și a statisticilor aferente cu metricile, sunt prezentate în anexa 5 – Interfața aplicației web.

Meniul din partea dreaptă a aplicației este răspunzător cu trasarea de grafice pentru metricile relevante din aplicație. Trasarea graficilor se face prin intermediul unor extensii jquery, disponibile online și open source, care se bazează pe construirea de imagini cu grafice de diferite forme – histograme, pie (plăcintă), radiale, punând pe axa ordonatelor valorile din prima coloană a tabelului și trasând liniile graficelor raportând acea coloană la restul de date extrase.

Trebuie precizat că graficele nu sunt foarte complexe, deoarece disponibilitatea redusă a datelor companiei nu a permis acest lucru. Tabela de test cu metrici din companie, cuprinde în jur de 200 înregistrări, iar modulul de analiză furnizează date reduse prin interogarea bazei de date. Deși graficele nu sunt foarte complexe și datele din tabela meniului Statistics, nu sunt actualizate automat, datorită lipsei de permisiuni pentru accesarea unui server privat, s-au proiectat în aplicație ca un studiu al automatizării colectării, stocării și analizei metricilor, scopul final al aplicației web proiectate.

Capitolul 6 –TESTAREA și INTEGRAREA APLICAȚIEI

6.1. Testarea aplicației

Testarea aplicației reprezintă etapa finală a oricărui ciclu de producție software și implicit a lucrării de față. O percepție comună asupra testării constă în testele rulate astfel încât software-ul să ruleze fără nicio restricție. Trebuie precizat că activitatea de testare în cadrul aplicației proiectate nu s-a desfășurat doar la finalul aplicației proiectate, ci în permanență, activitatea de testare implicând planificare și control, alegerea condițiilor de testare, proiectarea și executarea unor scenarii de testare, evaluarea ieșirilor raportată la intrări, etc.. La încheierea oricărei etape de testare s-au remarcat condițiile care fac aplicația să fie sigură în rulare, astfel încât integrarea modulelor să se facă cu ușurință și cu succes în interfața aplicației.

Atât testarea statică cât și cea dinamică asupra aplicației furnizează informații cu privire la cum poate fi îmbunătățită aplicația, cât și despre cum să se desfășoare pe mai departe procesul de dezvoltare într-un anumit punct.

La testarea aplicației proiectate, s-au avut în vedere o serie de obiective, care includeau găsirea defectelor, câștigarea încrederii prinvind standardele de calitate impuse de companie, furnizarea de decizii viitoare cât și prevenirea defectelor din aplicație.

O serie de defecte identificate referitoare la timpii de execuție prea mari, un cod neoptimizat sau incorect documentat la un anumit timp în dezvoltare, poate declanșa o serie de evenimente care pot avea drept efect distrugerea fizică a aplicației, nefuncționarea corectă a unui modul independent, pierderea timpului cu rezolvarea defectelor și în modul cel mai general, pierderea banilor companiei.

O metodă de testare aplicată conform ITSQB, este și documentarea corespunzătoare a claselor și metodelor fiecărei clase, astfel încât dezvoltările ulterioare să indice liniile directoare, cât și funcționalitățile ce trebuie conservate.

În testarea de dezvoltare, principalul obiectiv l-a constituit implementarea unor situații considerate neplăcute pentru aplicație, astfel încât eșecurile datorate timpilor de execuție mari, sau informularea corectă a unei cereri la server să furnizeze un rezultat nedorit. Se pot aplica și aceste situații, scopul lor clar fiind acela de a identifica din start defectele și a le evita ori de câte ori este cazul.

Pentru aplicația web de afișare a metricilor și a statisticilor cu acestea, o serie de obiective și sarcini specifice privind testarea și execuția testelor au inclus:

Finalizarea, implementarea și prioritizarea funcționalităților aplicației precum și luarea în considerare a unor defecte ce pot apărea;

Identificarea defectelor apărute cu dezvoltarea fiecărui modul în parte al aplicației;

Debugging – sau corectarea porțiunilor de cod acolo unde este cazul încât aplicația să aibă funcționalitatea corectă dată de specificații;

Dezvoltarea procedurilor de testare manuală, în primă etapă, și luarea în calcul a unor teste automate la finalizarea aplicației;

Executarea unor teste ce pot implica chiar și setarea intenționată a unor parametri greșiți în metodele claselor sau de cereri incorecte construite la nivelul clientului fiecărui API, cu scopul identificării eventualelor breșe de securitate sau a unor defecte în aplicație;

Raportarea defectelor în cazul identificării lor;

Corectarea defectelor raportate;

Retestarea aplicației.

Pentru testarea de dezvoltare a aplicației proiectate s-a folosit un model în V, care include, din punct de vedere al dezvoltatorilor software și al ghidului de certificare în testare, patru nivele de testare în etapa de la vârful V-ului înspre livrarea produsului final.

Testarea unitară a modulelor/componentelor este prima componentă a dezvoltării din modelul V și s-a efectuat pentru fiecare dintre modulele independente ale aplicației, odată cu creșterea liniilor de cod și implementarea de funcționalități modulare. Testarea unitară a inclus etapele de la simpla proiectare a claselor și implementarea claselor de test pentru fiecare modul independent proiectat, până la o revedere a codului și corectarea sa conform cu standardele companiei și ale regulilor de documentare a metodelor și fișierelor. Testarea unitară a presupus ca fiecare modul al aplicației să fie dezvoltat la modul general, încât să poată fi folosit și ca parte independentă într-o aplicație similară dezvoltată.

În virtutea testării unitare, voi furniza câteva scenarii de test pentru aplicație. De exemplu, în aplicația dezvoltată, trimiterea de cereri succesive la serverul intern al companiei, în vederea colectării datelor, poate duce la timpi de procesare ai cererilor mari, fapt ce ar putea returna drept rezultat eroarea HTTP 500 – Internal server error (eroare internă a serverului). De asemenea, la încercarea de conectare nepotrivită, prin parametri diferiți față de cei corecți la un mediu de colectare și trimiterea oricărei cereri ulterioare, poate furniza drept răspuns eroarea HTTP 404 – Not found (obiect negăsit), sau chiar o eroare HTTP 400 – Bad request (cerere incorectă). Eroarea HTTP 501 – Permission denied (permisiune refuzată), este dată de fiecare dată când se accesează o resursă la care utilizatorul nu are acces. Acestea sunt doar câteva dintre efectele identificate în formularea cererilor ReST pentru colectarea datelor și care au fost corectate încă din etapa de proiectare a modulului de colectare al datelor.

Și pentru celelalte module ale aplicației s-au efectuat teste unitare. Însă un deziderent al testării și poate chiar și o tendință actuală este implementarea testelor automate.

Testarea automată presupune scrierea unor script-uri PHP, deoarece modulele sunt dezvoltate aproape integral în PHP5.4, care la rularea lor să afișeze rezultate relevante de trecut sau eșuat pentru fiecare metodă a clasei. Pentru aplicația dezvoltată, modulul de testare automată este încă în etapă incipientă și nu a fost inclus în aplicația proiectată.

Pentru a analiza rezultatul unui test automat, pentru instanțele de medii colectoare, de tipul Singleton, voi furniza drept exemplu o porțiune de cod relevantă, cât și rezultatele testelor. Pentru a putea implementa testul automat de Singleton, este necesară existența pachetului php pear. O serie de setări trebuie făcute pentru integrarea pachetului Pear în proiectul existent.

Șablonul de proiectare Singleton este un șablon comun în programarea orientată pe obiecte. În PHP, spre deosebire de Java, acest șablon de proiectare impune probleme în adresare a unor teste automate. Nu putem implementa cazuri ale șablonului persistente, între solicitările noastre (fără nici un mecanism persistent, cum ar fi o bază de date, sau un server extern). În PHP putem să împărțim aceeași instanță singleton, cu acest model, în script-ul nostru. Indiferent unde ne aflăm, vom folosi TestSingleton:: getInstance () și ajungem la exemplul relatat. Acest test automat făcut, este util atunci când lucrăm, de exemplu, cu conexiuni la baza de date. Pentru a testa inițializarea unui Singleton, vom folosi o clasă precum urmează:

require_once 'PHPUnit/Framework/MockObject/Autoload.php';

class TestSingleton extends PHPUnit_Framework_TestCase{

public function testGetInstance(){

$cf = new CollectorFactory();

$jc = $cf->makeCollector(‘jira’);

$this->assertInstanceOf('JiraCollector',JiraCollector::getInstance()); }

}

De asemenea, pentru ca acea punere în comun a metodei de testare să nu altereze rezultatele testului, atunci când avem mai multe instanțe create, indiferent de tipul lor (testul va eșua), trebuie să implementăm în fiecare clasă, sau în cazul nostru în clasa părinte tuturor colectorilor, o metodă tearDown, după cum urmează:

public static function tearDown() { static::$instance = NULL; }

În clasa de test va fi suficientă o singură metodă, teardown, în forma:

public function tearDown() { JiraCollector::tearDown(); }

, iar testul automat nu va mai eșua în acest caz.

Figura 7.1. – Rezultatul testării automate

Alte serii de teste ce pot fi făcute doar după finalizarea completă a aplicației, chiar și cu adăugarea dezvoltărilor viitoare, din capitolul 7 al lucrării, pot include: testarea de acceptare a clientului, testarea de mentenanță și testarea funcțională, iar descrierea lor nu constituie subiectul subcapitolului 6.1..

6.2. Integrarea modulelor

Integrarea modulelor presupune cunoașterea tuturor modulelor ale aplicației, și ca toate etapele intermediare, până în acest moment, să fie complete, astfel încât părțile integrante să ofere un tot unitar, un produs funcțional.

În scop declarativ, aș putea afirma că și integrarea modulelor presupune o strategie de testare, ținând cont că la integrarea fiecărui modul în aplicație trebuie să se asigure funcționalitatea totală a interfeței. Integrarea între diferitele module independente s-a făcut progresiv, o dată cu dezvoltarea fiecăruia dintre ele și un pas premergător important în aplicație l-a constituit modelarea software a aplicației și modul comun de construcție al fiecărui modul, după criterii și reguli comune, stabilite de dezvoltator.

Interacțiunea dintre diferitele module independente ale sistemului, este un criteriu important la integrarea acestora în aplicație, la fel cum, de altfel, trebuie luat în considerare integrarea doar după ce testarea pe fiecare componentă a aplicației s-a realizat.

Scopul general al integrării este acela de a avea o aplicație completă, în care, fiecare modul să joace rolul său, contribuind la asigurarea cerințelor funcționale specificate încă din formularea problemei prezentei lucrări.

Din punct de vedere al strategiei de integrare al modulelor, trebuie să facem din nou conexiunea cu modelul de arhitectură generală a aplicației, la cerințele funcționale ale aplicației, cât și la regulile de proiectare. Pentru a se asigura izolarea defectelor ce pot apărea, cât și pentru reducerea riscului de erori grave, se propune ca integrarea modulelor să se facă în manieră incrementală, cu fiecare modul, mai degrabă, decât să se aleagă o strategie de integrare de tipul ”big bang”, unde resursele se adună la comun fără a stabili cum se realizează integrarea. Tot ca și soluție de integrare, în fiecare stadiul al realizării integrării, dezvoltatorul trebuie să aibă în vedere doar această etapă în care se află, și să testeze mai mult modul în care comunică modulele între ele, decât să piardă o parte din timp cu retestarea unitară, deja finalizată în această fază a proiectului.

Integrarea este ultima etapă în proiectarea unei astfel de aplicații, însă aș putea afirma că din punct de vedere al planificării integrării, această planificare trebuie să se realizeze încă de la început, pentru ca fiecare modul construit să se adapteze modulului de integrare și să nu fie necesar a fi făcute modificări în arhitectura aplicației, cu fiecare modul nou adăugat. Integrarea face posibilă comunicarea între module și funcționarea aplicației web proiectate, și fac aplicația utilizabilă, în forma în care va fi introdusă în activitatea firmei 4PSA.

Capitolul 7 – Dezvoltări viitoare și concluzii

7.1. Dezvoltări viitoare

Lucrarea de față abordează o temă actuală de care managerii organizațiilor din întreaga lume se lovesc permanent: evaluarea progresului organizației raportată la progresul individual al angajaților săi și al echipelor din care aceștia fac parte.

Raportându-ne la aplicația dezvoltată, cât și la domeniul metricilor de colecție, dezvoltările ulterioare ale aplicației ar implica atât adăugarea de module suplimentare, cât și operații de mentenanță care să asigure funcționarea corectă a interfeței în orice moment.

Așadar, pe lângă importanța asigurării funcționalității corecte a modulelor independente, modulului Controller al aplicației i se poate adăuga un fișier intern de configurare care să execute scripturile de generare al bibliotecilor colectoare periodic, la un anumit interval de timp. Execuția periodică a aplicației la un anumit interval asigură astfel de faptul că informațiile din interfață sunt menținute la zi (updatate), încât cel ce le manevrează ulterior să nu fie nevoit să execute la rândul său, operații suplimentare, consumatoare de timp.

Trebuie ținut cont ca, la adăugarea unui nou modul, să se testeze unitar funcționalitatea acestuia și să se integreze în aplicația finală, fără alterarea funcționalităților existente. Verificarea întregului presupune retestarea periodică a întregii aplicații.

Modulul de analiză al datelor se poate modifica în permanență, deoarece nu toți indicii de importanță atribuiți metricilor, pot fi relevanți și pentru o altă organizație exact în aceiași ordine. Deși utilizatorul final nu este conștient de ceea ce se ascunde în spatele interfeței, trebuie să existe un dezvoltator care să cunoască configurarea modulului Controller al aplicației și pe care să îl updateze permanent, raportându-se la cerințele de management. De asemenea, o ultimă posibilitate de dezvoltare a aplicației, trebuie să țină cont de faptul că, căutarea în spațiul de configurații al fiecărui modul se face permanent și automat.

Dezvoltări ulterioare la interfața grafică pot include: implementarea unui formular de înregistrare și autentificare, pentru utilizatori diferiți, astfel încât să se poată autentifica pe site și să vizualizeze statistici cu metricile colectate, în funcție de aria de interes.

De asemenea, știm că aplicația web proiectată este parametrizabilă doar la nivelul fișierelor de configurare. Doar dezvoltatorii au acces la acestea, însă deziderentul aplicației printr-o dezvoltare ulterioară, ar fi ca și utilizatori de alt profil și formație decât tehnică, din echipa de vânzări să spunem, să poată preciza ce metrici își doresc să vizualizeze, printr-un formular. Prelucrarea extragerii metricilor și în final a afișării metricilor s-ar face tot la nivelul fișierelor de configurare, lucru ce ar presupune o scriere în fișier.

De dezvoltările ulterioare ține și implementarea unei biblioteci bazată pe cereri ReST pentru mediul de colectare Confluence. În prezent, doar o bibliotecă SOAP a fost proiectată, colectarea metricilor s-a realizat cu succes, rezultatele fiind prezentate în Anexa 6 a prezentei lucrări.

7.2. Concluzii finale

Necesitatea înțelegerii metricilor de colecție și a modelului de dezvoltare agilă a diverșilor cercetători în domeniul managementului de dezvoltare software într-o organizație, a fost discutată pe parcursul întregii lucrări.

Putem considera căutarea unor metrici elocvente în spațiul organizației, un proces anevoios în măsura în care se face manual și nu automatizat. Propunerea unei soluții de automatizare al tuturor proceselor de căutare, colectare și stocare a metricilor în vederea analizei lor, aduce așadar o serie de avantaje incontestabile în evoluția unei organizații aflate într-o dinamică ascendentă, avanaje ce le vom discuta în cele ce urmează.

Cel mai important impediment întâlnit în dezvoltarea aplicației se datorează cu siguranță unor constrângeri temporale. Optimizarea unei arhitecturi software eficiente care să prelucreze în timp real metricile și să genereze statistici adecvate contextului din care metricile au fost extrase, s-a dovedit a fi un proces consumator de resurse temporale, depinzând de numeroși factori organizaționali. Atât strictețea regulilor de codare și dezvoltare, cât și parcurgerea tuturor etapelor unui proiect din faza incipientă până în faza de livrare a produsului final, cât și însușirea unor cunoștințe privind dezvoltarea în cadrul organizației, dar și modul în care procesele au evoluat în mediul de lucru, au fost variabile care au contribuit major la stadiul în care aplicația a ajuns în dezvoltare.

În ceea ce privește importanța aplicației dezvoltate, precum și a seriei de avantaje menționate anterior, putem enumera câteva aporturi considerabile ale automatizării proceselor de colectare, stocare și analiză a metricilor, precum urmează:

Stimularea progresului individual și de echipă;

Aplicația va fi integrată în activitatea firmei 4PSA;

Aplicția îmbină metode de management agile cu noțiuni teoretice de management, aplicându-le în domeniul dezvoltării software și prezintă în final o soluție automatizată;

Automatizarea proceselor se face cu minimizarea de timpi de procesare a unor date cantitative în primul rând, aportul privind calitatea rezultatelor obținute aparținând exclusiv dezvoltatorului;

Automatizarea acestor procese are un impact considerabil asupra viitoarelor evaluări realiste ale progresului în puncte bine definite;

Datorită punerii la dispoziție al unui astfel de produs, timpii morți din cadrul organizației pot fi eliminați aproape în întregime;

Toate viitoarele rapoarte ale calității muncii, ale progresului organizațional și ale succesului vor fi evaluate în mod mai obiectiv, responsabilitatea asupra întocmirii lor ne mai aparținând unei persoane ci exclusiv calculatorului.

Ajunge să concluzionăm, fără a repeta cunoștințele teoretice expuse în întreaga lucrare, că metricile sunt importante atât timp cât furnizează statistici reale, obiective. Timpul de colectare al acestora depinde de modul în care organizația furnizeză date ale progresului său, iar impactul metricilor este vizibil oricărui angajat, în orice moment bine definit al progresului.

Găsirea unei metode eficiente de căutare a metricilor este și va rămâne întotdeauna o prioritate, dar totodată și o problemă actuală a procesului de colectare. Una dintre soluțiile acestei probleme o reprezintă utilizarea de algoritmi "inteligenți" (machine learning).

Automatizarea celorlalte procese (stocare, analiză) referitoare la metrici și cumularea lor într-o interfață a adus un câștig considerabil de performanță organizației și a redus timpii de procesare, așa cum s-a demonstrat în întreaga lucrare.

Toate concluziile enumerate nu fac decât să întărească supoziții generale ale managerilor de top din întreaga industrie informatică, potrivit căreia viitorul aparține unei societăți în schimbare care are o permanentă nevoie de ghidaj a acțiunilor sale și în care orice părticică din cadrul unui întreg esta caracterizată de indicatori ai progresului său, indicatori ce au un impact esențial asupra a tot ceea ce se întâmplă într-o organizație, indiferent de mărimea sau domeniul în care aceasta (n.b. organizația) activează.

Participarea efectivă la dezvoltarea unei aplicații din etapa sa de prelucrare și până la finalizarea sa ulterioară mi-au permis să intru în contact cu tehnologii noi din domeniul de Ingineria Sistemelor de Programe (din engleză, Software Engineering) .

Punerea la dispoziție de către firma la care s-a desfașurat lucrarea, a tehnologiilor și a tuturor resurselor de calcul/fizice mi-au permis de asemenea să intru în contact cu ideea de echipă de dezvoltare, să îmi explorez limitele și să invăț să proiectez dupa șabloane de dezvoltare interne companiei, aplicații care să fie ulterior integrate în activitatea companiei. Aplicația finală va fi utilizată în activitatea de zi cu zi a companiei și va servi la contorizarea în mod de timp real a unor parametri ai eficienței activității individuale a angajaților, cât și a eficienței unei echipe și va ajuta la o evaluare mai obiectivă a activităților desfașurate în companie.

Ca și dezvoltator al unei aplicații complexe de acest tip, am observat ca adesea nu doar cunoștințele într-un singur domeniu sunt necesare și că dezvoltarea și integrarea unui nou modul la o aplicație constituie pe lângă planificarea sarcinilor și o viziune până la cel mai mic detaliu asupra codului scris, ceea ce face ca aplicația finală să fie completă, funcțională și utilizabilă – scop final al unei aplicații web, până la urmă.

BIBLIOGRAFIE

Articole științifice:

[SD-1] ***, "Application Development (AppDev) Defined and Explained". Bestpricecomputers.co.uk. 2007-08-13. Retrieved 2012-08-05, accesat la data 08.05.2013.

[PHP-2] ***, Arbor Software, "Multidimensional Analysis: Converting Corporate Data Into Strategic Information" – White Paper

[CC-1] How Cloud Computer Works, http://www.howstuffworks.com/cloud-computing/cloud-computing.htm , accesat la data 14.04.2013.

[CC-2] ***, Lohr, Steve. "Cloud Computing and EMC Deal." New York Times. Feb. 25, 2008. pg. C 6.

[CC-3] ***, Markoff, John. "Software via the Internet: Microsoft in 'Cloud' Computing." New York Times. Sep. 3, 2007. pg. C 1

[SQL-3] ***, MySQL Reference Manual for version 3.21.29

Bibliografie web:

[AII-1] Catedra AII, Sectiunea Studii de licenta, Lucrari in colaborare cu firme de profil – http://aii.pub.ro/index.php?option=com_content&view=article&id=309:automation-of-organization-metrics-gathering-and-analysis&catid=41:lucrari-de-licenta-colaborari-cu-firme-de-profil&Itemid=49 – accesat la data 14.06.2013.

[KPI-1] Best Practices using Metrics , http://nsdlnetwork.org/sites/default/files/BestPracticesMetrics-NSDLAug2010_4.pdf , accesat la data 24.05.2013.

[KPI-2] KPI and metrics, http://www.uie.com/brainsparks/2012/10/05/kpis-are-metrics-but-not-all-metrics-are-kpis/, accesat la data 09.03.2013.

[REST-2] ReST Introduction, http://www.infoq.com/articles/rest-introduction, accesat la data 12.04.2013.

[CC-4] ***, "IBM Introduces Ready-to-Use Cloud Computing." IBM. Nov. 15, 2007. http://www-03.ibm.com/press/us/en/pressrelease/22613.wss, accesat la data 04.05.2013.

[CC-5] ***, Naone, Erica. "Computer in the Cloud." Technology Review. Sept. 18, 2007. Retrieved March 12, 2008. http://www.technologyreview.com/Infotech/19397/?a=f , accesat la data 08.04.2013.

[REST-3] ReST Api, http://developer.zendesk.com/documentation/rest_api/introduction.html#headers , accesat la data 28.03.2013.

[CSS-1] The Beauty Of CSS Design, http://www.csszengarden.com, accesat la data 28.05.2013.

[CSS-2] Web Design, Use CSS Today, http://www.moock.org/webdesign/css/, accesat la data 29.05.2013.

[AC-1] Site oficial Active Campaign pentru cereri și metode ReST – http://www.activecampaign.com/api/overview.php

[GS-1] Actualizări recente Get Satisfaction – http://product.getsatisfaction.com/2011/06/recent-changes-to-our-rest-api/

[GA-1] Analytics Query Explorer- http://ga-dev-tools.appspot.com/explorer

[GA-2] Modele de cereri ReST Google Analytics – https://developers.google.com/analytics/devguides/config/mgmt/v3/mgmtReference/#collectcol_goals

[AT] Adobe Type – http://www.adobe.com/type, accesat la data 08.05.2013.

[HTML-2] Easing în HTML documents – http://www.opensource.org/licenses/mit-license.php, accesat la data 19.04.2013.

[JS-4] Jquery Back to Top plugin Example http://www.mattvarone.com/web-design/uitotop-jquery-plugin/, accesat la data 28.03.2013.

[PHP-8] Configure Eclipse for PhpUnit Tutorials – http://blog.loftdigital.com/running-phpunit-tests-in-eclipse-pdt, accesat la data 25.02.2013.

[PHP-9] Configure Eclipse for PhpUnit Tutorials, http://pkp.sfu.ca/wiki/index.php/Configure_Eclipse_for_PHPUnit, accesat la data 12.05.2013.

[PHP-10] Install PHPPear package – http://nishutayaltech.blogspot.in/2011/04/installing-phpunit-on-windows.html, accesat la data 26.04.2013.

BIBLIOGRAFIE

Articole științifice:

[SD-1] ***, "Application Development (AppDev) Defined and Explained". Bestpricecomputers.co.uk. 2007-08-13. Retrieved 2012-08-05, accesat la data 08.05.2013.

[PHP-2] ***, Arbor Software, "Multidimensional Analysis: Converting Corporate Data Into Strategic Information" – White Paper

[CC-1] How Cloud Computer Works, http://www.howstuffworks.com/cloud-computing/cloud-computing.htm , accesat la data 14.04.2013.

[CC-2] ***, Lohr, Steve. "Cloud Computing and EMC Deal." New York Times. Feb. 25, 2008. pg. C 6.

[CC-3] ***, Markoff, John. "Software via the Internet: Microsoft in 'Cloud' Computing." New York Times. Sep. 3, 2007. pg. C 1

[SQL-3] ***, MySQL Reference Manual for version 3.21.29

Bibliografie web:

[AII-1] Catedra AII, Sectiunea Studii de licenta, Lucrari in colaborare cu firme de profil – http://aii.pub.ro/index.php?option=com_content&view=article&id=309:automation-of-organization-metrics-gathering-and-analysis&catid=41:lucrari-de-licenta-colaborari-cu-firme-de-profil&Itemid=49 – accesat la data 14.06.2013.

[KPI-1] Best Practices using Metrics , http://nsdlnetwork.org/sites/default/files/BestPracticesMetrics-NSDLAug2010_4.pdf , accesat la data 24.05.2013.

[KPI-2] KPI and metrics, http://www.uie.com/brainsparks/2012/10/05/kpis-are-metrics-but-not-all-metrics-are-kpis/, accesat la data 09.03.2013.

[REST-2] ReST Introduction, http://www.infoq.com/articles/rest-introduction, accesat la data 12.04.2013.

[CC-4] ***, "IBM Introduces Ready-to-Use Cloud Computing." IBM. Nov. 15, 2007. http://www-03.ibm.com/press/us/en/pressrelease/22613.wss, accesat la data 04.05.2013.

[CC-5] ***, Naone, Erica. "Computer in the Cloud." Technology Review. Sept. 18, 2007. Retrieved March 12, 2008. http://www.technologyreview.com/Infotech/19397/?a=f , accesat la data 08.04.2013.

[REST-3] ReST Api, http://developer.zendesk.com/documentation/rest_api/introduction.html#headers , accesat la data 28.03.2013.

[CSS-1] The Beauty Of CSS Design, http://www.csszengarden.com, accesat la data 28.05.2013.

[CSS-2] Web Design, Use CSS Today, http://www.moock.org/webdesign/css/, accesat la data 29.05.2013.

[AC-1] Site oficial Active Campaign pentru cereri și metode ReST – http://www.activecampaign.com/api/overview.php

[GS-1] Actualizări recente Get Satisfaction – http://product.getsatisfaction.com/2011/06/recent-changes-to-our-rest-api/

[GA-1] Analytics Query Explorer- http://ga-dev-tools.appspot.com/explorer

[GA-2] Modele de cereri ReST Google Analytics – https://developers.google.com/analytics/devguides/config/mgmt/v3/mgmtReference/#collectcol_goals

[AT] Adobe Type – http://www.adobe.com/type, accesat la data 08.05.2013.

[HTML-2] Easing în HTML documents – http://www.opensource.org/licenses/mit-license.php, accesat la data 19.04.2013.

[JS-4] Jquery Back to Top plugin Example http://www.mattvarone.com/web-design/uitotop-jquery-plugin/, accesat la data 28.03.2013.

[PHP-8] Configure Eclipse for PhpUnit Tutorials – http://blog.loftdigital.com/running-phpunit-tests-in-eclipse-pdt, accesat la data 25.02.2013.

[PHP-9] Configure Eclipse for PhpUnit Tutorials, http://pkp.sfu.ca/wiki/index.php/Configure_Eclipse_for_PHPUnit, accesat la data 12.05.2013.

[PHP-10] Install PHPPear package – http://nishutayaltech.blogspot.in/2011/04/installing-phpunit-on-windows.html, accesat la data 26.04.2013.