Descrierea Aplicatiei

Cuprins

Introducere

Această lucrare prezintă o aplicație de gestionare a procesului de dezvoltare a unui produs software bazată pe metodologia Scrum. Deși este o aplicație web, aceasta nu se poate compara cu un site. Ea face parte din categoria aplicațiilor RIA (Rich Internet Applications). Faptul că se deschide într-un browser, îi oferă portabilitate și o ajută să ea întrunească toate caracteristicile unei aplicații desktop în ajutorul căreia vin controalele web cu un design mult mai prietenos cu utilizatorul și mai interactiv. Tehnologiile cu care a fost realizată îi asigură robustețe și responsivitate mare.

Această este o aplicație structurată pe mai multe nivele și întrunește toate caracteristicile unei aplicații de tip enterprise.

Este o aplicație deosebit de utilă și poate fi folosită cu ușurință de toate entitățile ierarhice din cadrul metodologiei Scrum.

Am realizat această aplicație deoarece am avut ocazia să mă familiarizez cu metodologia Scrum la locul de muncă și am observat limitările și neajunsurile unei aplicații de management a unui proiect pe care am folosit-o. Această aplicație vine să completeze neajunsurile acelei aplicații și să acopere problemele de care ne-am lovit ca și programatori pe parcursul procesului de dezvoltare a unui produs software.

Am ales să implementez această aplicație cu tehnologiile ce urmează a fi descrise din dorința de a folosi ultimele tehnologii din domeniu și de a învăța mai multe.

Majoritatea tehnologiilor și programelor utilizate la crearea acestei aplicații sunt gratuite,ceea ce determină ca dezvoltarea unei astfel de aplicații să fie foarte ieftină.

Felul în care aceasta a fost proiectată și construită facilitează procesul de mentenanță a acesteia sau chiar de extindere ulterioară a funcționalității sale.

Limbaje de programare utilizate

Java

Java este o tehnologie inovatoare lansată inițial de Sun Microsystems și achiziționată ulterior de Oracle. Aceasta este formată dintr-un limbaj de programare de nivel înalt pe bază căruia sunt construite o serie de platforme destinate implementării de aplicații pentru toate segmentele industriei software[1].

Acesta este un limbaj orientat pe obiecte dar nu este pur obiectual din cauză că deține și tipuri primitive de date. Caracteristicile principale ale acestui limbaj sunt:

Simplitatea

Ușurința

Robustețea

Complet orientat pe obiecte eliminând astfel stilul de programare procedural

Neutralitatea arhitecturala, neținând cont de arhitectura fizică a mașinii pe care rulează

Portabilitatea este data de codul compilat si interpretat care este independent de platforma pe care rulează

Performanța

Limbajul de programare Java a fost folosit la dezvoltarea unor tehnologii dedicate rezolvării unor probleme din cele mai diverse domenii.Aceste tehnologii au fost grupate în așa numitele platforme de lucru, ce reprezintă seturi de librării scrise în limbajul Java precum și diverse programe utilitare folosite pentru dezvoltarea de aplicații sau componente destinate unei anumite categorii de utilizatori[1]. Exemple de platforme sunt: J2SE (Standard Edition), J2ME (Micro Edition), J2EE (Enterprise Edition).

Toate aplicațiile Java sunt transformate în octeți (fișiere *.class) și rulate de către JVM (Java Virtual Machine).Acest lucru îi dă portabilitate, codul compilat putând fi executat pe oricare mașină virtuală.

La realizarea acestei aplicații am folosit platforma de lucru J2EE și versiunea de limbaj Java7. Această platformă de lucru vine în completarea J2SE și este destinată creării de aplicații de tip enterprise. Aceste aplicații au arhitecturi complexe și sunt împărțite pe mai multe nivele. J2EE face legătura dintre aceste nivele, mapează relațional obiectele și pune la dispoziție web service-uri și suport pentru rețele.

Figura 1.1.1 ilustrează arhitectura platformei J2EE și modul în care elementele constituente interactionează între ele. Aici este ilustrată structura tipică a unei aplicații de tip enterprise.

Fig. 1.1.1 – Arhitectura platformei J2EE [2]

SQL

Limbajul SQL (Structured Query Language) este în prezent unul din cele mai puternice limbaje structurate pentru interogarea bazelor de date relaționale. Este un limbaj neprocedural și declarativ deoarece utilizatorul descrie ce date vrea să obțină, fără a fi nevoie să stabilească modalitățile de a ajunge la datele respective. [3]

Este un limbaj de programare specific pentru manipularea datelor în sistemele de manipulare a bazelor de date relaționale (RDBMS), iar la origine este un limbaj bazat pe algebra relatională. Acesta are că scop inserarea datelor, interogații, actualizare și ștergere, modificarea și crearea schemelor, precum și controlul accesului la date. [4]

Instrucțiunile SQL pot fi grupate în:

instrucțiuni de definirea datelor, care permit descrierea structurii BD

instrucțiuni de manipulatea datelor: adaugă, șterge, modifică înregistrări

instrucțiuni de selecțiea datelor, care permit consultarea BD

instrucțiuni de procesarea tranzacțiilor

instrucțiuni de control al cursorului

instrucțiuni pivind controlul accesului la date

A devenit un standard în domeniu (standardizat ANSI-ISO), fiind cel mai popular limbaj utilizat pentru crearea, modificarea, regăsirea și manipularea datelor de către sistemele de gestiune a bazelor de date relaționale. Pe lângă versiunile standardizate ale limbajului, există o mulțime de dialecte și variante, astfel sistemele de gestiune a bazelor de date sunt prevazute cu diverse extensii.

SQL permite atât accesul la conținutul bazelor de date, cât și la structura acestora.

Există 3 metode de bază privind implementarea limbajului SQL:

Apelare directă (Direct Invocation): instrucțiunile sunt introduse direct de la prompter

Modulară (Modul Language): folosește proceduri apelate de programele aplicației

Incapsulată (Embedded SQL): conține instrucțiuni încapsulate în codul de program

La aplicația realizată am folosit atât metoda încapsulată de apelare a instrucțiunilor SQL pentru manipularea datelor, cât și apelarea directă pentru executarea instrucțiunilor de creare a bazei de date împreună cu constrângerile definite pentru aceasta.

JavaScript

JavaScript este un limbaj de programare orientat obiect bazat pe conceptul prototipurilor. Este folosit mai ales pentru introducerea unor funcționalități în paginile web, codul JavaScript din aceste pagini fiind rulat de către browser. Limbajul este binecunoscut pentru folosirea sa în construirea site-urilor web, dar este folosit și pentru acesul la obiecte încastrate (embedded objects) în alte aplicații. [5]

Cea mai des întâlnită utilizare a JavaScript este în scriptarea paginilor web. Acesta este introdus in cadrul paginilor web si contribuie la responsivitatea paginii, la realizarea unei pagini care interacționeaza cu utilizatorul.

Browserele rețin în memorie o reprezentare a unei pagini web sub forma unui arbore de obiecte și pun la dispoziție aceste obiecte script-urilor JavaScript, care le pot citi și manipula. Arborele de obiecte poartă numele de Document Object Model sau DOM. Există un standard W3C pentru DOM-ul pe care trebuie să îl pună la dispoziție un browser, ceea ce oferă premiza scrierii de script-uri portabile, care să funcționeze pe toate browserele. [5]

La realizarea acestei aplicații am folosit JavaScript pentru a valida câmpurile introduse de utilizator, la parsarea datelor primite de la server și la construcția paginii deoarece controalele SAPUI5 folosite pot fi manipulate doar ca și obiecte de JavaScript.

Tehnologii Web utilizate în realizarea aplicației

SAPUI 5

SAPUI 5 este un framework de JavaScript ce constituie o platformă de dezvoltare a aplicaților web de business moderne . Conține o bibliotecă JavaScript de controale suportate de toate browser-ele, destinate aplicaților web de tip RIA. Această bibliotecă a fost dezvoltată de SAP, companie germană multi-națională de dezvoltare de soluții software pentru business-uri sau relații cu clienții.

SAP este cunoscută pentru soluțiile sale SAP ERP (Enterprise Resource Planning), pentru programele de gestiune a produselor comerciale destinate lanțurilor de magazine SAP BW (Business Warehouse), suita de unelte de creare a rapoartelor de business SAP BO (Business Objects), sistemul de gestiune a bazelor de date relaționale in-memory SAP HANA și SAP Sybase, o suita de soluții software destinată telefoanelor mobile.

Această companie este lider mondial pe segmentul de Business Intelligence. În timp, și-a creat propriul limbaj de programare ABAP (Advanced Business Application Programming) și standarde foarte stricte în ceea ce privește întregul proces de realizare al aplicațiilor create de ei.

Aceste standarde sunt respectate și de framework-ul SAPUI care aduce pe lângă interactivitate foarte mare și un aspect de "business application” oricărei aplicații în care sunt folosite.

Aceast framework este destinat în special părții de client a unei aplicații web. Este un framework deosebit de flexibil, el putând fi folosit împreună cu o sumedenie de alte platforme și tehnologii precum: Apache Tomcat, Cascading Style Sheets (CSS) 3 version, Google Web Toolkit (GWT), HTML5 version, Java Platform as a Service (JPaaS), JavaScript (JS), JavaServer Faces (JSF), JavaScript Object Notation (JSON), jQuery, Open AJAX (Asynchronous JavaScript and XML), oData (Open Data Protocol), XML (Extensible Markup Language).

Controalele puse la dispoziție de acest framework sunt construite cu HTML5, CSS 3, jQuery și au capabilități de Ajax. Acestea suportă mai multe teme customizabile și pot fi accesate prin JavaScript. Fiind un framework orientat pe obiecte, controalele se pot declara și instanția ca și în Java urmând ca apoi să li se seteze proprietățile. Totodată acestea pot fi inițializate direct la instanțiere specificând proprietatiile sub formă de JSON.

Framework-ul este proiectat să implementeze design pattern-ul Model-View-Controller. Programatorul își poate crea ca și model datele sub formă de XML, JSON sau oData.

În această aplicație am folosit versiunea 1.12 a acestui framework din care am utilizat o mare varietate de astfel de controale dorind să scot în evidență capacitățile acestui framework și modul în care aceste controale pot fi utilizate.Am folosit de asemenea și design pattern-ul Model-View-Controller (MVC) furnizat de acesta dar combinat cu facilitățile framework-ului Struts care implementează același design pattern.

Spring

Este o platformă care oferă diverse facilități pentru construirea de aplicații Java de tip enterprise. Aceasta gestionează infrastructura aplicației lăsându-l pe programator să se concentreze pe partea de conținut a aplicației.Spring-ul face legătura între nivelele aplicației și oferă suport pentru conexiunea cu baza de date. Cu ajutorul acestui framework se crează aplicații ușor de testat și de întreținut. Acesta are numeroase plugin-uri care îi completează funcționalitatea.

Figura 2.2.1 ilustrează structura acestui framework.Acesta este alcătuit din mai multe module:

Nucleul (Core)

Modului Web – implementat pe baza MVC

Modulul pentru suportul testării

Modulul de accesare a datelor si integrare a acestora

La crearea aplicației prezentate în această lucrare am folosit acest versiunea 2.5.6 a acestui framework pentru a avea o arhitectură clară și pentru o bună delimitare între nivelele ei. Spring-ul se ocupă de transmiterea valorilor obiectelor între nivelele aplicației și ajută la implementarea design pattern-ului MVC făcând legăturile între model, prezentare și control.

Totodată am folosit și capabilitățile acestuia de injectare a valorilor obiectelor Java. Obiectele se declară în fișierul de configurare Spring definit de programator sub formă de beans unde le pot fi atribuite diferite proprietăți și pot fi transmise diferitelor clase. Acestea sunt preluate în codul Java cu ajutorul setter-elor și getter-elor.

Fig. 2.2.1 – Structura framework-ului Spring[8]

Apache Struts

ler. Programatorul își poate crea ca și model datele sub formă de XML, JSON sau oData.

În această aplicație am folosit versiunea 1.12 a acestui framework din care am utilizat o mare varietate de astfel de controale dorind să scot în evidență capacitățile acestui framework și modul în care aceste controale pot fi utilizate.Am folosit de asemenea și design pattern-ul Model-View-Controller (MVC) furnizat de acesta dar combinat cu facilitățile framework-ului Struts care implementează același design pattern.

Spring

Este o platformă care oferă diverse facilități pentru construirea de aplicații Java de tip enterprise. Aceasta gestionează infrastructura aplicației lăsându-l pe programator să se concentreze pe partea de conținut a aplicației.Spring-ul face legătura între nivelele aplicației și oferă suport pentru conexiunea cu baza de date. Cu ajutorul acestui framework se crează aplicații ușor de testat și de întreținut. Acesta are numeroase plugin-uri care îi completează funcționalitatea.

Figura 2.2.1 ilustrează structura acestui framework.Acesta este alcătuit din mai multe module:

Nucleul (Core)

Modului Web – implementat pe baza MVC

Modulul pentru suportul testării

Modulul de accesare a datelor si integrare a acestora

La crearea aplicației prezentate în această lucrare am folosit acest versiunea 2.5.6 a acestui framework pentru a avea o arhitectură clară și pentru o bună delimitare între nivelele ei. Spring-ul se ocupă de transmiterea valorilor obiectelor între nivelele aplicației și ajută la implementarea design pattern-ului MVC făcând legăturile între model, prezentare și control.

Totodată am folosit și capabilitățile acestuia de injectare a valorilor obiectelor Java. Obiectele se declară în fișierul de configurare Spring definit de programator sub formă de beans unde le pot fi atribuite diferite proprietăți și pot fi transmise diferitelor clase. Acestea sunt preluate în codul Java cu ajutorul setter-elor și getter-elor.

Fig. 2.2.1 – Structura framework-ului Spring[8]

Apache Struts

Este un framework open source pentru dezvoltare de aplicații Java de tip enterprise. Acesta extinde Servlet API și încurajează programatorii să folosească design pattern-ul MVC. Este un framework orientat pe request.

Într-o aplicație obișnuită, clientul apelează serverul folosind un form.Informația este transmisă unui servlet care interacționează cu bază de date și returnează un răspuns care este transmis paginii JSP sau HTML.Această abordare nu este deloc potrivită în cazul unei aplicații de dimensiuni mari deoarece combinarea părții de logică a aplicației cu partea de prezentare o face foarte greu de întreținut. Scopul acestui framework este să creeze această separare astfel:

Model – partea de logică a aplicației care interacționează cu baza de date

Prezentare – pagina web în care sunt afișate datele

Control – partea care se ocupă cu transmiterea informației între partea de prezentare și model

Figura 2.3.1 ilustrează arhitectura framework-ului Struts ilustrând relațiile dintre elementele din care este alcătuit si modul de funcționare al acestuia. Pe lângă implementarea MVC, se poate observa și modul în care este configurat acest framework, utilizând fișierele web.xml și struts-config.xml. De asemenea sunt ilustrate și 2 funcționalități de bază ale acestui framework precum: biblioteciile de tag-uri care sunt folosite la modulul de prezentare și resursele.Acestea din urmă sunt fișiere de tip *.properties, de forma “cheie=valoare” cu ajutorul cărora se implementează mecanismul prin care o aplicație poate suporta mai multe limbi. Aceste fișiere conțin chei cărora le corespund șiruri de caractere folosite în interfața grafică a aplicației,traduse în diferite limbi. Fișierele au denumiri de forma i18n_en_US (sufixul fiind diferit pentru fiecare limbă) În funcție de limba aleasă, acest framework decide conținutul cărui fișier se încarcă și se afișează în interfața grafică.

Fig. 2.3.1 – Arhitectura Struts [7]

Struts pune la dispoziția programatorilor controlul (ActionServlet) și template-uri pentru nivelul de prezentare al aplicației sub formă de biblioteci alcătuite din tag-uri pentru a fi folosite în paginile JSP.

Toate cele 3 elemente ale unei aplicații sunt legate cu ajutorul unui fișier de configurări struts-config.xml. Acest fișier conține definițiile acțiunilor (Actions), clase Java care procesează request-ul și trimit înapoi ca răspuns controlului (ActionServlet) pagina pe care trebuie să o afișeze clientului. Pe lângă acțiuni, acest fișier mai conține și declarații de form-uri, clase Java care conțin proprietățiile care vor lua valori în urma executării acțiunilor aferente și vor fi afișate în pagina web folosind un mecanism realizat de Struts care nu necesită introducerea de cod Java în cadrul paginii JSP.

La realizarea acestei aplicații am folosit Struts 1.2.7 pentru a structura aplicația conform principiilor MVC și pentru a prelua și furniza datele primate de la baza de date controalelor SAPUI 5.

Java Servlet

Un servlet este o clasă scrisă în limbajul Java al cărei scop este generarea dinamică de date într-un server HTTP. O astfel de clasă poate crea atât conținut HTML, cât și documente XML, imagini, alte fișiere etc. În cea mai mare parte servlet-urile sunt folosite împreună cu protocolul HTTP, deși există posibilitatea de a utiliza servlet-uri generice care nu sunt legate de un anumit protocol. Așadar prin „servlet” se înțelege de obicei „servlet HTTP”. [10]

Este o funcționalitate din platforma J2EE care extinde capacitățile unui server. Un servlet nu poate fi executat direct de către server, ci de către un container web. Acesta răspunde la diferite tipuri de request venite de la paginile publicate pe un server. Pentru a răspunde unei cereri de la un client (de obicei un browser) către un anumit servlet, serverul trimite mai departe cererea către container, care se ocupă de instanțierea obiectului respectiv și de apelarea metodelor necesare. Exemplele de containere web care suportă servlet-urile includ Apache Tomcat (acesta poate rula și ca server de sine stătător, dar performanțele sale nu se compară cu cele ale unui server web dedicat precum Apache). [10]

Servlet-urile sunt folosite de obicei pentru a procesa datele primite de la un form HTML, de a furniza dinamic datele extrase dintr-o bază de date sau de a realiza diferite operații în afara paginii web.Acestea pot fi apelate folosind URL-ul lor direct în browser sau în cadrul altor pagini web.

Ciclul de viață al unui servlet este alcătuit din 3 metode principale care sunt implementate de fiecare servlet și sunt apelate la momente de timp specifice de către server:

init()

service()

destroy()

Figura 2.4.1 ilustrează modul în care un client (browser) poate ajunge în posesia informațiilor stocate într-o bază de date. Containerul de Servlet trimite o cerere la servlet. Acesta execută operația de extragere a datelor și le furnizează înapoi containerului sub formă de răspuns.

Fig. 2.4.1 – Interacțiunea clientului cu baza de date utilizând framework-ul Servlet[15]

La aplicația prezentată în această lucrare am folosit tehnologia Servlet 2.5 pentru a implementa funcționalitatea de upload a fișierelor pe server.

JavaServer Page (JSP)

JavaServer Pages este o tehnologie care ajută la crearea de pagini web dinamice bazate pe HTML, XML sau alte tipuri de structuri de document. Este similar cu limbajul PHP dar se bazează pe limbajul Java. Pentru a publica o astfel de pagină e nevoie de un server care deține un container web compatibil cum ar fi Apache Tomcat sau Jetty.

JSP-urile sunt niște abstractizări ale servlet-urilor. În timpul rulării unei aplicații web, paginile JSP sunt compilate și traduse în servlet-uri care sunt executate în cadrul JVM (Java Virtual Machine) de către server. Containerul web crează obiectele implicite ale JSP precum: pageContext, servletContext, session, request și response.

Ele constituie partea de prezentare a design pattern-ului MVC și sunt folosite împreună cu modelul (JavaBeans) și cu controlul(Servlets și Struts).

Acțiunile definite cu ajutorul framework-ului Struts și servlet-urile au ca input o pagină de tip JSP. Această mapare se realizează în fișierul de configurări struts-config.xml.

În cadrul unei pagini JSP se folosesc diverși delimitatori. Cel mai des întâlnit este <%…%> care conține un scriptlet JSP. Scriptlet-ul este un fragment de cod java care este rulat când pagină este afișată. Se mai folosesc delimitatoi precum <%=…%> pentru expresii sau <%@…%> pentru directive.

Fig. 2.5.1 – Arhitectura modelului JSP [14]

Figura 2.5.1 ilustrează arhitectura modelului JSP. Browser-ul trimite request-ul la controller (Servlet). Acesta traduce pagina JSP. JSP-ul preia de la model datele extrase din baza de date și le afișează.

La realizarea acestei aplicații am folosit pagini JSP pentru input-ul acțiunilor Struts. Aceste pagini au structura unui document HTML obișnuit.

În secțiunea "head” sunt specificate link-urile spre documentele externe folosite în cadrul paginii precum : fișierele CSS, fișierele JavaScript și resursele SAPUI 5.

În secțiunea "body”, pe lângă elementele specifice unei pagini JSP descrise mai sus sunt specificate: definiții de bean-uri Java, cod JavaScript și taguri de Struts.

XML

XML (Extensiblee Markup Language) este un limbaj care permite etichetarea datelor pe baza înțelesului acestora. Acesta descrie datele într-un mod care este semnificativ atât oamenilor cât și calculatoarelor.

Fișierele de tip xml au extensia *.xml și au în antet o declarație opțională de forma “<?xml version = "1.0"?>” care specifică versiunea sintaxei documentului.

Acest document conține un element principal (root) în cadrul căruia sunt definite de către utilizator restul elementelor. Acestea pot avea orice nume și se declară astfel:

<numeEelement> valoareSauAltElement </numeElement>

La această aplicație am folosit fișiere de tip XML pentru configurarea framework-urilor Struts și Spring, și de asemenea pentru definirea proiectului Java. Proiectul Java din care este constituită această aplicație este de tipul Dynamic Web Project. Acesta are un fișier de configurări numit web.xml care conține toate configurările proiectului. În acest fișier se declară servlet-urile folosite, pagina de start a aplicației, calea către fișierele ce conțin tag-urile de Struts și calea către fișierul de configurare utilizat de Spring.

Numele fișierului de configurare utilizat de Spring este dat de programator. Acest fișier conține declarații de obiecte Java sub formă de beans care sunt atribuite ca și proprietăți altor clase Java.

Fișierul de configurare Struts se numește struts-config.xml și conține declararea acțiunilor și a form-urilor împreună cu maparea acestora cu paginile JSP corespunzătoare.

JSON

JSON (JavaScript Object Notation) este un mod simplu de a prezenta obiectele de JavaScript ca și șiruri de caractere. Fiecare obiect JSON este reprezentat ca și o listă de nume de proprietăți și valori conținute între acolade, iar tablourile sub forma unei înșiruiri de elemente între paranteze pătrate conform următorului format:

[

{ propertyName1 : value11, propertyName2 : value21 },

{ propertyName1 : value12, propertyName2 : value22 }

]

Valorile în JSON pot fi șiruri de caractere, numere de orice tip, alte obiecte JSON, valori booleene sau null.

Am folosit acest format de date pentru a transmite informațiile extrase din baza de date paginii JSP pentru a fi afișate corespunzător cu ajutorul controalelor SAPUI 5.

Pentru convertirea obiectelor Java în format JSON am folosit bibliotecă gson.jar dezvoltată de Google. Aceasta transformă un obiect într-un șir de caractere care constituie reprezentarea acestuia în formatul JSON și care poate fi parsat cu ajutorul funcției parse din JavaScript. Totodată această bibliotecă oferă și funcționalități de conversie inversă, din JSON în obiect Java.

Tipuri de Software utilizate în realizarea aplicației

Apache Tomcat

Apache Tomcat, cunoscut ca și Jakarta Tomcat, este un server web open source și un container pentru servlet-uri. Acesta implementează specificațiile Java Servlet și JavaServer Pages și furnizează un Server HTTP dedicat limbajului Java.

Acesta este alcătuit din mai multe componente:

Catalina – containerul destinat servlet-urilor

Coyote – conector ce folosește protocolul HTTP 1.1

Jasper – mecanismul care parsează paginile JSP și le traduce în servlet-uri care sunt executate de Catalina

Cluster – funcționalitate adaugată ulterior pentru a facilita load balancing-ul (mecanism prin care componentele unei aplicații sunt publicate și rulate pe mai multe server-e Tomcat)

Am folosit pentru realizarea aceastei aplicații Tomcat 6.0.35. Structura de fișiere a distribuției acestui server este ilustrată în figura 3.1.1.

Directoarele “backup” și “conf” conțin fișierele de configurări ale serverului. Acestea sunt accesibile și din Eclipse în momentul în care se adaugă o instanță a acestui server în Workspace, serverul fiind văzut ca și un proiect Java. Fișierul server.xml conține toate informațiile despre aplicațiile ce vor fi publicate pe server folosind Eclipse.

Directorul “temp” conține fișierele temporare care apar atunci când aplicația e publicată sub formă de fișier cu extensia *.war în directorul “webapps” și trebuie despachetată. Directorul “logs” conține log-urile serverului care furnizează informații despre modul de funcționare al acestuia.

Directorul “bin” conține funcționalitățile propriu-zise ale serverului. Aici se găsesc fișiere executabile de tip *.bat sau *.sh care au rolul de a porni modulele serverului sau de a le opri. În directorul “lib” se găsesc dependințele necesare rulării aplicației pe acest server iar în directorul “work” se găsește varianta compilată a paginilor JSP pentru fiecare aplicație publicată pe acest server.

Fig. 3.1.1 – Structura de directoare a unui server Tomcat

Pentru realizarea aplicației prezentate în această lucrare am folosit ca și mediu de dezvoltare Eclipse Juno și am publicat aplicația direct de aici folosind plugin-ul Servers. Acesta oferă posibilitatea de a defini un server și de a-l configura din cadrul mediului de dezvoltare, urmând ca acesta să apăra ca și un proiect Java distinct. Pentru publicarea aplicației am ales opțiunea de a folosi instanța instalată de Tomcat, din acest motiv, aplicația va fi publicată în directorul “wtpwebapps” iar biblioteciile din directorul WEB-INF\lib al proiectului Java vor fi copiate la publicare în directorul “lib” al serverului.

Crystal Reports

Crystal Reports este o unealtă ce face parte din suita SAP Business Objects. Aceasta a fost special creată pentru a ușura munca de întocmire și generare a rapoartelor. Acesta a devenit foarte popular după ce a fost integrat în Visual Studio începând de la varianta 2003. El oferă suport atât pentru .Net cât și pentru Java. Rapoartele pot fi create utilizând aplicația Crystal Reports sau programatic utilizând limbaje precum Java sau C#. Elementele raportului sunt construite pe baza principiilor programării orientate pe obiecte, fiecare tip de element fiind o clasă ce poate fi instanțiata.

Această unelta acceptă o mare varietate de surse de date. Pentru a folosi această unelta se definesc conexiuni (JDBC, ODBC etc) cu baza de date și se selectează datele ce urmează să fie afișate în raport selectând tabelele dorite sau definind o interogare SQL.

Conținutul raportului poate fi creat cu foarte mare ușurință, acesta punând la dispoziția utilizatorului o mulțime de funcționalități cum ar fi: grafice de diverse tipuri, tabele, parametrii de filtrare a datelor, metode de navigare între entitățile ierarhice, formule pentru gestionarea valorilor afișate etc.

După crearea raportului acesta se salvează într-un format *.rpt. Acesta fișier rezultat este defapt template-ul raportului și conține detaliile conexiunii cu bază de date. Acesta poate fi deschis cu ajutorul aplicației Crystal Reports sau cu ajutorul unui servlet sau pagini JSP.

Pentru realizarea acestei aplicații am folosit Crystal Reports XI și am creat un astfel de raport care se deschide în browser apelând un servlet care deschide fișierul *.rpt și ilustrează date privind procesul de gestionare a Sprint-ului.

Modul în care a fost creat acest raport și modul de funcționare al acestei unelte vor fi descrise mai detaliat într-un capitol următor.

Eclipse Juno si SVN (Subversioning)

Pentru realizarea aplicației de management a unui proiect am folosit ca și mediu de dezvoltare Eclipse Juno. Acesta crează un Workspace care va servi drept cadru pentru proiectele Java. Este distribuit împreună cu o mulțime de plugin-uri care extind funcționalitatea lui făcându-l să acopere multe tehnologii, framework-uri și posibilități de dezvoltare a produselor software.

Am folosit funcționalitatea Servers a acestuia pentru a defini serverul pe care va fi rulată aplicația web. Pe lângă această funcționalitate am mai instalat un plugin de SAPUI 5 care vine împreună cu distribuția framework-ului. Cu ajutorul acestui plugin se pot crea proiecte special construite pentru o aplicație de tip SAPUI5. Totodată am instalat și o extensie a acestui framework pentru a adăuga funcționalitatea de autocompletare a codului JavaScript.

Din dorința de a păstra controlul reviziilor și de a avea o copie de siguranță mereu la zi a aplicație am creat un repository privat pe platformă online assembla.com ce oferă servicii SVN.

SVN (Subversioning) este un software de versionare și de control al reviziilor. Acesta facilitează munca în echipă și rezolvă problemele care pot să apăra în cazul în care mai mulți programatori lucrează la același proiect. Fiecare programator își comite modificările care pot fi văzute și preluate de ceilalți membrii ai echipei. Proiectele la care se lucrează folosind SVN sunt puse într-un loc comun numit repository. Acesta este de obicei localizat pe o mașină dedicată la care au acces prin rețea toți programatorii pentru a lua sau comite modificări.

Pentru a avea acces din cadrul mediului Eclipse la conținutul repository-ului, am instalat un plugin numit Subclipse.Acesta este un client de SVN care dă posibilitatea programatorului să comită modificările făcute asupra fișierelor pe acel repository. M-a ajutat în mod special pentru că am avut întotdeauna un punct stabil de revenire în cazul unor erori neprevăzute, o copie de siguranță mereu la zi dar totodată și o evidența clară a funcționalităților implementate dată de comentariile care însoțesc fiecare comit. De asemenea această abordare aduce și portabilitate procesului de dezvoltare al aplicației.Totodată, se poate cu ușurință descărca aplicația pe orice alt calculator folosind orice variantă de Eclipse cu un client de SVN instalat și comite modificările făcute acolo pentru a putea continua munca în altă locație sau pe un alt calculator.

MSSQL Server 2005

Microsoft SQL Server este un sistem de gestionare de baze de date relaționale (RDBMS – Relational Database Management System) produs de compania americană Microsoft Corp. Limbajele primare de interogare sunt MS-SQL și T-SQL. Este un sistem destinat bazelor de date de dimensiuni foarte mari.

MS SQL Server suportă conexiuni de diverse tipuri. Pentru realizarea acestei aplicații am folosit conexiuni de tip ODBC (Open Database Connectivity) și JDBC (Java Database Connectivity).

ODBC este un limbaj de programare C standard care crează nivelul de legătură dintre o aplicație și baza de date, independent de tipul bazei de date sau sistemul de operare al mașinii pe care este definite. Am folosit acest tip de conexiune pentru a extrage datele necesare la generarea raportului realizat cu unealta Crystal Reports XI. Această conexiune se configurează foarte ușor pe sistemul de operare Windows (Control Panel > Administrative Tools > Data Sources).

JDBC este o tehnologie dezvoltată de Oracle care definește modul în care un client are acces la server-ul de baze de date. Acesta pune la dispoziție metode de interogare a bazei de date și de modificare a datelor din aceasta. Este conceput pentru baze de date relaționale. Am folosit acest tip de conexiune pentru a selecta informațiile necesare din baza de date folosind limbajul Java. Pentru a realiza acest lucru am folosit un driver JDBC (MSSQLJDBC-1.2.jar).

Scrum

Descrierea metodologiei

De-a lungul anilor au apărut și evoluat diverse framework-uri ce sunt folosite pentru a planifica structura și procesul de dezvolare a unui produs software, denumite metodologii de dezvoltare software. În funcție de fiecare proiect în parte și de condițiile de lucru a fost aleasă metodologia care s-a considerat că este potrivită luând în calcul aspecte tehnice ale proiectului.

Dezvoltarea de software agilă este denumirea unui grup de metodologii de dezvoltare software ce sunt bazate pe principii comune. Astfel de metodologii propun un anumit stil al procesului de management al proiectelor ce pune accent pe inspecție frecventă si adaptare continuă, muncă de echipă, auto-organizare și responsabilitate, favorizând astfel dezvoltarea rapidă a unui produs software de mare calitate, precum și coordonarea procesului de dezvoltare cu cererile clientului și obiectivele companiei. Cele mai multe metode agile propun dezvoltarea iterată. Acest lucru are avantajul corectării pe parcurs a cerințelor în cazul în care se descoperă că acestea nu sunt ceea ce destinatarul produsului își dorește.

Scrum este o metodă de gestionare a proiectelor caracteristică programării agile. Prima abordare a acestei metode a fost descrisă de Takeuchi and Nonaka în „The New Product Development Game” (Harvard Business Review, Jan-Feb 1986). Ei au scris că de-a lungul timpului proiectele care folosesc echipe mici care au posibilitatea de a transfera una de la alta sarcini produc cele mai bune rezultate. De asemenea ei au asemănat aceste echipe performante cu grămada folosită în rugby (în engleză „scrum”), referindu-se la această metodă de organizare a proiectelor ca Scrum. [11]

Aceasta este o metodă iterativă și incrementală al cărei scop este cel de a ajuta echipele de dezvoltare să iși concentreze atenția asupra obiectivelor stabilite și minimizarea muncii depunse de aceștia pentru rezolvarea sarcinilor mai puțin importante. Scrum dorește să pastreze simplitatea intr-un mediu de afaceri complicat. Aceasta metodologie se bazează pe două elemente: autonomia echipei și adaptabilitate. Autonomia echipei se referă la faptul că cei care conduc proiectul stabilesc sarcinile care trebuie rezolvate de către echipă, însă acesta are libertatea de a-și stabili propriul mod de lucru în cadrul fiecărei iterații, scopul fiind cel de a spori productivitatea echipei. [13]

Deși Scrum a fost menită să fie o metodă de gestionare a proiectelor de dezvoltare a programelor, ea poate fi folosită și în echipe de mentenanță sau ca o abordare de gestionare a programului: Scrumul scrumului. [11]

Scrum încurajează crearea echipelor cu auto-organizare și cominicarea verbală între toți membrii echipei și între diferitele departamente care au legătură cu proiectul. Un principiu important în această abordare o reprezintă acceptarea faptului că, pe parcursul dezvoltării unui proiect, clientul se va răzgândi de multe ori cu privire la ce dorește și are nevoie să ofere produsul software. Astfel de schimbări neprevizibile nu sunt ușor de adaptat la proiect folosind metodele tradiționale de dezvoltare software. Scrum adoptă o abordare empirică susținând că o problemă nu poate fi pe deplin ințeleasă sau definită și punând accent pe dezvoltarea abilității unei echipe de a rezolva rapid noi cerințe. [13]

Rolurile Scrum

Conform Agile Manifesto, document care conține bazele teoretizate a acestei metodologii, în cadrul unui proces Scrum sunt definite 6 roluri, fiecare cu diferite sarcini și scopuri [16]. Aceste roluri sunt împărțite în două categorii:

Porcii – cei direct implicați în procesul de dezvoltare, angajați să construiască proiectul și care sunt trași la răspundere.

Conducătorul Scrum – are un rol de project manager (dar el nu este șeful echipei) ce trebuie să se asigure că procesul de dezvoltare evoluează în conformitate cu tehnicile, valorile și regulile Scrum. Acesta interacționează atât cu Echipa de dezvoltare, cât si cu clienții și conducerea organizației. Este de asemenea responsabil să se asigure că orice impediment și orice element care distrage atenția echipei sunt înlăturate, astfel încât productivitatea echipei să fie permanent la un nivel ridicat.

Deținătorul de produs – reprezintă vocea, interesele clientului. El este responsabil de proiectarea, administrarea, controlul și prezentarea produsului nerezolvat; ia decizia finală cu privire la sarcinile din produsului nerezolvat și le asociază priorități. Este ales de către Conducătorul Scrum, client și conducere.

Echipa – este responsabilă cu dezvoltarea produsului; are autoritatea de a decide ce măsuri trebuie luate pentru a rezolva sarcina asociată fiecărui sprint și are dreptul de a se auto-organiza tot în același scop. În general o echipă Scrum este alcătuită din 5-9 persoane.

Puii – cei care nu sunt implicați direct în dezvoltarea proiectului, dar de a căror părere trebuie să se țină cont. În abordarea agilă un aspect foarte important îl reprezintă implicarea utilizatorilor, clienților, oamenilor de afaceri în procesul de dezvoltare. Aceștia trebuie să ofere feed-back cu privire la rezultatele fiecărui sprint pentru a adapta și îmbunătăți viitoarele procese de lucru.

Utilizatorii – cei care vor folosi produsul software

Clienții – cei care stabilesc scopul proiectului; sunt implicați în procesul de dezvoltare doar când are loc evaluarea unui sprint

Manager-ii – cei responsabili de luarea deciziilor finale. Participă de asemenea în stabilirea obiectivelor și a condițiilor de lucru

Elemente și principii de funcționare

Rolurile predefinite ale Scrum-ului sunt:

Echipa (Team) – cea care se ocupă de realizarea produsului

Conducător Scrum (Scrum Master) – este asemenea unui manager de proiect, acesta gestionează activitatea echipei pe parcursul unei iterații

Deținător de produs (Product Owner) – reprezinta vocea clientului și specifică cerințele ce trebuie implementate

Entitățile enumerate mai sus desfășoară o serie de activități specifice care sunt ilustrate în figura 4.3.1 împreună cu setul de activități specifice realizate de acestea.

Deținătorul de produs preia cerințele direct de la clienți și întocmește o listă de cerințe (Tasks) numită Product Backlog (Produsul nerezolvat). Acesta descrie funcționalitățile și serviciile dorite și le asignează priorități. Câteva dintre elementele ce pot face parte produsul nerozolvat sunt implementarea anumitor funcții, remedierea bug-urilor, înlăturarea defectelor, îmbunătățirea diferitelor componente.

După clarificarea acestor cerințe, echipa estimează efortul, evaluează timpul necesar pentru implementarea fiecărei cerințe în parte și dă o estimare optimistă (timpul minim de implementare) sau pesimistă (timpul maxim de implementare când există posibilitatea să apară impedimente pe parcursul implementării). Pe baza acestor estimări și a bugetului alocat pentru proiectul respectiv, deținătorul de produs decide care funcționalități dorește să fie implementate.

Fig. 4.3.1 – Principiile de funcționare ale Scrum-ului [12]

Produsul software evoluează de-alungul mai multor etape numite Sprint-uri (iterații). Sprint-urile sunt perioade cu lungime stabilită de echipă (între 15-30 zile). Un Sprint include faze tradiționale de dezvoltare software precum etape de cerințe, analiză, design, evoluție, livrare. La sfârșitul unei iterații echipa trebuie să prezinte o nouă unitate funcționabilă a produsului.

Un Sprint începe cu o întâlnire de planificare a Sprint-ului (Planning Meeting). Această întâlnire se desfășoară în două etape.

Prima etapă pune fața în fața clienții, utilizatorii, conducerea, deținătorul de produs și echipa pentru a decide obiectivele urmatorului Sprint. La această întâlnire, echipa împreună cu detinatarul de proiect decid pe baza orelor disponibile din Sprint și a priorității, sarcinile din Product Backlog care vor fi implementate în iterația următoare. Lista de cerințe obținute în urma acestei întâlniri se numește Sprint Backlog (Sprint-ul nerezolvat).Aceste cerințe trebuie împărțite în sarcini mai mici care nu depășesc 16 ore (Subtasks). Ele nu le sunt repartizate angajaților, aceștia având posibilitatea să își aleagă sarcinile dorite.

La a doua parte a întâlnirii participă conducătorul Scrum și echipa pentru a discuta despre cum se va implementa unitatea produsului reprezentată de acest Sprint.

Echipa comite că aceste sarcini vor fi terminate la sfârșitul iterației respective.Lungimea unui Sprint nu se poate modifica pe parcursul acestuia, dar în cazuri excepționale, deținătorul de proiect și conducătorul Scrum împreuna cu echipa pot decide să scoată din cadrul Sprint-ului diverse sarcini și să le înlocuiască cu altele de obicei mai prioritare în limita orelor disponibile. Această abordare nu este indicată deoarece strică echilibrul Sprint-ului.

Pe parcursul Sprint-ului, angajații pontează zilnic ore la sarcinile la care lucrează. În cazul în care estimările au fost făcute corect și nu au existat impedimente, aceștia ar trebui să se încadreze în estimarea dată pentru sarcina respectivă.

urn down este un grafic care ilustrează modul în care un Sprint evoluează din punctul de vedere al orelor rămase. Acesta este actualizat zilnic și cu ajutorul lui se poate estima cât timp a mai rămas până la finalizarea proiectului.

Pe parcursul implementării, cerințele deținătorului de proiect pot fi completate și rafinate. În cazul în care se produc schimbări majore în cadrul cerințelor, există riscul depășirii estimărilor.

Întâlnirea Scrum zilnică (Daily Meeting) este o componentă foarte importantă a acestei metodologii datorită faptului că Scrum pune foarte mare accent pe comunicarea între părțile implicate în cadrul procesului de dezvoltare al produsului. Această întâlnire are loc zilnic la aceeași oră, o oră stabilită de către echipă împreună cu conducatoru Scrum. Este condusă de Scrum Master și durează aproximativ 15 minute. Această întâlnire este organizată pentru a urmări continuu progresul echipei. Este deosebit de utilă și pentru planificarea sarcinilor, fiecare programator vorbește despre ce a lucrat în ziua precedentă si despre ce urmează să lucreze în ziua respectivă. Tot aici se discută și despre problemele și impedimentele care au afectat membri echipei în ceea ce privește atingerea obiectivelor stabilite iar conducatorul Scrum are sarcina de a încerca să remedieze problemele apărute. La această întâlnire e invitat să participe oricine e interesat de stadiul Sprint-ului, însă doar cei direct implicați au voie să vorbească.

După fiecare funcționalitate implementată, se organizează o întâlnire cu deținătorul produsului. Această întâlnire se numește PO Approval. În cazul în care acesta este mulțumit cu rezultatul obținut aprobă funcționalitatea respectivă. În caz contrar se consideră că acea funcționalitate nu este finalizată.

La sfârșitul Sprint-ului are loc întâlnirea de evaluare (Review Meeting). În cadrul acestei întâlniri, echipa împreună conducătorul Scrum prezintă realizările din Sprint-ul tocmai încheiat conducerii. Un Sprint este încheiat cu success dacă toate sarcinile din Sprint Backlog au fost finalizare, în caz contrar acesta se consideră eșuat. În cadrul acestei întâlniri se iau decizii cu privire la direcțiile ce trebuie urmate în continuare.

Ultima etapă a acestui proces este retrospectiva (Retrospective). În cadrul acestei întâlniri, membrii echipei împreună cu deținătorul Scrum reflectă asupra Sprint-ului tocmai încheiat subliniind aspectele pozitive și negative ale acestuia. Aici se decide ce ar trebui schimbat sau adăugat pentru îmbunătățirea procesului.

Avantaje și dezavantaje

Acest model agil de gestionare este în special folosit pentru proiectelor informatice complexe. Deși pare foarte simplu, simplitatea lui poate fi înșelătoare deoarece acesta nu are o rețetă prescrisă a procesului. Datorita faptului ca e utilizat la proiectele complexe, acesta nu poate anticipa ce trebuie făcut în fiecare circumstanță. Scrum oferă doar un cadru și un set de practici pentru a păstra totul vizibil. Acest lucru permite practicanților săi să știe exact ceea ce se întâmplă pentru a face față ușor ajustărilor ce pot interveni și pentru a menține proiectul înspre obiectivele dorite.

Avantajele Scrum-ului sunt:

Încurajează lucrul în echipă și transparența. Sparge ierarhia și ajută oamenii noi din echipă să devină  productivi cât mai repede și să înțeleagă proiectul.

Se concentrează pe funcționalități clare și bine specificate.

Scrum este adaptiv și ajută echipa de management să vadă în timp real rezultate prin update-uri constante și status la zi acest lucru ajutând la depășirea eventualelor impedimente ce pot să apară pe parcursul procesului de dezvoltare.

Se pot prevedea costurile viitoare și planifica bugetele corespunzător.

Clienții au abilitatea de a modifica cerințele din mers.

Există o transparență a costurilor și a caracteristicilor implementate.

Programatorii au o documentație inițială minimă.

Împărțirea task-urilor se face printr-o abordare colaborativă.

Există o colaborare foarte bună cu managerii și clientii, în urma căreia rezultă multe idei.

Dezvoltarea are loc în iterații numite Sprint-uri.

Dezavantajele Scrum-ului sunt:

Scrum se focusează pe caracteristici clare. Devine foarte tentant să finalizezi rapid un lucru într-o manieră nu tocmai elegantă. Aceasta poate afecta mai târziu arhitectura, scalabilitatea și securitatea, deși acestea nu au un efect imediat vizibil în experiența utilizatorului.

Metodologia cere fiecărui membru să uite de specializarea sa și să acționeze ca un membru al echipei, indiferent dacă e designer, front-end developer sau programator. Asta poate da uneori probleme de inconsistență.

Din cauza presiunii constante zilnice apare stresul, iar spre finalul proiectului, nivelul moral al echipei este deficitar.

Abordarea rezolvă probleme specifice ale proiectului, dar lasă altele nerezolvate și creează posibilitatea  solicitării de noi task-uri care duc la extinderea proiectului.

Împărțirea task-urilor în echipă poate duce la probleme din cauza nepotrivirii pe anumite task-uri.

Pentru a accepta o asemenea abordare, clientul trebuie să aibă mare încredere în dezvoltatorul de soluții.

Pot apărea dificultăți în estimarea costului final al proiectului, datorate dorinței permanente de a adăuga noi și noi caracteristici care apar din ideile venite pe parcurs.

Refactoring-ul are prioritate scăzută din cauza actualizării constante a statusului și a cererii de noi funcționalități.

Se întâmplă frecvent ca membrii echipei să se piardă în detalii și să uite scopul general al proiectului.

Scrum cere un nivel mare de automatizare.

Descrierea aplicației

Acest capitol va trata modul în care a fost implementată aplicația destinată managementului unui proiect și functionalițătiile pe care aceasta le oferă. Dependințele specifice fiecărei tehnologii folosite la realizarea acestei aplicații se regăsesc în Anexa1.

Structura bazei de date

Anexa 2 ilustrează structura bazei de date și relațiile dintre tabelele acesteia. Aceasta conține 11 tabele:

Posturi – se atribuie un id unic fiecărui post specific (ex. Programator,ScrumMaster etc)

Asignări_proiecte – ilustrează la ce proiecte lucrează un utilizator al acestei aplicații

Proiecte – ilustrează proiectele care sunt monitorizate cu ajutorul acestei aplicații

Utilizatori – păstrează utilizatorii care pot folosi această aplicație împreuna cu datele lor

Echipe – păstrează informații despre echipe pentru a le putea asigna Sprint-uri

Taskuri – toate cerințele și functionalitațiile ce vor fi implementate

Comentarii – oferă utilizatorilor posibilitatea să adauge comentarii task-urilor

Atasamente – oferă utilizatorilor posibilitatea să atașeze fișiere task-urilor

Sprinturi – reține toate datele specifice unei iterații

Planificare_Sprinturi – ilustrează task-urile care vor fi implementate într-un Sprint

Ore_pontate – ilustrează modul in care evoluează implementarea unui task

În structura de directoare a aplicației, în directorul ‘resources’ sunt 2 scripturi:

dbStructure.sql – folosit pentru a genera tabelele bazei de date și constrângerile aferente acestora

dbData.sql – folosit pentru a popula baza de date cu datele inițiale cum ar fi tipurile de funcții pe care le poate avea un utilizator

Datele din aceste tabele vor fi manipulate cu ajutorul instrucțiunilor SQL scrise în partea de server a aplicației. Pentru a crea conexiunea cu baza de date și pentru a le executa s-a folosit un driver JDBC (Java Database Connectivity).

Datele necesare pentru realizarea unei conexiuni cu baza de date, cum ar fi numele bazei de date, url-ul acesteia, numele utilizatorului și parola acestuia, se vor specifica într-un fișier de configurări cu extensia *.properties. Acest fișier se numește ‘projectManagement.properties’ iar configurările sunt:

#Database credentials

prjMng.db.url=jdbc:sqlserver://127.0.0.1:1433;databaseName=PRJ_MNG

prjMng.db.user=ancaPM

prjMng.db.password=anca

Configurările aplicației

Utilizatorul are posibilitatea să specifice anumite configurări necesare pentru rularea aplicației. Aceste configurări se găsesc în fișierul ‘projectManagement.properties’.

Acest fișier conține datele necesare pentru a realiza conexiunea cu baza de date, datele necesare pentru a inițializa sistemul de logging și datele predefinite necesare pentru funcționarea aplicației. Conținutul acestui fișier este ilustrat în fragmentul de cod de mai jos:

#Project Management application configurations

#Database credentials

prjMng.db.url=jdbc:sqlserver://127.0.0.1:1433;databaseName=PRJ_MNG

prjMng.db.user=ancaPM

prjMng.db.password=anca

#Logging system configurations

prjMng.log.filePath=E:/PRJMNGlogs

prjMng.log.fileName=log.txt

prjMng.log.dateFormat=dd/MM/YYYY hh:mm:ss

prjMng.log.fileHeader=–Project Management Log–

#Default values

prjMng.default.password=123abc

Structura acestui fișier este de forma ‘cheie = valoare’. Cheia este reținută într-un fișier *.xml. În momentul publicării aplicației pe server, Spring-ul ia valoarea acestei chei și o injectează în obiectul Java aferent. Fragmentul următor de cod ilustrează modul în care sunt mapate cheile folosite pentru conexiunea cu baza de date și este extras din fișierul ‘applicationContext.xml’ :

<bean id="userDao" class="com.app.dao.DaoImpl">

<property name="dbUrl" value="${prjMng.db.url}" />

<property name="dbUser" value="${prjMng.db.user}" />

<property name="dbPassword" value="${prjMng.db.password}" />

<property name="userDefaultPassword" value="${prjMng.default.password}" />

</bean>

Sistemul de logging

Pentru a ajuta la dezvoltarea aplicației dar și pentru a ajuta la descoperirea cauzelor unor eventuale probleme după punerea în folosință a acestei aplicații, am creat un sistem de logging.

Acesta este configurabil de către utilizator prin intermediul fișierului descris în capitolul anterior. Se pot configura:

Calea unde se dorește să fie creat acest fișier

Numele acestuia

Formatul în care va fi scris momentul de timp în care se întamplă o anumită acțiune

Antetul acestui fișier

Sistemul de logging este implementat în clasa ‘Logger.java’. Această clasă este un singleton. Conform principiilor acestui design pattern, această clasă se instanțiază o singură dată iar această instanță este folosită de toate celelalte clase. Datorită faptului că există doar o singură instanță, aceasta nu poate reține starea unor obiecte și nici un tip de informații. Aceasta clasa pune la dispoziția celorlaltor clase metodele implementate în cadrul ei.

Clasa conține metoda ‘log’ care este răspunzătoare cu scrierea mesajului de log în fișierul configurat de utilizator. Această clasă este sincronizată, fapt care o face să funcționeze corect pe mai multe fire de execuție simultan, scenariu ce are loc în cazul în care 2 utilizatori diferiți folosesc aplicația simultan.

Configurările sistemului de logging sunt injectate în momentul în care aplicația este publicată pe server, de către Spring, în clasa ‘LogFileProperties.java’ de unde sunt luate de fiecare dată când este apelată metoda ‘log’. Această clasă conține metode de tipul setter și getter, necesare pentru injectarea valorilor. Maparea se face în fișierul ‘logging.xml’.

<bean id="logFile" class="com.app.util.LogFileProperties">

<property name="filePath" value="${prjMng.log.filePath}" />

<property name="fileName" value="${prjMng.log.fileName}" />

</bean>

<bean id="loggerInstance" class="com.app.util.Logger">

<property name="logFilePropr" ref="logFile" />

</bean>

Fiind un singleton, această clasă are un constructor privat iar metoda acesteia se poate apela de oriunde sub forma: Logger.log("Mesaj ce va fi scris in fisierul de log");

Structura aplicației

Aceasta este o aplicație web de tip enterprise și din acest motiv are o structură multi-nivel (multi-layer). Aceasta este structurată pe 3 niveluri:

Nivelul de extragere a datelor din baza de date (DAO)

Nivelul de business (Business Service)

Nivelul interfața grafică cu utilizatorul (GUI)

Nivelul de extragere a datelor se bazează pe design pattern-ul DAO (Data Access Object). Acesta oferă o interfață abstractă către orice tip de bază de date fără a expune detaliile conexiunii și crează o separare între nevoile aplicației și datele acesteia. DAO este asociat de obicei cu aplicațiile Java EE care folosesc baze de date relaționale accesate cu ajutorul JDBC.

Nivelul de business preia datele extrase de la DAO și le procesează trimițându-le mai departe către intrefata cu utilizatorul sub formă sintetizată.

Figura 5.4.1 ilustrează nivelurile și modul în care acestea interacționează pentru funcționarea aplicației.

Totul începe de la un utilizator care accesează aplicația cu ajutorul unui browser. Acest lucru crează o cerere (request) care e trimisă la server (Tomcat) unde este procesată de către un servlet care trimite cererea la celelate component pentru a fi executată.

Fig. 5.4.1 – Structura aplicației în raport cu tehnologiile folosite [9]

Servlet-ul comunică cu framework-ul Struts care face legătura dintre partea de client a aplicației și partea de server.

Partea de client este alcătuită din JavaServer Pages (JSP) care utilizează tag-uri de Struts și funcționează împreună cu JavaScript, CSS, HTML.

Partea de server a aplicației este structurată de asemenea pe mai multe niveluri, legate între ele de Spring cu ajutorul fișierelor de configurări (Context Configuration XML). Această parte, prin intermediul conexiunii JDBC, realizează conexiunea cu bază de date și extrage din aceasta datele necesare funcționării aplicației.

Privită in ansamblu, aceasta aplicație respectă principiile design pattern-ului MVC (Model View Control), astfel:

modelul este constituit din datele extrase din baza de date

controlul este asigurat de partea de server a aplicației

prezentarea este asigurată de interfața grafică cu utilizatorul

Partea de control a aplicației este structurată în Action-uri și Form-uri Struts. Action-urile sunt clase Java care extind o clasă Struts numită ‘ActionSupport’ și au ca input o pagină JSP mapată în fișierul de configurare Struts. Acestea sunt apelate pe baza url-ului sau facânduse submit din pagina JSP mapată acestuia. Action-urile primesc cereri de tip HttpServletRequest pe care le procesează și trimit răspunsuri de tip HttpServletResponse paginilor sau celorlaltor Action-uri către care redirecționează răspunsul.

Fiecare Action are asociat pe lângă pagina de input, și un Form. Acesta este o clasă Java care conține reprezentarea datelor care sunt trimise de la pagina JSP și folosite de Action.

Toate acestea sunt mapate în fișierul de configurare al Struts-ului numit ‘struts-config.xml’. Fragmentul următor de cod ilustrează modul în care este mapat Action-ul care realizează funcția de autentificare a utilizatorului:

<struts-config>

<form-beans>

<form-bean name="LoginForm" type="com.app.form.LoginForm"/>

</form-beans>

<global-forwards>

<forward name="login" path="/Login.do"/>

<forward name="loginJsp" path="/jsp/index.jsp"/>

</global-forwards>

<action-mappings>

<action path="/Login" name="LoginForm" validate="true" input="/index.jsp"

type="com.app.action.LoginAction">

</action>

</action-mappings>

Toate Action-urile implementează metoda execute care are urmatoarea formă :

public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception {…}

Aceasta returnează locul în care se redirecționează răspunsul folosind global-forwards definite în fișierul de configurări (ex. return mapping.findForward(“login”);) sau folosind pagina de input a acestuia, în cazul nostru ‘/jsp/index.jsp’

(return mapping.getInputForward();)

Tot pentru gestionarea cererilor venite de la partea de client am folosit și servlet-uri. Acestea se mapeaza în fișierul de configurări al proiectului Java ‘web.xml’. Acest fișier este specific proiectelor java de tip web.

Unul dintre servlet-urile folosite este utilizat pentru copierea pozelor selectate de utilizator pe server pentru a fi afișate în aplicație. Fragmentul de cod următor ilustrează modul în care se realizează această mapare. Pentru aplelarea acestui servlet se folosește url-ul specificat pentru tag-ul ‘url-pattern’.

™ <servlet>

<display-name>FileUploadServlet</display-name>

<servlet-name>FileUploadServlet</servlet-name>

<servlet-class>com.app.servlet.FileUploadServlet</servlet-class>

</servlet>

<servlet-mapping>

<servlet-name>FileUploadServlet</servlet-name>

<url-pattern>/uploadFile</url-pattern>

</servlet-mapping>

Clasa în care este implementat acest servlet se numește FileUploadServlet. Aceasta trebuie să extindă clasa HttpServlet și să implementeze metoda:

protected void doPost(HttpServletRequest request,

HttpServletResponse response) throws ServletException, IOException{…}

Struct generală a proiectului

Figura 5.5.1 ilustrează structura generală a proiectului Java prin care este implementată această aplicație. Se poate observa clar distincția dintre partea de server a aplicației (organizată în pachete sub directorul ‘src’), partea de client (în directorul ‘WebContent’) și librăriile Java.

Partea de server este structurată în pachete Java. Acestea au nume sugestive care identifică nivelul aplicației care este implementat în acel pachet. Pachetul ‘resources’ conține fișierele de configurări și script-urile necesare pentru crearea și inițializarea bazei de date.

De remarcat în structura de fișiere de pe partea de client a aplicație, este directorul ‘WEB-INF’. Acesta conține fișierul de configurare al acestui proiect web (web.xml), fișierul de configurare al framework-ului Struts (struts-config.xml) precum și fișierul de configurare al framework-ului Spring (applicationContext.xml). Tot în acest director se găsește și directorul ‘lib’. Acesta conține toate dependințele necesare pentru rularea aplicației într-un container web (Tomcat).

Fig. 5.5.1 – Structura generală a proiectului Java

Funcționalitățiile aplicației

Acest subcapitol va descrie fiecare pagină a aplicației și fiecare funcționalitate a acesteia.Aplicația este alcătuită din următoarele pagini:

Pagina de autentificare (Login)

Pagina destinată proiectelor (Projects)

Pagina destinată tuturor sarcinilor de lucru create (Tasks)

Pagina destinată planificării Sprint-ului (Backlog)

Pagina destinată Sprint-ului (Sprints)

Pagina de administrare vizibilă doar dacă utilizatorul are drepturi (Administration)

Toate aceste pagini joacă un rol foarte important și sunt necesare pentru managementul eficient al unui Sprint.

Secțiunea Login

Aplicația are un utilizator predefinit numit ‘admin’. Acesta este creat în urma rulării script-ului ‘dbData.sql’ și are parola predefinită ‘a’. Cu ajutorul acestui utilizator, administratorul aplicației se poate autentifica și poate crea restul utilizatorilor folosind secțiunea ‘Administration’. Utilizatorii creați astfel, au posibilitatea să își schimbe parola după autentificare prin accesarea opțiunii ‘Profile’.

Câmpurile formularului de autentificare sunt validate iar introducerea greșită a unuia dintre ele va determina afișarea unui mesaj corespunzător. Același lucru se va întâmpla și în cazul în care unul dintre aceste câmpuri nu e completat. Mesajul de eroare va apărea sub câmpuri și va descrie motivul pentru care autentificarea a eșuat.

Prin apăsarea butonului ‘Login’, datele introduse vor fi preluate și transmise acțiunii Struts numite ‘LoginAction’. Aici, acestea se vor prelucra și trimte bazei de date. În cazul în care acest utilizator există în baza de date și parola introdusă este corectă, această acțiune Struts va redirecționa pagina către pagina principală a aplicației.

Figura 5.6.1.1 ilustrează această secțiune a aplicației. Formularul este foarte simplu și intuitiv, caracteristică preluată de la aplicațiile de tip desktop.

Fig. 5.6.1.1. – Secțiunea Login

Secțiunea Projects

După autentificare, utilizatorul va fi redirecționat la pagina principală aplicației. Aceasta conține:

Un buton pentru crearea rapidă a unui task nou

Informațiile despre profilul utilizatorului autentificat unde acesta are posibilitatea să le editeze și să salveze informațiile in baza de date

Secțiune cu informații despre echipa din care face parte utilizatorul autentificat

Secțiune unde utilizatorul poate să ponteze ore pentru fiecare task la care a lucrat

Secțiunile destinate managementului unui proiect care sunt afișate sub formă de tab-uri

Un buton de ‘Logout’

Secțiunea cu informații despre echipă și cea pentru pontarea orelor sunt vizibile indiferent ce tab ar fi selectat. Când sunt deschise acestea se extind fără să strice structura paginii în care sunt integrate.

Figura 5.6.2.1. ilustrează secțiunea ‘Projects’ și secțiunea care conține informații despre echipa din care face parte utilizatorul autentificat. Un utilizator poate să lucreze la mai multe proiecte. Aceste proiecte îi sunt asignate de administrator utilizând o opțiune din meniul ‘Administration’. La deschiderea acestei pagini, acesta trebuie să aleagă proiectul pe care dorește să îl vadă. Selectarea proiectului dorit va popula pagina cu date referitoare la acesta:

Numele și sigla acestuia în cazul în care acesta are una, în caz contrar va fi afișată o imagine predefinită

Grafic care reprezintă distribuția task-urilor în Sprint în funcție de statusul acestora

Grafic care reprezintă repartiția task-urilor în Sprint în funcție de prioritatea acestora

O listă a tuturor task-urilor care aparțin acestui proiect

Fig. 5.6.2.1. – Secțiunea Projects

Secțiunea cu informații despre echipă va conține sigla echipei în cazul în care există una setată, numele echipei și descrierea echipei. Aceste informații sunt completate de către administrator în momentul în care acesta crează o echipă nouă.

Tot în această secțiune vor fi afișate și informații despre membrii echipei precum: numele, postul ocupat, adresa de email și o fotografie în cazul în care această există. Toate fotografiile și siglele afișate în cadrul acestei aplicații sunt încărcate pe server în fișiere corespunzătoare de către administrator folosind secțiunea ‘Administration’ în momentul creării fiecărei entități, iar adresa acestora este memorată în baza de date. În momentul afișării, acestea sunt luate din fișierul corespunzător în cazul în care numele acestora este salvat în baza de date.

Secțiunea Tasks

Această secțiune poate fi deschisă prin selectarea tab-ului ‘Tasks’ din cadrul paginii principlale ale aplicației. Aceasta va conține o listă cu toate task-urile de la toate proiectele care sunt gestionate cu ajutorul acestei aplicații. În cadrul acestei liste se vor regăsi informații precum: numele, id-ul, tipul task-ului, prioritatea, statusul, orele estimate pentru implementare, utilizatorul care a creat acest task, utilizatorul căruia i-a fost asignat pentru implementare, data creării și Sprintul în care a fost planificat.

În această secțiune, task-urile pot fi selectate în funcție de prioritatea lor sau de cererile venite din partea cliențiilor care folosesc aplicațiile respective și mutate în ‘Backlog’ de unde vor fi planificate în următoarele Sprint-uri în funcție de orele disponibile.

Fig. 5.6.3.1. – Secțiunea Tasks

Figura 5.6.3.1 ilustrează o captură de ecran a acestei secțiuni și a secțiunii destinate pontării orelor. La selectarea oricărui task, o fereastră care va conține toate informațiile despre task-ul selectat se va deschide.

Secțiunea pentru pontarea orelor conține un buton pentru generarea unui raport *.pdf cu ajutorul uneltei Crystal Reports XI. Acest raport va conține toate detaliile despre orele pontat de către utilizatorul autentificat. Pe lângă acest raport utilizatorul poate ponta alte ore selectând task-ul la care lucrează și să le salveze în baza de date.

Secțiunea Backlog

Din punctul de vedere al implementării, ‘Backlog’ este considerat ca fiind un Sprint special, un Sprint temporar în care sunt planificate task-urile ce urmează a fi implementate. Acestea sunt mutate aici folosind secțiunea ‘Tasks’. Scopul acestei secțiuni este să ofere suport pentru ședința de planificare a Sprintului.

În cadrul acestei ședințe, Conducătorul Scrum va selecta din Sprint-urile disponibile pe acela care urmează să fie planificat. În urma acestei selecții, o nouă secțiune a paginii va fi afișată. Aceasta va oferii informații în timp real despre task-urile selectate pentru implementare în relație cu orele disponibile din Sprint-ul respectiv.

Conducătorul Scrum împreună cu Deținătorul de produs și cu echipa al cărei Sprint este planificat vor decide împreună pe baza orelor disponibile, care sunt task-urile care vor fi implementate în următorul Sprint.

Figura 5.6.4.1 ilustrează o captură de ecran a acestei secțiuni. Componentele acestei pagini sunt:

Lista cu task-urile ce urmează a fi planificate

Un selector pentru alegerea Sprint-ului ce va fi planificat

O bară care va ilustra procentul de planificare al orelor disponibile

Lista cu task-urile selectate și estimarile acestora

Grafic cu ponderea orelor task-urilor selectate în Sprint-ul planificat

Se poate observa că în urma selectării unor task-uri, lista cu task-urile selectate, graficul și bara se vor adapta imediat. Acestea vor afișa informațiile legate de viitorul Sprint în timp real.

Fig. 5.6.4.1. – Secțiunea Backlog

Când orele disponibile ale Sprintului planificat se epuizează, aceste task-uri se mută efectiv în noul sprint cu ajutorul butonului ‘Move to Sprint’.

Secțiunea Sprints

Utilizatorul autentificat, poate cu ajutorul acestei secțiuni să vizualizeze informații despre Sprint-urile terminate sau în progres ale echipei din care face parte.

Figura 5.6.5.1 ilustrează o captură de ecran a acestei secțiuni. Componentele acestei pagini sunt:

Un selector pentru Sprint-uri

Lista cu task-urile din Sprint-ul selectat

O bară care indică orele ramase în Sprint și dă informații despre numărul de ore pontate

Secțiune care conține informațiile despre Sprint

Grafic care prezintă distribuția task-urilor în Sprint în funcție de statusul acestora

Fig. 5.6.5.1. – Secțiunea Sprints

Secțiunea Administration

Această secțiune este vizibilă doar utilizatorilor care au privilegii de administrator. Utilizând această secțiune un utilizator poate să realizeze toate operațiile ce țin de administrarea acestei aplicații:

Crearea unui utilizator nou

Crearea unei echipe noi

Crearea unui nou proiect

Crearea unui Sprint nou

Crearea unui task

Asignarea de proiecte utilizatorilor

Fig. 5.6.6.1. ilustrează tabul destinat creării unui utilizator din această secțiune. Numele echipelor și posturile disponibile sunt luate din baza de date de fiecare dată când este accesat acest tab, acest lucru ajutând la păstrarea consistenței datelor. Același comportament se aplică și în cazul informațiilor necesare pentru crearea entitațiilor din celelalte tab-uri. Acestea sunt aduse de fiecare dată din baza de date.

Administratorul are posibilitatea de a salva pe server și o poză a noului utilizator creat. Aceasta va fi salvată pe server în directorul corespunzător din directorul ‘upload’. Astfel imaginile pentru fiecare utilizator creat, vor fi salvate în ‘upload/users’. În cazul creării unei echipe noi sau unui proiect nou, acestea vor fi salvate în ‘upload/teams’ respectiv ‘upload/projects’. Acest lucru este realizat de servletul ‘FileUploadServlet’ care verifică entitatea care se crează și alege fișierul potrivit. Aceste imagini vor rămâne publicate pe server, în baza de date fiind memorat doar numele acestora. Aceasta face încărcarea pozelor să fie foarte rapidă dar face necesară mutarea manuală a pozelor în cazul în care aplicația este publicată pe alt server.

Fig. 5.6.6.1. – Secțiunea Administration

Concluzii

Aplicația prezentată în această lucrare contribuie cu succes la gestionarea eficientă a unui Sprint oferind toate mijloacele și funcționalitățile necesare.

Realizând această aplicație am dorit să învăț mai multe și să pun în valoare capabilitățile framework-urilor folosite și descrise în lucrare.

Este o aplicație portabilă datorită tehnologiilor cu care a fost realizată și a structurii sale. O altă caracteristică a sa este interactivitatea sporită care o face ușor de folosit și ajută la vizualizarea rezultatelor modificărilor făcute de utilizatori în timp real.

Faptul că este configurabilă de către utilizator sporește și mai mult utilitatea acestei aplicații.

Modul în care a fost structurată lasă loc de o eventuală extindere a funcționalităților acesteia în viitor.

O direcție posibilă ar putea fi chiar o versiune destinată telefoanelor mobile a acesteia. Acest lucru ar spori foarte mult portabilitatea ei oferind acces din orice locație la problemele de gestionare ale unui proiect software. Acest lucru este facilitat de extinderea framework-ului SAPUI5 și pentru platformele mobile odata cu lansarea ultimelei versiuni ale acestuia. Acest framework împreună cu PhoneGap ar putea transforma această aplicație într-o aplicație destinată telefoanelor mobile păstrând funcționalitățile și aspectul interfeței grafice actual.

Bibliografie

[1] Curs practic de Java – Cristian Frăsinaru

[2] http://www.pawlan.com/monica/articles/j2eearch/

[3] http://vega.unitbv.ro/~cataron/Courses/BD/BD_Cap_5.pdf

[4] http://ro.wikipedia.org/wiki/SQL

[5] http://ro.wikipedia.org/wiki/JavaScript

[7] http://strutscx.cappuccinonet.com/overview.php?target=overview

[8] http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/overview.html

[9] http://technology.amis.nl/2006/03/22/amis-goes-spring/

[10]http://ro.wikipedia.org/wiki/Servlet

[11]http://ro.wikipedia.org/wiki/Scrum_%28programare%29

[12] http://ctrl-d.ro/development/cariera-business-development/totul-e-scrum/

[13]http://profs.info.uaic.ro/~alaiba/mw/index.php?title=Procesul_SCRUM_de_dezvoltare_agil%C4%83_a_produselor_software

[14] http://en.wikipedia.org/wiki/JavaServer_Pages

[15] http://docs.oracle.com/cd/B14099_19/web.1012/b14017/overview.htm

[16] http://agilemanifesto.org/

Anexa 1 – Dependințe utilizate

Anexa 2 – Structura bazei de date folosită de aplicație

Bibliografie

[1] Curs practic de Java – Cristian Frăsinaru

[2] http://www.pawlan.com/monica/articles/j2eearch/

[3] http://vega.unitbv.ro/~cataron/Courses/BD/BD_Cap_5.pdf

[4] http://ro.wikipedia.org/wiki/SQL

[5] http://ro.wikipedia.org/wiki/JavaScript

[7] http://strutscx.cappuccinonet.com/overview.php?target=overview

[8] http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/overview.html

[9] http://technology.amis.nl/2006/03/22/amis-goes-spring/

[10]http://ro.wikipedia.org/wiki/Servlet

[11]http://ro.wikipedia.org/wiki/Scrum_%28programare%29

[12] http://ctrl-d.ro/development/cariera-business-development/totul-e-scrum/

[13]http://profs.info.uaic.ro/~alaiba/mw/index.php?title=Procesul_SCRUM_de_dezvoltare_agil%C4%83_a_produselor_software

[14] http://en.wikipedia.org/wiki/JavaServer_Pages

[15] http://docs.oracle.com/cd/B14099_19/web.1012/b14017/overview.htm

[16] http://agilemanifesto.org/

Anexa 1 – Dependințe utilizate

Anexa 2 – Structura bazei de date folosită de aplicație