Autor: Bianca Mihai
Yüklə 102,18 Kb.
|
- Bu səhifədəki naviqasiya:
- INTRODUCERE 4 ARHITECTURA APLICATIEI 5
- DESIGNUL ARHITECTURII 12
- ALEGEREA ARHITECTURII 28 TEHNOLOGII FOLOSITE 28 Scopul documentului
- Scenarii cheie si modul de utilizare
- Gestionare informatii din sinteza
- Gestionare nomenclatori
- Observatorul
- Specificatii si constrangeri
- Arhitectura de baza a aplicatiei
- Cazul gestionarii datelor din cadrul unei sinteze curente
- Cazul gestionarii nomenclatoarelor
- Validatorul
|
FMEA
Data Creare: 25 martie 2011 Data modificare: 25 martie 2011 Document Versiune: 1 Aprobari: SCOPUL DOCUMENTULUI 3 INTRODUCERE 4 ARHITECTURA APLICATIEI 5 prezentare generala 5 SCENARII CHEIE SI MODUL DE UTILIZARE 7 SPECIFICATII SI CONSTRANGERI 9 arhitectura de baza a aplicatiei 10 DESIGNUL ARHITECTURII 12 FUNCTIONAL VIEW 12 PROCESS VIEW 17 NON-FUNCTIONAL VIEW 22 LOGICAL VIEW 23 INTERFACE VIEW 24 DESIGN VIEW 24 INFRASTRUCTURE VIEW 26 DEPLOYMENT VIEW 26 OPERATIONAL VIEW 26 SECURITY VIEW 26 DATA VIEW 27 ALEGEREA ARHITECTURII 28 TEHNOLOGII FOLOSITE 28
Scopul documentului este acela de a prezenta arhitectura, modul de lucru si scenarile posibile ale aplicatiei FMEA.
Aplicatia FMEA trebuie sa fie fie un produs care sa asiste inteligent utilizatorii in a lua decizii cu privire la planificarea si proiectarea produselor si proceselor. Planificarea Avansata a Calitatti Produsului reglementeaza planificarea avansata a calitatii produsului si a etapelor de dezvoltare a acestuia pentru a satisface toate cerintele clientului. Aplicatia FMEA este o aplicatie web, multiuser compatibila cu Project Repository si cu iSecurity. Sincronizarea dintre Project Repository si iSecutiry se face prin intermediul servicilor web. La acesarea aplicatiei FMEA de catre un utilizaor acesta trebuie sa fie inregistrat si sa aibe drepturi de vizualizare/lucru pe proiectul pe care incearca sa il acceseze. Proiectele sunt trase din Project Repository iar identificarea lor se face pe baza unui id care este stocat in sesiunea aplicatiei. Pentru ca FMEA este o aplicatie WEB aceasta trebuie sa poata fi accesata de pe orice calculator conectat la internet de catre un utilizator autorizat si trebuie sa functioneze la fel pe browsere diferite. La accesarea aplicatiei de catre utilizator pentru a planifica/proiecta un anumit proiect sau proces acestuia i se va afisa un formular de logare. Logarea se va face simplu prin utilizator si parola. Pentru logare se acceseaza Isecurity folosind un serviciul web. Datele primite vor fi stocate si local. Daca serviciul web nu poate sa fie accesat atunci se va incerca login-ul folosind datele stocate local la inregistrari anterioare. In datele stocate pe langa user si parola se regasesc si drepturile utilizatorului in functie de proiectul pe care doreste sa lucreze. Exista trei tipuri de utilizatori: observator, membru de echipa si coordonator. Rolurile le vom discuta mai pe larg in capitolele urmatoare. Deoarece FMEA este o aplicatie multiuser la editarea informatilor din cadrul aplicatiei se va folosi un sistem de lock pentru a pastra consistenta si integritatea datelor stocate. Astfel cand un utilizator va incerca editarea unei informatii aplicatia va face lock pe informatia respectiva si nu va permite deschiderea pentru editare a informatiei respective de catre un alt utilizator pana cand primul nu a terminat sau nu i-a expirat sesiunea.
In acest capitol este prezentata doar o sinteza a aplicatiei pentru informatii mai pe larg despre aceasta si arhitectura ei va rugam sa parcurgeti intregul document.
Pentru ca este vorba despre o aplicatie web arhitectura este una client-server. Urmatoarea figura prezinta arhitectura client-server. 
Fig 1 – Arhitectura generala – Client Server Clientul poate accesa de pe orice calculator conectat la internet aplicatia FMEA daca are drepturi. Arhitectura interna a aplicatiei este o arhitectura MVC poate sa fie impartita in trei blocuri mari:
In acest capitol vom face o prezentare sumara acestea urmand sa fie detaliate in capitolele urmatoare. Controller-ul este blocul care preia toate cererile clientului si le solutioneaza facand legatura intre celelalte doua blocuri. Este procesorul central al arhitecturii. Ascesta preia toate cererile HTTP si le transfera celorlalte obiecte din arhitectura. Model reprezinta partea logica a aplicatiei. El are in responsabilitate actiunile si operatiile asupra datelor, integrarea diverselor clase ce permit procesarea informatiilor din baza de date. View reprezinta interfata afisata utilizatorului. Este formata din pagini HTML care contin css si javascript. Interfata aplicatiei FMEA este impartita in doua. In partea stanga se regasesc toate datele introduse pe proiectul pe care se lucreaza sub forma de arbore iar in partea stanga vizualizarea lor mai in detaliu. Utilizatorul poate alege modul de vizualizare care poate sa fie fie tip tabela fie gantt. In figura de mai jos se prezinta interfata principala a aplicatiei. O explicatie mai detaliata se poate regasi in capitolul de prezentare a functionalitatilor.
Fig 2 – interfata aplicatiei FMEA Scurta descriere:
La accesarea aplicatiei utilizatorului i se cere sa se autentifice (daca nu este deja autentificat). Autentificarea este prezentata in figura de mai jos. Utilizatorului i se afiseaza un formular de introducere a numelui si parolei iar acestea sunt folosite la autentificare accesand un serviciu web. Daca autentificarea a avut succes atunci aplicatia va stoca local datele primite de la serviciul web pentru a le putea folosi la autentificari viitoare in cazul in care serviciul web nu raspunde cererii aplicatiei. 
Fig 3 – scenarii logare In figura urmatoare sunt prezentate scenariile posibile si modul de utilizare a aplicatiei FMEA dupa inregistrarea utilizatorului.
Fig 4 – Scenarii cheie O descrire completa a fiecarui caz va fi facuta in capitolele urmatoare mai jos fiind prezentate pe scurt.
Informatile sunt vizualizate in trei moduri: sub forma de arbore pe mai multe nivele, sub forma de tabela si sub forma de grafic de tip gantt. Cautara si filtrarea informatilor pot sa fie accesate de orice utilizator indiferent de rolul pe care il are in proiectul accesat. Cautarea este de doua feluri: cautare simpla si cautare avansata. Cautarea simpla se face dupa orice atribut de tip text a informatilor introduse iar cautarea avansata se va efectua folosind un serviciu web. Filtrare se va putea efectua dupa oricare coloana afisata in modul de afisare tip tabela. Gestionare informatii din sinteza – aici intra trei cazuri care pot avea loc doar pe sinteza curenta:
Adaugare sinteza noua – cazul poate sa fie folosit doar de catre coordonator. La crearea unei sinteze noi sintezele precedente sunt arhivate si devin readonly. Gestionare nomenclatori – poate fi folosit doar de catre coordonator si cuprinde operatii CRUD cum sunt Adaugare, Editare si Dezactivare. Generarea rapoartelor – este un scenariu care poate sa fie pus in practica de catre coordonatorul proiectului. Generarea rapoartelor se face folosind o aplicatie java open source. Cum se poate vedea in imaginea precedenta exista trei roluri posibile pentru fiecare client in functie de proiectul/procesul pe care lucreaza in aplicatia FMEA. Cele trei roluri sunt: observator, membru sau coordonator. In functie de rolul pe care il are un utilizator acesta are anumite drepturi si privilegii. Observatorul este utilizatorul cu cele mai putine drepturi. Acesta poate doar vizualiza informatile deja introduse in aplicatie nu poate edita sau sterge nimic. Membrul de echipa este utilizatorul care poate vizualiza informatile deja introduse si poate lucra doar pe datele din sinteza curenta. Acesta are drepturi de adaugare, stergere si editare de informatii din sinteza curenta. Coordonatorul este membrul cu drepturi depline. Acesta are dreptul sa vizualizeze toate informatile introduse, poate sa lucreze pe sinteza curenta adica sa adauge informatii noi in sinteza curenta, sa le editeze si sa le stearga. Mai poate crea o sinteza noua si in acest caz aceasta automat devine sinteza curenta restul fiin arhivate si pastrate doar pentru vizualizare si mai poate gestiona nomenclatorii
Aplicatia FMEA va fi scrisa in limbajul PHP deci va putea rula pe un server pe care este instalat Apache. Comunicarea cu restul aplicatilor va fi facuta prin intermediul servicilor web. Pentru a putea lucra cu servicii web este nevoie ca libraria SOAP sa fie instalata si activata pe server.Deoarece este o aplicatie web va folosi pentru comunicare protocolul HTTP. Pentru mai multa securitate se recomanda folosirea unui protocol securizat cum este HTTPS. Dupa ce o conexiune este deschisa user-ului i se va cere sa se autentifice. Autentificarea este facuta prin user si parola. Pentru autentificare aplicatia va apela un web service. Dupa apelarea webservice-ului daca autentificarea a fost facuta cu success va stoca local (in baza de date) datele utilizatorului. Astfel daca la un moment dat serviciul web nu va putea sa fie apelat se va incerca autentificarea utilizatorului folosind datele stocate local. Accesarea aplicatiei se va face mereu cu un id de proiect ca si parametru care se poate trimite pe POST sau pe GET. Acest id este preluat din Project Repository. Daca proiectul respectiv nu are corespondent in baza de date locala a aplicatiei FMEA utilizatorului i se afiseaza un mesaj de eroare. Sincronizarea proiectelor intre Project Repository si FMEA se face tot ptin intermediul unui serviciu web la anumite intervale de timp (se poate folosi un cron job).Informatile primite de la servicile web se vor stoca mereu si in baza de date locala a aplicatiei. Pentru ca FMEA este o aplicatie pe care lucreaza mai multi utilizatori concomitent este nevoie de un sistem de lock la editarea datelor. Astfel se asigura pastrarea consistentei informatilor. FMEA trebuie sa dispuna de un modul de validare a informatilor. Orice date care sunt trimise pentru salvare sau care sunt afisare in interfata trebuie sa fie sanitizate si validate. Astfel vor exista situatii cand un ultilizator va incerca sa modifice o informatie deja deschisa pentru editare de catre un alt user. In acest caz daca sesiunea primului user nu expirat deja, utilizatorul va primi un mesaj de eroare, daca sesiunea de editare a expirat informatia va fi deblocata si se va bloca pentru al doilea utilizator la editare. Aplicatia trebuie sa dispuna de un sistem de loguri, care vor fi pastrate in acelasi fisier pentru toti utilizatorii. Astfel va exista un fel de jurnal al tuturor actiunilor efectuate.Orice eroare aparuta in aplicatie trebuie tratata si logata intr-un fisier de error loguri. Eroarea aparuta este stocata in log iar utilizatorului i se afiseaza un mesaj user-friendly. La afisarea interfetei pentru vizualizarea informatilor va fi folosit un grid (componenta javascript) care primeste pentru afisare date in format XML. Pentru acest grid va trebui respectat standardul XML. Toate specificatile si constrangerile prezentate mai sus trebuie sa fie respectate in dezvoltare aplicatiei FMEA.
Arhitectura aplicatiei este una MVC. MVC, sau Model-View-Controller este un sablon arhitectural folosit in web development. Aceasta modalitate de lucru reuseste cu succes izolarea partii logice de interfata proiectului, rezultand in aplicatii extrem de usor de modificat. In organizarea MVC, modelul reprezinta informatia (datele) de care are nevoie aplicatia, viewerul corespunde cu elementele de interfata iar controller-ul reprezinta sistemul comunicativ si decizional ce proceseaza datele informationale, facand legatura intre model si view. In figura de mai jos sunt evidentiate cele trei blocuri controller-ul, model-ul si view-ul si legaturile dintre acestea. Se observa cum toate cererile HTTP sunt captate de catre controller care este creierul arhitecturii acesta fiind responsabil cu accesarea si stabilirea legaturilor dintre celelalte doua modele. 
Fig 5 – Arhitectura de baza a aplicatiei Cand un client trimite o cerere aceasta este trimisa Controller-ului pentru rezolvare. Orice date primite trebuie sa fie validate. Validarea se va face in controller si va fi tratata de catre modulul de validare. Astfel orice date care sunt trimise catre aplicatie pe get sau pe post vor fii sanitizate si orice operatie ceruta (adaugare, stergere etc) va fi mai intai verificata daca se gaseste in lista actiunilor permise. Cererea de validare a datelor se va face dupa primirea lor si inaintea salvarii lor in baza de date. In functie de cererea primita Controller-ul decide daca este nevoie sa apeleze modelul pentru extragerea de informatii sau salvarea informatilor primite iar pentru afisarea rezultatelor apeleaza View-ul care adiseaza utilizatorului interfata grafica obtinute. View-ul foloseste pentru afisare HTML, CSS, JS si XML. Pe langa modulul de validare in Controller mai exista un modul de generare a XML-urilor. XML-uri care sunt folosite in interfara pentru afisarea datelor in structura de tip treegrid. Aceasta structura treegrid este o componenta javascript care primeste datele pentru afisare sub forma de XML-uri. Informatiile sunt stocate local intr-o baza de date relationala MySQL. Pentru interfata se va folosi libraria Jquery si o componenta javascript treegrid. Restul codului va fi scris de catre programator. Arhitectura folosita va fi MVC si principiul SingleTon. Arhitectura MVC este prezentata in figura precedenta si in Figura 1. Principiul Singleton se traduce prin restrictionarea instantierii unei clase si anume o clasa va avea o singura instanta care va fi apelata de mai multe resurse din aplicatie. La instantierea unui obiect se va verifica mai intai daca nu exista deja o instanta creata si daca da se va returna instanta respectiva. Erorile vor fi tratate prin intermediul unei clase care va afisa erori user-friendly utilizatorului dar in acelasi timp va loga eroarea aparuta in fisierul de loguri. Toate erorile vor fii logate in fisier de loguri folosind functia php error_log. Baza de date MySLQ este una relationala.
In capitolul precedent arhitectura este prezentata ca un bloc cu componente care interactioneaza si submodule. In acest capitol se va prezenta aceasi arhitectura dar din puncte de vedere diferite pentru a avea o viziune cat mai clara asupra ei.
Functionalitatea principala a aplicatiei FMEA este de a stoca informatii si a le afisa. Pentru a indeplini aceste functii aplicatia trebuie sa dispuna de un modul de validare a datelor pentru a asigura integritatea informatilor stocate sau afisate utilizatorilor precum si transformarea datelor pentru a returna interfetei date in format corect (exemplu XML) daca acest lucru este cerut. Pentru ca aplicatia este construita in jurul unor module deja existente si depunde de aceste module aceasta trebuie sa implementeze cateva submodule obligatorii:
La accesarea aplicatiei FMEA utilizatorului i se afiseaza un formular de login. Dupa logare acesta este redirectat intr-o pagina de dashboard. 
Fig 6 – login in aplicatia FMEA Interfata paginii de dashboard este impartita in doua. Sus exista un meniu. Optiunea de “Nomenclatori” din meniu apare doar utilizatorilor cu drepturi de administrare. Apoi este afisat numele utilizatorului logat si optiunea de logout. Dupa meniu exista optiunea de schimbare a limbii. Vor exista doua limbi in aplicatia FMEA (engleza si romana). Implicit aplicatia se ve deschide pe limba utilizatorului. Optiunea “Rapoarte” din meniu duce in subsectiunea de generare a rapoartelor iar “Cautare avansata” in subsectiunea de cautare folosind un web service. In partea stanga sunt afisate sub forma de tabela toate proiectele pe care utilizatorul logat are drepturi. Deasupra tabelei exista optiune de cautare dupa un proiect, optiune de afisare doar a proiectelor deschise, doar a proiectelor inchise sau a tuturor proiectelor. In tabela se afiseaza titlul proiectului, descrierea proiectului, data de inceput si data de sfarsit a proiectului. La click pe un proiect din partea stanga in partea dreapta se afiseaza toate intrarile FMEA needitabile din acel proiect care ii sunt asignate utilizatorului logat si care sunt deschise.
Fig 7 – dashboard Prin dubluclick pe un proiect din partea stanga acesta este selectat pentru lucru. Interfata pentru lucru pe un proiect este prezentata in figura 8. Deschiderea unui proiect pentru lucru se face intr-o pagina noua. Astfel se poate lucra pe mai multe proiecte in acelasi timp. Ca si la pasul anterior aceasta este impartita in doua are insa in plus un submeniu cu optiuni. In partea stanga sunt afisate sub forma de tabela toate sintezele din proiectul selectat. 
Fig 8 – navigator sinteze FMEA In submeniu exista optiunea de “Tree view”. La click pe aceasta optiune afisarea in stanga se va face sub forma de tree pe doua nivele. Pe primul nivel sintezele iar pe nivelul al doilea atributele sintezei (ex: echipa, coordonator, numarul si data etc). Vizualizarea de tip tree este schitata in figura de mai jos.
Fig 8 – Tree View in navigatorul de sinteze Celelalte trei optiuni: “Adaugare sinteza noua”, “Editare sinteza” si “Stergere sinteza” se vor afisa doar utilizatorilor cu drept de coordonator. La click pe optiunea de adaugare sau optiunea de editare a unei sinteze in partea dreapta de deschide un formular pentru adaugarea unei sinteze noi respectiv editarea unei sinteze selectate. La click pe butonul de stergere a unei sinteze aplicatia va sterge sinteza selectata de catre utilizator impreuna cu toate datele care tin de aceasta. Inainte de stergere utilizatorului I se va cere sa confirme actiunea. La click pe o sinteza in partea stanga se deschide pentru vizualizare tabela cu toate intrarile din sinteza(needitabile). La dubluclick pe o sinteza in partea dreapta de deschide o sinteza pentru lucru intr-o pagina noua. Exista posibilitatea de a lucra pe mai multe sinteze simultan. Mai jos este explicat pasul de lucru pe o sinteza.
Fig 9 – aplicatia FMEA In submeniu apar optiunile “Adauga grup”, “Adauga editie” si “Adauga item FMEA in editia curenta”. Primele doua optiuni sunt vizibile doar coordonatorului de sinteza iar a treia este vizibila coordonatorului si membrilor. Toate trei deschid in partea dreapta formulare de adaugare a unui grup nou, editie noua respective formular de adaugare a unui item FMEA nou. In partea stanga a aplicatiei se regasesc informatile introduse pe proiectul care se lucreaza. Acestea sunt afisate intr-o structura de tip arbore pe 4 nivele. Pe primul nivel se gasesc sintezele introduse, ordonate dupa data. Se poate lucra doar pe editia curenta restul sunt readonly (pot sa fie doar vizualizate). Urmatorul nivel sunt grupuril apoi itemii fmea si ultimul nivel este format din toate atributele unui item fmea. La click pe o editie sau pe un grup in partea dreapta se afiseaza itemii fmea care fac parte din editia sau grupul respectiv. Modul de vizualizare poate sa fie ales de catre utilizator. Implicit este selectat modul de vizualizare de tip tabela dar utilizatorul poate sa treaca pe vizualizarea de tip gantt folosind meniul de tip tab. In modul de vizualizare de tip tabela exista o cautare simpla, filtrare si sortare dupa fiecare coloana din tabela mai putin prima care este folosita pentru optiunile de selectare, editare sau stergere. Randurile din table pot sa fie grupate dupa anumite coloane. Exista si optiune de filtru custom, de exemplu afisarea celor mai critice 10 intrari. Modul de vizualizare de tip tabela permite si editarea la nivel de linie nu numai la nivel de formular. Pentru editarea la nivel de formular se acceseaza optiunea de editare din prima coloana. Va exista si optiune de stergere multipla prin selectarea mai multor randuri din tabela dar si optiunea de export in xsl sau pdf a tabelei afisate. Optiunile de stergere si editare la nivel de linie si formular sunt prezente doar in cazul sintezei curente. Pentru restul sintezelor aceste optiuni lipsesc. Vor exista insa optiunile de export in xsl sau pdf. Tot la vizualizarea de tip tabela exista optiuni de grupare dupa anumite coloane cum este de exemplu tipul reviziei (proces, proiect, piesa etc). Daca utilizatorul doreste sa vizualizeze informatile sub forma grafica trebuie sa selecteze tabul Gantt. Diagrama se realizeaza pe baza datei de introducere a reviziei si a datei setate pentru luarea masurilor. Se poate adauga si un filtru pe data prin care utilizatorul sa poata vizualiza revizile doar pe o anumita perioada. In figura de mai jos este prezentata interfata de tip Gantt cu optiunea de filtrare pe o anumita perioada de timp. 
Fig 10 – vederea de tip gantt La adaugarea unei editii noi aceasta devine editia curenta pe care se va lucra pana se va adauga urmatoarea. Restul devin readonly si mai pot sa fie doar vizualizate. Dupa adaugarea unei editii sau la editarea reviziei curente structura de tip arbore din partea stanga a aplicatiei este refacuta pentru a reflecta modificarile. Validarea formularului va fi facuta pe doua nivele: la nivel de javascript si la nivel de cod php prin intermediul validatorului din aplicatie. Formularul de adaugare sau editare a unei revizii este prezentat in figura urmatoare. 
Fig 11 – adaugare/editare revizii La adaugarea/editarea revizilor campurile din formular vor fi populate cu liste de nomenclatori pe baza revizilor introduse anterior in sistem. Nomenclatorii sunt gestionati de catre coordonator din sectiunea de “Gestionare nomenclatori”. Dupa adaugarea sau editarea unei revizii structura de tip arbore din partea stanga a aplicatiei este refacuta pentru a reflecta ultimele modificari din sinteza curenta. Validarea formularului va fi facuta pe doua nivele si anume la nivel de javascript si la nivel de aplicatie prin intermediul validatorului din aplicatie. Interfata pentru gestionarea nomenclatorilor este construita pe baza aceleasi componente js. Valorile nomenclatorilor se afiseaza grupat. Exista un selectbox din care se va alege nomenclatorul pe care se doreste sa se lucreze. Implicit la afisare este selectat un nomenlator. Valorile sunt afisate in grid paginat. Exista insa optiune de afisare nepaginata. Tot in grid exista si cautare/filtrare simpla dupa orice text afisat in componenta js. Primul rand este gol pentru a putea introduce rapid o noua valoare. Editarea si adaugarea se fac la nivel de rand in tabela afisata. Exista validari pentru unicitatea valorilor introduse. In sectiunea de nomenclatori nu exista stergere. Exista insa dezactivare adica trecerea unui nomenclator in modul inactiv. Doar utilizatorii cu rol de coordonator au acces in sectiunea de gestionare a nomenclatorilor. Acestia sunt folositi pentru afisarea unei liste la completarea campurilor formularelor de adaugare/editare a unei revizii in functie de grupul din care fac parte si de optiunile precedente ale utilizatorului. Pe nomenclatori se pot efectua operatile de tip CRUD anume adaugare, editare si dezactivare. Nu se poate efectua o stergere fizica a unui nomenclator pentru a asigura integritatea datelor introduse din aceasta cauza a fost introdusa dezactivarea. Daca un nomenclator este dezactivat acesta nu va mai aparea in lista la adaugarea/editarea unei revizii. In figura urmatoare este prezentata o schema a interfetei pentru gestionarea nomenclatorilor. 
Fig 10 – gestionare nomenclatori Cautarea avansata si rapoartele vor fi prezentate in capitolul care prezinta cerintele non-functionalitatile sistemului deoarece sunt generate folosind componente externe.
Diagrama de mai jos prezinta princilalele procese din sistem si cum interactioneaza ele. 
Fig 11 – principalele procese din sistem Figura urmatoare detaliaza procesele din cazul de vizualizare informatii. Pe figura se observa cum Controller-ul este cel care se ocupa de cererea utilizatorului si apeleaza validatorul pentru sanitizarea informatiilor trimise in acest caz id-ul proiectului pentru care se cer informatile apoi apeleaza model-ul care returneaza informatile controller-ului iar acesta cere mai departe afisarea lor utilizatorului.
Fig 12 – procesele pentru cazul vizualizare informatii Cazul de creare a unei sinteze noi de lucru contine urmatorii pasi:
Daca apar probleme (un utilizator lucreaza de exemplu in acelasi timp pe sinteza curenta) acestea vor fi trimise controller-ului care le va afisa utilizatorului. In figura urmatoare este reprezentat procesul de creare a unei sinteze noi in cadrul proiectului pe care se lucreaza. 
Fig 13 – Procesele pentru cazul de creare sinteza noua Cazul gestionarii datelor din cadrul unei sinteze curente este cazul cel mai des intalnit in aplicatie. Operatile posibile in acest caz sunt operatile CRUD si anume adaugare, editare si stergere Pasii de baza sunt:
Figura urmatoare prezinta cazul gestionarii datelor pentru cele trei tipuri de operatii: adaugare, editare si stergere. 
Fig 14 – Procesele pentru cazul de gestionare a datelor din sinteza curenta Cazul gestionarii nomenclatoarelor este intalnit doar la utilizatorii cu rod de coordonator. Gestionarea nomenclatoarelor cuprinde procesul vizualizare sub forma de tip arbore sau tabela, procesul de adaugare a unui nou nomenclator, procesul de editare a unui nomenclator si procesul de stergere. Pentru ca nomenclatoarele sunt informatii commune utilizate de toate proiectele si fiecare proiect poate avea un coordonator diferit in cazul de editare este nevoie de lock din partea sistemului iar la adaugare este nevoie de verificare a unicitatii. Nu exista un proces de stergere a nomenclatoarelor pentru a pastra integritatea datelor introduse in aplicatie sub forma de revizii. In locul stergerii s-a introdus procesul de dezactivare. Daca un nomenclator este dezactivat el nu va mai aparea in lista pentru selectie la adaugarea sau editarea unei revizii, va fi insa afisat in continuare la vizualizare sau in rapoarte in revizile unde a fost deja introdus. In figura urmatoare sunt prezentate procesele din cazul gestionarii nomenclatoarelor (vizualizare, adaugare, editare si dezactivare). 
Fig 14 – procese gestionare nomenclatori Alt caz care poate sa apara doar in cazul utilizatorilor cu rol de coordonator este cel de generare rapoarte. Pentru generarea rapoartelor se foloseste o aplicatie externa. In figura de mai jos este schitat procesul de generare raport nou.
Fig 15 – generare rapoarte Un alt caz intalnit de catre toti utlizatorii la accesarea aplicatiei FMEA este loginul. Logarea se face prin user si parola utilizand un serviciu web. Daca serviciul nu poate sa fie accesat se va incerca logarea cu datele salvate in baza de date locala in cazul logarilor efectuate cu success.
Fig 16 - login
Acest subcapitol sintetizeaza cerintele cheie non-functionale si le evidentiaza pe cele care sunt importante din punctul de vedere al arhitecturii. FMEA va oferi servicii de logare pentru logica de business. Toate logurile vor fi pastrare in acelasi fisier. Nu exista o cerinta obligatorie de a avea un istoric al operatilor efectuate in aplicatie insa aceasta caracteristica va construi in jurnal al tuturor actiunilor efectuate. FMEA va oferi un jurnal al erorilor. Aplicatia va scrie intr-un fisier de log toate erorile aparute in timpul executiei. Utilizatorului nu I se vor afisa codurile de eroare ci doar mesaje user-friendly. Tot o cerinta non-functionala este si login-ul deoarece este efectuat printr-o componenta externa si anume iSecurity. Login-ul se face prin utilizator si parola si este obligatoriu pentru a putea accesa aplicatia FMEA. Mai jos este prezentata o schema a formularului de logare. 
Fig 17 – formular autentificare Tot o cerinta non-functionala este si sincronizarea proiectelor cu Project Repository dar si cautarea avansata care deschide o pagina noua cu diferite criterii si campuri de cautare. Cautarea se va face accesand un serviciu web extern. Rapoartele sunt si ele cerinte non-functionale si se vor intocmi folosind aplicatia java jasper reports. Aplicatia jasper reports este o aplicatie open source care genereaza rapoarte pe baza de template-uri. Astfel o modificare in rapoarte se va face relativ usor modificand doar template-ul care sta la baza acelui raport. Comunicarea dintre php si java se poate face in doua moduri, folosind componenta PHP/Java Bridge (mai multe detalii despre aceasta componenta se regasesc acici: http://php-java-bridge.sourceforge.net/pjb/) sau prin scriere unei mici aplicatii java care sa acceseze jasper reports si sa puna la dispozitia aplicatiei FMEA un serviciu web prin care sa poata cere intocmirea unui raport.
Aplicatia poate sa fie impartita in trei parti. Logica functionala (controller-ul), componenta business logic(modelul) si interfata (view). Diagrama de mai jos prezinta aceste trei componente si componentele externe cu care aplicatia comunica. 
Fig 18 – logica aplicatiei Clientul Web Service trateaza comunicarea cu iSecurity la logarea utilizatorului in aplicatie. Comunicarea este facuta prin intermediul servicilor web. Aplicatia foloseste libraria SOAP pentru consumarea serviciului web. Tot prin intermediul servicilor web se realizeaza si sincronizarea proiectelor si proceselor din aplicatia ProjectRepository. Toate datele obtinute sunt salvate local in baza de date. Roluri:
Validatorul este folosit in doua cazuri:
Modelul reprezinta partea de hard-programming, partea logica a aplicatiei. El are in responsabilitate actiunile si operatiile asupra datelor, autentificarea utilizatorilor, integrarea diverselor clase ce permit procesarea informatiilor din diverse baze de date. FMEA va extinde Modelul pentru fiecare din cazurile prezentate mai sus si anume pentru gestionarea sintezelor, pentru gestionarea operatilor din sinteze, pentru gestionarea nomenclatorilor precum si pentru salvarea datelor obtinute din servicile web. View-ul se ocupa de afisarea datelor, practic aceasta parte a programului va avea grija de cum vede end-userul informatia procesata de controller. O data ce functiile sunt executate de model, viewului ii sunt oferite rezultatele, iar acesta le va trimite catre browser. in general viewul este o mini-aplicatie ce ajuta la randarea unor informatii, având la baza diverse template-uri. Acesta se va concretiza in aplicatia FMEA in formulare de login, adaugare si editare informatii si pagini de vizualizare in diferite forme a informatilor introduse. Controller-ul reprezinta creierul aplicatiei. Aceasta face legatura intre model si view, intre actiunile userului si partea decizionala a aplicatiei. in functie de nevoile utilizatorului, controllerul apeleaza diverse functii definite special pentru sectiunea de site in care se afla userul. Functia se va folosi de model pentru a prelucra (extrage, actualiza) datele, dupa care informatiile noi vor fi trimise catre view, ce le va afisa apoi prin template-uri.
FMEA va comunica cu doua aplicatii existente (iSecurity si ProjectRepository). Comunicarea se va face prin servicii web. FMEA va implementa un client pe baza librariei SOAP care va putea consuma servicile puse la dispozitie de cele doua aplicatii. Toate datele obtinute se vor salva si in baza de date. Pentru generarea rapoartelor FMEA foloseste Jasper Reports. Pentru comunicarea cu aplicatia java FMEA are doua posibilitati. Una dintre ele este sa foloseasca Php/Java Bridge iar a doua este sa comunice printr-un serviciu web cu o aplicatia java care va accesa jasper reports pentru generarea rapoartelor.
Componente importante ale aplicatiei sunt controller-ul si clasele care extind controller-ul, modelul si clasele care il extind, view-ul, validatorul dar si clientul care consuma web service-urile . Controller-ul contine cateva metode importante:
Model-ul:
Validatorul:
Clientul web service:
Fig 19 Diagrama claselor inportante
Pentru ca FMEA este o aplicatie web scrisa in limbajul PHP care foloseste o baza de date relationala MySQL, serverul pe care aceasta va fi instalata trebuie sa aibe APACHE-ul instalat . Versiuniea PHP trebuie sa nu fie mai veche de 5.3 iar cea de MySQL de 5.5. PHP -ul trebuie sa aibe activata extensia SOAP pentru ca aplicatia sa poata consuma servicii web folosind libraria mai sus amintita.
Pentru instalarea aplicatiei mai intai trebuie creata baza de date. Pentru a crea baza de date trebuie rulat scriptul fmea.sql din directorul aplicatiei. Dupa ce baza de date a fost creata trebuie creat un user identificat de o parola. Acestuia i se dau drepturi de selectare, adaugare, stergere si editare informatii in baza de date precum si de a rula proceduri stocate. Acest user va fi folosit de catre aplicatie, si nu trebuie sa aibe drepturi de administrator. Urmatorul pas este urcarea fisierelor pe server in directorul radacina al aplicatiei. Toate datele de configurare se regasesc in fisierul config.php (din directorul radacina al aplicatiei). Doar aici trebuiesc modificate datele pentru ca aplicatia sa functioneze corect. Apoi se dau drepturi de scriere pe directoarele logs si error_logs pentru ca aplicatia sa poata loga actiunile utilizatorilor precum si erorile aparute in aceste directoare.
Exista un singur fisier de configurare pentru aplicatia FMEA iar acesta este config.php. In fisierul config.php exista urmatoarele constante importante care trebuie obligatoriu setate pentru functionarea aplicatiei:
Toate logurile din aplicatie vor fi stocate in directorul logs iar logarea erorilor se va face in directorul error_logs, ambele in directorul radacina a aplicatiei. Logarea actiunilor utilizatorului precum si a erorilor se va face prin folosind functia php error_log. Trebuie verificat sa existe drepturi de scriere pe aceste directoare pentru ca aplicatia sa poata loga in ele actiunile si erorile aparute in executie.
Autentificarea si autorizarea este obligatorie pentru a putea accesa aplicatia si este facuta prin iSecurity folosind username si parola. Utilizatorul trebuie sa fie logat inainte de a putea face orice operatie in aplicatia FMEA. Utilizatorul va putea efectua actiuni doar pe proiectele pe care are drepturi in functie de rolul sau. Exista trei tipuri de utilizatori (roluri) in aplicatia FMEA. Observatorul este utilizatorul cu cele mai putine drepturi. Acesta poate doar vizualiza informatile deja introduse in aplicatie nu poate edita sau sterge nimic. Membrul de echipa este utilizatorul care poate vizualiza informatile deja introduse si poate lucra doar pe datele din sinteza curenta. Acesta are drepturi de adaugare, stergere si editare de informatii din sinteza curenta. Coordonatorul este membrul cu drepturi depline. Acesta are dreptul sa vizualizeze toate informatile introduse, poate sa lucreze pe sinteza curenta adica sa adauge informatii noi in sinteza curenta, sa le editeze si sa le stearga. Mai poate crea o sinteza noua si in acest caz aceasta automat devine sinteza curenta restul fiin arhivate si pastrate doar pentru vizualizare si mai poate gestiona nomenclatorii. Comunicarea poate sa fie securizata folosind SSL(HTTPS) din cauza faptului ca, conexiunea se face prin internet. Indiferent de protocolul de de comunicare HTTP sau HTTPS autentificarea prin user si parola este obligatorie si ar trebui sa fie securizata prin SSL. Cum datele utilizatorului trebuie sa fie stocate si local parola va fi criptata si nu text simplu.
Pentru stocarea informatilor aplicatia foloseste o baza de date relationala a carei structura este prezentata mai jos: 
Fig 20 - Diagrama bazei de date
Pentru implementarea aplicatiei s-a ales arhitectura MVC. Aceasta separa foarte bine partea de interfata de logica business si de logica functionala. Mai multe detalii despre aceasta arhitectura au fost prezentate in capitolul anterior. Un principiu care a stat la baza construirii aplicatiei pe langa arhitectura ei MVC a fost principiul Singleton. Principiul Singleton se traduce prin restrictionarea instantierii unei clase si anume o clasa va avea o singura instanta care va fi apelata de mai multe resurse din aplicatie. La instantierea unui obiect se va verifica mai intai daca nu exista deja o instanta creata si daca da se va returna instanta respectiva. Tehnologii folosite Pentru implementarea interfetei s-a folosit HTML, CSS, Javascript si libraria jQuery. Mai multe despre libraria jQuery se poate citi aici: http://docs.jquery.com/ Tot in interfata spentru afisarea informatilor in functie de alegerea utilizatorului (sub forma de arbore, tabela sau gant) s-a utilizat o componenta javascript care lucreaza cu XML-uri. Mai multe despre aceasta componenta se poate citi aici: http://www.treegrid.com/treegrid/www/ Baza de date este una relationala MySQL. Pentru scrierea aplicatiei se va incerca folosirea unui framework si anume yiiframework (mai multe detalii despre acest framework se pot citi in documentatie: http://www.yiiframework.com/doc/ ) daca insa se observa ca folosirea lui este nepotrivita se vor scrie clasele php de catre programator. Pentru rapoarte se va folosi jasper reports. Jasper reports este o aplicatie scrisa in java, open source care genereaza rapoarte pe baza de template-uri. Comunicarea dintre php si java se poate face in doua moduri, folosind componenta PHP/Java Bridge (mai multe detalii despre aceasta componenta se regasesc acici: http://php-java-bridge.sourceforge.net/pjb/) sau prin scriere unei mici aplicatii java care sa acceseze jasper reports si sa puna la dispozitia aplicatiei FMEA un serviciu web prin care sa poata cere intocmirea unui raport. Yüklə 102,18 Kb. Dostları ilə paylaş:
|
