Gestiunea Facturilor Intr Un Spital

Universitatea „Dunărea de Jos” din Galați

Facultatea de Automatică, Calculatoare, Inginerie Electrică și Electronică

Departamentul de Calculatoare și Tehnologia Informației

Lucrare de licență

Gestiune
a consultațiilor și facturilor pentru un spital

Coordonator științific,

Ș.l. dr. ing. Mihai Vlase

Absolvent,
Șerban Sabin-Adrian

Tabela figurilor

Figura 3.1. Diagrama Use Case 12

Figura 3.2. Diagrama de activități 15

Figura 3.3. Diagrama claselor 18

Figura 2.4. Modelul conceptual al datelor 24

Figura 3.5. Modelul logic al datelor 26

Figura 3.6. Modelul fizic al datelor 27

Figura 4.2. Schematica paginii de logare 33

Figura 4.3. Schematica interfaței cu utilizatorul 34

Figura 4.4. Schematica formularului de programare 35

Figura 4.5. Schematica formularului de programare pasul 2 36

Figura 4.6. Schematica formularului de programare pasul 3 37

Figura 5.1. Fluxul de gestiune a unei cereri prin Web MVC 41

Figura 4.2. Fluxul de gestiune a unei cereri prin REST 42

Figura 6.1. Structura proiectului 61

Figura 6.2. Bara de meniu 62

Figura 6.3. Secțiile spitalului 64

Figura 6.4. Medicii unei secții 64

Figura 6.5. Filtrare medici 65

Figura 6.6. Servicii și Tarife 65

Figura 6.7. Date Contact 66

Figura 6.8. Formular de logare 66

Figura 6.9. Mesaj eroare logare 67

Figura 6.10. Interfața cu utilizatorul 67

Figura 6.11. Formular de programare date personale 68

Figura 6.12. Formular de selectare data și ora programării 68

Figura 6.13. Selectarea datei și orei unei programări 69

Figura 6.14. Confirmare programare 70

Figura 6.15. Confirmare programare mesaj 70

Figura 6.16. Grilă istoric 71

Figura 6.17. Modal fișă pacient 71

Figura 6.18. Fișă pacient 72

Figura 6.19. Modal pentu consultații 72

Figura 6.20. Factura consultațiilor 73

Figura 6.21. Calendar programări 74

Figura 6.22. Selectare programare 74

Figura 6.23. Modal programare 75

Figura 6.24. Formular Consultație 76

Figura 6.25. Internare pacient 77

Figura 6.26. Externare pacient 77

Figura 6.27. Modal inserat programare 78

Figura 6.28. Inserarea programare pacient existent 79

Figura 6.29. Inserarea programare pacient nou 79

Figura 6.30. Data și Ora programării inserate 80

Figura 6.31. Mesaj de confirmare 80

Figura 6.32. Mesaj de eroare 81

Figura 6.33. Tabelă gestiune conturi 81

Figura 7.34. Unit Testing Spring REST 82

Introducere

Structura documentației

Se va prezenta pe scurt conținutul fiecărui capitol din această lucrare. Lucrarea este formată din șapte capitole plus anexe.

Primul capitol se va prezenta câteva detalii despre domeniul medical, motivarea lucrării și scopul acesteia. În al doilea capitol se prezintă cerințele clienților asupra ce trebuie să realizeze aplicația.

Al treilea capitol cuprinde analiza aplicației, cu tipul de utilizatori și operațiile lor, precum și diagramele uml use-case, de activități și a claselor. Pe lângă acestea se mai află și proiectarea bazei de date cu modelul conceptual, logic și fizic al datelor. Al patrulea capitol prezintă schemele de proiectare a interfeței web, pentru a ajuta în stabilirea aspectului ei.

În capitolul cinci sunt prezentate detalii despre tehnologiile folosite pentru implementarea aplicației. Al șaselea capitol reprezintă prezentarea celor mai importante operații din aplicația implementată cu detalii despre acestea.

În ultimul capitol sunt prezentate concluziile finale referitoare la tot ce s-a prezentat pe parcursul acestei licențe și câteva direcții de îmbunătățire a aplicației realizate.

Scopul și obiectivele lucrării

Datorită utilizării tot mai accentuate a calculatoarelor și a extinderii din ce în ce mai mare a Internetului și a World Wide Web în tot mai multe domenii de activitate și în viața de zi cu zi au apărut din ce în ce mai multe aplicații web based care oferă pachete de servicii pentru clienții săi.

Fiecare dintre noi se confruntă cu problema stocării, organizării și prelucrării în timp real a informațiilor relevante pentru noi sau pentru locul de muncă. Sistemul medical nu este exclus din această categorie.

Sistemul medical din România este un sistem finanțat de Comisia Națională a Fondului de Asigurări Sociale de Sănătate, la care angajatorii și angajații fac contribuții obligatorii, iar serviciile medicale sunt acordate în baza contribuției la fondul de asigurări de sănătate a asiguratului. Înainte de anul 1989, România avea un sistem medical finanțat public și deținut de stat cu putere de decizie centralizată integral și fără a se face vreo diferențiere între beneficiari/furnizori în ceea ce privește furnizarea serviciilor medicale. Se punea accentul pe asistența medicală spitalicească și pe sănătatea publică la scară largă.

Reformele majore din 1989 și, ulterior, cele din 1998 au introdus asigurări sociale de sănătate obligatorii și relați contractuale între furnizor și beneficiarii de servicii. În urma reformelor au apărut societăți private mici care furnizau asistență medicală primară și au obligat Ministerul de Sănătate să înființeze Casa Națională de Asigurări de Sănătate, astfel plățile pentru serviciile medicale au devenit o combinație de capitație, tarife și sistem de plată bazat pe caz.

În prezent, sistemul medical este într-o continuă reformă și reorganizare. Scopul acestei reforme este de a crește și de a diversifica serviciile medicale oferite și de a gestiona aceste informații cu scopul reutilizării lor.

Sistemul medical este eficient dacă medicul reușește să depisteze și să trateze afecțiunile pacientului și să poată reține aceste informații pentru viitoarele posibile consultații fără a fi nevoie de a scrie rapoarte întregi și îndosariate. Acum acest lucru este posibil, folosind tehnologii moderne se pot stoca informațiile relevante pentru consultarea pacientului în format digital pentru refolosirea acestora.

Multe din spitalele și clinicele private din România au început să implementeze aplicații web pentru a promova serviciile de care dispun spitalele lor, dar foarte puține au implementat aplicații web ce oferă servicii de înaltă calitate pentru clienții lor prin intermediul Internetului, cum ar fi programările online și vizualizările de documente. De asemenea multe dintre site-urile acestora nu sunt făcute să fie receptive pentru dispozitivul de pe care se vizualizează. Unele din puținele clinici private care implementează un astfel de sistem ar fi Medlife care permite programarea și aflarea rezultatele analizelor online. Implementarea unei astfel de aplicații consumă mult timp și resurse dar este un pas necesar pentru a intra într-o piață în continuă creștere, care a revoluționat felul în care oamenii interacționează cu companiile furnizoare de servicii.

În contextul de față, proiectul de față își propune să realizeze un sistem de gestiune a consultărilor și facturilor pentru un spital privat, care să fie receptiv pentru orice dispozitiv și să ofere servicii de înaltă calitate pentru pacienți și să folosească servicii REST pentru a crea o aplicație cât mai dinamică și fluidă pentru utilizatori.

Cerințe și specificații

Pentru realizarea unui astfel de aplicații de gestionare a programărilor trebuie luate în considerare cerințele medicilor și a pacienților ce vor folosi aplicația.

Sistemele informatice de gestiune permit controlul unui volum mare de date și prelucrarea acestora într-un timp relativ scurt, de aceea au devenit esențiale pentru o multitudine de domenii de activitate.

Tema acestei licențe reprezintă dezvoltarea unei aplicații web pentru gestionarea consultărilor și facturilor. Trebuie să fie responsive, adică paginile se adaptează în funcție de mediul de vizionare. De asemenea, aplicația va fi SPA, adică aplicație pe o singură pagină pentru a oferi o experiență mai bună pentru utilizatori. Elementele necesare realizării unei astfel de aplicații sunt un back-end pentru prelucrarea datelor, bază de date pentru salvarea datelor primite și un server pentru back-end.

Elementele folosite în aplicație sunt:

Am folosit un web server Tomcat pentru un back-end REST scris în Java;

MySQL, pentru sistemul de gestiune a bazei de date;

HTML5 și AngularJS pentru realizarea aplicației client pe o singură pagină;

Bootstrap și CSS pentru stilizarea elementelor și realizarea de pagini responsive.

Aplicația trebuie să permită vizualizarea primei pagini de către oricine cu acces la internet, unde pot fi găsite informații utile despre spital: secțiile spitalului, echipele medicale, servicii și tarife, date de contact și locația spitalului.

Vizitatorii se pot conecta cu un cont, dacă au. Dacă nu sunt autentificați, să se afișeze în aceeași pagină un mesaj de eroare sugestiv. Altfel, în funcție de nivelul de acces al acestora, să poată efectua diferite operații în aplicație.

Aplicația trebuie să conțină o pagină care să permită pacienților să realizeze o programare la un medic. Pagina va conține o listă a medicilor care vor fi filtrați după nume, specializare sau secție.

Trebuie să existe o pagină unde pacientul poate vedea istoricul său, cu toate consultațiile și internările și să ofere posibilitatea obținerii fișelor de pacient și facturilor generate relative la consultațiile efectuate.

Trebuie să existe o pagină care oferă o modalitate de vizualizare și gestionare a programărilor unui medic, într-un mod interactiv și ușor, ca un calendar. De asemenea, medicul trebuie să aibe posibilitatea să modifice sau să anuleze o programări. Aplicația trebuie să permită medicului să consulte pacientul care are o programare. Pagina de consultație trebuie să conțină informații personale despre pacient, dacă este sau nu internat și serviciile ce le poate efectua pentru acea consultație. Serviciile efectuate vor fi adăugate în mod dinamic pe pagină și se va afișa prețul total al acestora. Formularul se va completa cu un diagnostic, simptome și observații ce vor fi de folos pentru viitoarele consultații. Serviciile vor fi folosite pentru factura clientului. Tot în această pagină, trebuie oferită posibilitatea internării pacientului, să se selecteze ce tip de internare este și să ofere posibilitatea selectării datei de internare. Dacă este o urgență, data internării va fi cea curentă. În urma unei internări se va selecta un pat dintr-una din camerele puse la dispoziție.

Dacă în urma unei consultații, medicul hotărăște să externeze pacientul, atunci trebuie să se specifice tipul externării, starea pacientului la externare și data externării. Dacă starea pacientului este decedat, atunci se va completa consultația cu informații adiționale: cum a decedat, diagnosticul decesului și ora decesului. În urma externării, se va elibera patul ocupat din cameră.

Pentru fiecare consultație sau internare se va deschide o fișă a pacientului pentru tratamentul respectiv. Dacă pacientul nu este internat, fișa va fi relativă numai pentru acea consultație. Dacă este internat atunci toate consultațiile viitoare vor fi asociate cu fișa deschisă în momentul internării, până când pacientul va fi externat. Dacă în urma unei consultații se constată faptul că pacientul nu este internat sau este externat atunci se va genera fișa de pacient cu toate consultațiile efectuate și ce servicii s-au efectuat și factura aferentă consultației sau internării pacientului sub format pdf. Fișa și factura vor respecta ca structură standardele deja existente de către instituțiile medicale. În funcție de ce se decide, fișa și cu factura vor fi salvate pe server sau direct în baza de date pentru a oferi posibilitatea vizualizării acestora la o dată ulterioară.

Medicul trebuie să vadă poată vedea într-o pagină separată istoricul pacienților săi. El va putea vedea doar consultațiile efectuate la secția de care aparține medicul, astfel respectând relația de confidențialitate doctor-pacient.

Pentru administratorul sistemului trebuie să poată accesa o pagină din aplicație unde va gestiona conturile existente și să adauge noi conturi. De asemenea, trebuie să existe o pagină unde poate gestiona toate programările tuturor pacienților.

Analiza și proiectarea aplicației

Analiza aplicației

În contextual actual, datorită evoluției continue a tehnologiilor și a internetului, nu mai există astăzi nici un domeniu de activitate care să nu recurgă la utilizarea calculatoarelor cu acces la internet sau să nu aibe implementate diferite sisteme informatice pentru gestionarea și prelucrarea datelor de un anumit tip.

Un sistem informatic este definit ca o entitate alcătuită din două sau mai multe componente sau subsisteme, interconectate care stabilesc o legătură dinamică, pe baza unor reguli prestabilite, cu scopul atingerii unui obiectiv comun. Pentru a implementa eficient un sistem informatic care să gestioneze un domeniu sau subdomeniu de activitate, trebuie realizate trei etape: analiza noului sistem, proiectarea sistemului și implementarea acestuia.

În această etapă inițială se examinează posibilitatea realizării noului sistem informatic prin răspunderea la întrebarea: Este noul sistem informatic pe care dorim sa îl implementăm viabil din punct de vedere tehnic, economic și operațional? Proiectarea unui sistem de acest gen presupune stabilirea resurselor hardware și software și descrierea arhitecturii sistemului.

Etapa de implementare depinde de proiectarea sistemului care este transpusă în programe și se verifică dacă fiecare program rulează și respectă cerințele stabilite anterior în analiză.

Această aplicație are ca public țintă orice unitate spitalicească ce dorește să ofere clienților și angajaților săi o modalitate mai ușoară de a gestiona programările și informațiile consultațiilor. Ea este realizată folosind resurse open-source, deci costurile pentru licențele de utilizare sunt inexistente. Într-un domeniu în care aplicațiile de acest gen sunt puține și simpliste în funcționalitate, această aplicație este creată să acopere această lipsă din sistemul medical, atât cel de stat cât și cel privat și să ofere servicii de înaltă calitate pentru utilizatori.

Tipul de oameni ce vor folosi acest sistem vor fi:

medici;

pacienți;

administrator.

Acești utilizatori depind unul cu celălalt pentru a rula corect acest sistem. Fiecare utilizator are un număr finit de operații pe care le poate efectua în cadrul acestei aplicații.

Un Pacient poate să:

se conecteze la interfața cu utilizatorul;

se programeze la un doctor pentru o anumită dată;

vadă istoricul său cu documentele asociate fiecărei consultații;

își actualizeze detaliile despre cont;

se deconecteze de pe aplicație.

Un Medic poate să:

se conecteze la interfața cu utilizatorul;

vizualizeze de pe calendar toate programările efectuate și care trebuie efectuate;

selecteze o programare de pe calendar pe care să o poată modifica sau șterge;

vizualizeze istoricul pacientului înainte de a-l consulta;

consulte un pacient prin completarea unui formular cu detaliile consultației;

interneze sau externeze un pacient;

genereze factura și fișa unui pacient dacă pacientul nu este internat sau este externat;

adauge programări în calendar;

își modifice informațiile din profil;

se deconecteze.

Un Administrator poate să:

gestioneze conturile existente;

șteargă sau să pună pe inactiv un cont;

adauge conturi noi;

vadă toate programările medicilor și să modifice data programărilor;

anuleze programările;

editeze datele de profil;

se deconecteze din interfața cu utilizatorul.

Operațiile acestea trebuie să se realizeze în cât mai puține și simple etape pentru a nu intimida utilizatorul să nu folosească aplicația. Toate formularele din aplicație trebuie realizate astfel încât să nu îngreuneze utilizatorul în procesul de completare, ele trebuie trebuie să îndrume utilizatorul prin prezentarea clară și concisă a elementelor din formular.

Etapa de proiectare a sistemului informatic s-a realizat plecând de la abordările tehnico-practice specifice limbajului UML (Limbajul de modelare Unificat). UML-ul reprezintă un limbaj de modelare orientat pe obiecte considerat standard de către dezvoltatorii software și este succesorul celor mai bune trei limbaje de modelare anterioare orientate obiect (Booch, OMT, OOSE), care au fost unificate.

UML a fost conceput cu scopul de a reuni elementele cele mai semnificative ale tuturor metodelor de modelare și analiză cunoscute până în acel moment (anul 1994) și de a furniza un mecanism eficient de dezvoltare a programelor, dar mai ales de a impune o metodă unică de analiză. Această operație de unificare prezintă anumite avantaje și dezavantaje.

Avantaje: eliminarea unor diferențe de concepție și de notație și eliminarea conceptelor ce nu sunt foarte folosite.

Un dezavantaj este introducerea a unui număr de noi concepte care sporesc complexitatea metodei.

Diagramele UML nu sunt realizate pentru dezvoltatori ci și pentru oameni obișnuiți și oricine dorește să înțeleagă sistemul. În următoarele paragrafe se vor prezenta diagrama use case, diagrama de activități și diagrama claselor pentru o mai bună înțelegere a sistemului realizat.

Diagrama Use Case

Diagramele Use Case prezintă interacțiunile utilizatorului cu sistemul într-un mod organizat. Elementele cele mai importante dintr-o diagramă sunt: sistemul – reprezentat printr-un chenar dreptunghiular ce cuprinde componentele interne; actorii – obiect ce poate reprezenta un utilizator sau o organizație și interacționează cu sistemul reprezentat; asocierea – utilizată pentru reprezentarea legăturilor dintre actori și sistem.

În diagrama use case, reprezentată prin figura 3.1., se observă prezența a 3 actori: Cont, Pacient și Medic. Între Cont și ceilalți doi actori există o relație de generalizare deoarece Cont este actorul părinte. Actorii fii vor moșteni toate relațiile părintelui. Astfel toți fii vor trebui să se autentifice cu un user și o parolă pentru a ajunge la interfața online cu utilizatorul.

Actorul Medic reprezintă un angajat al societății, care are rolul de a gestiona programările, consultațiile și internările pacienților, precum și generarea fișelor pacienților și facturilor pentru consultarea sau internarea pacienților. Contul Medic permite vizualizarea istoricul unui pacient pe secția lui, pentru a-l ajuta în consultațiile viitoare pentru pacientul respectiv.

Actorul Pacient reprezintă persoana fizică ce va beneficia de pe urma acestei platforme online, care după obținerea unui cont va putea să se autentifice și să poată să se programeze la un medic de specialitate completând un formular. De asemenea, Clientul își poate vedea istoricul personal în legătură cu toate consultațiile și internările efectuate, precum și facturile achitate.

Figura 3.1. Diagrama Use Case

Scenariile regăsite în sistemul prezentat sunt:

Autentificare – presupune introducerea datelor de autentificare, realizată prin intermediul scenariului Introducere date, care la rândul ei implică verificarea datelor introduse prin scenariul Verificare date. Dacă datele introduse nu sunt valide va înștiința utilizatorul prin afișarea unui mesaj de eroare prin intermediul scenariului Afișare Eroare.

Vizualizare informații generale despre spital – reprezintă scenariul în care orice persoană cu acces la internet poate accesa pagina principală fără a fi nevoie de vreo autentificare din partea persoanei și poate să se informeze despre secții, echipele medicale, servicii și tarife și locația spitalului cu date de contact.

Realizare programare – presupune completarea unui formular, realizat prin intermediul scenariului Completare formular, cu scopul programării unei consultații pentru o anumită persoană la un anumit medic. Dacă datele introduse sunt valide (Verificare date) atunci programarea s-a realizat, altfel se va notifica utilizatorul printr-un mesaj de eroare (Afișare Eroare). Acest scenariu este disponibil atât pentru Client cât și pentru Medic. Diferența o constă în faptul că un pacient se poate programa la orice medic din orice secție dorește, în timp ce medicul poate programa un pacient în funcție de orarul său de lucru.

Vizualizare programări – scenariu în care actorului Medic i se prezintă toate programările pe care le are de efectuat sau pe care le-a efectuat și la ce oră sunt acestea, sub forma unui calendar. De aici Medicul poate modifica ora unei programări, prin intermediul scenariului Modificare Programare, sau poate să anuleze o programare, prin scenariul Anulare Programare. Acest scenariu este necesar pentru accesarea scenariului Realizare Consultație, pentru a putea verifica un pacient.

Realizare Consultație – reprezintă scenariul în care medicul realizează consultația pacientului și completează un formular cu detaliile consultației efectuate asupra pacientului spre a fi salvate în baza de date (Completare formular). După completarea formularului se validează datele introduse (Validare date) și dacă nu sunt valide se va afișa un mesaj de eroare adecvat pentru acea situație (Afișare eroare). În urma diagnosticului dat de Medic se poate hotărî internarea pacientului pe o perioadă de timp (reprezentat de scenariul Internare pacient), astfel se vor programa alte consultații viitoare, revenind la scenariul Realizare Programare până când pacientul este externat (Externare pacient). Dacă Pacientul nu este internat sau este externat atunci se generează o fișă a pacientului și o factură, reprezentate de scenariul Generare Fișă Pacient, respectiv Generare Factură, pe baza serviciilor oferite și costurile aferente acestora, care sunt stocate în baza de date pentru vizualizări viitoare.

Vizualizare istoric pacienți – presupune aducerea tuturor consultațiilor și internărilor pacienților care s-au consultat la secția de care aparține Medicul. Aici se pot observa toate fișele și facturile generate pentru fiecare consultație și factură.

Vizualizare istoric personal – este asemănător cu scenariul Vizualizare istoric pacienți, singura diferență este că Pacientul își poate vedea numai consultațiile și internările sale, precum și documentele aferente acestora.

Diagrama de activități

Diagrama de activități reprezintă o modalitate de modelare vizuală a aspectelor dinamice ale sistemului. Diagrama de activități este o diagramă ce prezintă fluxurile(tranzițiile) de la o activitate la altă activitate. Activitatea este o operațiune a sistemului. Cu ajutorul diagramelor de activități pot fi modelate foarte bine use case-urile, dar, în aceeași măsură, aceste diagrame pot fi folosite pentru modelarea proceselor de business (fără legătură cu sistemul informatic).

Elementele esențiale pentru reprezentarea unei astfel de diagrame sunt:

Activitatea – reprezintă fluxul de lucru reprezentat de diagramă;

Nod inițial – punctul de pornire a diagramei, este prima acțiune din diagrama de activitate;

Acțiune – un pas din activitate, în care utilizatorii sau sistemul efectuează niște operații;

Tranziții – treceri de la o activitate la altă activitate, se referă la evenimentele care completează desfășurarea acțiunii din activitatea pe care o părăsește;

Decizii – tranziții condiționale reprezentate printr-un romb. Are o intrare și două sau mai multe ieșiri;

Reuniuni – necesare pentru îmbinarea fluxurilor care au fost împărțite de un nod de decizie. Are două sau mai multe intrări și o singură ieșire;

Nod final – sfârșitul activității efectuate, când fluxul ajunge în acest punct activitatea s-a terminat;

Partiționare – compartimentează activitățile și împarte responsabilitatea acestora.

În continuare se va prezenta diagrama de activități aferentă realizării programărilor și consultațiilor unui pacient, din perspectiva medicului și a pacientului.

Figura 3.2. Diagrama de activități

Din nodul inițial Start se trece în tranziția accesare pagină principală într-un nod de decizie unde vizitatorul hotărăște dacă se va loga la interfața cu utilizatorul sau va rămâne în pagina principală unde poate să descopere informații generale despre spital (secții, servicii și costuri, echipe medicale). Dacă nu se autentifică niciodată atunci se încheie activitatea prin tranziția Ieșire și ajunge la nodul final Ieșire sistem. Dacă dorește să se conecteze va trebui să își introducă numele de utilizator și parola, care apoi sunt validate prin tranziția Validare date. Dacă datele introduse sunt invalide, prin intermediul nodului de decizie Date corecte?, va rămâne în formularul de logare și se va afișa un mesaj de eroare cu cauza erorii. Dacă datele sunt valide, se va trece la activitatea Afișare pagină utilizator.

Următoarele activități sunt partiționate în două coloane. În prima coloană atât utilizatorul cu nivel de acces pacient cât și cel cu nivel de acces medic pot efectua acele activități, iar în a doua coloană numai utilizatorul cu nivelul de acces medic poate efectua acele activități.

Accesând din meniul de operații link-ul Programare, se trece la activitatea Programare pacient. Prin tranziția Validare date se verifică dacă datele introduse sunt corecte, ajungându-se într-un bloc de decizie. Dacă datele sunt incorecte, prin tranziția Nu. Afișare eroare se revine la activitatea precedentă și va înștiința utilizatorul prin afișarea unei erori. Altfel se va duce pe cealaltă tranziție disponibilă unde se inserează în baza de date. Medicul va vedea noua programare înregistrată prin selectarea din meniul de operații link-ul Calendar reprezentat de activitatea Calendar Programări.

Medicul trebuie să decidă ce operație va efectua asupra programării printr-un nod de decizie. Tranziția selectare opțiune istoric duce spre activitatea Vizualizare istoric pacient unde medicul poate vedea consultările precedente ale pacientului. Această activitate este accesibilă și pacientului, unde își poate vizualiza numai consultările efectuate de acesta.

Dacă medicul hotărăște să modifice sau să anuleze programarea, atunci prin tranziția anulare sau modificare programare se revine la activitatea precedentă și va reflecta modificările făcute. Prin apăsarea butonului Consultare se trece la activitatea Completare formular consultație. Din această activitate, prin intermediul unui nod de decizie, se verifică dacă pacientul este sau nu internat. Dacă nu este atunci se trece la următorul nod de decizie unde se verifică dacă este necesară internare pacientului. Internarea unui pacient presupune selectarea unei camere unde va sta pe toată durata internării, care este reprezentată de activitatea Selectare cameră internare. Dacă nu se internează pacientul atunci se va face tranziția către activitatea Generare fișă pacient și factură, unde i se vor prezenta documentele aferente consultației. Dacă pacientul este internat deja se trece la nodul de decizie Externare pacient? unde se determină dacă se externează pacientul sau rămâne internat. Dacă nu se externează pacientul atunci se salvează consultația dar nu se duce în activitatea Generare fișă pacient și factură și medicul va trebui să revină la activitatea Programare pentru programarea următoarei consultații până se externează pacientul. La externarea unui pacient se ajunge la activitatea Generare fișă pacient și factură.

După aceste activități se verifică validitatea datelor introduse în formular. Dacă nu sunt valide se duce în activitatea Completare formular consultație și se înștiințează utilizatorul prin afișarea unei erori, altfel se ajunge în activitatea Inserare în baza de date. Se ajunge la nodul final Ieșire sistem prin tranzacția Ieșire. Astfel se încheie activitatea realizării programărilor și consultațiilor.

Diagrama claselor

Diagrama de clasă oferă o imagine de ansamblu a sistemului proiectat prin descrierea obiectelor și claselor din interiorul sistemului și relațiile dintre acestea. Scopul acestui tip de diagramă este aceea de a fi utilizată pentru descrierea structurii statice. Acest tip de diagramă este utilizat cel mai adesea de către dezvoltatori pentru specificarea claselor.

Elementele de bază regăsite în diagramele de clase sunt:

clasele – descriu un set de obiecte care au aceleași caracteristici structurale, constrângeri și semantică. Atributele unei clase sunt deținute de clasă.

asocierile (legăturile) – reprezintă relațiile dintre clasele diagramei. Au cel puțin două capete reprezentate de tipul conectat la capăt. Mai mult de un capăt poate avea același tip.

Figura 3.3. reprezintă diagrama claselor aferentă sistemului de gestiune a consultărilor și a facturilor.

Figura 3.3. Diagrama claselor

Actorul Cont se regăsește în diagrama claselor sub forma clasei Cont. Fiecare cont este identificat unic prin atributul id. Fiecare cont are câte un atribut rol obținut prin asocierea compozită între clasa Cont și clasa Roluri. Un cont are un atribut status ACTIV sau INACTIV pentru valabilitatea utilizatorului. Statusul este regăsit prin asocierea compozită dintre Cont și clasa UserStatus ce conține o listă de enumerare. Un cont își poate modifica parola curentă cu orice dorește cât timp respectă condițiile de validare din metoda schimbareParolă. Un Cont se autentifică prin intermediul atributelor user și parolă folosind metoda autentificare și dacă statusul contului este ACTIV atunci s-a autentificat utilizatorul cu succes. Relația de generalizare între clasa Cont și clasele Angajat și Pacient face diferențierea dintre tipurile de utilizatori conectați.

Clasa Angajat reține angajații societății, care sunt identificați unic prin atributul idangajat. Alte atribute din clasă sunt nume și prenume pentru fiecare angajat, atributele email și telefon sunt folosite pentru a putea lua legătura cu persoanele respective. De asemenea, un Angajat are un interval orar de lucru de cinci zile pe săptămână și aparține unei secții prin intermediul asociației dintre clasa Angajat și clasele Orar și Secție. Din clasa Angajat numai medicii sunt specializați pe o anumite arii. Acestea sunt obținute prin clasa asociativă Specializat dintre clasa Angajat și Specializare, care are ca atribute idspecializare și idmedic unde se reține ce specializări are orice medic. Din multiplicitatea asociației reiese că aceleași specializări pot fi la mai mulți doctori, iar un doctor poate să aibe mai multe specializări.

Clasa Orar are atributele luni, marți, miercuri, joi ,vineri, sâmbătă și duminică. Fiecare atribut are intervalul orar de lucru pe ziua respectivă al fiecărui angajat. Un angajat lucrează cinci zile pe săptămână. Sunt șase tipuri de orar disponibile pentru un angajat: de luni până vineri dimineața, după amiaza sau seara și de miercuri până duminică dimineața, după amiaza și seara. Numai unul din aceste orare poate fi atribuit unui angajat.

Clasa Secție este o clasă ce arată locația unde angajatul își practică meseria. Datorită relației de multiplicitate se înțelege că un angajat este atribuit la o secție și o secție poate să aibe mai mulți angajați atribuiți.

Fiecare specializare presupune niște servicii specifice acelei specializări fiecare având un cost pentru efectuarea acelui serviciu. Clasa Servicii se ocupă de acest lucru. Ea are atributele idservicii (identificator unic), denumire și cost.

Clasa Pacient reprezintă actorul Pacient, deci reprezintă toți clienții care folosesc serviciile oferite de aplicația web. Are un identificator unic numit idpacient. Alte atribute sunt nume, prenume, telefon, email, asemănătoare cu cele ale clasei Angajat, plus grupa_sanguină, rh și dată_naștere reprezentând informații utile când pacientul este consultat de către medic. Între clasa Pacient și clasa Fișă_Pacient există o asociere compozită. Din multiplicitatea asocierii reiese că o singură fișă are un singur pacient, în timp ce un pacient poate avea una sau mai multe fișe. Clasa Fișă_Pacient are un atribut unic idfișă și alte atribute cum ar fi nrfișă, dată_inserare, dată_eliberare și outputpdf. Clasa este folosită pentru reținerea fișei generate pentru pacient în urma unei consultații cu medicul sau externări ale pacientului. Atributul outputpdf reprezintă documentul aferent fișei salvat sub formă binară pentru a nu mai fi necesară generarea documentului de fiecare dată când se dorește vizualizarea acestuia, astfel se cere doar atributul pdfoutput și pe partea de client este transformat într-un document pdf care este afișat clientului sau medicului. Clasa Pacient mai are o asociere cu clasa Internare, care are atributele: identificatorul unic idinternare, dată_internare, tip_internare, criteriu_internare, dată_externare, tip_externare, stare_externare, deces, dată_deces, diagnostic deces. Această asociere presupune că un pacient poate să nu fi fost internat niciodată sau să fi fost de mai multe ori internat în urma controalelor medicale.

Clasa Internare este afectată doar dacă clasa Angajat, mai specific medicul, hotărăște să interneze un pacient sau să-l externeze, folosind metodele internare și externare. Când se internează un pacient se inserează o nouă internare cu data internării, tipul și criteriul de internare. De asemenea se selectează o cameră unde pacientul va sta pe parcursul internării. Clasa Camere gestionează camerele disponibile cu numărul de paturi ocupate și neocupate. Atributele ei sunt identificatorul unic idcameră, număr_paturi care le are la dispoziție sala, paturi_ocupate, etaj și denumirea sălii. Camerele pot fi ocupate de mai mulți pacienți în urma internării lor. Când se ocupă un pat dintr-o cameră atributul paturi_ocupate crește cu unul și dacă paturi_ocupate coincide cu număr_paturi atunci acea cameră nu va mai putea fi folosită până nu se mai externează un pacient și se va căuta o cameră cu un pat liber.

Externarea unui pacient presupune modificarea internării inserate atribuindu-i o dată de externare, tipul și starea externării pacientului. Dacă din nefericire se constată decesul pacientului atunci se completează și cu data decesului și diagnosticul decesului. Se eliberează și patul ocupat din clasa Camere.

Între clasa Camere și clasa Secție există asociația aparține, cărei multiplicitate arată faptul că o secție are mai multe camere în clădire, iar o cameră aparține unei singure secții.

Clasa Programare este clasa cu atributele: identificatorul unic cu numele idprogramare, data_ început și dată_sfârșit unde se salvează data și ora la care pacientul trebuie să vină pentru consultarea sa și durata estimativă a vizitei sale pe baza programării făcute ori de pacient ori de medicul asociat acelei programări. Durata standard a unei programări făcute de pacient este o oră pentru a oferi destul timp pentru consultarea respectivei persoane.

Din asociația multiplă dintre clasele Angajat, Pacient și Programare reiese clasa Consultație, cu identificatorul unic idconsultație și atributele simptome, diagnostic și internare, folosită pentru stocarea informațiilor relevante consultării pacientului pe parcursul programării. Este utilizată în principal pentru vizualizarea istoricului pacientului împreună cu clasa Fișă_Pacient pentru a ajuta medicul în viitoarele sale consultări și în depistarea cu ușurință a diagnosticului corect.

O consultație presupune că s-au efectuat anumite servicii pentru tratamentul pacientului. Între clasa Servicii și clasa Consultație există o clasă asociativă ServiciiEfectuate care ține cont de ce servicii au fost efectuate și câte au fost pentru o anumită consultație. Multiplicitatea dintre ele arată că o consultație implică una sau mai multe servicii, iar serviciile se pot regăsi de mai multe ori în aceeași consultație sau în alte consultații.

În urma unei consultații, dacă pacientul nu este internat sau este externat, se inserează o factură pentru achitarea costurilor serviciilor efectuate. Clasa Consultație are o asociație cu clasa Factură care are atributele identificatorul unic idfactură , nrfactură, total_factură, data_emisă și outputpdf. Clasa este folosită pentru reținerea facturii, iar în atributul ouputpdf se salvează documentul generat în formă binară.

Angajatul își poate modifica anumite date personale, cum ar fi atributele email și telefon prin folosirea metodei modificareProfil. Metoda vizualizareIstoric oferă posibilitatea medicului să vadă consultațiile precedente ale pacienților pentru a se informa de trecutul lor medical. Medicul își poate modifica programările sale sau să le anuleze prin apelarea metodei modificareProgramare și respectiv anulareProgramare. Un medic poate să apeleze metoda consultare dacă un pacient sau medicul a făcut o programare, salvează informațiile despre simptome, observații și diagnosticul pacientului în clasa Consultare. În timpul unei consultații se verifică dacă pacientul este internat sau nu în spital. Dacă nu este internat și dorește să-l interneze se folosește metoda internare. Altfel, dacă este internat și pacientul urmează a fi externat se va folosi metoda externare.

Metodele generareFișă și generareFactură ale clasei Angajat sunt apelate doar dacă în urma unei consultații pacientul nu este internat sau este externat. Aceste metode generează pdf-urile relevante consultației/internării pacientului sub formă binară și se transformă în documente pdf pentru a putea fi văzute de către utilizator. Acestea sunt salvate în atributele outputpdf în clasa Fișă_Pacient și respectiv Factură pentru vizualizări ulterioare.

Proiectarea Bazei de date

Proiectarea corectă a structurii unei baze de date relaționale este o etapă importantă în scrierea oricărei aplicații. Structura trebuie să fie cât mai bine realizată pentru a preveni apariția de anomalii când se folosește baza de date.

Aceste anomalii ce pot apărea sunt: anomalii de actualizare (modificară aparițiile unei date, dar în unele situații va rămâne valoarea veche), anomalii de inserare (neputința inserării unor informații deoarece depind de existența unei alte informații din alte tabele) și anomalii de ștergere (la ștergerea unei linii dintr-o tabelă se va șterge și datele din alte tabele care aveau legătură cu aceea).

De aceea pentru a ne feri de aceste situații este necesară folosirea unui model de date pentru reprezentarea datelor, pentru a înțelege mai bine care este scopul și obiectivele pentru baza de date relațională. Un model de date descrie schema bazei de date, entitățile ei și legăturile dintre acestea, cheile primare și străine.

În continuare se vor prezenta modelul conceptual și modelul logic al datelor ce au ajutat la realizarea bazei de date.

Modelul conceptual al bazei de date

Modelul conceptual al datelor reprezintă baza de date sub formă de entitate-asociere.

Entitatea reprezintă un obiect unic cu caracteristici distincte. Asocierea reprezintă legătura dintre două sau mai mult entități.

Din Figura 3.4. se pot deduce următoarele entități:

Cont – care va reprezenta conturile atât pacienților cât și al doctorilor;

Roluri – vor reprezenta rolurile fiecărui cont;

Angajat – vor fi salvate datele angajaților;

Pacient – vor fi salvate datele pacienților;

Orar – va reprezenta programul de lucru al angajaților;

Secție – clădirea unde vor lucra medicii;

Specializare – ce fel de calificări are un doctor;

Servicii – ce operații contra-cost se pot efectua pe un pacient;

Fișă_Pacient – fișa medicală a unui pacient pe un anumit diagnostic;

Internare – va reprezenta perioada când un pacient a fost sau este internat;

Camere – locul unde va fi internat pacientul;

Programare – momentul când va avea loc consultația;

Consultație – controlul medical al pacientului și momentul când va fi diagnosticat;

Factură – plata totală pentru serviciile efectuate în consultații;

Asocierile și cardinalitatea dintre entități sunt:

Un cont ARE un rol, iar un rol este la mai multe conturi;

Un cont ARE ori un pacient ori un angajat, un angajat ARE un cont, iar un pacient ARE sau nu un cont;

Un pacient ARE unu sau mai multe fișe, unu sau mai multe fișe aparțin unui singur pacient;

Un pacient ARE sau nu o internare, o internare sau mai multe au un singur pacient;

Un orar ARE mai mulți angajați, unu sau mai mulți angajați au același orar;

Un angajat este Specializat în mai multe specializări, mai multe specializări sunt atribuite la mai mulți medici;

specializare CONȚINE mai multe servicii, unu sau mai multe servicii sunt atribuite unei specializare;

Un angajat APARȚINE unei secții, o secție are mai mulți angajați în ea;

O secție i se ATRIBUIE unul sau mai multe camere, unu sau mai multe camere sunt atribuite unei secții;

O cameră CONȚINE unu sau mai multe internări de pacienți, unu sau mai mulți pacienți internați sunt atribuiți unei camera;

O consultație are unu sau mai multe ServiciiFolosite, mai multe servicii sunt folosite în unul sau mai multe consultații;

O consultație sau mai multe au atribuite costuri_factură relative la o factură, o factură sau mai multe au costuri_factură pentru unu sau mai multe consultații;

Un pacient FACE unu sau mai multe programări, unu sau mai multe programări au un pacient;

Un angajat, mai precis un doctor ARE unu sau mai multe programări, unu sau mai multe programări au un doctor;

O consultație ARE o programare, o programare are o consultație.

Figura 2.4. Modelul conceptual al datelor

Modelul logic al datelor

Modelul logic al datelor depinde de modelul conceptual. Entitățile devin tabele cu atribute și restricții, cum ar fi cheile primare. Asocierile de mai mult la mai mult au devenit și ele tabele cu atribute proprii, cum ar fi: ServiciiFolosite, Specializat și costuri_factură. Anumite atribute ale tabelelor au migrat ca chei străine către alte tabele datorită asociației lor.

Cheia primară la Roluri s-a dus ca cheia străină la Cont datorită cardinalității care spune că orice legătură 1:1..N, cheia primară a primului cap de legătură migrează către cea de-a doua. La fel se întâmplă și pentru legăturile dintre Pacient-Fișă_Pacient, Orar-Angajat, Camere- Internare, Secție-Camere, Secție-Angajat, Specializare-Servicii, Angajat-Programare, Pacient-Programare. În asocierile Angajat-Cont, Pacient-Cont și Programare-Consultație cheia primară a primei tabele a migrat în cea de-a doua.

Asocierea binară Specializat reprezintă relația dintre Angajat și Specializare, deci are loc o dublă migrație a cheilor primare ca chei străine în tabela Specializat. Același proces se face și pentru costuri_factură și ServiciiFolosite.

Tabelele obținute sunt:

Roluri[id, rolename]

Cont[id, idrol, idangajat, idpacient, user, parolă, lastlogin, status]

Angajat[idangajat, idsecție, idorar, nume, prenume, adresă, telefon, sex, cnp, serie, număr, email, data_naștere]

Orar[idorar, luni, marți, miercuri, joi, vineri, sâmbătă, duminică]

Sectie[idsecție, denumire, descriere]

Specializat[idspecializare, idangajat]

Specializare[idspecializare, denumire, categorie]

Servicii[idservicii, idspecializare, denumire, cost]

ServiciiFolosite[idservicii,idconsultație]

Consultatie[idconsultație,idprogramare,internare,simptome,diagnostic,observatii]

Costuri_Factură[idconsultație, idfactură]

Factura[idfactură,total_factură, data_emisă, outputpdf]

Programare[idprogramare, idangajat, idpacient, titlu, data_început, data_sfârșit, tip, motiv, modificabil, aranjabil]

Pacient[idpacient, nume, prenume, adresa, telefon, sex, cnp, serie, număr, email, data_naștere, grupă_sanguină, rh, cetățenie, ocupație, loc_muncă]

Fișă_Pacient[idfișă, idpacient, nr_fișă, data_inserare, data_eliberare, tratat, medic, outputpdf]

Internare[idinternare, idcameră, data_internare, tip_internare, criteriu_externare, data_externare,stare_externare,tip_externare,deces, data_deces, diagnostic_deces]

Camere[idcameră, idsecție, număr_paturi, paturi_ocupate, etaj, denumire]

Figura 3.5. Modelul logic al datelor

Modelul fizic al datelor

Modelul fizic reprezintă ultima etapă în realizarea bazei de date. Este o machetă a bazei de date relaționale. În ea se regăsește cum trebuie ca datele să fie structurate și legate într-un sistem de gestiune a bazelor de date. Asta înseamnă că trebuie specificat tipul atributelor și dimensiunea lor și să se verifice dacă numele tabelelor și coloanelor nu sunt cuvinte-cheie din sistem.

Figura 3.6. Modelul fizic al datelor

Proiectarea interfeței

O componentă software-hardware care permite unei persoane să interacționeze cu un sistem informatic are denumirea de interfață. Ea permite utilizatorului să execute anumite acțiuni în funcție de logica sistemului, fiind totodată și mijlocul prin care utilizatorul este înștiințat de rezultatele acțiunilor sale.

O interfață este construită în jurul utilizatorilor ce vor interacționa cu ea și de cerințele acestora. Utilizatorii se uită nu numai la informații ci și la conținutul prezentat în interfață. În vederea proiectării unei interfețe se ține cont de: conținutul prezentat, poziția elementelor din interfață, fonturile elementelor, graficele prezente pentru o orientare mai ușoară, etc.

Succesul unei interfețe depinde de elementul “look and feel” al interfeței. Modul de prezentare vizuală a interfeței deseori determină succesul sau eșecul unei interfețe. Această sintagmă “look and feel” face referire la următoarele principii:

Perioada de adaptare la interfață a utilizatorilor trebuie să fie cât mai mică. Utilizatorii trebuie să fie capabili să navigheze prin interfață și să folosească comenzile sale fără a fi nevoiți să aibe un manual de utilizare pentru navigarea sa, acest lucru este important mai ales pentru utilizatorii care accesează rar interfața.

Interfața trebuie să fie clară și concisă.

Interfața trebuie să fie vizual plăcut pentru utilizator. Trebuie să ofere o senzație de familiaritate, confort pentru a atrage utilizatorul să folosească interfața.

Interfața trebuie să fie ușor de utilizat, adică operațiile disponibile utilizatorului trebuie să se realizeze într-un număr minim de acțiuni din partea utilizatorului.

Durata de execuție a comenzilor primite de la utilizator trebuie să fie cât mai mică posibil. Aplicația trebuie să confirme vizual că s-a preluat cererea utilizatorului. În cazul unor operații care durează un interval de timp, trebuie să i se prezinte utilizatorului starea cererii sale;

Interfața trebuie să gestioneze erorile umane. În realizarea oricărei interfețe trebuie să se presupună că utilizatorul face multe greșeli fizice (apăsarea neintenționată pe o operație) și de judecată, logică (efectuarea unei operații de ștergere a unei informații cruciale care nu trebuia ștearsă). O bună interfață trebuie să prevadă aceste cazuri de eroare prin atenționarea utilizatorului când e pe punctul de a efectua o operație importantă de modificare a datelor și prin recuperarea datelor alterate.

Interfața trebuie să fie responsive, adică să poată fi adaptată la diferite echipamente hardware (monitoare cu rezoluții diferite, smartphone, iphone, etc.).

Organizarea coerentă și clară a informației afișate pe ecran și prezentarea anumitor informații într-un anumit context.

Proiectarea unei interfețe este un element cheie în funcționalitatea unui sistem informatic. Interfața permite utilizatorului să acceseze componentele interne ale sistemului într-o manieră relativ simplă și fără a cunoaște cum sunt integrate aceste componente. Cu cât se asigură un acces mai ușor utilizatorului, cu atât interfața este considerată mai bună. Sistemul informatic este adesea evaluat pe baza interfeței cu utilizatorul.

În proiectarea unei interfeței cu utilizatorul trebuie să se țină cont de următoarele principii:

Principiul utilității care face referință la ușurința navigării, căutării și gestionarea informațiilor prezentate în interfața web.

Principiul vizibilității presupune aranjarea într-un singur loc a tuturor elementelor ce îndeplinesc un anumit scop pentru o mai ușoară accesibilitate pentru utilizator (estetica paginii).

Principiul funcționalității se referă la funcționarea corectă a tuturor comenzilor din pagină când utilizatorul solicită operația respectivă.

Principiul simplicității este principiul ce asigură o execuție cât mai grabnică a funcțiilor oferite utilizatorului de aplicație.

Principiul feedback-ului face referire la faptul că orice acțiune, interpretare, modificare de stare, eroare sau excepție care sunt relevante pentru utilizator trebuie să informeze utilizatorul într-un mod concis și clar.

Principiul toleranței este relativă la faptul că o interfață trebuie să reducă sau să prevină costul greșelilor și a utilizărilor necorespunzătoare făcute de utilizator prin furnizarea de mijloace recuperare a datelor alterate.

Principiul reutilizării sugerează ca interfața să refolosească elemente deja existente în aplicație într-un context diferit de cel în care sunt folosite pentru a da senzația de familiaritate față de utilizator.

Interfața folosită pentru sistemul de gestiune pe care dorim să-l realizăm este bazată pe web (web user interfaces – WUI). Acest tip de interfață conține drept componentă pagini web care sunt accesate pe Internet și vizualizate într-un browser web.

În realizarea unei interfețe web se practică următorii pași: planificarea, proiectarea interfeței, selectarea culorilor folosite pentru aspectul paginii, popularea cu informații reale și implementarea interfeței.

În etapa de planificare trebuie stabilite funcționalitățile pe care utilizatorul are acces și le poate efectua, structura site-ului, ce informații se vor prezenta pe pagini, tehnologiile folosite pentru implementarea părții client a aplicației. Pentru realizarea paginilor web ale aplicației s-a folosit HTML (Hyper Text Markup Language) pentru conținutul static din pagini, CSS (Cascading Style Sheets) și Bootstrap pentru pentru a oferi un aspect mai atractiv utilizatorilor și de adaptare a paginilor în funcție de dispozitivul folosit pentru vizualizare, AngularJS care este un JavaScript Framework și extinde HTML cu directive proprii pentru a prezenta conținut dinamic utilizatorului și Ajax pentru a asigura control în timp real asupra datelor și de a modifica asincron paginile web în comunicarea sa cu serverul scăpând astfel de nevoia să se dea “refresh” la pagina de browser.

Pentru determinarea structurii paginilor web vom folosi wireframes. Un wireframe, cunoscut ca schematică sau model al unei pagini web, este un ghid vizual care prezintă scheletul unui website. Wireframe-urile ilustrează ce anume se dorește să apară în paginile site-ului, să se împartă în mod eficient spațiul pentru fiecare tip de informație și să se precizeze elementele esențiale din pagină. Wireframe-urile sunt variante simplificate ale produsul final, fără să se pună elemente de stilizare pe acestea. Schematicile sunt foarte utile pentru dezvoltatori pentru a obține o imagine clară a ceea ce vor trebui să implementeze în paginile web. De asemenea sunt utile și pentru comunicare cu clientul în legătură cu ceea ce se va realiza. Scopul principal este de a arăta clientului cum va fi structurat site-ul înainte de a trece la partea de dezvoltare. În această perioadă, clientul poate face observații și modificări asupra elementelor reprezentate pe schiță, astfel nu se vor cere modificări de proiectare în timpul implementării interfeței care durează mult timp de identificat unde trebuie modificat. Astfel wireframes ajută la economisirea de timp și resurse pentru realizarea de aplicații web.

Elementele din schematică sunt afișate și organizate pe baza următoarelor criterii:

Conținut – ce elemente sunt necesare pentru a realiza schița interfeței;

Structură – se pune problema cum se așează elemente în pagină, cum vor fi grupate.

Ierarhie – se hotărăște poziția etichetarea și dimensiunea fiecărui element;

Funcționalitatea – se va decide cum vor interacționa elementele unele cu altele;

Comportament – se prezintă cum vor interacționa elementele din schiță cu utilizatorul.

Schematicile au mai multe niveluri de detalii și pot fi împărțite în două categorii, în termeni de fidelitate (cât de mult seamănă cu produsul final):

Fidelitate redusă – sunt schițe abstracte care au detalii foarte puține și sunt ușor de reprodus.

Fidelitate înaltă – sunt folosite pentru documentație pentru că au un nivel de detalii foarte apropiat de produsul final, dar durează mai mult timp să fie realizate.

Următoarele figuri reprezintă schematicile de fidelitate înaltă a paginilor principale a site-ului: pagina principală, pagina de logare, pagina unde se regăsește calendarul medicului și paginile formularului de programare a unui pacient.

Figura 4.1. Schematica paginii principale

Figura 4.1. reprezintă schematica paginii principale pe care vizitatorii o accesează. În partea superioară a schiței, adică capul paginii, se regăsește un meniu orizontal ce conține în interiorul său legături către alte pagini: Logo, Acasă, Secții, Specializări, Farmacie, Contact și Logare. Ele sunt puse în acea poziție pentru o mai ușoară accesare a acestora, datorită faptului că meniul va putea fi vizualizat în continuare chiar dacă vizitatorul derulează în jos. Legăturile Logo și Acasă amândouă duc către pagina principală. Legătura Secții va aduce pagina cu informații despre secțiile spitalului. Specializări va arăta vizitatorului o pagina care va conține toate specializările cu serviciile sale și costurile aferente acestora. Farmacie arată informații despre locația farmaciilor de unde se pot cumpăra medicamente. Legătura Contact arată un Google Map cu locația spitalului plus informații de contact: număr de telefon, fax, email. Logare este o legătură ce duce la Figura 4.2., care este pagina de logare.

Următorul element este un carusel unde se vor prezenta o galerie rulantă de imagini sugestive, relevante spitalului. Sub acesta sunt prezente șase imagini sugestive care sunt legături către alte pagini. Sub este o zonă de text unde se vor scrie câteva cuvinte despre societate și obiectivele sale. Cercurile reprezintă niște bare de progres rotunjite unde se arată statistici relevante. Primul cerc arată numărul de medici angajați, al doilea arată numărul de pacienți care folosesc serviciile spitalului și al treilea prezintă numărul de servicii puse la dispoziția pacienților care se pot regăsi apăsând pe legătura Specializări.

Zona următoare prezintă noutățile postate de către administratorul site-ului, se prezintă o imagine sugestivă și un scurt paragraf din articolul respectiv. Se poate apăsa pe imagine pentru a fi dus către articolul complet.

În subsolul paginii se găsesc 3 legături către diferite medii de comunicare, cum ar fi Facebook, Twitter sau Linkedin.

Apăsând pe legătura Logare vom trece la următoarea schematică și anume schematica paginii de logare unde clientul se va autentifica ca să poată accesa interfața cu utilizatorul.

Figura 4.2. Schematica paginii de logare

În pagina de logare avem prezente două câmpuri de tip text așezate unul sub altul, una este pentru introducerea numelui de cont și una pentru parolă, cu scopul autentificării utilizatorului ca să acceseze interfața cu utilizatorul. Avem de asemenea două butoane în subsolul câmpurilor una lângă alta. Toate aceste elemente sunt încadrate într-un container generic. Primul buton Pagină principală va întoarce utilizatorul în pagina precedentă. Al doilea buton Logare va declanșa execuția verificării datelor introduse în cele două câmpuri de către server. Dacă nu sunt valide se va afișa un mesaj de eroare deasupra câmpului unde se trece numele de cont. Dacă sunt datele valide atunci utilizatorul se conectează și este redirecționat către pagina unde utilizatorul poate efectua diferite operații asupra informațiilor prezentate în pagină.

Figura 4.3. Schematica interfaței cu utilizatorul

Figura 4.3. descrie pagina care oferă posibilitatea utilizatorului să efectueze operații în funcție de rolul contului său. Această schiță este pentru un cont cu rolul de Medic. În capul paginii se află o bară de meniu unde se regăsește în partea dreaptă logo-ul societății. În cealaltă parte se află un buton care permite utilizatorului să ascundă/arată bara de meniu lateral. Acest lucru este implementat pentru ecranele de dimensiuni mici pentru a oferi mai mult spațiu pentru efectuarea operațiilor din conținutul paginii.

În partea stângă se regăsește meniul lateral cu diferite legături către diferite operații. Întâi se vede Nume cont unde va apărea numele unic atribuit contului cu o imagine sugestivă în partea dreaptă. Pagina principală duce la pagina pagina principală a interfeței cu utilizatorul unde se găsesc niște informații relevante pentru cont (ca exemplu ultima dată de logare). Operații este de fapt o listă ordonată care se extinde dacă se apasă și va apărea operațiile relevante contului autentificat. Pentru această diagramă operația se numește Calendar. Legătura Setări va duce utilizatorul în pagina unde se vor prezenta informațiile senzitive pentru utilizator, cum ar fi contul, parola, adresa de email, etc., pe care unele dintre ele pot fi modificate. Ultima legătură numită Delogare va deconecta utilizatorul din interfață și va fi dus înapoi la pagina de logare (Figura 3.2.).

Următoarele figuri vor prezenta schița formularului de programare a unui utilizator care are rolul de pacient.

Figura 4.4. Schematica formularului de programare

În figura 4.4. se observă că atât capul paginii și cât și meniul lateral este același cu Figura 4.3., singura diferență este formular prezent în pagină. Acest formular este încadrat într-un container și este format din două părți: prima parte este titlul sugestiv din vârful containerului și sub el se găsesc legăturile unde se arată pasul la care utilizatorul este momentan, a doua parte, în restul containerului, se regăsesc elementele care interacționează cu utilizatorul. Pasul curent al acestei operații este cel de Date personale. În acest pas se găsesc unele sub altele etichetele și câmpurile corespunzătoare fiecăreia. Sub eticheta Nume se scrie numele utilizatorului în câmp, sub Prenume se scrie prenumele, iar în ultimul câmp se introduce adresa de email. Butonul Pasul următor va fi dezactivat până când câmpurile sunt completate și sunt valide. Dacă sunt se va trece la următorul pas Data.

Figura 4.5. Schematica formularului de programare pasul 2

Formularul din pagină s-a schimbat. Acum se află noi elemente așezate tot unele sub altele. Sub eticheta Medic se găsește o listă dropdown unde se găsesc toți medicii, grupați după secția la care aparțin. Se va căuta medicul la care dorește pacientul să se programeze prin filtrarea după nume, secție sau specializare. Apoi sub eticheta Ora programare pacientul va selecta data și ora programării cu medicul. Aici se poate selecta ora dintr-un calendar. Următorul pas va fi de completat o zonă de text cu o scurtă descriere a simptomelor de care suferă pacientul, localizat chiar sub eticheta Motiv. În subsolul formularului sunt două butoane: Pasul precedent, care duce înapoi la elementele din Figura 4.4. în caz că se dorește modificarea vreuneia dintre valori, și butonul Pasul următor, care duce la pasul următor din formular și anume Confirmare.

Figura 4.6. Schematica formularului de programare pasul 3

Ultima etapă presupune revizuirea criteriilor scrise sau selectate din celelalte două etape. Se prezintă sub forma unei tabele de două coloane. Pe prima coloană sunt numele etichetelor fiecărei valori, iar în a doua coloană sunt valorile. Tabela doar poate fi văzută nu și editată.

Sub tabelă se află butonul Pasul precedent care duce înapoi la pasul Data ( Figura 3.5.) în caz că datele prezentate nu sunt cele dorite. Și lângă acesta se află butonul Confirmare, care presupune etapa de inserare a programării care va fi reflectată în calendarul medicului la care s-a programat (Figura 4.3.).

Tehnologii folosite

HTML5, bogat în caracteristici pentru browser și "single page application" sunt instrumente extrem de valoroase pentru dezvoltarea de aplicații moderne, dar orice interacțiune semnificativă va implica un server back-end, deci la fel de bine ca și conținut static (HTML, CSS și JavaScript) vom avea nevoie de un server back-end. Serverul back-end poate: servi conținut static, uneori (dar nu atât de des în aceste zile) de redare conținut HTML dinamic, autentificarea utilizatorilor, asigurarea accesului la resursele protejate și interacțiunea cu JavaScript în browser prin HTTP și JSON (uneori denumită REST API).

În dezvoltarea sistemului de gestiune au fost folosite pentru partea de front-end, mai specific aplicația client, HTML, CSS și Bootstrap cu AngularJS, pe partea de server Java și anume Spring pentru serviciul REST și Spring Security pentru autentificare și permisiuni și Hibernate pentru legătura dintre server și baza de date, iar pentru baza de date a sistemului s-a folosit MySql.

Java

Java este un limbaj de programare de nivel înalt, dezvoltat de SunMicroSystems și lansat în 1995. În ziua de azi sunt o mulțime de aplicații care nu pot fi rulate dacă nu ai Java instalat. Java este rapid, sigur și de încredere. Java se regăsește pe laptopuri, console de jocuri, calculatoare și telefoane mobile.

Am folosit Java în realizarea aplicației datorită următoarelor avantaje:

Orientat pe obiect: În Java totul este un obiect, oferind posibilitatea de extindere a acestuia într-o manieră ușoară;

Independent de platformă: Spre deosebire de limbaje ca C sau C++, care sunt compilate specific pentru o platformă, Java este compilată în cod binar. Astfel acest cod este trimis prin web iar mașina virtuală Java (JVM) va interpreta codul pe orice mașină este instalată;

Simplu: Java este făcut pentru a fi ușor de învățat. Dacă aveți noțiunile de bază ale programării orientate pe obiect atunci veți înțelege Java;

Sigur: este un limbaj de programare foarte sigur, furnizând mecanisme stricte de securitate a programelor concretizate prin: verificarea dinamică a codului pentru detectarea secvențelor periculoase, impunerea unor reguli stricte pentru rularea proceselor la distanță, etc.;

Neutru din punct de vedere arhitectural: Compilatorul Java generează un obiect fișier neutru din punct de vedere architectural, ceea ce face să execute codul compilat pe mai multe procesoare ce au JVM;

Portabil: Java fiind neutru din punct de vedere arhitectural și independent de platforma de lucru, aceeași aplicație poate fi rulată pe sisteme de operare diferite, cum ar fi Windows, Linux, OS, Solaris etc., reducând costul cheltuielilor pentru firmele dezvoltatoare de software;

Robust: Java încearcă să elimine situațiile predispuse la eroare prin punerea accentului pe verificarea erorilor de compilare și de rulare;

Multi-thread: Cu Java poți scrie programe care pot executa mai multe sarcini simultan;

Interpretabil: Codul binar Java este tradus imediat în cod mașină și nu este stocat nicăieri;

Înaltă performanță: Cu utilizarea compilatoarelor Just-in-Time , Java este de înaltă performanță;

Distribuit: limbajul Java este proiectat pentru distribuirea acestuia pe Internet;

Dinamic: Java este considerat a fi mai dinamic decât C sau C ++, deoarece este conceput pentru a se adapta la un mediu în continuă evoluție.

Java SE (Java Standard Edition) este platforma standard de lucru ce oferă suport pentru crearea de programe independente și applet-uri. Ea oferă funcționalitățile de bază a limbajului Java. Conține toate bibliotecile și API-urile necesare pentru realizarea de programare Java (java.io, java.math, java.lang, java.net).

J2ME (Micro Edition) este o platformă ce oferă biblioteci necesare pentru scrierea de programe pentru dispozitive mobile și sisteme integrate.

J2EE (Enterprise Edition) este oferă API-ul necesar dezvoltării de aplicații complexe (de obicei aplicații web). Oferă librării pentru accesarea bazei de date (JDBC, JPA), servicii web, procesare XML, servlet. JSP, etc.

Spring RESTful

Spring framework este o platformă Java open source, care oferă suport complet de infrastructură, pentru dezvoltarea rapidă și ușoară de aplicații Java robuste. Spring este unul dintre cele mai populare framework-uri pentru dezvoltarea aplicațiilor Java. Este ușor atunci când vine vorba de mărime și transparență (versiunea de bază are în jur de 2 MB).

Principala caracteristică a framework-ului este că poate fi folosită în dezvoltarea oricărei aplicații Java, dar are extensii pentru construirea de aplicații web deasupra platformei Java EE. Spring încearcă să facă dezvoltarea J2EE mai ușoară și să promoveze programarea corespunzătoare prin folosirea modelului de programare bazat pe POJO( Plain Old Java Object ).

Avantajele folosirii framework-ului Spring:

Permite dezvoltatorilor să folosească POJO în aplicațiile lor.

Este modulară, adică chiar dacă numărul de pachete și clase crește substanțial trebuie doar să te uiți numai la clasele de care ai nevoie în acel moment și să le ignori pe celelalte.

Testarea unei aplicații este ușoară deoarece codul dependent de platformă se regăsește în framework.

Spring Web este un MVC (Model-View-Controller) framework bine conceput, oferind o alternativă mai bună față de alte framework-uri ca Struts sau alte framework-uri mai puțin populare.

Spring este asociat cu injectarea dependențelor (Dependency Injection) a inversiunii de control (Inversion of Control). Inversiunea de control este un concept general, iar injectarea dependențelor este un mod de a exprima acest lucru. Injectarea dependențelor înseamnă că deși clasele sunt independente unele față de celelalte, pentru a putea fi refolosite, prin intermediul inversiunii de control acestea sunt injectate una în cealaltă de către framework, astfel acestea au legătură una cu cealaltă dar în același timp sunt și independente.

Pentru sistemul de gestiune realizat s-a folosit Spring Web MVC framework, mai specific Spring RESTful, versiunea 4.2.5. Spring web MVC oferă o arhitectură model-view-controller și vine cu un set de componente existente care pot fi folosite pentru a dezvolta aplicații web flexibile. Modelul MVC separă diferitele aspecte ale aplicației, cum ar fi logica de intrare, logica de afaceri și logica interfeței cu utilizatorul (User Interface), oferind în același timp o legătură minimală între acestea.

S-a folosit un serviciu REST pentru ca AngularJS să apeleze API-ul CRUD a serviciului REST prin efectuarea de cereri Ajax.

Modelul reprezintă datele aplicației, acestea fiind reprezentate de obiectele Java create. View-ul este responsabil de redarea datelor modelului și în general generează o ieșire HTML pe care browser-ul poate sa-l interpreteze. Controller-ul se ocupă cu procesarea cererilor utilizatorului și construirea modelului adecvat care apoi îl trimite la View.

Framework-ul Spring Web MVC este proiectat în jurul la DispatcherServlet care se ocupă de cererile și răspunsurile HTTP.

Figura 5.1. Fluxul de gestiune a unei cereri prin Web MVC

După ce primește o cerere HTTP de la client, DispatcherServlet consultă HandlerMapping (reprezentat printr-un fișier XML) să apeleze Controller-ul (reprezintă o clasă Java care are la început adnotarea @Controller) potrivit. Controller-ul preia cererea și cheamă metoda potrivită pentru metodele HTTP GET, POST, PUT, DELETE (deasupra metodei din Controller se găsește declarată adnotarea @RequestMapping. Metoda va seta modelul pe bază a logicii de afaceri și îl va da lui DispatcherServlet. Acesta îl va trimite la View Resolver pentru a obține view-ul potrivit pentru cerere. La sfârșit se va trimite la View pentru a fi redat în browser.

În termeni de servicii web, REpresentational State Transfer (REST) este o arhitectură stateless client-server în care serviciile web sunt privite ca resurse și pot fi identificate prin URL-urile lor.

Este compusă din două componente: serverul, care oferă acces la resurse și un client REST care accesează și modifică resursele REST. Servicii web RESTful folosesc metode de protocol HTTP pentru operațiile care le efectuează. Acestea sunt:

GET – definește o cerere de citire a resursei;

PUT – folosit în mod general pentru a modifica o resursă;

DELETE – șterge resursa;

POST – creează o nouă resursă.

Diferența esențială dintre Spring RESTful și Spring MVC este controller-ul și cum răspunsul HTTP este creat. Dacă la MVC se bazează pe View, serviciul RESTful întoarce obiectul și datele obiectului direct în răspunsul HTTP sub format JSON sau XML.

Figura 4.2. Fluxul de gestiune a unei cereri prin REST

Clientul face o cerere sub formă de un URI. DispatcherServlet interceptează cererea și caută cu ajutorul la HandlerMapping controller-ul potrivit (clasa cu adnotarea @RestController). Se verifică dacă are metoda potrivită cererii și întoarce un HTTP răspuns cu obiectul de tip JSON sau XML în el pentru a fi prelucrat în browser.

DispatcherServlet pentru aplicația realizată este spring-servlet.xml unde se regăsesc bean-urile pentru conectarea la baza de date, sesiunea de hibernate și atribuirea de nume logice pentru paginile web. Un bean este un obiect instanțiat și controlat de container-ul Spring IoC. Sunt definite între tag-urile <bean></bean>.

În acest fișier mai sunt definite alte elemente:

<context:annotation-config />, care permite folosirea adnotărilor în Java;

<context:property-placeholder location="cale " />, pentru citirea luarea proprietăților pentru conectarea la baza de date;

<context:component-scan base-package="pachet"/>, pentru scanarea pachetelor pentru clase cu adnotări Spring, cum ar fi controller-ul;

<tx:annotation-driven />, pentru procesarea și gestionarea de tranzacții bazate de adnotări între server și baza de date cu hibernate.

Acesta este implementat, ca orice servlet, prin setarea în fișierul de descriere web web.xml. Se face prin încadrarea între tag-urile <servlet></servlet> și sub-tag-urile <servlet-name></servlet-name> și <servlet-class></servlet-class>. De asemenea, este nevoie și de o mapare URL folosind tag-ul <servlet-mapping></servlet-mapping> cu sub-tag-urile <servlet-name></servlet-name> și <url-pattern>/</url-pattern>.

HandlerMapping-ul este DefaultAnnotationHandlerMapping care mapează URL-urile către controalele cu adnotarea @RestController sau @Controller. Controller-ul @RestController este format din @Controller și @ResponseBody (convertește obiectul de trimis într-un format JSON/XML și îl atribuie la răspunsul HTTP).

Sunt create în proiect două controale REST și anume clasele: HomePageRestController și UserPageRestController pentru a fi mai ușor de gestionat și citit codul. Primul control este pentru operațiile de vizualizare din pagina principală a sistemului, iar al doilea este pentru pagina de operații a utilizatorului logat. Ambele au adnotarea care arată că sunt un controller și anume @RestController. Aici se găsesc metodele de tratare a cererii clientului. Fiecare metodă de tratare este mapată la un URL specific sau model de URL definită prin adnotarea @RequestMapping aflată deasupra fiecărei metodei. Adnotarea are ca parametrii: value-reprezintă URL-ul la care este atribuit, method-reprezintă tipul cererii HTTP, produces- reprezintă ce tip de răspuns întoarce la client, JSON fiind cel de bază.

Răspunsul întors de metodele de tratare este este de tip ResponseEntity<T> ce extinde HttpEntity, ceea ce înseamnă că răspunsul va trebui să conțină un HTTP status indiferent că se întâmpină o eroare sau nu. Spre exemplu, dacă se cer toate secțiile din spital se execută Hibernate-ul și aduce o listă de obiecte. Se verifică la întoarcere dacă lista este cumva goală. Dacă da atunci se va returna un ResponseEntity<List<Secții>> cu HTTP status de NO_CONTENT (204) reprezentând faptul că nu s-a găsit nici o secție, altfel se întoarce un ResponseEntity<List<Secții>> cu Http status OK (200), semnificând că s-au găsit secții. În funcție de răspunsurile trimise, pe front-end se pot gestiona diferite cazuri pentru aceste erori și de notificare a clientului de problemele întâmpinate.

Spring Security

Pentru securitatea aplicației s-a folosit Spring Security. Spring Security este un security framework care permite autentificarea pentru securitatea aplicațiilor Spring. Se integrează ușor cu Spring web MVC și vine deja cu algoritmi de securitate implementați.

Principalul scop al lui Spring Security este de a autentifica și autoriza:

Autentificarea este procesul în care se stabilește că s-a conectat un utilizator;

Autorizarea este procesul în care se verifică dacă utilizatorul conectat are dreptul de a efectua anumite operații sau accesa anumite pagini.

În aplicația realizată Spring Security este realizat prin intermediul unui servlet xml numit security-context.xml unde se găsesc tag-urile pentru securitatea site-ului.

Site-ul are două module de AngularJS. Prima este HomePage unde toată lumea care are Internet are acces și a doua este UserInterface unde doar utilizatorii autentificați au voie să acceseze pagina. Aceste lucruri trebuie specificate în xml folosind tag-ul <http/> și sub-tag-ul <intercept-url pattern=”URL” access=”Rol”/>. În acest fel se vor intercepta URL-urile din browser și se va verifica ce permisiune au acestea. Spre exemplu <intercept-url pattern="/home" access="permitAll"/> arată că pentru URL-ul ce conține /home, care este numele asociat lui HomePage, toată lumea are acces la ea, în timp ce pentru tag-ul <intercept-url pattern="/user**" access="hasRole('ROLE_PACIENT') or hasRole('ROLE_MEDIC')"/> arată că orice URL ce conține /user doar utilizatorii ce s-au autentificat și au rolurile ROLE_PACIENT sau ROLE_MEDIC pot să le acceseze.

Pentru autentificare s-a folosit tag-ul form-login care redirecționează vizitatorul către pagina de logare Login când se sesizează accesarea unui URL restricționat și utilizatorul nu s-a autentificat deja. Acesta va folosi autentificat-provider pentru gestiunea datelor de logare, care de fapt reprezintă un bean cu o referință către o clasă Java numită UserDetailsServiceImpl. UserDetailsServiceImpl implementează UserDetailsService al lui Spring Security și suprascrie metoda loadUserByUsername pentru a putea verifica datele de logare cu baza de date a aplicației. Dacă nu se găsește nici un cont cu datele introduce se va arunca o excepție UsernameNotFoundException care va fi gestionată în pagină pentru notificarea utilizatorului. Altfel se va întoarce un obiect User, tot al lui Spring Security, care va conține date relevante contului cum ar fi user, parolă, statusul contului și rolul reprezentat printr-o colecție de GrantedAuthority unde se salvează rolul sau rolurile unui cont. Pe baza acestei colecții se verifică în xml dacă contul are rolul corespunzător pentru URL-ul accesat.

Hibernate

Atunci când lucrăm cu o sisteme orientate pe obiecte, există o neconcordantă între modelul de obiect și baza de date relațională. RDBMS (Relational Database Management System) prezintă datele într-un format tabular în timp ce limbajele orientate pe obiecte, cum ar fi Java sau C# îl reprezintă ca un graf al obiectelor interconectate. Maparea obiectelor relaționale (ORM) este soluția pentru acest impediment.

ORM reprezintă Object-Relational Mapping (ORM) și este o tehnică de programare pentru conversia datelor între bazele de date relaționale și limbajele de programare orientate pe obiect, cum ar fi Java, C#, etc. Un sistem ORM are următoarele avantaje fată de JDBC:

Permite codului de business să acceseze obiectele și nu tabelele DB, deci nu este afectată de baza de date cât timp obiectele sunt create și valorizate;

Ascunde detaliile de interogare SQL de logica orientării pe obiecte;

Nu este nevoie să te atingi de implementarea bazei de date;

Entitățile sunt bazate pe concepte de afaceri și nu pe structura bazei de date;

Gestionare tranzacțiilor și generarea automată a cheilor primare;

Dezvoltarea rapidă a aplicațiilor.

Hibernate este o bibliotecă ORM (Object-Relational Mapping) pentru limbajul Java, utilă pentru maparea modelului orientat pe obiecte peste bazele de date relaționale. Principalul atu al acestei librării este faptul că oferă o soluție rapidă, de înaltă performanță, independentă de tipul bazei de date folosite pentru modelarea obiectelor unei baze relaționale. Această tehnologie este gratis și open source, distribuită sub licența GNU Lesser General Public License.

Principala caracteristică a Hibernate este maparea între clasele Java și tabelele bazelor de date precum și între tipurile de date Java și SQL. Hibernate pune la dispoziție posibilitatea scrierii de interogări și luarea de informații din tabelele din baza de date. Hibernate suportă multe sisteme de gestiune a bazelor date, cum ar fi: Oracle, MySQL, PostgreSQL, FrontBase, etc.

Spring framework suportă integrarea cu Hibernate, Java Persistence API (API), implementări Data Access Object (DAO) și strategii de tranzacții. Hibernate este folosit în aplicație pentru operații de modificare, selectare, ștergere și introducere a datelor din baza de date. În cazurile în care este necesară doar o valoare dintr-o tabelă din baza de date se va folosi HQLQuery pentru interogări simple pentru economisirea de timp, iar pentru filtrarea datelor din baza de date se va folosi Criteria unde se pot seta diferite filtre de căutare (like, equals, etc.).

Maparea claselor Java pe tabele din baza relațională se realizează prin configurarea unui fișier XML sau prin folosirea de adnotări Java. În aplicație s-au folosit adnotări Java pentru gestionarea operațiilor. Hibernate oferă posibilitatea de a realiza relații unu-la-unu, mulți-la-mulți sau unu-la-mulți între clase, astfel se obține informațiile necesare înt.

Se definește în spring servlet un obiect de tip SessionFactory care va permite conectarea la baza de date, primind datele de conectare la sistemul de gestiune printr-un fișier securizat și se specifică pachetul unde sunt obiectele mapate cu adnotările hibernate.

În obiectele mapate se vor găsi următoarele adnotări:

@Entity – folosit pentru HQLQuery, este numele entități;

@Table(name = "nume") – permite să se specifice detaliile din tabelă, care vor fi folosite pentru a persista entitatea în baza de date și anume numele tabelei;

@Id și @GeneratedValue – fiecare entitate are o cheie primară reprezentată prin adnotarea @Id, care poate fi un singur câmp sau mai multe. A doua adnotare arată tipul chei primare prin tipul strategiei sale, adică dacă este generată de o secvență sau este automată (MySql);

@ManyToMany, @OneToMany, @ManyToMany – adnotări ce arată legăturile dintre entități;

@JoinTable – folosită pentru legături @ManyToMany pentru a reprezenta tabela de legătură dintre ele;

@Column – specifică detaliile coloanei respective cum ar fi numele, lungimea și dacă este nulă.

Acest SessionFactory se cere în clasa HibernateUtil unde este adnotat cu @Autowired pentru injectare automată de dependență și se folosește pentru diferite operații CRUD. Aceste operații sunt cerute prin clase DAO.

Jasper Reports

Jasper Reports este un motor open source Java de generare de documente. Jasper Reports este o bibliotecă de clasă Java destinată pentru adăugarea posibilității de creare de rapoarte pentru aplicație. Această bibliotecă oferă posibilitatea de generare de rapoarte în diferite formate, cum ar fi HTML, PDF, XLS, ODT, CSV, etc. pe ecran sau direct la imprimantă.

Jasper Reports este flexibil în crearea aspectului raportului, poate prezenta datele atât scris cât și grafic, poate genera watermarks (o a doua imagine deasupra primei imagini) și suportă crearea de sub-rapoarte. Un alt avantaj al lui este modul cum își obține datele pentru afișare. Poate să-și ia informația din obiecte Java, Hibernate sau JDBC. Mai poate primi parametri prin setarea unui Map în cod Java.

Un raport este format dintr-un fișier .jrxml, care este de fapt un fișier xml, ce conține tag-ul <jasperReport> ca elementul de bază, care la rândul lui conține multe sub-tag-uri. Aici sunt trecute elementele grafice ce vor apărea în raport plus datele și metoda de obținere a datelor.

Pentru o prelucrare mai ușoară a fișierului fără a necesita cunoștințele necesare despre tag-urile jasper, Jasper reports oferă un plugin pentru Eclipse numit JasperSoft Studio care oferă o interfață unde se poate modela raportul. Folosind o paletă se poate lua și pune direct pe raport elementele statice și dinamice dorite și se pot modifica aceste elemente în funcții de nevoi. Plugin-ul oferă posibilitatea de vizualizare a paginii în timpul dezvoltării ajutând mult în procesul de dezvoltare a rapoartelor și oferă posibilitatea de modificare a rapoartelor foarte ușoară.

Când se creează un nou raport trebuie selectat modul de preluare a datelor pentru afișarea acestora. Pentru aplicația realizată am hotărât să se ia direct din baza de date informațiile necesare pentru generarea raportul cu parametrii primiți din Java pentru realizarea interogării.

Am folosit Japer Reports pentru generarea fișei de pacient și facturii aferente pacientului pentru serviciile primite pe durata consultațiilor și/sau internărilor. Aceste documente respectă standardele folosite de toate societățile medicale și private din România, astfel încât se regăsesc pe acestea toate informațiile relevante atât pentru pacient și doctor.

Aceste documente sunt generate în momentul în care este efectuată o consultare standard (nu este internat) sau pacientul este externat. Prin apelarea metodelor REST din controller se caută fișierul .jrxml în structura de directoare a proiectului. Folosindu-ne de metodele deja existente din biblioteca Jasper se compilează întâi raportul, dându-se calea către fișier găsită, apoi după ce primește conexiunea la baza de date și parametrii Java se excută interogarea efectuată de Jasper. Se populează raportul cu datele aduse de interogare. După aceea se exportă sub formă binară și se trimite răspunsul în format JSON la AngularJS unde este interpretat ca un application/pdf și se afișează într-o nouă fereastră documentul sub formă pdf. De asemenea, forma binară este salvată și în baza de date într-un BLOB, astfel oferind posibilitatea de a obține documentul realizat fără a mai fi nevoie de a genera din nou documentele.

Log4J

Log4J este un framework de logare fiabil, rapid și flexibil scris în Java distribuit sub licența Apache Software.

Log4J este extrem de configurabil prin fișiere de configurare externe în timpul rulării. Acesta vede procesul de logare pe nivelurile de prioritate și oferă mecanisme de scriere a informației logate către diferite destinații, cum ar fi o bază de date, fișier, consolă, UNIX Syslog, etc.

Log4J are 3 componente importante:

loggers – responsabili pentru pentru prinderea informației ce trebuie logată

appenders – responsabili pentru publicarea informației către destinațiile dorite

layouts – responsabili pentru prezentarea informației logate sub o anumită formă.

Log4J este optimizat pentru viteză și thread-safe. Are multe nivele de prioritate: ALL, TRACE, DEBUG, INFO, WARN, ERROR, FATAL și OFF. Ordinea lor de prioritate este aceasta: ALL < DEBUG < INFO < WARN < ERROR < FATAL < OFF.

Log4J poate încetini o aplicație, în funcție de câte loguri se folosesc, și poate încărca un fișier cu foarte multe informații făcând greu de citit și căutat informația dorită, dar este ușor de învățat și de folosit.

Log4J a fost folosit în aplicație cu scopul logării operațiilor efectuate și a erorilor întâmpinate pe parcursul folosirii aplicației. Informația este salvată într-un fișier unde se pot verifica oricând operațiile logate. Astfel se poate găsi cu ușurință cauza ce a dus la producerea erorii. Acesta a fost configurat folosind un fișier log4j.xml, situat în folderul de resurse al proiectului. În fișier se specifică unde se salvează informația logată și anume în consolă și intr-un fișier din proiect, folosind un stil unde se specifică data și ora efectuării operației sau erorii. Aici se mai specifică și ce nivel să se folosească pentru fiecare librărie, cum ar fi INFO pentru spring.

Maven

Maven este un instrument de automatizare folosit în pricipal pentru proiecte Java. Este bazat pe conceptul unui model obiect de proiect (POM). Cuvântul maven înseamnă “acumulator de cunoștințe” în Yiddish (limbă a everilor). Maven descrie dependențele unui proiect și cum trebuie construit proiectul. Este un instrument mai performant decât Apache Ant și mai simplificat.

Scopul principal al lui Maven este de a permite dezvoltatorului să înțeleagă starea completă a unui efort de dezvoltare, în cea mai scurtă perioadă de timp. În vederea atingerii acestui obiectiv Maven încearcă să realizeze următoarele:

Să facă procesul de construcție ușor;

Furnizarea unui sistem de construcție uniform;

Furnizarea de informații de calitate despre proiect;

Furnizarea de repere pentru cele mai bune practici de dezvoltare;

Permiterea migrației transparente pentru noi caracteristici.

POM reprezintă Project Object Model. Este un fișier xml ce conține cum trebuie construit proiectul, dependențele proiectului, ordinea de construire, directoarele și plugin-urile. Maven conține target-uri predefinite pentru fiecare operație de realizat. Un proiect Maven este și ușor de portat ori ca JAR, WAR sau EAR.

În cazul unui proiect de mari dimensiuni cu multe librării de folosit unde trebuie să le descarci și să le pui ]n proiect manual Maven vine și rezolvă problema aceasta a dependențelor. Acesta descarcă librăriile necesare de pe repository-ul Maven Central Repository, unde se regăsesc bibliotecile dorite și le descarcă într-un cache local. De asemenea, i se poate specifica și alte repository-uri pentru librării dacă este nevoie. Singurul dezavantaj ar fi că Maven necesită ca dezvoltatorul să înțeleagă inițial cum funcționează un proiect din punctul de vedere al Maven și cum interacționează Maven cu acesta. Dar odată înțeles acest lucru, Maven poate fi folosit pentru orice proiect deoarece modul de definire și structurare a unui proiect și a celorlalte target-uri se folosesc în orice alt proiect cu ușurință.

Pentru proiect s-a folosit Maven 3.3 unde s-au declarat toate dependențele necesare pentru proiect cum ar fi librăriile Spring, Spring Web MVC, Jasper Reports, Log4j, Hibernate etc.

HTML5

HTML5 ( Hyper text Markup Language ) este un este un limbaj de marcare ce descrie structura unei pagini web și este la a cincea iterație în acest moment. Standardul oficial este hotărât de World Wide Web Consortium ( W3C ).

HTML5 extinde și îmbunătățește marcajele pentru documentele web. Au fost adăugate multe etichete noi, cum ar fi pentru multimedia <video> și <audio>. Include și caracteristici specifice pentru aplicații mobile cross-platform, cum ar fi smartphone și tablete. Toate browserele de pe dispozitivele mobile suportă HTML5 și tot mai multe aplicații apar pentru acestea. Codul HTML se scrie folosind etichete pentru a descrie un anumit conținut dintr-un document. Etichetele sunt cuvinte-cheie pe care browser-ul îl interpretează și redă documentul către persoana care accesează o pagină web.

Elementele de bază dintr-un document sunt:

DOCTYPE – ce declară ce versiune de HTML se folosește pentru redarea corectă a documentului în browser. Pentru HTML5 se declară <!DOCTYPE html>;

<html> – reprezintă documentul ce va fi văzut;

<head> – oferă informații despre document;

<title> – este titlul documentului afișat în URL-ul browser-ului;

<body> – descrie conținutul paginii ce se va vedea.

HTML5 este o îmbunătățire față de celelalte versiuni prin simplu fapt că codul este mai ușor și mai curat de scris, oferă suport multimedia cu noile etichete. Interacțiunile dintre pagina web și client sunt mai accentuate prin adăugarea etichetei <canvas>. Canvas este un tag folosit pentru desenarea de grafice, adăugarea de imagini, text și chiar oferă posibilitatea de a crea jocuri.

HTML5 oferă suport cross-platform, adică toate browserele suportă HTML5. Deși browserele mai vechi recunosc DOCTYPE-ul nu înseamnă că poate să și folosească noile etichete, dar există o soluție prin intermediul la JavaScript care prin încărcarea unui fișier JavaScript ajută la folosirea acelor etichete.

Am folosit HTML5 pentru aplicația mea pentru a putea vizualiza aplicația pe orice dispozitiv indiferent că este pe un calculator, tabletă sau mobil și să se vadă corespunzător pentru acele dispozitive.

Bootstrap

Bootstrap este cel mai popular framework HTML, CSS, JavaScript pentru dezvoltarea de pagini web responsive pentru mobil. Bootstrap este complet gratuit.

Bootstrap conține șabloane HTML și CSS pentru formulare, tabele, butoane, navigare, modale, etc. pentru a crea pagini responsive și atractive. Pagini responsive înseamnă pagini web care se adaptează automat ca să arate bine pe orice dispozitiv, de la telefoane mobile la desktop. Bootstrap este ușor de folosit, dacă ai cunoștințe de bază în HTML și CSS. El a fost creat în primul rând pentru aplicații mobile și este compatibil cu toate browserele mobile.

Pentru a folosi bootstrap se trece în atributul class al elementului dorit clasa din bootstrap. Aceasta va implementa stilul și funcționalitatea asociate cu acel atribut. Un motiv de nefolosire al lui ar fi faptul că dacă site-ul conține numai elemente bootstrap atunci site-ul va arăta aproape identic cu alte site-uri care îl folosește. Dar acest lucru poate fi rezolvat prin folosirea CSS-ului propriu pentru a da un aspect unic paginilor web fără să sacrifice funcționalitatea oferită de Bootstrap.

Pentru realizarea aplicației am decis de la început ca front-end-ul să fie cât mai receptiv față de dispozitivul pe care se vizualizează. Acest lucru a determinat să se implementeze bootstrap-ul în proiect.

CSS3

CSS sau Cascading-Style-Sheets descrie cum trebuie să fie prezentate elementele dintr-un HTML pe ecran. CSS este folosit pentru stilizarea paginilor web, inclusiv proiectarea, aspectul și variațiile de afișare pentru dispozitive și ecrane diferite.

Inițial când s-a introdus eticheta <font> și atributele de culori la HTML 3.2, a început să apară probleme pentru dezvoltatori. Dezvoltarea de aplicații web de dimensiuni mari trebuiau să adauge pentru fiecare pagină acest stil și dacă mai târziu trebuia schimbat stilul atunci trebuia să intri din nou pentru fiecare pagină în parte să modifici. Acest proces consuma foarte mult timp. Pentru a rezolva această problemă, W3C au creat CSS, astfel au scos stilizarea paginii din HTML. Stilul pentru pagini este salvat într-un fișier separat cu extensia .css și dacă este necesară modificarea stilului pentru pagini trebuie doar să se modifice un singur fișier.

Sintaxa unei reguli CSS este: selector {proprietate: valoare; proprietate: valoare; …}. Selectorul semnifică ce element HTML vrei să fie stilizat. Proprietatea și valoarea reprezintă ce anume dorești să se întâmple cu acel element, cum ar fi culoarea roșu color: red. Se pot adăuga mai mult de o proprietate și o valoare în selector. CSS3 este ultimul standard pentru CSS. Acesta este compatibil cu celelalte versiuni de CSS.

CSS3 aduce multe îmbunătățiri pentru dezvoltatori cum ar fi translatarea 2D/3D a elementelor din HTML (modificarea poziției, formei și mărimii în mod dinamic), tranziții și animații pentru realizarea de efecte atrăgătoare pentru utilizator, suport pentru paginare. Aceste se rezumă la faptul că se pot modifica elemente din HTML în mod dinamic.

Cel mai mare avantaj ar reprezenta noul aspect numit flexbox și media queries. Flexbox asigură că elementele se comportă corespunzător când pagina este redată pe diferite dispozitive și ecrane. Poți modifica orientarea elementelor dintr-un container flex cu ușurință (exemplu, direction: rtl – orientare de la dreapta la stânga), alinierea lor în container și cum să se comporte când ies din marginea containerului.

În ultimii ani tendința pieței este către crearea de aplicații care se pot folosi pe mobil și tabletă cu ușurință. Media Queries sunt una din metodele folosite pentru realizarea unor astfel de aplicații. Ele extind regula media de la CSS2. În loc să se uite de pe ce tip de dispozitiv se redă documentul, se uită la capacitatea dispozitivului.

Media Queries sunt folosite să verifice multe lucruri cum ar fi:

lățimea și înălțimea viewportului;

lățimea și înălțimea dispozitivului;

orientarea ( este tableta sau telefonul în modul peisaj sau portret? );

rezoluția.

Sintaxa css este: @media not|only mediatype and (expresie){CSS-Code;}

Media Queries sunt folosite pentru a reda un stil specific pentru tablete, IPhone și Android. Există anumite puncte limită, exprimate în pixeli sau în em (înălțimea fontului în inch), pentru fiecare dispozitiv și pe baza acestora se pot delimita stilurile ce trebuiesc aplicate prin intermediul la media query. Dar datorită faptului că sunt o sumedenie de dispozitive de dimensiuni diferite este aproape imposibil să faci media query pentru fiecare caz. Așa că se trec niște limite comune și de acolo se verifică pentru fiecare dispozitiv dacă se aplică, dacă nu se creează un media query special pentru acest dispozitiv.

Pentru proiectul realizat s-a folosit media query și elemente de stilizare pentru redarea adecvată și atractivă a elementelor HTML pe diferite dispozitive și browsere. Am folosit acestea pentru a prezenta un aspect plăcut atât pentru dispozitive mari (calculator, laptop) cât și pentru dispozitive mici (telefoane, tablete).

Limitele impuse de mine pentru media query au fost:

Între 480px-600px este pentru smartphone-uri, Android și IPhone în mod peisaj;

Între 600px-768px este pentru tablete în modul portret, IPad, Android pe modul peisaj;

Peste 768px este pentru laptop, tablete, calculatoare.

CSS-ul a folosit și pentru animațiile între pagini când se schimbă pagina. Animația de ieșire este o tranziție ușoară a paginii de la dreapta la stânga, la fel și pentru animația de intrare cu o întârziere de o secundă între ele.

AngularJS și Ajax

AngularJS este un framework JavaScript. AngularJS este open source, gratis și distribuit sub licența Apache versiune 2.0.

JavaScript este limbajul de programare pentru HTML și web. Java Script este open și cross-platform. Este complementar și integrat atât cu HTML cât și cu Java. Javascript permite scripturi client-side să interacționeze cu utilizatorul și este folosit pentru a crea pagini dinamice. JavaScript este folosit pentru schimbarea proprietăților elementelor HTML: poate să ascundă/arate un element, poate să-i schimbe stilul CSS, poate să adauge atribute unui element, etc. JavaScript adaugă diferite funcționalități pentru elementele HTML.

Unele din avantajele la Javascript ar fi mai puține interacțiuni cu serverul, spre exemplu validarea datelor scrise de utilizator pot fi validate de JavaScript fără a mai fi nevoie să le trimită la server pentru validare, astfel se realizează mai rapid decât să se aștepte răspunsul de la server. Vizitatorii pot vedea imediat informațiile necesare. Un alt avantaj ar fi creșterea interacțiunii cu utilizatorul, adică se pot crea pagini unde dacă utilizatorul este cu mouse-ul pe anumite elemente va apărea o notă informative declanșată de JavaScript (funcția onmouseover). Astfel se pot crea pagini foarte interactive și dinamice pentru vizitatori.

Definiția la AngularJS este următoarea: AngularJS este un framework structural pentru aplicații web dinamice. Îți permite să utilizezi HTML ca un limbaj șablon și permite să extinzi sintaxa HTML pentru a exprima componentele aplicației în mod succint și clar. Sincronizarea datelor (data binding) și injectarea de dependență elimină o mare parte din codul care trebuie scris. Și totul se întâmplă în browser, făcându-l un partener ideal cu orice tehnologie de server.

Figura 4.3. Conceptele de bază a lui AngularJS

În diagrama de mai sus sunt reprezentate toate conceptele de bază:

Sincronizarea datelor (Data-binding) – este sincronizarea automata a datelor între model și view;

Scope – este un storage de informații (preluate de la model) pentru a fi utilizate mai târziu în controale, servicii sau directive. Cu ajutorul acestuia se pot face funcționalități care pot modifica o parte sau toată interfața;

Modules – modulele pot fi văzute ca părți diferite/independente a unei aplicații, ea este părintele în care se definesc controalele aplicației web;

Controller – reprezintă funcții JavaScript legate la un anumit scope și modul;

Services – sunt obiecte singleton instanțiate o singură data în aplicație, folosite de obicei pentru apeluri Ajax cu $http;

Filters – utilizate pentru a formata datele afișate utilizatorului;

Templates – view-uri cu informații din controller și model;

Routing – conceptul de schimbare a view-urilor, adică schimbarea de pagini în timpul navigării;

Injectarea de dependență (Dependency Injection) – AngularJS are încorporat acest lucru pentru a crea și testa aplicații cu ușurință;

Expresii (Expressions) – folosite pentru a sincroniza datele din aplicație cu HTML. Se scriu astfel: {{expresie}};

Directives – directivele sunt marcatori pentru elemente din DOM (elemente HTML, atribute, css, etc.) și sunt folosite pentru a crea noi etichete HTML care servesc ca noi extensii ale aplicației. AngularJS are predefinite câteva directive, cum ar fi:

ng-app – activează AngularJS la crearea DOM-ului și permite utilizarea unui modul. Este folosită pentru o singură dată și dacă există dubluri vor fi ignorate. Este de obicei declarată în <body>;

ng-controller – specifică ce controller din modul va fi folosit asupra paginii;

ng-model – realizează legătura bidirecțională dintre view și model, folosită la input, textarea, select pentru primirea de date și alterarea acestora.

AngularJS este asemănător cu Spring-ul prin faptul că amândouă au o arhitectură MVC pentru a scrie aplicații pe partea de client. AngularJS este compatibil cu toate browserele. Modelul este responsabil cu datele din aplicație, răspunde la cererea de la view și la instrucțiunile de la controller. View-ul este o reprezentare a datelor într-un format și sunt ușor de integrat cu Ajax, cum ar fi JSP, ASP, PHP. Controller răspunde la interacțiunile utilizatorului și modifică datele din model.

Este folosit pentru proiecte Single Page Application (SPA). Single Page Application se distinge de alte aplicații web prin simplul fapt că ele pot redesena diferite elemente din interfața utilizatorului (UI – User Interface) fără să apeleze serverul ca să încarce noul HTML, oferind astfel o experiență mai fluidă și plăcută pentru utilizator.

Cea mai folosită tehnică pentru realizarea de proiecte SPA este Ajax. Ajax înseamnă Asynchronous JavaScript and XML. Ajax este o tehnică folosită pentru schimbarea de date dintre client și server, fără să reîncarce pagina. Baza pentru Ajax este XMLHttpRequest., care este un obiect folosit pentru transferarea de informații între server și client. Asta înseamnă că se poate modifica părți din pagina vizualizată fără a se reîncărcă pagina. Se poate trimite și primi informații în diferite formate (JSON, XML, HTML, chiar și fișiere). Toate browserele moderne au deja incorporate în ele un obiect XMLHttpRequest.

Pentru a folosi Ajax în AngularJS s-a folosit serviciul $http. Acesta este predefinit în AngularJS și este ușor de folosit. Cu acest serviciu se face legătura dintre client și serviciul Spring RESTful. Întâi se hotărăște ce protocol de cerere este făcut, adică GET, PUT, POST sau DELETE. În serviciu se specifică adresa URL de unde se obține informația de pe server. În URL se trece, dacă există, datele de trimis pentru server, care va fi preluată de serviciul Spring RESTful și prelucrată. Dacă totul decurge cum trebuie atunci se va întoarce un răspuns cu un HTTP status și informațiile cerute de pe server, altfel se întoarce un răspuns HTTP cu un mesaj de eroare.

Pe parcursul folosirii lui AngularJS în proiect, în componența proiectului s-au mai folosit alte directive. Unele directive au fost create special pentru acest proiect, cum ar fi directiva de adăugat html dinamic cu tot cu validarea acestora pentru adăugarea de servicii efectuate la o consultație, selectarea datei și orei pentru programare în funcție de orele disponibile ale medicului. Altele existau deja, cum ar fi directivele de la Angular UI. Angular UI este o organizație care încearcă să consolideze și să creeze diferite directive utile pentru AngularJS.

Pentru aplicație s-au folosit:

Bootstrap UI este o reimplementare a tuturor elementelor Bootstrap în Angular (folosit în principal pentru modalele din aplicație);

UI Router folosit pentru rutarea complexă a paginilor în SPA;

UI Grid este o grilă de date pentru AngularJS care oferă multe operații pe datele prezentate (exportare de PDF, ordonare, filtrare date);

UI Select folosit pentru filtrarea datelor de către utilizator (căutarea medicului pentru programare în funcție de unu sau mai multe filtre).

Acestea sunt doar câteva din directivele oferite de Angular UI. Pe site-ul lor sunt o mulțime de directive utile pentru orice proiect.

Cel mai important și mai folosit element ar fi UI Router. UI Router este un framework pentru AngularJS pentru realizarea de proiecte SPA. Rutarea pentru SPA actualizează URL-ul browserului în timp ce utilizatorul navighează prin aplicație. Pe baza acelui URL se schimbă paginile între ele fără să se facă o cerere către server. Aplicațiile UI Router sunt modelate ca un arbore ierarhic de stări. Astfel se pot înlănțui multe stări care duc spre diferite pagini într-un mod fluid. De asemenea, acele stări pot avea sub-stări, oferind un control mai mare asupra la ce poate vizualiza clientul într-o pagină. În starea la UI Router se specifică întâi numele stării, URL-ul ce va fi reprezentat în browser, apoi este URL-ul către pagina care trebuie afișată și opțional controller-ul angular pentru acea pagină.

MySql

MySql este cel mai popular open source sistem de gestionare a bazelor de date. Este una dintre cele mai bune RDBMS (Relational Database Management System) folosite pentru dezvoltarea aplicațiilor web. RDBMS sau sistem de gestiune a bazelor de date este un soft care permite să se implementeze o bază de date cu tabele, coloane și indecși. Permite actualizarea automată a indecșilor și interpretează o interogare SQL și combină informații din diferite tabele.

MySQL folosește un format standard al limbajului SQL. Rulează pe mai multe sisteme de operare (Windows, Linux, etc.) și este compatibil cu multe limbaje ca Perl, PHP, Java, C și C++. Pentru un open source el suportă baze de date de dimensiuni mari, în jur de 50 de milioane de înregistrări pe o tabelă, dar această limită poate fi extinsă dacă se dorește.

Caracteristicile la MySQL sunt:

Flexibilitate – indiferent de sistemul de operare, MySQL oferă suport pentru majoritatea acestora;

Putere de procesare;

Prezența unei interfețe grafice;

Oferă suport pentru ODBC;

Independență de platformă;

Duplicarea bazei de date de pe un anumit pe server pe altul. Astfel se face o copie de rezervă în caz de pierdere cea inițială;

Securitatea este asigurată printr-o multitudine de opțiuni de configurare, cum ar fi dimensiunea memoriei alocate pentru interogări, tabele temporare, chiar și numărul maxim de conexiuni la server.

MySQL este ușor de instalat și chiar vine cu un instrument vizual care permite arhitecților, dezvoltatorilor și administratorul bazei de date să modifice, să șteargă sau să creeze baze de date, tabele sau coloane. Acest instrument oferă generarea de diagrame ER (Entitate-Relație) din baza de date creată și crearea de diagrame ER care le poți transforma în bază de date, procese numite forward engineering și reverse engineering.

Datorită acestor avantaje oferite de MySQL și capabilitățile oferite de acesta am folosit MySQL pentru crearea bazei de date prin intermediul instrumentului vizual MySQL Workbench. Acest instrument face ca perioada de concepere și creare a bazei de date să fie mult mai scurtă.

Implementarea aplicației

Sistemul informatic realizat și prezentat în acest capitol este descris din perspectiva software și din punctul de vedere al principalelor sale funcționalități.

Sistemul a fost dezvoltat conform arhitecturii client-server. Arhitectura client-server reprezintă o arhitectură computațională care presupune unul sau mai multe procese client, aflate pe calculatoare client, invocând servicii de la un proces server, aflat pe un calculator conectat în rețea cu calculatoarele client. Cel ce inițiază cererea de procesare se numește client, iar cel care onorează această cerere se numește server.

Sistemul creat este o aplicație web SPA și a fost realizat folosind limbajul orientat pe obiecte Java pentru partea de server, AngularJS, CSS, HTML și Bootstrap pentru client. Generarea de rapoarte se face prin intermediul la Jasper Reports. Logarea pe partea de server se face folosind Log4J. Acestea au fost realizate folosind mediul de dezvoltare Eclipse Mars. Baza de date a fost construită folosind MySQL cu ajutorul instrumentului vizual MySQL Workbench.

Comunicarea între aceste elemente se face printr-un serviciu REST pe server și cereri Ajax pe front-end și Hibernate între server și MySQL. Deasupra acestora se află și Spring Security pentru autentificarea și autorizarea pentru folosirea anumitor operații din aplicații. Pentru dependențele acestora și structura proiectului s-a folosit Maven 3.3.

Codul Java a fost scris folosind modelul de proiectare Data Access Object ( DAO ) și Service. Data Access Object este un model de proiectare folosit pentru persistență. Este bazat pe principiile de abstractizare și încapsulare, astfel protejând restul aplicației de schimbările de persistență cum ar fi schimbarea sistemului de gestiune a bazei de date. El este folosit în principal pentru conectarea la baza de date și prelucrarea datelor.

Un avantaj la implementarea DAO ar fi că testarea JUnit ar fi mai rapidă deoarece trebuie doar făcut un Mock și nu mai e necesară să faci și pentru conexiunea la baza de date.

Service este folosit ca un strat de protectiv pentru implementările DAO. El este intermediarul pentru datele care trebuiesc trimise către DAO și datele venite de la DAO. Oferă protecție deoarece service nu are nici o legătură cu conectarea la baza de date, el doar apelează metodele DAO, deci va fi mai greu de “spart” baza de date prin partea de client.

Structura proiectului este reprezentată în figura 6.1. Fișierul pom.xml din proiect reprezintă baza Maven-ului. În el sunt declarate toate dependențele necesare proiectului, luate de pe repository-ul Maven Repository. Cele mai importante sunt jar-urile de spring-core, spring-web, spring-webmvc, spring-security-core, spring-security-web, jackson-databind, hibernate-core, mysql-connector-java, log4j, mysql-connector-java, jasperreports.

În pachetul src.main.java.spital.angular se află mai multe subdirectoare: în configuration se regăsesc clasele pentru CSRF (Cross-Site Request Forgery) și CORS (Cross Origin Resource Sharing) tokens; în controller se află clasele pentru serviciul REST; dao unde se află clasele ce fac operațiile Hibernate scrise pe baza modelului de proiectare DAO (Data Access Object) pentru persistență; jsonviews sunt clasele folosite pentru controlarea mai granulată a procesului de creare a răspunsului JSON trimis către client; model sunt POJO-urile cu adnotări pentru hibernate, ele sunt folosite pentru prelucrarea datelor din baza de date; service este pachetul cu clasele ce apelează clasele din pachetele DAO, oferind protecție pentru acestea; util se află o singură clasă unde sunt trecute toate metodele hibernate uzuale, această clasă fiind apelată de către clasele DAO în mod regulat.

În pachetul src.main.resources sunt trecute fișierele cu datele de conectare la baza de date și proprietățile pentru logarea informațiilor cu Log4J. În pachetul src.main.webapp sunt mai multe subdirectoare: partials unde se află paginile secundare (copii) ce vor fi chemate de către UI Router în AngularJS, în resources sunt resursele statice folosite de proiect: css,unde sunt fișierele css pentru stilizarea aplicației; img, pentru imagini și iconițe; jasper, unde sunt trecute fișierele jrxml pentru generarea rapoartelor; js, unde este scris AngularJS pentru frontend; json, fișiere cu date json în ele, folosite pentru teste cu Ajax. În WEB-INF sunt în folderul jsp paginile principale (părinte) unde sunt folosite modulele lui AngularJS, tot în WEB-INF se regăsesc trei xml-uri: security-context (unde este declarat Spring Security), spring-servlet (unde se află obiectele instanțiate pentru serviciul Spring REST) și web.xml (descrie implementarea cele două xml-uri).

Figura 6.1. Structura proiectului

În continuare este prezentat în detaliu sistemul informatic dezvoltat, fiind folosite capturi de ecran pentru o mai bună înțelegere a funcționalității aplicației.

Aplicația accesată este Single Page Application, ceea ce înseamnă că nu mai este nevoie de reîncărcare paginii pentru a redesena o parte din aceasta. Pentru schimbarea între pagini, fără apelarea serverului, s-a folosit UI Router care declară paginile ca pe niște stări care când sunt apelate vor aduce pagina asociată acelor stări.

În momentul accesării aplicației dintr-un browser Spring Security interceptează URL-ul accesat și verifică cine are voie să acceseze pagina cu ajutorul fișierului security-context. Va vedea că permisiunea este setată pentru oricine și se va încărca pagina principală pentru vizitatori. La această pagină toată lumea are acces reprezentat de parametrul access="permitAll". Aici se pot obține informații utile despre spital. Elementele stilizate din pagină au fost realizate cu Bootstrap și CSS, pentru a oferi un aspect cât mai atrăgător pentru utilizator. Bootstrap-ul este implementat printr-un link de css și unul de js care încarcă resursa din CDN. CSS-ul este împărțit în mai multe fișiere css unde sunt scrise proprietățile și sunt incluse în pagină.

Prin selectarea unei legături din bara de meniu din susul paginii se pot afla multe informații relevante, cum ar fi secțiile spitalului cu echipele medicale din cadrul lor, specializările doctorilor, serviciile și tarifele lor și datele de contact. Toate aceste informații sunt aduse dinamic din baza de date prin Ajax cu serviciu REST astfel că orice modificare pe baza de date va fi reflectată și în pagină. Într-un fișier js este creat folosind AngularJS un modul numit mainApp la acest modul se atribuie mai multe controllere, câte un controller pe pagina adusă de UI Router. Modulul este încărcat în pagina principală numită HomePage prin directiva numită ng-app declarată în corpul paginii. În fiecare pagină rutată nu mai trebuie scrisă directive ng-controller, deoarece controlul este declarat în UI Router. Ca exemplu: .state('MainPage', { url : '/MainPage', templateUrl : './partials/partial-user-intro.jsp', controller : 'ChartController'}), care se traduce în felul următor: Pentru starea MainPage i se atribuie url-ul /MainPage cu pagina de la adresa ./partials/partial-user-intro.jsp cu controlul ChartController.

Bara de meniu din pagina principal va rămâne în acea poziție chiar dacă se va derula în jos.

Figura 6.2. Bara de meniu

În figura 6.3. se pot observa toate secțiile deținute de spital și informații generale despre ele. Fiecare are două legături către echipa medicală a secției, respectiv serviciile cu tarifele aferente prezentate sub formă de acordeon. Aceste date sunt aduse prin intermediul apelului Ajax din AngularJS. În controlul din pagină sunt definite funcții care apelează un serviciu injectat pentru a folosi apelurile Ajax prin $http. Serviciul este factory, adică întoarce un obiect și anume informațiile primite de la server. El se declară .factory(nume) și apoi este apelat de orice control prin injectarea lui în el, .controller(numeFactory).

Apelul Ajax în AngularJS se face cu $http, care este un serviciu regăsit în AngularJS, acesta face cereri http de get, put, post sau delete care vor fi preluate de serviciul REST și întors un răspuns http și un obiect de tip JSON.

Sintaxa unei funcții ar fi în felul următor:

funcție:function(){ return $http.get(url).then( function(răspuns) { return răspuns.data; }, function(eroareRăspuns) { return $q.reject(eroareRăspuns); } ); }.

În URL se pune adresa care va fi recepționată de serviciul REST, în el se pot trece și obiecte care pot fi prelucrate de serviciul REST. Dacă totul decurge bine, atunci se apelează prima funcție din $http care întoarce datele din răspuns, altfel apelează cea de-a doua funcție care trimite mesajul de eroare și http statusul.

Pe back-end serviciul REST este folosit prin adnotarea unei clase Java de control numită @RestController. Această adnotare arată că răspunsul trimis de server va fi un răspuns HTTP cu un obiect atașat în el. Această adnotare este declarată deasupra denumirii clasei. În ea se regăsesc diferite metode care tratează cererile efectuate de client prin maparea la ele url-ul din Ajax și tipul cererii. Asta se face prin scrierea deasupra metodei dorite cu adnotarea numită @RequestMapping ( value = uri, method=RequestMethod.GET/POST/PUT/DELETE)). Metoda va obține informațiile trimise de către client din uri prin adnotările @PathVariable (folosit pentru a identifica un model din uri) și @RequestBody (indică că un parametru este legat la corpul cererii http, folosit pentru aducerea de obiecte de un tip specific). Aceste metode vor întoarce un răspuns http cu date atașate de acesta.

Ca exemplu, pentru inserarea unei consultații se face cererea Ajax de tip post cu url-ul /consultatie/1 și cu un parametru atașat de url de tip Consultatie. Clasa HomePageRestController cu metoda createConsultatie() cu adnotarea deasupra metodei @RequestMapping(value="/consultatie/{idPacient}",method=RequestMethod.POST) va recepționa cererea și va lua id-ul 1 și obiectul prin declararea a doi parametri în metodă: @PathVariable("idPacient") int idPacient și @RequestBody Consultatie consultatie. Prima va lua din uri valoarea după /consultatie/ și a doua va lua obiectul atașat în cerere. Această metodă va insera obiectul prin apelarea unei metode Service numită insertConsultatie() care la rândul ei va apela o metodă DAO numită la fel. Aici ajuns, obiectul obținut de tip Consultatie este folosit într-o metodă numită create() din clasa HibernateUtil ce primește ca parametru final T entity, adică orice tip de obiect Java. Metoda va apela din sesiunea de hibernate metoda save() care o va insera în baza de date. Răspunsul trimis va fi un răspuns http cu un idFișă atașat la el. Se scrie în felul următor: return new ResponseEntity<Integer>(idFisa, HttpStatus.CREATED). În cazuri de eroare se va trimite un http status de CONFLICT care va arăta că s-a întâmplat ceva cu inserarea consultației, return new ResponseEntity<Integer>(HttpStatus.CONFLICT).

Figura 6.3. Secțiile spitalului

Dacă se apasă pe Echipă medicală se va duce pe o pagină cu toți medicii din acea secție. Aici se pot filtra medicii folosind câmpul de deasupra.

Figura 6.4. Medicii unei secții

Acest câmp este un typeahead din Bootstrap UI pentru AngularJS. Cu ajutorul acestuia se pot filtra dinamic după nume datele din pagină fără a fi nevoie de apelarea serverului, dând în același timp și sugestii pentru ceea ce scrii, asemănător cu Google Search.

Figura 6.5. Filtrare medici

Dacă în figura 6.3. se apasă Servicii și Tarife va apărea o pagină în care sunt prezentate toate serviciile la o specializare și costurile aferente acestora, tot sub formă de acordeon.

Figura 6.6. Servicii și Tarife

Pentru detalii de conectare se selectează din bara de meniu Contact, unde se găsește o hartă cu direcții către spital plus date de contact ca numărul de telefon, fax, email. Acest Google Maps a fost făcut tot prin AngularJS și anume directiva ui-gmap-google-map de la Angular UI. Această directivă primește coordonatele longitudinale și latitudinale și se va duce pe acea poziție pe hartă.

Figura 6.7. Date Contact

Pentru a accesa interfața cu utilizatorul, din pagina principală în bara de meniu se va apăsa Logare și se încearcă accesarea paginii pentru utilizator. Se pot întâmpla două lucruri: Spring Security verifică cererea de conectare la interfața cu utilizatorul și vede că nu ești autentificat și vei fi redirecționat către o pagină de logare unde vei scrie numele user-ului și parola pentru conectare. Dacă ești autentificat deja și dacă ai autorizația necesară vei fi dus la interfața cu utilizatorul.

Figura 6.8. Formular de logare

Dacă sunt introduse datele greșite se va afișa un mesaj de eroare sugestiv pentru utilizator.

Figura 6.9. Mesaj eroare logare

Dacă te-ai autentificat acum ți se va verifica autorizarea. Fiecare utilizator poate face anumite operații. Aici facem distincția majoră dintre conturi cu rol de pacient și rol de medic sau admin. Pentru pacienți operațiile de bază sunt: programarea la un medic și vizualizarea istoricului său cu tot cu documentele aferente acestora.

Figura 6.10. Interfața cu utilizatorul

Din meniul lateral se selectează din Operații legătura Programare care va aduce un formular pentru programarea la un medic. Sunt trei etape pentru o programare după cum se vede și în titlul formularului Programare Consultație: Date personale, Data și Confirmare din figura 6.11. Prima etapă este de completat cu datele personale pentru a verifica autenticitatea celui care face operația. Se va completa cu nume, prenume și opțional mail ca să poți fi notificat de programare. Aceste câmpuri sunt validate în mod dinamic prin Angular, adică se verifică dacă lungimea valorilor trecute în câmpuri este cea recomandată sau dacă nu s-a completat un câmp obligatoriu și va afișa mesaje adecvate (exemplu: Acest câmp este obligatoriu., Acest câmp este prea scurt.). Până când toate câmpurile nu sunt valide nu se poate merge mai departe în realizarea programării.

Figura 6.11. Formular de programare date personale

După completarea câmpurilor se apasă pe butonul acum abilitat Pasul următor care va duce la etapa a doua și anume Data. În această etapă se selectează doctorul la care se programează, ora la care se va efectua consultația și o mică descrie cu ce simptome suferă pacientul.

Figura 6.12. Formular de selectare data și ora programării

În primul câmp din figura 6.12 se află o listă cu toți medicii din spital. Pentru a selecta mai ușor doctorul dorit, s-a folosit UI Select. UI Select este o directivă care permite căutarea și selectarea dintr-o listă de obiecte. Căutarea este și mai ușor de realizat datorită filtrelor puse pe listă. Se poate filtra după numele medicului, după specializare sau după secție. Pe baza a ce medic se selectează se vor schimba orele disponibile pentru programare din al doilea câmp.

Al doilea câmp este folosit pentru selectarea datei și orei programării. Ținând cont că această aplicație va fi folosită de mai mulți utilizatori, mai ales pentru inserarea de programări, s-a decis folosirea unei directive de selectare dată și oră numită datetimepicker. Când se selectează un medic atunci se va aduce din baza de date orarul disponibil pentru acel doctor și va modifica lunile, zilele și orele disponibile de selectat din acest selector. Așa cum se observă în figura 5.13, care arată că programul unui medic este de luni până vineri, de la opt dimineața la 5 după-amiaza, pentru data de 21/06/2016.

Figura 6.13. Selectarea datei și orei unei programări

În al treilea câmp se va descrie simptomele de care suferă pacientul, pentru a oferi un plus de ajutor medicului în depistarea timpurie a diagnosticului corect.

În pasul următor, după toate acestea, se va ajunge la Confirmare în care se vor revizui datele selectate în etapele precedente. Dacă totul este în regulă se apasă butonul roșu Submit care va trimite cererea la doctor și pacientul va fi notificat prin email de programare.

Figura 6.14. Confirmare programare

La apăsarea butonului Submit se va insera programarea și utilizatorul este notificat printr-un mesaj. Programarea inserată de pacient are ca durată standard de timp o oră pentru consultația pacientului. Este folosită această durată de timp pentru că am decis să fie destul timp alocat unei consultații. Pot apărea situații în care consultația durează mai mult decât era prevăzut la momentul programării și va rezulta în decalarea programărilor ce urmează după aceasta și anunțați clienții de schimbarea efectuată, ceea ce produce neplăceri de ambele părți, mai ales pentru pacienți. Durata poate fi schimbată de medic dacă dorește, dar asta înseamnă că își asumă acest risc pe propria răspundere. Am ales să fie mai mult timp decât mai puțin special pentru a evita astfel de situații.

Figura 6.15. Confirmare programare mesaj

O altă operație constă în vizionarea istoricului pacientului care conține sub formă de grilă toate fișele pacientului cu toate consultațiile atribuite acestuia. Grila s-a realizat cu UI Grid. O directivă angular ce permite structurarea și manipularea datelor prezente în grilă. Se pot genera rapoarte pdf, filtra date după o anumită coloană pentru o căutare mai ușoară, paginarea datelor când este un volum mare de date, la fel cum este reprezentată ca în figura următoare.

Figura 6.16. Grilă istoric

Liniile din grila fișelor se pot extinde în sub-grile. Asta înseamnă că orice fișă a pacientului are una sau mai multe consultații. O altă operație este de deschidere a unui modal în urma apăsării rapide de două ori pe un rând din fișă. În acest modal se va arăta informațiile relative la fișă, cum ar fi serviciile folosite, data eliberării și data inserării fișei.

Figura 6.17. Modal fișă pacient

În acest modal se mai regăsește în partea superioară o legătură numită Fisă Pacient. Această legătură va aduce din baza de date documentul generat la momentul încheierii fișei pacientului. Fișa este salvată în baza de date în format binar. În urma cererii Ajax pe partea de client, serviciul REST va întoarce un răspuns http atașat cu pdf-ul în formă binară. Pe partea de client, AngularJS va transforma data din răspuns într-un tip application/pdf și se deschide o nouă fereastră documentul sub format PDF. Acest document precum și factura emisă respectă standardele documentelor folosite în spitalele și clinicele din România.

Figura 6.18. Fișă pacient

În fișă sunt trecute datele personale ale pacientului și consultațiile relative la această fișă plus serviciile efectuate pe durata fișei și costurile acestora.

În sub-grilele din fiecare fișă din figura 6.17 se poate deschide la fel modal pentru fiecare linie. Aici se regăsesc informații despre consultația respectivă, cum ar fi diagnostic, simptome, observații și ce servicii au fost efectuate și costurile lor.

Figura 6.19. Modal pentu consultații

De asemenea, se regăsește în partea superioară a modalului o legătură Factură. Acestă legătură va aduce din baza de date factura aferentă acelei consultații în același mod ca la fisa pacientului.

Figura 6.20. Factura consultațiilor

Pentru medic operațiile sunt: vizualizarea programărilor sale, modificarea sau anularea acestora, vizualizarea istoricului unui pacient și consultarea unui pacient, internarea și externarea sa în urma unei consultări, adăugarea de programări.

Toate aceste operații se învârt în jurul unui singur element și anume un calendar grafic unde se pot vizualiza programările. Calendarul este realizat tot printr-o directivă de angular numită mwl-calendar.Acesta primește evenimentele din baza de date aduse de server și le transpune grafic pe calendar. Se pot vedea evenimentele pe an, lună, săptămână sau zi. Standardul este setat pe lună.

Figura 6.21. Calendar programări

În figura 6.21 este reprezentată calendarul cu programările doctorului pe care le-a avut sau le va avea. Una din problemele întâmpinate pentru acest calendar ar fi programările făcute pe parcursul perioadei în care doctorul rămâne inactiv pe calendar și nu vede noile programări. Pentru a rezolva această problemă folosit un interval care odată la două minute va declanșa funcția de aducere a programărilor și datorită sincronizării programărilor din AngularJS cu reprezentarea lor în pagina web, calendarul se va păstra la zi cu programările.

Pentru a accesa aceste programări se apasă pe ziua marcată cu buline de diferite culori și va extinde o listă cu programările, reprezentată ca în figura 6.22.

Figura 6.22. Selectare programare

Dacă se apasă pe unul dintre evenimente se va deschide un modal cu datele despre programare, cum ar fi cine este pacientul, motivul programării, data când este programat cu data terminării consultației. Din acest modal se poate vizualiza istoricul pacientului prin apăsarea butonul Istoric care este identic cu cel explicat mai sus pentru pacient, singura diferență fiind că medicul va vedea istoricul pacienților care au efectuat consultații în secția de care aparține doctorul. Astfel se va păstra confidențialitatea doctor-pacient.

Figura 6.23. Modal programare

O programare poate fi modifică doar dacă data acesteia este mai mare decât data curentă. Prin apăsarea butonului Anulare se șterge programarea din baza de date, iar prin apăsarea butonului Modificare se actualizează data programării prin alterarea valorilor din câmpurile cu date. Ambele proprietăți vor anunța pe mail pacientul de modificarea făcută.

Odată ce un pacient vine la programare atunci doctorul îl va consulta și la sfârșit va completa un formular cu detaliile consultației prin apăsarea butonului Consultare. Acest formular trebuie să fie completat de către doctor pentru a putea încheia consultația și a genera documentele necesare.

Figura 6.24. Formular Consultație

În acest formular trebuie completate câmpurile pentru diagnostic, simptome și observații. La Servicii Efectuate se va selecta întâi specializarea doctorului, deoarece poate să aibe mai multe, apoi se va adăuga sau șterge servicii cu costul aferent prin folosirea unei directive proprii de adăugare și ștergere dinamică a unui element html.

În partea de sus a figurii se văd niște butoane radio. Acestea vor determina dacă acest pacient va fi sau nu internat. Dacă nu este internat atunci este o consultație standard și sistemul va merge mai departe și va introduce informațiile introduse de doctor. Se vor genera fișa pacientului și factura (figurile 6.18 și 6.20) asociate acestei consultații.

Dacă se va interna pacientul atunci vor apărea noi elemente ce vor trebui completate, așa ca în figura 6.25.

Figura 6.25. Internare pacient

Figura 6.26. Externare pacient

Se selectează întâi tipul internării: urgență, trimit. MF, trimit. Ambulatoriu, la cerere. Dacă este selectat urgență atunci această consultație este inclusă în internare și nu va genera la sfârșit o factură și o fișă a pacientului. După aceea se alege criteriul de internare: urgență, diagnostic, tratament, nedeplasabil, epidemiologic. Acum se va selecta și data internării pentru pacient, dacă ar fi fost selectat urgență la tip atunci data de internare ar fi fost automat setată pe data curentă și nu putea fi schimbată.

După internare, următoarele consultații pentru pacient vor avea opțiunea să externeze pacientul. Trebuie să se aleagă tipul de externare: externat, externat la cerere, transfer inter spitalicesc, decedat. La fel și starea: vindecat, ameliorat, staționar, agravat, decedat. Se va selecta data și ora externării. Dacă decedat a fost ales atunci se vor completa informații adiționale, cum ar fi tipul decesului, diagnosticul și ora decesului.

La externare se generează o factură ce va cuprinde toate serviciile efectuate pe perioada internării și o fișă a pacientului ce va cuprinde toate consultațiile de pe perioada internării. Aceste documente sunt identice ca structură cu cele prezentate în figurile 6.18 și 6.20.

O altă operație pe care o poate efectua un medic este de a adăuga noi programări, dar numai pentru el. În figura 6.21 se află în jos un buton Adaugă care va deschide un modal în care va trebui completat un formular tabular pentru a crea o nouă programare. Figurile de la 6.27 până la 6.31 vor acoperi acest caz.

Figura 6.27. Modal inserare programare

Aici se va selecta numele evenimentului, tipul (prioritatea) acestuia și o scurtă descriere a programării. După acest pas se va activa al doilea tab Pacient unde va trebui selectat un pacient.

În acest tab sunt două opțiuni pentru atribuirea unui pacient la programare: pacientul există, deci se caută dintr-o listă persoana după filtrare sau nu există, deci trebuie introdus un nou pacient prin completarea unui formular cu datele necesare.

Figura 6.28. Inserarea programare pacient existent

Figura 6.29. Inserarea programare pacient nou

După acest proces se deschide și ultimul tab Data și Ora unde se va selecta data și ora programării și data și ora când se va termina consultația. Dacă totul este valid în formular atunci se poate insera în baza de date prin apăsarea butonului de inserare, ca în figura 5.30.

Figura 6.30. Data și Ora programării inserate

Pentru a fi siguri de selecția făcută, aplicația întreabă utilizatorul pentru o ultimă dată dacă este sigur de operația ce dorește să se execute și dacă este de acord atunci se va trimite cererea la serviciul REST și o va insera în baza de date. Succesul operației se va observa direct din calendar unde se va regăsi noua programare.

Figura 6.31. Mesaj de confirmare

Pentru orice eroare ce apare între cererea Ajax și răspunsul de la serviciul REST se va notifica utilizatorul prin apariția unui mesaj de eroare sub forma Eroare <<mesaj>> Status <<http status>>, ca exemplu fiind figura 6.32.

Figura 6.32. Mesaj de eroare

Un utilizator cu rolul de admin poate să efectueze operații de modificare și actualizare a utilizatorilor, de ștergere sau adăugare de utilizatori și de gestionare a programărilor.

Datorită faptului că operațiile efectuate pe datele relative la conturi și programări sunt prezentate și gestionate într-un mod aproape identic s-a atașat o singură figură.

Figura 6.33. Tabelă gestiune conturi

Testarea aplicației

Testarea unei aplicații este o etapă importantă din procesul de implementare a unei aplicații. Aceasta presupune executarea unei părți de cod din aplicație ca să se vadă dacă au rulat corect operațiile cerute. Este folosit și cu scopul identificării bug-urilor de soft. Acest proces ajută mult dezvoltatorii în timpul implementării pentru a depista din timp problemele din cod și a le corecta. Este un proces lent ce necesită răbdare pentru a putea testa toate cazurile posibile la care se pot gândi dezvoltatorii.

Procesul folosit în acest proiect pentru testare este unit testing. Unit testing se referă la testele ce verifică funcționalitatea unei anumite porțiuni de cod. În Java, acest lucru înseamnă testarea unei clase cu metodele aferente acesteia, iar pentru Spring REST se testează controller-ul prin verificarea răspunsului http, tipul obiectului din răspuns și informațiile din obiect.

Figura 7.34. Unit Testing Spring REST

Am creat o nouă clasă Java pentru testarea a două operații din serviciul REST. Pentru a rula testele se declară adnotările: RunWith – care permite rularea testelor, ContextConfiguration – încarcă servletul de Spring pentru a putea folosi controller-ul. Am folosit MockMvc pentru a seta controller-ul ce va fi folosit într-o metodă cu adnotarea Before. Before va rula această metodă înainte de a executa metodele de test. În metodele de test adnotate cu Test se va folosi MockMvc pentru a simula o cerere din partea clientului și de a prelua răspunsul pentru verificare. În metode sa verificat că răspunsul primit este de 200 (OK) și că conținutul este de tip JSON. O altă metodă de testare este Postman, o extensie la Google Chrome, care permite la fel simularea unei cereri către serviciul REST și se verifică răspunsul primit.

Pentru verificarea funcționalității pe partea de client s-au folosit utilizatori ce au interacționat direct cu interfața. Aceștia au testat aplicația din punct de vedere al ușurinței cu care poți naviga , dacă au apărut erori sau elemente nedorite în pagini și dacă cererile făcute de ei au fost îndeplinite.

Concluzii și direcții de îmbunătățire

Într-o lume care este conectată la internet tot timpul și în care aproape nici o activitate nu poate fi rezolvată fără a se folosi de calculator, laptop, tabletă sau telefon, multe companii au început să investească în sisteme informatice, mai ales în cele web și mobile, pentru a atrage clienți prin oferirea de diverse servicii online.

La momentul actual, în domeniul medical din România sunt foarte puține sisteme de gestiune a consultărilor pacienților și de programări online a pacienților. Multe dintre acestea doar implementează un site simplist care doar descrie ce servicii pot oferi pacienților săi și oferă un număr de telefon pentru a realiza o programare la doctor. Volumul de informații îndosariate pentru pacienții consultați crește din ce în ce mai mult pe parcurs ce trece timpul, în special pentru spitalele județene sau clinicile private renumite. Căutarea unei fișe specific unui pacient în timpul consultației poate dura o perioadă foarte lungă de timp, timp în care pacientul ar fi putut primi serviciile medicale necesare pentru tratamentul acestuia.

Acest lucru este un dezavantaj imens pentru un domeniu care se află într-o societate în care toate informațiile personale sau relative la locul de muncă sunt digitalizate și prelucrate de acolo. De aceea, scopul acestei lucrări a fost de a concepe și a crea un sistem informatic de gestiune a consultărilor și facturilor într-o unitate spitalicească prin intermediul internetul.

Așa cum se observă din toate informațiile prezentate pe parcursul lucrării, sistemul realizat oferă o serie de servicii importante pentru orice spital sau clinică privată, cum ar fi: un site web modern ce este dinamic și adaptabil pe orice dispozitiv, realizarea de programări online, realizarea de consultații cu serviciile efectuate, generarea de factură și fișă a pacientului aferente consultării, internarea sau externarea unui pacient, vizualizarea online a istoricului unui pacient. Datorită volumului mare de prelucrări a datelor de natură senzitivă s-a pus un accent deosebit pe securitatea aplicației. Toate acestea duc la îmbunătățirea comunicațiilor dintre pacient și medic, micșorează complexitatea și timpul de lucru alocat completării de documente pentru pacient, căutarea unei fișe de pacient este mult mai ușoară datorită filtrelor de căutare puse.

O direcție de îmbunătățire pentru aplicație poate fi extinderea de rapoarte generate, cum ar fi analizele de laborator și vederea online ale acestora. O altă direcție ar fi verificarea aspectului aplicației pe mai multe dispozitive de diferite dimensiuni și adaptarea acestuia pentru acele dispozitive cu probleme de aspect. O ultimă îmbunătățire ar fi realizarea unei aplicații strict mobile care complimentează aplicația web.

Bibliografie

G. Vîrlan, C. M. Enache, C. G. Zamfir – Proiectarea sistemelor informatice de gestiune

Stănică Giovanna, Proiectarea sistemelor informatice

C. Frăsianu, Curs practic de Java, 2005

Novac-Ududec, C., Sisteme de operare, Editura Didactică și Pedagogică, Bucuresti, 2009

Leonard Richardson și Sam Ruby, RESTful Web Services: O'Reilly Media

K. Sierra și Bert Bates, Head First Java 2nd Edition: O'Reilly Media

Referințe web

http://www.techit.ro/tutorial_uml_3.php

https://java.com/en/download/faq/whatis_java.xml

http://javapostsforlearning.blogspot.it/2013/04/restful-web-service-tutorial.html

https://www.genuitec.com/spring-frameworkrestcontroller-vs-controller/

https://maven.apache.org/what-is-maven.html

https://docs.angularjs.org/guide/introduction

http://www.tutorialspoint.com/spring/spring_web_mvc_framework.htm

http://www.tutorialspoint.com/design_pattern/data_access_object_pattern.htm

http://docs.jboss.org/hibernate/orm/4.3/quickstart/en-US/html_single/

Anexe

Anexă 1 – Cod sursă pentru inserarea unei consultații:

Apelul Ajax prin Angular:

createConsultatieStandard:function(idPacient,consultatie){return $http.post('./consultatie/'+ idPacient, consultatie).then(function(response){return response.data;},

function(errResponse){return $q.reject(errResponse);});};

Serviciul REST:

@RestController

public class UserPageRestController {

@Autowired

private FacturaService facturaService;

@Autowired

private ConsultatieService consultatieService;

@RequestMapping(value = "/consultatie/{idPacient}", method = RequestMethod.POST)

Public ResponseEntity<Integer> createConsultatie(@PathVariable("idPacient") int idPacient, @RequestBody Consultatie consultatie) {

if (consultatie.getDiagnostic() == null || "".equals(consultatie.getDiagnostic())) {

logger.info("Consultatia nu s-a putut insera");

return new ResponseEntity<Integer>(HttpStatus.CONFLICT);

}

Authentication auth = SecurityContextHolder.getContext().getAuthentication();

CustomUser userDetails = null;

if(auth.getPrincipal() instanceof UserDetails){userDetails=(CustomUser) auth.getPrincipal();

logger.info ("User id = "+userDetails.getIdUser());}

Factura factura = facturaService.insertFactura();logger.info("Noua factura = "+factura);

consultatie.setFactura(factura);

String nume = mediciService.getNumeMedic(userDetails.getIdUser());

Int idFisa=fisaPacientService.insertFisa(idPacient, nume);

consultatie.setIdfisa(idFisa); consultatieService.insertConsultatie(consultatie);

boolean updated = fisaPacientService.inchideFisa(idPacient, idFisa);

facturaService.emitereFactura(factura, idFisa);

return new ResponseEntity<Integer>(idFisa, HttpStatus.CREATED);}}

Inserare hibernate:

public void insertConsultatie(Consultatie consultatie) {hibernateUtil.saveOrupdate(consultatie);}

Anexă 2 – Codul sursă pentru generare și afișare fișă:

Apelul Ajax prin Angular:

aduFactura: function(idPacient, idFisa) {

return $http.get('./aduFactura/'+idPacient+'/'+idFisa, { responseType: 'arraybuffer' }).then(

function(response){return response.data;},

function(errResponse){return $q.reject(errResponse);});};

Serviciul REST:

@RequestMapping(value = "/aduFactura/{idPacient}/{idFisa}", method = RequestMethod.GET, produces = "application/pdf")

public ResponseEntity<byte[]> aduFactura(@PathVariable("idPacient") int idPacient, @PathVariable("idFisa") int idFisa, HttpServletRequest request) {

byte[] outputPDF = null; Connection conn = null; HttpHeaders headers = null;

try {

try {Class.forName("com.mysql.jdbc.Driver");} catch(ClassNotFoundException e) {

logger.info("Niciun Mysql Driver prezent"); e.printStackTrace();}

conn = DriverManager.getConnection("jdbc:mysql://localhost/schema","user","parola");

if(conn != null) { logger.info("Conectat la DB.");}

HashMap<String,Object> hmParams=new HashMap<String,Object>();

hmParams.put("idPacient", idPacient); hmParams.put("idFIsa", idFisa);

String fileName = "Factura";

File reportFile = new File( request.getSession().getServletContext().getRealPath("/resources/jasper/" + fileName + ".jrxml"));

JasperReport jasperReport = JasperCompileManager.compileReport(reportFile.getPath());

JasperPrint jasperPrint = JasperFillManager.fillReport(jasperReport, hmParams, conn);

outputPDF = JasperExportManager.exportReportToPdf(jasperPrint);

if(outputPDF==null) {return new ResponseEntity<byte[]>(HttpStatus.CONFLICT);}

headers = new HttpHeaders();

headers.setContentType(MediaType.parseMediaType("application/pdf"));

DateFormat df = new SimpleDateFormat("yyyyMMdd_HH:mm:ss");

String dateFormat = df.format(new Date());

String filename = "Factura"+dateFormat+".pdf";

headers.setContentDispositionFormData(filename, filename);

facturaService.salveazaPDF(outputPDF, idFisa);

} catch (Exception sqlExp) {Logger.info( "Exceptie::" + sqlExp.toString());} finally {

try { if (conn != null) { conn.close();}} catch (SQLException expSQL) {

logger.info("SQLExp::INCHIDE::" + expSQL.toString());}}

return new ResponseEntity<byte[]>(outputPDF, headers, HttpStatus.OK);

}