Specializarea: Informatică [304055]

UNIVERSITATEA „LUCIAN BLAGA” DIN SIBIU

FACULTATEA DE ȘTIINȚE

Specializarea: Informatică

LUCRARE DE LICENȚĂ

Sibiu

2017UNIVERSITATEA „LUCIAN BLAGA” DIN SIBIU

FACULTATEA DE ȘTIINȚE

Specializarea: Informatică

Sisteme mobile de notificare și monitorizare a datelor pentru facilitarea supervizării programelor de medicamentație si nutriție

Sibiu

2017

Cuprins

Introducere 1

Contextul lucrării 1

Motivație 1

Obiective 2

Descrierea titlului 3

Structura lucrării 3

Capitolul 1. Utilitatea sistemelor mobile in supervizarea medicamentației și nutriției 4

1.1 Probleme generale în cadrul nutriției 4

1.1.1 Program și limite ale nutriției 4

1.1.2 Alimente procesate 4

1.1.3 [anonimizat] 5

1.1.4 Obezitatea 5

1.1.5 Probleme digestive și cardiovasculare 6

1.1.6 Zaharuri și grăsimi 6

1.1.7 Sodiul 6

1.1.8 Probleme respiratorii 7

1.1.9 Probleme ale sistemului nervos central 7

1.1.10 Probleme ale sistemului osos și ale pielii 7

1.2 Probleme generale în cadrul medicamentației 8

1.2.1 Efecte secundare 8

1.2.2 Alergii 8

1.2.3 Interacțiuni între medicamente 9

1.2.4 Interacțiuni cu alimente 9

1.2.5 Supradozarea 10

1.3 Asemănările si caracterul interdisciplinar ale acelor doua problematici 11

1.3.1 Caracterul interdisciplinar al lucrării prezente 11

1.3.2 Asemănările problematicilor prezentate 11

1.4 Soluția propusă în cadrul problemelor prezentate 12

1.4.1 Utilitatea și necesitatea sistemelor mobile 12

1.4.2 Arhitectura și caracteristicile platformei propuse 13

Capitolul 2. Tehnologii utilizate 15

2.1 Limbajul de programare Java 15

2.1.1 Prezentare generală 15

2.1.2 Performanță 15

2.1.3 Sintaxă 16

2.1.4 Servlet 17

2.2 Sistemul de operare Android 19

2.2.1 Prezentare generală 19

2.2.2 Arhitectura sistemului Android 20

2.2.3 Versiuni Android 22

2.2.4 Cotă de piață 26

2.3 Dezvoltare de aplicații Android 27

2.3.1 Android Studio 27

2.3.2 Android SDK 28

2.3.3 Android NDK 29

2.3.4 Gradle 29

2.3.5 Limbajul XML 30

2.4 Representational state transfer (REST) 32

2.4.1 Prezentare generală 32

2.4.2 Proprietăți arhitecturale 32

2.4.3 [anonimizat] 33

2.4.4 Formatul JSON 35

2.5 Baze de date MySQL 38

2.5.1 Prezentare generală 38

2.5.2 Limitări 39

2.5.3 Implementare 39

2.5.4 MariaDB 40

2.5.5 PhpMyAdmin 41

Capitolul 3. Prezentarea soluției 42

3.1 Descrierea arhitecturii și modulele funcționale ale soluției 42

3.1 Baza de date 44

3.2 Serverul web 52

3.3 Aplicația Android dedicată utilizatorilor 60

3.3 Aplicația Android dedicată medicilor 82

Concluzii 95

Bibliografie 95

[anonimizat]. [anonimizat], sau a activităților complexe de zi cu zi care nu lasă suficient timp pentru îngrijorare. Acest fapt este o [anonimizat] o bomba cu ceas care așteaptă să “explodeze” sub forma unor complicații majore sau chiar a unor boli grave.

Acest lucru poate fi evitat foarte ușor prin simpla vizită a [anonimizat] “vitezei” [anonimizat].

Din aceste necesități firești s-a născut și dorința mea de a crea o modalitate de a facilita cât mai rapid, in orice împrejurare posibilitatea de a stoca datele într-un loc sigur și de a le pune la dispoziția medicilor specialiști, iar soluția găsită poarta numele de “ICare”.

Motivație

Principalul aspect care a stat la baza motivației mele în cadrul proiectului ICare este reprezentat de dorința de a îmbunătății calitatea vieții umane, în special datorită stilului dezordonat de viața organismul suferă modificări care perturbă buna sa funcționare, astfel apare fenomenul de dezechilibru al organismului sau chiar îmbolnăvirea acestuia. Pentru a păstra o buna funcționare a organismului este necesară intervenția medicilor specialiști, care prin expertiza lor, reușesc sa readucă starea de echilibru a organismului, dar pentru a permite medicilor sa ofere ajutorul, aceștia au nevoie de date concrete pe care sa își bazeze diagnosticele precum și rețetele.

Astfel apare nevoia de o “instanță” mijlocitoare capabila să stocheze și să pună la dispoziție toate informațiile necesare pentru stabilirea cu exactitate a unui diagnostic de către medicii specialiști, în mod normal aceasta “instanță” sunt persoanele însăși atunci când vizitează medicul și își prezintă simptomele în scopul obținerii unui diagnostic, precum și mijloacele prin care se pot însănătoși. Dar nu întotdeauna ceea ce se transmite medicului este corect sau concret, astfel si diagnosticul medicului poate sa sufere erori considerabile. Din acest motiv se naște o altă motivație in cadrul acestei lucrări, acesta fiind înlăturarea impreciziei și incorectitudinii informațiilor prelevate către medicii specialiști.

O altă motivație este reprezentată de utilizarea sistemelor mobile deoarece “instanța” necesara pentru managementul informațiilor utile în cadrul selecției unui diagnostic favorabil de către medici trebuie să ofere posibilitatea stocării cu ușurința a datelor , dar și vizualizarea acestora într-o manieră cat mai organizată. În acest context sistemele mobile sunt fezabile pentru atingere scopului propus, deoarece sunt foarte versatile, relativ ieftine, disponibile oricui sub diferite forme in funcție de buget sau de necesități și mai ales sunt la îndemâna unui număr impresionant de utilizatori, in general sub forma unui smartphone sau a unei tablete.

Una dintre motivațiile personale este reprezentată de faptul că eu însumi întâmpin dificultăți in legătură cu prezentarea problemelor de sănătate în special datorită faptului ca nu reușesc să rețin tot ceea ce întâmpin, precum si faptul ca apelez destul de rar la un medic și în general în ultima instanța atunci când starea mea devine destul de precară.

O alta motivație personală este reprezentată de către dorința mea de a aprofunda cat mai multe cunoștințe in domeniul sistemelor mobile, bazelor de date, protocoalelor de comunicație, tehnicilor de programare, arhitecturii client-server, serviciilor web, industriei medicale, dar și dezvoltarea mea personală și profesională.

Obiective

rezolvarea problemelor de comunicare și expunerii simptomelor medicii specialiști

eliminarea distorsiunilor datelor prezentate, pentru o cat mai bună acuratețe

creșterea stării de bine și a condițiilor de viață

dezvoltarea sistemului medical pentru a avea parte de cât mai mulți beneficiari

stimularea activității medicilor prin punerea în contact cu cât mai mulți pacienți

întâmpinarea si prevenirea problemelor medicale prin consultanță specializată

formarea unor automatisme corespunzătoare pentru o stare de bine

respectarea programelor de medicamentație și nutriție date de medicii specialiști

utilizarea sistemelor mobile pentru inserarea și stocarea datelor prelevate de către utilizatori, precum și punerea lor la dispoziția medicilor pentru stabilirea tratamentului

posibilitatea vizualizării datelor cheie ale unor medicamente, sub forma de prospect, pentru a putea preveni utilizarea incorectă a acestora

înștiințarea cu privire la diferitele efecte secundare și a efectul nociv pe care îl pot avea medicamentele în contact cu alte substanțe

urmarea unor diete stricte și bine stabilite de care medicii în vederea însănătoșirii și a menținerii greutății corporale normale

propria dezvoltarea personală și profesională

posibilitatea studiului, acumulării cunoștințelor și experienței în cadrul domeniilor precum: baze de date, protocoale de comunicații, arhitectura client-server, sisteme mobile

Descrierea titlului

Titlul lucrării, “Sisteme mobile de notificare și monitorizare a datelor pentru facilitarea supervizării programelor de medicamentație și nutriție”, reprezintă modul in care sistemele mobile pot fi utilizate pentru a gestiona și monitoriza datele necesare pentru a asigura o cat mai bună funcționare a organismului uman. În acest sens concentrarea și tematica acestei lucrări de licență pică pe definirea și explicarea principalelor aspecte care duc la periclitarea stării de bine, dar și pe rezolvarea acestor intemperii propunând o soluție optimă și viabilă pentru o cât mai bună gestiune a datelor necesare stabilirii unor diagnostice și rețete, valorificând funcționalitățile, fiabilitatea, răspândirea largă și ușurința în utilizare a sistemele mobile.

Structura lucrării

În această lucrare de licență voi prezenta detaliat demersul realizării unui framework medical cu scopul de a facilita monitorizarea datelor pentru supervizarea programelor de medicamentație și nutriție prin intermediul sistemelor mobile.

Această lucrare de licență este structurată în trei capitole: utilitatea sistemelor mobile în supervizarea medicamentației și nutriției, tehnologii utilizate, prezentarea aplicației.

În cadrul primului capitol, utilitatea sistemelor mobile în supervizarea medicamentației și nutriției, sunt reliefate principalele aspecte care stau la baza necesității acestei abordări, prezentând principalele aspecte problematice care stau la baza dezechilibrelor sănătății din cadrul medicamentației si nutriției. Tot în acest capitol este reliefat și dualitatea acestora, în special asemănările și dependințele celor doua problematici, precum și soluția viabilă bazată pe utilitatea, fiabilitatea, funcționalitatea și răspândirea sistemelor mobile.

În al doilea capitol sunt prezentate principalele tehnologii utilizate în realizarea soluției pentru problemelor date. Aici sunt incluse limbaje de programare utilizate, framework-uri, medii de dezvoltare integrate, componente software, baze de date, servicii web, precum si alte tehnologii care stau la baza realizării soluției propuse.

Ultimul capitol prezintă soluția implementată pentru rezolvare problematicilor enunțate mai sus. În acest capitol se remarcă arhitectura soluției, modul de implementare, logica și funcționalitatea din spatele codului. Soluția dezvoltată este împărțita în patru componente principale: baza de date care conține informațiile prelevate de către utilizatori și de către medici, serverul web, implementat cu ajutorul servlet-urilor în cadrul unei aplicații web bazată pe limbajul Java respectând arhitectura REST, care stă la baza comunicării aplicațiilor cu interfață grafică cu baza de date, o aplicație Android dedicată utilizatorilor pentru a le permite introducerea și gestionarea datelor si, precum și o aplicație Android dedicată medicilor care le pune la dispoziție vizualizarea datelor prelevate de către utilizatorilor în vederea stabilirii tratamentelor necesare.

Capitolul 1. Utilitatea sistemelor mobile in supervizarea medicamentației și nutriției

1.1 Probleme generale în cadrul nutriției

1.1.1 Program și limite ale nutriției

În cadrul unei bune dezvoltări ale corpului omenesc precum și pentru menținerea unei stări cât mai bune de funcționare nutriția ocupă un loc fruntaș. Pentru a putea supraviețui aproape orice organism are nevoie de hrană în mod regulat, aceasta fiind combustibil pentru acel organism. Omul are nevoie în general de o program regulat al procesului de hrănire, acesta fiind reprezentat de 3 mese principale la intervale de 4-5 ore, la care se pot mai adăuga gustări în cazul în care este necesar.

În principiu omul poate supraviețui mai mult de 3 săptămâni, Mahatma Grandhi a supraviețuit 21 de zile fără nici o sursă de hrană, dar nu și fără apă. Cel puțin 60% din corpul unui adult este făcut din apă, iar fiecare celulă din corp necesită apă are nevoie de apă pentru a putea funcționa. Apa funcționează ca un lubrifiant pentru articulații, în plus reglează temperatura corpului prin transpirație și respirație și ajută la spălarea deșeurilor din organism. O persoană poate supraviețui cel mult o săptămână fără apă în anumite circumstanțe, dar în general poate rezista în jur de 3-4 zile sau 100 de ore. [1]

1.1.2 Alimente procesate

Alimentele consumate au un impact foarte important asupra organismului, în special alimentele procesate sau conservate care pot conține diferite substanțe nesănătoase sau chiar toxice. În prezent majoritatea alimentelor de pe piață sunt procesate, prea puține însă sunt disponibile în stare naturală de către producători ecologici, datorită faptului că alimentele procesate sunt mult mai ușor de produs și mult mai ieftin în comparație cu cele ecologice, de aici și diferențele relativ mari de prețuri în defavoarea alimentelor ecologice. Astfel tot mai multe alimente nesănătoase ajung pe piață, care datorită prețului scăzut și gustului artificial și alterat pentru a satisface au o foarte mare cerere și cotă de piață, însă efectele negative sunt resimțite de către consumator. Un astfel de exemplu de alimente nocive, dare care se bucură de o mare popularitate prin vânzări susținute sunt cele prelevate de industria fast-food.

1.1.3 Alimente de tip fast-food

Alimentele de tip fast-food nu sunt neapărat nepotrivite pentru organism, dar în majoritatea cazurilor sunt foarte procesate și conțin cantități mari de carbohidrați, zaharuri, grăsimi și sodiu.[2]

Deși aceste alimente au în general multe calorii, valoarea lor nutrițională este foarte mică. În cazul persoanelor cu o dietă bogată în alimente de tip fast-food, pot să apară probleme de nutriție , de sănătate și de obezitate. Testele pe animalele de laborator au arătat probleme grave și în cazul dietelor de durată scurtă bazate pe alimente de tip fast-food, chiar și acestea pot avea efecte negative asupra sănătății. [2]

În cadrul persoanelor care suferă de obezitate riscurile sunt mult mai prezente cu o varietate mult mai largă de probleme de sănătate cronice, incluzând boli de inimă, diabet și infarcturi. [2]

Potrivit fundației “Robert Wood Johnson”, majoritatea oamenilor subestimează numărul de calorii pe care le consumă într-un restaurant fast-food. Un studiu publicat în 2013 în “JAMA Pediatrics” a arătat că copiii și adolescenții iau mai multe calorii în restaurantele de fast-food și alte restaurante decât la domiciliu. Mâncarea la un restaurant a adăugat între 160 și 310 de calorii pe zi, fapt îngrijorător care poate duce cu siguranță la probleme de sănătate și obezitate. [2]

1.1.4 Obezitatea

Potrivit “Centers for Disease Control and Prevention” (CDC) definiția obezității este reprezentată de diferențele indicelui de masă al corpului (BMI). [2]

BMI (“body mass index” sau indicele de masă al corpului) este greutatea unei persoane în kilograme (kg) împărțită la înălțimea sa în metri pătrați. Institutul Național de Sănătate (NIH) definește acum greutatea normală, excesul de greutate și obezitatea, conform BMI, mai degrabă decât diagramele înălțime / greutate tradiționale. O persoană supraponderală are un BMI de 27,3 sau mai mult pentru femei și de 27,8 sau mai mult pentru bărbați. Obezitatea este un BMI de 30 sau mai mult pentru fiecare sex (aproximativ 30 de kilograme peste limită). O persoană foarte musculoasă poate avea un BMI ridicat fără riscuri pentru sănătate. [3]

Există, de asemenea, o categorie numită “obezitate extremă”, care este definită de un indice de masa BMI mai mare de 40. [2]

Coaliția de Acțiune pentru Obezitate (OAC) raportează că numărul de magazine de fast-food sa dublat față de 1970, este probabil ca mulți factori să fi contribuit la epidemia de obezitate, dar corelația dintre disponibilitatea fast-food-ului ieftin și rata de îngrășare. Obezitatea crește probabilitatea bolilor de inimă, tensiunii arteriale crescute, bolilor renale, diabetului, problemelor comune și mult mai mult. [2]

1.1.5 Probleme digestive și cardiovasculare

Multe alimente de tip fast-food și băuturi sunt încărcate cu carbohidrați și, prin urmare, o mulțime de calorii. Sistemul digestiv sparge carbohidrații în zahăr (glucoză), pe care apoi îl eliberează în sânge. Pancreasul răspunde prin eliberarea de insulină, care este necesară pentru a transporta zahărul în celulele din întregul corp. Pe măsură ce zahărul este absorbit, nivelul glicemiei scade. Când zahărul din sânge scade, pancreasul eliberează un alt hormon numit glucagon. Glucagonul îi spune ficatului să înceapă să utilizeze zaharurile stocate. [2]

Când totul funcționează în sincronizare, nivelurile de zahăr din sânge se menține într-un nivel normal. Când se introduc în cantități mari carbohidrați în organism, se provoacă o creștere a glicemiei. Aceasta poate modifica răspunsul normal la insulină. Frecvențele crescute ale zahărului din sânge pot fi un factor care contribuie la rezistența la insulină și la apariția diabetul de tip 2. [2]

1.1.6 Zaharuri și grăsimi

Zaharurile adăugate nu au valoare nutritivă, ci sunt bogate în calorii. Potrivit studiilor, majoritatea persoanelor consumă de doua ori mai mult zahar decât se recomanda pentru o sănătate optima. Toate aceste calorii suplimentare sunt răspunzătoare pentru greutatea în plus, care este un factor care contribuie la obținerea bolilor de inima și a obezității. [2]

Multe dintre grăsimile procesate nu aduc valoare nutrițională sporită și sunt considerate foarte nesănătoase, unele sunt atât de periculoase încât au fost interzise în anumite țări.
Deseori găsite în alimentele de tip fast-food, se știe că grăsimile în exces cresc nivelurile de colesterol LDL. Acesta este tipul nedorit de colesterol. Ele pot, de asemenea, să scadă colesterolul HDL, care este așa-numitul colesterol bun. Grăsimile procesate pot crește riscul de apariție a diabetului de tip 2. [2]

1.1.7 Sodiul

Sodiul în cantități ridicate duce la fenomenul numit retenție de apă, adică favorizează reținerea apei în organism, dar poate duce și la alte probleme mai grave. Favorizează apariția tensiunii arteriale și la lărgirea mușchiului inimii. În cazul în care sunt prezente în organism: probleme cu inima, boli ale rinichilor, cancer la stomac sodiul contribuie la creșterea periculoasă a lichidului în zonele afectate și implicit la apariția complicațiilor. Excesul de sodiu poate să crească riscul apariției pietrelor la rinichi, boli ale rinichilor și cancer la stomac. [2]

1.1.8 Probleme respiratorii

Obezitatea este asociată cu creșterea problemelor respiratorii. Chiar și fără afecțiuni medicale diagnosticate, obezitatea poate provoca episoade de respirație scurtă sau respirație șuierătoare de la puțin efort. Obezitatea poate juca, de asemenea, un rol în dezvoltarea apneei în cadrul somnului, o condiție în care somnul este perturbat continuu prin respirație superficială și astm. Un studiu recent publicat în revista Thorax sugerează că persoanele tinere, în general copiii care mănâncă alimente de tip fast-food de cel puțin trei ori pe săptămână prezintă un risc crescut de astm și rinită, ceea ce implică un nas înfundat și secreții. [2]

1.1.9 Probleme ale sistemului nervos central

Un studiu publicat în jurnalul “Public Health Nutrition” a arătat că consumul de produse de panificație (gogoși, cornuri și chiar brioșe de tărâțe) și alimente fast-food (pizza, hamburgerii) poate duce la depresie. Studiul a stabilit că persoanele care mănâncă alimente fast-food au cu 51% mai multe șanse de a dezvolta depresie decât cei care mănâncă puțin sau fără alimente fast-food. De asemenea, în cadrul studiului a ieșit la iveală o problemă mai gravă, cu cât participanții la studiu consumau mai multe alimente de tip fast-food cu atât creșteau șansele să dezvolte depresie. [2]

O dietă alimentară bazată pe alimente nesănătoase, potrivit unui studiu publicat în revista ”Nature”, poate de asemenea să afecteze sinapsele creierului și moleculele care stau la baza memoriei și învățării. Testele pe animale au arătat același efect, șoarecii hrăniți constant cu o dietă bazată pe mâncare nesănătoasă în care mai mult de jumătate dintre calorii erau provenite din grăsimi, după doar câteva zile au avut probleme în a rezolva labirintul pe care l-au învățat anterior într-un studiu din 2009. [2]

1.1.10 Probleme ale sistemului osos și ale pielii

Ciocolata și alimentele bogate în grăsimi sunt adesea acuzate de acnee, dar nu sunt adevărații vinovați. Potrivit clinicii Mayo, carbohidrații sunt de vină, deoarece alimentele bogate în carbohidrați cresc nivelurile de zahar din sânge, ele pot declanșa si acneea. Studiul din Thorax a arătat un risc mai mare de eczeme (inflamații, plăci iritate ale pielii) printre copiii cu o dietă bogată în fast-food. [2]

Când se consumă alimente bogate în carbohidrați și zahăr, bacteriile care locuiesc în gură produc acizi. Acești acizi pot distruge smalțul dinților, un factor care contribuie la cavitățile dentare. Atunci când smaltul dintelui este pierdut, acesta nu poate fi înlocuit. Sănătatea orală slabă a fost, de asemenea, legată de alte probleme de sănătate. Excesul de sodiu poate crește riscul de apariție a osteoporozei (oase subțiri, fragile). [2]

1.2 Probleme generale în cadrul medicamentației

1.2.1 Efecte secundare

Unele dintre principalele efecte în cadrul medicamentației foarte frecvent întâlnite sunt efectele secundare. Un efect secundar este orice alt efect care nu corespunde celui dorit. Acestea tind să fie în general ușoare, dar produc neplăceri. În unele cazuri reacțiile adverse pot fi grave, pot produce degradări ale organismului, stări de febrile, stări de vomă, complicații și pot duce chiar la moarte. [4]

Majoritatea efectelor secundare se regăsesc pe prospectele medicamentelor, deși studiile arată că tot mai puține persoane verifică prospectele înainte să folosească un medicament, ceea ce poate duce la neplăceri majore și pericole nebănuite. Medicii și specialiștii susțin că este impetuos necesară citirea cu atenție a prospectului înainte de a utiliza orice medicament pentru a putea preveni orice efect secundar nedorit și pentru a nu fi supus unor pericole mari.

Efectele secundare pot să apară la începutul, scăderea / creșterea dozei sau terminarea unui regim de medicamentație. Reacțiile adverse pot duce, de asemenea, la nerespectarea tratamentului prescris. Când efectele secundare ale unui medicament sau ale medicamentelor sunt severe, doza poate fi ajustată sau poate fi prescris un al doilea medicament. Stilul de viață sau modificările dietetice pot, de asemenea, ajuta la minimizarea efectelor secundare. [5]

1.2.2 Alergii

Alergiile apar atunci când sistemul imunitar al organismului răspunde unei substanțe pe care o consideră "invadator". Substanțele care provoacă sistemul imunitar într-un răspuns alergic sunt cunoscute sub numele de alergeni. Nu există nici un fel de alergen universal. Ceea ce ar putea declanșa un răspuns alergic care amenință viața unei persoane nu poate provoca absolut nici un rău altei persoane. [6]

Mecanismul fiziologic al reacțiilor alergice este același, la persoanele din toată lumea. Alergenii intră în corp, fie prin ingestie, inhalare sau contact cu pielea sau cu membranele mucoase. Acest lucru face ca celulele albe să elibereze un anticorp care apoi se leagă de ceea ce este cunoscut sub numele de celule mastocite. Ruptura celulelor toracice și în proces, eliberează substanțe biochimice, inclusiv histamina. [6]

Simptomele alergice ușoare includ mâncărime, ochi apoși, un nas înfundat, gât iritat și o erupție cutanată. Mai severe, simptomele alergiei care pun viața în pericol includ umflarea gâtului, respirația șuierătoare și dificultatea respirației. [6]

1.2.3 Interacțiuni între medicamente

O interacțiune medicamentoasă este o situație în care o substanță (de obicei un alt medicament) afectează activitatea unui medicament atunci când ambele sunt administrate împreună. Această acțiune poate fi sinergică (când efectul medicamentului este crescut) sau antagonistă (atunci când efectul medicamentului este scăzut) sau poate fi produs un nou efect care nu este produs de medicamentele inițiale. [7]

În mod obișnuit, interacțiunile dintre medicamente sunt prezente pe prospectele medicamentelor pentru a putea fi evitate. Cu toate acestea, pot exista și interacțiuni între medicamente și alimente, precum și medicamente și plante medicinale. Persoanele care iau medicamente antidepresive, cum ar fi inhibitorii de monoaminooxidază, nu ar trebui să ia alimente care conțin tiramină, deoarece poate apărea o criză hipertensivă (un exemplu de interacțiune medicamento-alimentară). Aceste interacțiuni pot apărea din cauza utilizării accidentale sau din cauza lipsei de cunoștințe despre ingredientele active implicate în substanțele relevante. [7]

Prin urmare, este ușor să vedem importanța acestor interacțiuni farmacologice în practica medicinei. Dacă un pacient ia două medicamente și una dintre ele crește efectul celeilalte, este posibil să apară un supradozaj. Interacțiunea dintre cele două medicamente poate, de asemenea, să crească riscul apariției efectelor secundare. Pe de altă parte, în cazul în care acțiunea unui medicament este redusă, acesta poate înceta să aibă o utilizare terapeutică datorită administrării sub doză. În ciuda celor de mai sus, ocazional aceste interacțiuni pot fi căutate pentru a obține un efect terapeutic îmbunătățit. [7]

Exemple de acest lucru includ utilizarea de codeină cu paracetamol pentru a crește efectul său analgezic. Sau combinația de acid clavulanic cu amoxicilină pentru a depăși rezistența bacteriană la antibiotic. De asemenea, trebuie reamintit faptul că există interacțiuni care, din punct de vedere teoretic, pot apărea, dar în practica clinică nu au repercusiuni importante. [7]

1.2.4 Interacțiuni cu alimente

O interacțiune între medicamente și alimente se întâmplă atunci când alimentele pe care o persoană le consumă afectează ingredientele dintr-un medicament pe care l-a luat astfel încât medicamentul să nu poată funcționa așa cum ar trebui. [8]

Interacțiunile dintre medicamente și alimente se pot întâmpla atât cu medicamentele eliberate pe bază de rețetă, cât și cu cele fără prescripție medicală, inclusiv antiacidele, vitaminele și pilulele de fier. [8]

Nu toate medicamentele sunt afectate de alimente, dar multe medicamente pot fi afectate de alimentele consumate și de perioade în care au fost consumate . De exemplu, administrarea unor medicamente în același timp în care se consumă anumite alimente poate interfera cu modul în care stomacul și intestinele absorb medicamentul. Alimentele pot întârzia sau reduce absorbția medicamentului. De aceea, unele medicamente trebuie luate pe stomacul gol (cu 1 oră înainte de a mânca sau 2 ore după masă). [8]

Pe de altă parte, unele medicamente sunt mai ușor de tolerați atunci când sunt consumate cu alimente. Adresați-vă medicului dumneavoastră sau farmacistului dacă este bine să luați medicamentul cu o gustare sau o masă sau dacă trebuie luat pe stomacul gol. [8]

1.2.5 Supradozarea

Supradozarea este un tratament medical inadecvat care apare atunci când un pacient ia medicamente inutile sau excesive. Acest lucru se poate întâmpla deoarece medicul care prescrie medicamentele nu este conștient de alte medicamente pe care pacientul le ia deja, din cauza interacțiunilor medicamentoase cu alte substanțe chimice sau cu populația țintă, din cauza erorilor umane, din cauza condițiilor medicale nediagnosticate sau din cauza conflictelor de interese din industria farmaceutică, promovarea (prin intermediul campaniilor publicitare, a vânzărilor în practica privată a medicilor sau a studiilor medicale părtinitoare sau modificate) care cauzează utilizarea inutilă a unui anumit medicament sau dozarea excesivă a unui medicament, datorită motivelor de profit excesiv din industria farmaceutică. Acest lucru este, uneori, descris ca fiind comercializarea medicamentelor. [9]

Supradozarea poate apărea, de asemenea, atunci când consumatorii iau mai multă medicamente decât este prescris sau etichetat pe produse fără prescripție medicală, fie în mod intenționat sau neintenționat, sau atunci când consumatorii iau în necunoștință de cauză atât medicamente pe bază de prescripție medicală, cât și medicamente fără prescripție medicală care conțin aceleași ingrediente active. De exemplu, medicamentul cu prescripție, cum ar fi Vicodin, care conține atât hidrocodonă, cât și acetaminofen, se poate administra împreună cu produsul Tylenol fără prescripție medicală, care conține ca substanță activă acetaminofenul, un medicament cu prescripție (sub formă de supradozaj acut). Cu alte cuvinte, supradozarea poate fi cauzată atât de medicii care prescriu medicamentele, cât și de consumatori sau de îngrijitorii acestora. [9]

Un alt exemplu important de supradozare apare atunci când consumatorii au medicamente prescrise de medici, împreună cu alte medicamente suplimentare care produc efecte terapeutice similare sau identice. De exemplu, dacă un pacient ia un medicament ibuprofen pe bază de prescripție medicală și utilizează, de asemenea, un produs de naprosyn aceasta poate constitui o supradoză, care poate fi periculoasă și poate fi costisitoare pentru pacient în costurile generale de îngrijire a sănătății. Deseori, consumatorii (pacienții) se supun la supradozare prin luarea medicamentelor la intervale mai scurte decât cele prescrise. Ca urmare, medicamentele se pot acumula la nivele mai ridicate, provocând reacții adverse nedorite, uneori grave sau chiar fatale.[9]

1.3 Asemănările si caracterul interdisciplinar ale acelor doua problematici

1.3.1 Caracterul interdisciplinar al lucrării prezente

În cadrul aceste lucrări de licență se remarcă, printre altele, și faptul că se regăsesc aspecte teoretice din cadrul mai multor discipline și arii curriculare, de aici reiese și caracterul interdisciplinar al lucrării de licență prezente.

Se remarcă integrarea cu succes a unor concepte teoretice și problematici ce țin de domeniul medical, cu ajutorul cărora se conturează o nouă abordare în vederea rezolvării impedimentelor pentru a putea prevenii și combate principalele riscuri și evenimente nedorite în cadrul programelor de medicamentație.

Un alt aspect important este reprezentat de prezentarea și integrarea multiplelor noțiuni teoretice ale problemelor generate în cadrul procesul de hrănire, aceste lucruri constituind obiectul de studiu în cadrul domeniul nutriției, care își face cu ușurință simțită prezența în această lucrare de licență.

Astfel lucrarea prezentă aduce în prin plan principalele aspecte negative regăsite în cadrul programelor de medicamentație și nutriție, prezintă și explică aceste probleme cu scopul de a propune o soluție viabilă pentru a putea reduce sau chiar înlătura efectele negative ale problemelor prezentate.

1.3.2 Asemănările problematicilor prezentate

Există și câteva similarități în ceea ce privește problemele semnalate din cadrul programelor de medicamentație și nutriție, în această ipostaza se remarcă faptul că în ambele situații, persoanele suspuse acestor programe tind să le neglijeze sau să nu le respecte conform indicațiilor medicilor specialiști. În acest sens persoanele care nu își respectă programele de medicamentație și nutriție, adeseori uită cu desăvârșire orele la care este necesar să își asimileze medicamentele, sau la care trebuie să se hrănească, cel mai adesea din cauza lipsei de timp, a rutinei zilnice tot mai încărcate, sau a situaților stresante sau critice în care efectiv respectarea programelor nu reprezintă o prioritate sau nu poate fi posibilă.

Astfel multe medicamente sunt luate fie prea devreme, fie prea târziu, efectele lor fiind accentuate sau diminuate, crescând riscul de interacțiune cu alte medicamente sau cu diverse alimente, adesea fiind accentuate efecte adverse nedorite.

Acest fapt fiind valabil și în cazul procesului de hrănire, care tinde să nu fie respectat, mesele principale ale zilei fiind luate la ore nepotrivite sau ignorate complet, fapt ce poate duce la un dezechilibru masiv al organismului.

O altă asemănare este reprezentată de faptul că în cadrul ambelor programe, persoanele vizate, tind să nu respecte cantitățile optime ale medicamentelor sau alimentelor necesare, astfel apare o serie de efecte adverse neplăcute care pot dăuna sănătății, fapt deosebit de periculos care poate duce la complicații, efecte adverse, interacțiuni nedorite între diferite medicamente, precum între medicamente și alimente.

Atât în cadrul programelor de medicamentație cât și în cadrul celor de nutriție este impetuos necesar existența unui program bine pus la punct, stabilit de medicii specialiști pentru a asigura o cât mai bună performanță în cadrul acestora, minimalizând riscurile existente.

1.4 Soluția propusă în cadrul problemelor prezentate

1.4.1 Utilitatea și necesitatea sistemelor mobile

Soluția optimă pentru rezolvarea problemelor prezentate este susținută de utilitatea sistemelor mobile. Pentru a putea preveni majoritatea problemelor care pot apărea în cadrul programelor de medicamentație și nutriție este necesară expertiza medicilor specialiști, deoarece aceștia posedă cunoștințele și expertiza necesară pentru a soluționa problemele prezente.

În acest caz pentru ca informațiile legate de starea de starea de sănătate a persoanelor în cauză să poată fi disponibile, în timp real, medicilor specialiști este impetuos necesar un sistem de gestiune informațiilor capabil să pună la dispoziție informațiile medicilor specialiști, dar care să confere și posibilitatea introducerii datelor de către utilizatori.

Pentru realizarea unei platforme cât mai versatile, cu posibilități cât mai mari de răspândire, cu un suport pe măsură, cu o disponibilitate foarte mare și cu o ușurință cât mai mare de utilizare, este nevoie de sisteme performante capabile să poată rula și susține platforma necesară, din acest punct de vedere se remarcă utilitatea sistemele mobile.

Sistemele mobile se diferențiază în special prin faptul că dețin o cotă semnificativă de piață, fapt ce contribuie la mărirea ariei de acoperire a aplicațiilor, care se bucură de un număr tot mai mare de utilizatori în fiecare zi, tot de aici se evidențiază și familiarizarea utilizatorilor cu aceste sisteme, deoarece zilnic sunt expuși la acestea în activitățile de zi cu zi.

Un criteriu foarte important în favoarea sistemelor mobile este reprezentat de portabilitatea acestora, la care se adaugă și o putere relativ mare de calcul și costurile scăzute ale multor dispozitivele mobile au atras tot mai mulți adepți, astfel un dispozitiv mobil, de tipul unui smartphone sau al unei tablete este la îndemâna oricui în fiecare moment al zilei, gata să ușureze viața utilizatorilor prin multitudinea de funții si aplicații disponibile.

1.4.2 Arhitectura și caracteristicile platformei propuse

Platforma menită să confere sistemul de gestiune al informațiilor utilizatorilor, bazată pe sistemele mobile, necesită o cât mai bună acoperire, astfel trebuie să fie disponibilă pe majoritatea sistemelor mobile actuale în funcție de popularitatea lor, astfel sisteme mobile ca Android sau IOS sunt principalele vizate datorită cotei de piață în continuă creștere, dar ți a popularității lor.

Aceeași platformă trebuie să pună la dispoziție o bază de date distribuită capabilă să stocheze toate datele necesare și care să permită accesul tuturor utilizatorilor conectați mijlocit prin intermediul altor entități, pentru a nu pune în pericol securitatea și integritatea ei prin accesul direct al unor utilizatori neavizați sau rău intenționați. Însă foarte importante sunt și capacitatea de stocare, care să suporte un număr considerabil de tabele ți înregistrări, performanța care să asigure o viteză cât mai mare de acces și de transport de date, disponibilitatea fiind obligatoriu ca aceasta să fie gata să stocheze date în fiecare moment al zilei.

În cadrul accesului mijlocit la baza de date este recomandată utilizarea unui server web, care să fie capabile sa transfere date de la utilizatori către baza de date și de la baza de date la utilizatori, într-un mod cât mai sigur, pentru a evita apariția breșelor în securitate, coruperea sau compromiterea datelor vehiculate de acestea. Alt aspect important este performanța lor, fiind necesar să poată opera la viteze cât mai mari pentru un timp de răspuns cât mai mic, un astfel de server web este bazat pe arhitectura client-server, logica fiind bazată pe cereri din partea utilizatorilor, iar pe baza acestor cereri serverul trebuie să transmită răspunsuri valide în cel mai scurt timp. Astfel necesitatea unui timp de răspuns cât mai mic este crucială ți in acest sens trebuie luate masuri optime în cadrul arhitecturii rețelelor utilizate, a volumului de date vehiculat de serverul web, fiind mult mai optimă trimiterea datelor strict necesare pentru utilizatori, astfel timpul de transfer scade în raport cu volumul de date vehiculate.

În cadrul soluției propuse un rol important îl are posibilitatea utilizatorului de a comunica cu platforma, acest lucru realizându-se în cadrul unei aplicații cu interfață grafică destinată sistemelor mobile pentru a putea facilita utilizatorului posibilitatea de a introduce, monitoriza și gestiona datele sale în scopul prezentării medicilor specialiști pentru o expertiză optimă. Această aplicație este necesar să fie prietenoasă, atractivă și ușor de utilizat pentru a putea facilita gestiunea datelor cât mai eficientă. Este necesar să pună la dispoziție funcționalități avansate pentru a permite utilizatorului să introducă, să modifice, să șteargă și să vizualizeze datele vitale pentru rezolvarea problemelor de medicamentație și nutriție enunțate anterior, dar și pentru multe altele. Datele prelevate trebuie stocate cu ajutorul serverului web în baza de date și tot prin intermediul serverului web să fie puse la dispoziția medicilor specialiști. Pentru o cât mai ușoară gestiune a lor se impune utilizarea unor opțiuni grupate pe categorii în meniuri pentru a putea naviga cu ușurință printre ele, atunci când este nevoie.

Aceste categorii trebuie să acopere a varietate de informații diferite, dar înrudite, cum ar fi diferite simptome, măsurători, medicamente, diete și multe altele pentru a putea satisface nevoile tuturor utilizatorilor.

Astfel datele prelevate de către utilizatori ajung cu succes în baza de date, unde sunt stocate în siguranță, însă aceste date pentru a putea fi valorificate se impune expunerea lor către medicii specialiști, dar pentru ca acest lucru să poată fi posibil este necesară o aplicație cu interfață grafică care să beneficieze de avantajele sistemelor mobile, pentru a permite medicilor să vizualizeze datele utilizatorilor și să le valorifice la adevărata lor valoare pentru a putea modifica în bine starea de sănătatea a utilizatorilor. În acest sens gazdele ideale pentru această aplicație sunt tot sistemele mobile.

Aplicația destinată medicilor necesită funcționalități asemănătoare cu cea a utilizatorilor, însă trebuie să pună la dispoziție un sistem de gestiune al utilizatorilor care se întâmplă sa fie pacienți ai acestor medici, trebuie să permită vizualizarea datelor pacienților, dar și adăugarea și ștergerea lor. Însă este necesar să pună în valoare datele prelevate de către utilizatori prin intermediul categoriilor dispuse în meniuri sugestive, asemenea aplicației destinate utilizatorilor, pentru a putea facilitatea rapiditatea și simplitatea gestiunii datelor, precum și inserarea datelor programelor de medicamentație și de nutriție de către medici, fiecărui pacient care, conform datelor sale, necesită aceste intervenții.

Ideal este și punerea la dispoziție a unui sistem de gestiune a acordurilor dintre medici și utilizatori, cu alte cuvinte utilizatorii trebuie să posede opțiuni specifice, în cadrul aplicației destinate pentru ei, pentru a putea decide ce medic le poate vizualiza datele, mai ales ți ce date pot aceștia să vizualizeze, precum și posibilitatea de a selecta ce medici au dreptul să le transmită date, precum programe de medicamentație și nutriție. Însă este necesar ca același sistem să fie disponibil și pentru medici în cadrul aplicației destinate lor, aceștia trebuie să profite de posibilitatea de a selecta pacienții doriți, sau posibilitatea de a seta care pacienți să posede posibilitatea de a le transmite date, ce fel de date pot să transmită, sau în cadru căror intervale se poate face transmiterea și recepționarea datelor în cauză.

Un alt aspect important ce trebuie integrat atât în cadrul aplicației destinate utilizatorilor, cât și a medicilor, este existența unui sistem de notificări care să semnaleze atât utilizatorilor cât și medicilor apariția unor evenimente, precum apariția, modificarea sau ștergerea anumitor date, precum și posibilitatea dea seta ce fel de notificări și de la cine pot să fie recepționate, sau în cadrul cărui interval orar, atât de către utilizatori cât și de către medici.

Mai concret, în cadrul aplicației destinate utilizatorilor să se primească notificări legate de programe de medicamentație și nutriție, cum ar fi orele la care trebuie satisfăcute aceste, dar și adăugări, ștergeri sau modificări de date de către medici. Iar în cazul aplicației destinate medicilor este necesar să se primească notificări de la utilizatori pentru eventualele probleme, simptome, măsurători și modificări ale stării lor de sănătate.

Indicat este și prezența unui sistem de gestiune al medicamentelor, cu posibilitatea utilizatorilor de a verifica prospecte și indicații de utilizare ale medicamentelor, dar și posibilitatea medicilor de a verifica tipul și numărul medicamentelor disponibile ale fiecărui pacient cu scopul de a le prescrie altele în prealabil în cazul în care nu sunt suficiente.

Capitolul 2. Tehnologii utilizate

2.1 Limbajul de programare Java

2.1.1 Prezentare generală

Java este un limbaj de programare cu scop general, concurent, bazat pe clase, orientat pe obiecte și conceput special pentru a avea cât mai puține dependințe de implementare. Este destinat să permită dezvoltatorilor de aplicații să "scrie o dată, să ruleze oriunde" (WORA), ceea ce înseamnă că codul Java compilat poate rula pe toate platformele care suportă Java fără a fi nevoie de recompilare. Aplicațiile Java sunt în mod obișnuit compilate la cod binar care poate rula pe orice mașină virtuală Java (JVM) indiferent de arhitectura calculatorului. Începând cu anul 2016, Java este una dintre cele mai populare limbi de programare utilizate, în special pentru aplicațiile web client-server, cu un raportor de 9 milioane de dezvoltatori. Limbajul de programare Java a fost inițial dezvoltat de James Gosling la Sun Microsystems (care a fost achiziționată de Oracle Corporation) și lansat în 1995 ca o componentă de bază a platformei Java Sun Microsystems. Limbajul derivă mult din sintaxa sa din C și C ++, dar are mai puține facilități de nivel scăzut decât oricare dintre ele. [10][11][12]

Implementarea originală și implementarea de referință a compilatoarelor Java, a mașini virtuale și a bibliotecilor de clasă au fost inițial lansate de Sun sub licențe de proprietate. Începând cu luna mai 2007, în conformitate cu specificațiile “Procesului Comunitar Java”, Sun a realizat majoritatea tehnologiilor Java în cadrul “Licenței Publice Generale GNU”. Alții au dezvoltat, de asemenea, implementări alternative ale acestor tehnologii Sun, cum ar fi compilatorul GNU pentru Java (compilator bytecode), GNU Classpath (biblioteci standard) și IcedTea-Web (plugin pentru browser în scopul creării applet-urilor). Ultima versiune este Java 8, care este singura versiune acceptată în prezent gratuit de Oracle, deși versiunile anterioare sunt acceptate atât de Oracle, cât și de alte companii pe bază comercială. [13]

2.1.2 Performanță

Programele scrise în Java au reputația de a fi mai lente și necesită mai multă memorie decât cele scrise în C ++. Cu toate acestea, viteza de execuție a programelor Java s-a îmbunătățit semnificativ odată cu introducerea compilării “just-in-time” în 1997/1998 pentru Java 1.1, plus adăugarea unor elemente de limbaj care să susțină o analiză mai bună a codului (cum ar fi clasele interioare, clasa StringBuilder, afirmațiile opționale etc. .) Și optimizări în mașina virtuală Java, cum ar fi HotSpot devenind implicit pentru JVM-ul Sun în 2000. Cu Java 1.5, performanța a fost îmbunătățită prin adăugarea pachetului java.util.concurrent, incluzând implementările Free Lock ale ConcurrentMaps și alte colecții multi-core și au fost îmbunătățite ulterior în Java 1.6. [13]

Unele platforme oferă suport hardware direct pentru Java; Există microcontrolere care pot rula Java în hardware în loc de o mașină virtuală Java software și unele procesoare bazate pe ARM ar putea avea suport hardware pentru executarea Java bytecode prin opțiunea lor Jazelle, deși suportul a fost în mare parte abandonat în implementările curente ale ARM . [13]

2.1.3 Sintaxă

Sintaxa Java este în mare parte influențată de C ++. Spre deosebire de C ++, care combină sintaxa pentru programare structurată, generică și orientată pe obiecte, Java a fost construit aproape exclusiv ca un limbaj orientat pe obiecte. Tot codul este scris în interiorul clasei și fiecare element de date este un obiect, cu excepția tipurilor de date primitive (adică numere întregi, numere cu virgulă mobilă, valori booleene și caractere), care nu sunt obiecte din motive de performanță. Java reutilizează câteva aspecte populare ale C ++ (cum ar fi metoda printf ()). [13]

Spre deosebire de C ++, Java nu suporta supraîncărcarea operatorilor sau moștenirea multiplă pentru clase, deși moștenirea multiplă este suportată pentru interfețe. Acest lucru simplifică limbajul și ajută la prevenirea potențialelor erori și a designului anti-pattern. [13]

Java utilizează comentarii similare cu cele din C ++. Există trei stiluri diferite de comentarii: un stil de linie marcat cu două slash-uri (//), un stil cu mai multe linii deschis cu / * și închis cu * /, iar stilul de comentare Javadoc a fost deschis cu / ** și închis cu * / . Stilul de comentare Javadoc permite utilizatorului să execute executabilul Javadoc pentru a crea documentația pentru program și poate fi citită de unele medii de dezvoltare integrate (IDE, mediu de dezvoltarea integrat), cum ar fi Eclipse, sau Intellij IDEA pentru a permite dezvoltatorilor să acceseze documentația din cadrul IDE. [13]

Clasicul “Hello World!” in limbajul Java poate fi remarcat în Figura 1.1.

Figura 1.1. Aplicația “Hello World!” [13]

2.1.4 Servlet

Tehnologia Java Servlet furnizează dezvoltatorilor web un mecanism simplu și consistent pentru extinderea funcționalității unui server Web și pentru accesarea sistemelor de afaceri existente. Servlet-urile sunt componente Java EE care generează răspunsuri (de obicei pagini HTML) de la server, la cereri (de obicei, solicitări HTTP) de la clienți. Un servlet poate fi considerat aproape ca un applet care rulează pe partea de server. [13]

Un exemplu de servlet care imită clasicul “Hello Word” poate fi văzut in Figura 1.2.

Figura 1.2. Exemplu Servlet “Hello Word” [13]

Instrucțiunile de import direcționează compilatorul Java să includă toate clasele publice și interfețele din pachetele java.io și javax.servlet în cadrul compilării. Pachetele fac limbajul Java potrivit pentru aplicații la scară largă. [13]

Clasa Hello din exemplul dat în Figura 1.2 extinde clasa GenericServlet, care oferă interfața pentru server pentru transmiterea cererilor către servlet și controlul ciclului de viață al servlet-ului. Clasa Hello înlocuiește metoda serviciului (ServletRequest, ServletResponse) definită de interfața Servlet pentru a furniza codul pentru dispozitivul de preluare a cererii de servicii.
Metoda service() este pasată, un obiect ServletRequest care conține cererea de la client și un obiect ServletResponse folosit pentru a crea răspunsul returnat clientului, tot metoda service() declară că aruncă excepțiile ServletException și IOException dacă o problemă o împiedică să răspundă la cerere. [13]

Metoda setContentType(String) în obiectul destinat răspunsului este chemată pentru a seta tipul de conținut MIME al datelor returnate la "text / html". Metoda getWriter() din răspunsuri returnează un obiect PrintWriter utilizat pentru a scrie datele trimise clientului. Metoda println(String) este chemată să scrie "Hello Word!" la răspuns și apoi metoda close() este chemată să închidă scriitorul de imprimare, ceea ce face ca datele care au fost scrise în flux să fie returnate clientului. [13]

Pentru a implementa și rula un servlet, trebuie folosit un container web. Un container web (cunoscut și ca un container de servlet) este, în esență, componenta unui server web care interacționează cu servlet-urile. Containerul web este responsabil pentru gestionarea ciclului de viață al servlet-urilor, maparea unei adrese URL la un anumit servlet și asigurarea faptului că solicitantul adresei URL are drepturile de acces corecte. [13]

Servlet-urile pot fi generate automat din JavaServer Pages (JSP) de către compilatorul de JavaServer Pages. Diferența dintre servlet-uri și JSP este că servlet-urile încorporează de obicei cod HTML în interiorul codului Java, în timp ce JSP-urile încorporează codul Java în HTML. În timp ce utilizarea directă a servlet-ului pentru a genera codul HTML a devenit rară, cadrul web MVC de nivel superior din Java EE (JSF) utilizează în mod explicit tehnologia Servlet pentru gestionarea solicitării / răspunsului la nivel scăzut prin FacesServlet . O utilizare oarecum mai veche constă în folosirea servlet-urilor împreună cu JSP într-un model denumit "Model 2", care este o aromă a controlerului de model-vedere. [13]

Avantajele utilizării servlet-urilor sunt: performanța lor rapidă și ușurința de utilizare, combinate cu mai multă putere peste CGI-ul tradițional (Common Gateway Interface). Scripturile tradiționale CGI scrise în Java au un număr de dezavantaje de performanță:

Atunci când se face o solicitare HTTP, se creează un nou proces de fiecare dată când este apelat scriptul CGI. Costurile asociate creării de procese pot domina volumul de lucru, mai ales atunci când scenariul face operațiuni relativ rapide. Astfel, crearea de proceselor va dura mai mult timp pentru executarea scriptului CGI. În schimb, pentru servlet, fiecare cerere este gestionată de un thread Java separat în cadrul procesului de server web, evitând astfel cheltuielile aferente proceselor de ”forking” în cadrul daemon-ului HTTP.

Cererile CGI simultane vor încărca scriptul CGI care va fi copiat în memorie câte o dată pentru fiecare cerere. Cu servlet, există o singură copie care persistă între solicitări și este împărțită între fire.

Doar o singură instanță răspunde concurent tuturor solicitărilor. Acest lucru reduce utilizarea memoriei și facilitează gestionarea datelor persistente.

Un servlet poate fi rulat de un container servlet într-un mediu restrictiv, numit sandbox. Acesta este similar cu un applet care rulează în sandbox-ul browserului web. Acest lucru permite utilizarea restricționată a servlet-urilor potențial dăunătoare . Programele CGI pot fi, desigur, și sandbox-urile, deoarece sunt pur și simplu procese de operare. [13]

Tehnologii cum ar fi FastCGI și derivatele sale (inclusiv SCGI, AJP) nu prezintă dezavantajele de performanță ale CGI, cauzate de procesul care se creează constant. Ele sunt, însă, la fel de simple ca CGI. Prin urmare acestea sunt, de asemenea, în contrast cu servlet-urile care sunt substanțial mai complexe. [13]

2.2 Sistemul de operare Android

2.2.1 Prezentare generală

Android este un sistem de operare bazat pe nucleul Linux, dezvoltat de compania Google pentru dispozitivele mobile capabile de funcționalitate touchscreen cum ar fi smartphone-uri sau tablete. Interfața grafică a sistemului de operare Android se bazează in principal pe manipularea directă, folosind gesturi tactile care corespund în mod liber acțiunilor din lumea reală, cum ar fi împingerea, atingerea și ciupirea pentru manipularea obiectelor sau a conținutului de pe ecran împreună, precum și o tastatură virtuala modificabilă pentru a facilita introducea de text. [14]

În prezent, pe lângă dispozitivele cu touchscreen, compania Google și-a extins sfera de interes in ceea ce privește distribuția sistemului de operare Android, încercând implementarea acestuia și pe alte dispozitive prin intermediul unor distribuții special create pentru a profita de noile oportunități puse la dispoziție de: televizoare inteligente cu ajutorul sistemului de operare Android TV, mașini cu ajutorul sistemului de operare Android Auto sau ceasuri inteligente cu ajutorul sistemului de operare Android Wear. [14]

Acest sistem de operare a fost inițial dezvoltat de compania Android Inc., companie care a fost ulterior cumpărată de Google. Sistemul de operare Android a fost prezentat in mod oficial publicului in anul 2007, tot atunci își făcea apariția și prima sa versiune finală, împreună cu “Open Handset Alliance”, un consorțiu de companii hardware, software și de telecomunicații dedicate avansării standardelor deschise pentru dispozitivele mobile. Începând cu prima reclama pentru dispozitivele cu Android in septembrie 2008, sistemul de operare a trecut prin multiple versiuni importante, versiunea curentă fiind 7.1.2 “Nougat” lansată în 4 aprilie 2017. Aplicațiile Andoid (“apps”) pot fi descărcate din magazinul Google Play, în care se regăsesc peste 2.7 milioane de aplicații in februarie 2017. Android este cel mai bine vândut sistem de operare pentru tablete încă din 2013 și rulează pe marea majoritate a smartphone-urilor. În mai 2017, sistemul de operare Android are parte de două miliarde de utilizatori activi lunar, fiind cel mai utilizat sistem de operare. [14]

Codul sursa al sistemului de operare Android este făcut public de Google sub licență de tip open-source, deși cele mai multe dispozitive cu Android conțin o combinație de software open-source și software patentat, incluzând software patentat necesar pentru a accesa serviciile Google. Android este preferat de companiile de tehnologie care au nevoie de un sistem de operare gata făcut, care are costuri scăzute și personalizabil pentru dispozitive performante. Datorită faptului că este open-source a încurajat o mare comunitate de dezvoltatori și entuziaști să folosească codul open-source ca o fundație pentru proiecte conduse de către comunitate, care creează actualizări pentru dispozitive mai vechi, care adaugă funcționalități noi pentru utilizatorii avansați, sau care adaugă Android unor dispozitive care nu au fost lansate cu acest sistem de operare. Datorită diversității componentei hardware care rulează sistemul Android apar întârzieri relativ mari când vine vorba de actualizări de sistem pentru trecerea la versiuni mai noi ale sistemului de operare sau în cadrul patch-urilor de securitate, fiind nevoie în mod normal de luni până sa ajungă la utilizatori, iar câteodată nu își mai fac apariția. [14]

2.2.2 Arhitectura sistemului Android

Nucleul sistemului de operare Android este bazat pe cel al sistemului de operare Linux. Din aprilie 2014, dispozitivele cu Android folosesc versiunile 3.4, 3.10 sau 3.18 ale nucleului Linux. Versiunea specifică a nucleului folosit depinde de actualul dispozitiv cu Android și de platforma sa hardware. Android a folosit versiuni variate ale nucleului încă de la versiunea 2.6.25 care a fost folosită în versiunea Android 1.0. [14]

Variația nucleului Linux în Android conține și modificări de arhitectură implementate de Google în afara ciclului e dezvoltare tipic nucleului Linux, cum ar fi includerea unor componente precum: Binder, ashmem, pmem, logger, wakelocks și manipularea în afara memoriei (OOM).

Anumite caracteristici pe care Google le-a contribuit nucleului Linux, în special o caracteristică de gestionare a puterii numita “wakelocks” , au fost respinse de dezvoltatorii nucleului principal , parțial pentru că au considerat că Google nu a intenționat să își mențină propriul cod. [14]

Spațiul de stocare flash pe dispozitivele Android este împărțit în mai multe partiții, cum ar fi “/system” pentru sistemul de operare în sine și “/data” pentru datele de utilizator și instalările aplicațiilor. În contrast cu distribuțiile Linux de tip desktop, proprietarii de dispozitive Android nu primesc acces “root” la sistemul de operare, iar părțile sensibile, cum ar fi “/system”, oferă doar posibilitatea de citire. Cu toate acestea, accesul “root” poate fi obținut prin exploatarea defectelor de securitate din Android, lucru des folosit de către comunitatea open-source pentru a spori capacitățile dispozitivelor lor, dar și de către părțile rău intenționate pentru a instala viruși și programe rău intenționate. [14]

Android este o distribuție Linux, în conformitate cu “Linux Fundațion”, șeful open-source Chris DiBona și câțiva jurnaliști. Alții, cum ar fi inginerul Google, Patrick Brady, declară că Android nu este Linux în sensul tradițional de Linux asemănător Unix. Android nu include biblioteca GNU C (folosește Bionic ca o bibliotecă alternativă C) și cateva alte componente găsite de obicei în distribuțiile Linux. [14]

Figura 2.1. Diagrama arhitecturii Android [14]

Pe partea de sus a nucleului Linux există middleware, biblioteci, API-uri scrise in C și software-ul aplicațiilor care rulează pe framework-ul aplicațiilor care include biblioteci compatibile cu Java. Dezvoltarea nucleului Linux continuă independent de bazele codului sursă ale sistemului Android. [14]

Până la versiunea 5.0, Android a folosit Dalvik ca și mașină virtuală de proces cu compilare just-in-time( JIT) bazată pe urmăriri pentru a executa Dalvik “dex-code” (Executabil Dalvik), care de obicei este tradus in Java bytecode. Urmărind principiul JIT bazat pe urme, pe lângă interpretarea majorității codului de aplicație, Dalvik efectuează compilația și execuția nativă a segmentelor de cod executate selectate (“urme”) de fiecare dată când este lansată o aplicație. Android 4.4 a introdus Android Runtime (ART) ca un mediu de rulare nou, care utilizează compilarea înainte de timp (AOT) pentru a compila în întregime bytecode-ul aplicației în cod mașină la instalarea unei aplicații. În android 4.4, ART a fost o caracteristică experimentală și nu a fost activată in mod implicit, dar a devenit singura opțiune de rulare în următoarea versiune majoră de Android, 5.0. Pentru biblioteca sa Java, platforma Android utilizează un subset al proiectului Apache Harmony, proiect întrerupt în prezent. În decembrie 2015, Google a anunțat că următoarea versiune de Android trece la o implementare Java bazată pe OpenJDK. [14]

Biblioteca standard C a sistemului Android, Bionic, a fost dezvoltată de Google în mod specific pentru Android, ca o derivare a codului librăriei standard C în cadrul BSD. Bionic în sine a fost proiectat cu câteva caracteristici majore specifice nucleului Linux. Principalele avantaje ale utilizării Bionic în locul bibliotecii GNU C (glibc) sau uClibc sunt amprenta mai mică de rulare și optimizarea procesoarelor cu frecvență joasă. În același timp, Bionic este licențiat sub licența BSD, pe care Google o consideră mai potrivită pentru modelul global de licențiere al sistemului Android.

Urmărind un model de licențiere diferit, spre sfârșitul anului 2012, Google a schimbat stiva Bluetooth în Android de la BlueZ cu licență GPL, la BlueDroid cu licență Apache. [14]

Android nu are în mod implicit un sistem nativ X Window și nici nu suportă setul complet de biblioteci standard GNU. Acest lucru a făcut dificilă transferarea aplicațiilor sau bibliotecilor existente de pe Linux către Android, până când versiunea r5 a chitului nativ de dezvoltare (NDK) a adus suport pentru aplicațiile scrise complet în C sau C++. Bibliotecile scrise în C pot fi, de asemenea, folosite în aplicații prin utilizarea JNI. [14]

De la apariția versiunii Marshmallow, “Toybox”, o colecție de utilitare la linia de comandă (mai ales pentru utilizarea ei de către aplicații, deoarece Android nu oferă o interfață pentru linia de comandă în mod implicit), a înlocuit colecția similară “Toolbox”. [14]

Android are un alt sistem de operare, Trusty OS, în cadrul acestuia, ca parte a componentelor software “Trusty” care susțin un mediu de execuție de încredere (TEE) pe dispozitivele mobile. Trusty și Trusty API pot fi modificate. Aplicațiile pentru sistemul de operare Trusty pot fi scrise în C/C++ (suportul pentru C++ este limitat) și au acces la o bibliotecă mică C. Toate aplicațiile Trusty au un singur fir de execuție, execuția pe mai multe fire de execuție în spațiul Trusty în prezent nu este suportată. Dezvoltarea aplicațiilor de la terți nu este suportat în versiunea curentă și software-ul care ruleaza pe sistemul de operare și pe procesor pentru acesta, rulează și framework-ul DRM pentru conținut protejat. Există multe alte utilizări pentru un TEE cum ar fi plățile prin telefon, securizarea bancară, criptarea completă a disk-ului, autentificarea multi-factor, protecția pentru resetarea dispozitivului, stocarea permanentă protejată prin repetare, afișarea wireless a conținutului protejat, securizarea PIN-urilor și procesarea amprentelor digitale și chiar detectarea software-ului rău intenționat. [14]

2.2.3 Versiuni Android

Istoricul versiunilor sistemului de operare Android a început cu lansarea Android Alpha în 5 noiembrie 2007. Prima versiune comercială Android 1.0 a fost lansată în septembrie 2008. Android este dezvoltat continuu de Google și de Open Handset Alliance și a văzut o serie de actualizări ale sistemului de operare de bază de la lansarea inițială. [14]

Versiunile 1.0 și 1.1 nu au fost lansate sub nume specifice de coduri. Numele de cod Android sunt legate de produse de cofetărie și au fost în ordine alfabetică începând cu 2009, Android 1.5 Cupcake, cea mai recentă versiune majoră fiind Android 7.0 Nougat, lansată în august 2016. [14]

Versiunile majore ale sistemului de operare lansate in ordine cronologica sunt:

1.0

Lansată în 23 septembrie 2008

Versiune 1.0

Nivel API 1

1.1

Lansată în 9 februarie 2009

Versiune 1.1

Nivel API 2

Cupcake

Lansată în 27 aprilie 2009

Versiune 1.5

Nivel API 3

Figura 2.2. Interfața în Android 1.5 [14]

Donut

Lansată în 15 septembrie 2009

Versiune 1.6

Nivel API 4

Figura 2.3. Interfața în Android 1.6 [14]

Eclair

Lansată în 26 octombrie 2009

Versiuni 2.0-2.1

Nivele API 5-7

Figura 2.4. Interfața în Android 2.0 [14]

Froyo

Lansată în 20 mai 2010

Versiuni 2.2-2.2.3

Nivel API 8

Figura 2.5. Interfața în Android 2.2 [14]

Gingerbread

Lansată în 6 decembrie 2010

Versiuni 2.3-2.3.7

Nivele API 9-10

Figura 2.6. Interfața în Android 2.3 [14]

Honeycomb

Lansată în 22 februarie 2011

Versiuni 3.0-3.2.6

Nivele API 11-13

Figura 2.7. Interfața în Android 3.0 [14]

Ice Cream Sandwich

Lansată în 18 octombrie 2011

Versiuni 4.0-4.0.4

Nivele API 14-15

Figura 2.8. Interfața în Android 4.0 [14]

Jelly Bean

Lansată în 9 iulie 2012

Versiuni 4.1-4.3.1

Nivele API 16-18

Figura 2.9. Interfața în Android 4.1 [14]

KitKat

Lansată în 31 octombrie 2013

Versiuni 4.4-4.4.4

Nivel API 19

Figura 2.10. Interfața în Android 4.4 [14]

Lollipop

Lansată în 12 noiembrie 2014

Versiuni 5.0-5.1.1

Nivele API 21-22

Figura 2.11. Interfața în Android 5.0 [14]

Marshmallow

Lansată în 5 octombrie 2015

Versiuni 6.0-6.0.1

Nivel API 23

Figura 2.12. Interfața în Android 6.0 [14]

Nougat

Lansată în 22 august 2016

Versiuni 7.0-7.1.2

Nivele API 24-25 [14]

Figura 2.13. Interfața în Android 7.0 [14]

2.2.4 Cotă de piață

Compania de cercetare Canalys a estimat în prima jumătate din 2009 că Android avea o cotă de 2,8% din livrările de smartphone-uri la nivel mondial. Până la sfârșitul anului 2010, acesta a crescut la 33% din piață devenind cea mai bine vândută platforma pentru smartphone-uri, depășind Symbian. Până în trimestrul al treilea al anului 2011, Gartner a estimat că mai mult de jumătate (52,5%) din vânzările de smartphone-uri au aparținut companiei Android. Până în a doua jumătate a anului 2011, Gartner a estimat că mai mult de jumătate (52,5%) din vânzările de smartphone-uri au aparținut sistemului Android. Până în a doua jumătate a anului 2012, Android a avut o cotă de 75% din piața smartphone globală, potrivit firmei de cercetare IDC. [14]

În iulie 2011, Google a declarat că 550 000 de dispozitive Android erau activate în fiecare zi, de la 400 000 pe zi în mai, iar peste 100 de milioane de dispozitive au fost activate cu o creștere de 4,4% pe săptămână. În septembrie 2012, 500 de milioane de dispozitive au fost activate cu 1,3 milioane de activări pe zi. În mai 2013, la Google I / O, Sundar Pichai a anunțat că 900 de milioane de dispozitive Android au fost activate. [14]

Cota de piață pentru Android variază în funcție de locație. În iulie 2012, "abonații cu vârsta de peste 13 ani" din Statele Unite, folosind Android, au fost de până la 52% și au crescut la 90% în China. Începând cu luna mai 2013, au fost instalate 48 de miliarde de aplicații ("apps") din magazinul Google Play și până în septembrie 2013 au fost activate un miliard de dispozitive Android. În februarie 2017, magazinul Google Play a publicat peste 2,7 milioane de aplicații Android, iar în mai 2016 aplicațiile au fost descărcate de peste 65 de miliarde de ori. [14]

Potrivit unei estimări, smartphone-urile Android au avut o bază instalată de 1,8 miliarde de unități în 2015, ceea ce reprezintă 76% din numărul total estimat de smartphone-uri din întreaga lume.[14]
Android are cea mai mare bază instalată a oricărui sistem de operare mobil și, începând cu 2013, cel mai bine vândut sistem de operare global, cu vânzări în 2012, 2013 și 2014 aproape de baza instalată a tuturor PC-urilor. În a doua jumătate a anului 2015, cota de piață globală de smartphone-uri cu Android a fost de 84,7%, cea mai mare valoare înregistrată vreodată. Începând cu data de 28 septembrie 2016, cu o cotă de piață de 52,5%, Samsung rămâne liderul pentru livrarea de smartphone-uri și tablete cu Android, urmat de LG, Huawei, Motorola, Lenovo, Sony, HTC, Asus, Alcatel și Xiaomi. [14]

Până în 2016, Android era pe majoritatea smartphone-urilor în aproape toate țările lumii, cu excepția Statelor Unite și a Canadei (incluzând continentul Americii de Nord în totalitate), Australia și Japonia. Câteva țări, cum ar fi Marea Britanie, pierd majoritatea Android dacă sunt incluse tablete. [14]
În septembrie 2015, Google a anunțat că Android avea 1,4 miliarde utilizatori activi lunar. Acest lucru s-a schimbat la 2 miliarde utilizatori lunari activi în mai 2017. [14]

2.3 Dezvoltare de aplicații Android

2.3.1 Android Studio

Android Studio este mediul oficial de dezvoltare integrat (IDE) pentru platforma Android. A fost anunțat la data de 16 mai 2013 la conferința Google I / O. [15]

Android Studio a fost în faza de acces timpuriu pornind de la versiunea 0.1 în mai 2013, apoi a intrat în etapa beta pornind de la versiunea 0.8, care a fost lansată în iunie 2014. Prima versiune stabilă a fost lansată în decembrie 2014, începând cu versiunea 1.0. Bazat pe software-ul IntelliJ IDEA de la JetBrains, Android Studio este conceput special pentru dezvoltarea de aplicații Android. Este disponibil pentru descărcare pe Windows, MacOS și Linux și a înlocuit Eclipse Android Development Tools (ADT) ca IDE primar Google pentru dezvoltarea de aplicații native Android. Interfața mediului integrat de dezvoltare Android Studio se observă în Figura 2.14. [15]

Figura 2.14. Interfața în Android Studio [16]

Funcții noi vor fi lansate cu fiecare versiune de Android Studio. Următoarele funcții sunt furnizate în versiunea stabilă actuală:

suport de construcție bazat pe Grandle

refactorizare si remedieri rapide specifice Android

Instrumente Lint pentru a rezolva probleme legate de performanța, grad de utilizare, compatibilitatea versiunilor și alte probleme

Integrare ProGuard și capabilități de semnare a aplicațiilor

Utilitare bazate pe șabloane pentru a crea desene și componente comune Android

Un editor de layout bogat, care permite utilizatorilor drag-and-drop pe componentele UI, opțiunea de a previzualiza layout-urile pe mai multe configurații de ecran

Suport pentru crearea aplicațiilor Android Wear

Suport încorporat pentru Google Cloud Platform, care permite integrarea cu Firebase Cloud Messaging ("Google Cloud Messaging") și Google App Engine

Dispozitiv virtual Android (Emulator) pentru a rula și depana aplicații [15]

2.3.2 Android SDK

Kitul de dezvoltare software Android (SDK) include un set cuprinzător de instrumente de dezvoltare. Acestea includ un program de depanare, biblioteci, un emulator de dispozitive mobile bazat pe QEMU, documentație, cod exemplu și tutoriale. Platformele de dezvoltare acceptate în prezent includ computerele care rulează Linux (orice distribuție modernă pentru Linux), Mac OS X 10.5.8 sau ulterior și Windows 7 sau o versiune ulterioară. Începând cu martie 2015, SDK nu este disponibil pe Android, însă dezvoltarea de software este posibilă prin utilizarea de aplicații Android specializate. [17]

Până la sfârșitul anului 2014, mediul de dezvoltare integrat suportat oficial (IDE) a fost Eclipse utilizând pluginul Android Development Tools (ADT), deși IntelliJ IDEA IDE (toate edițiile) suportă pe deplin dezvoltarea Android, iar NetBeans IDE suportă, de asemenea, Dezvoltare Android prin intermediul unui plugin. Începând cu 2015, Android Studio, produs de Google și bazat pe IntelliJ, este IDE-ul oficial. Totuși, dezvoltatorii sunt liberi să utilizeze alte medii de dezvoltare, însă Google a făcut clar faptul că ADT a fost oficial anulat de la sfârșitul anului 2015 pentru a se concentra pe Android Studio ca Android IDE oficial. În plus, dezvoltatorii pot folosi orice editor de text pentru a edita fișiere Java și XML, apoi să utilizeze instrumentele din linia de comandă (Java Development Kit și Apache Ant sunt necesare) pentru a crea, a construi și a depana aplicații Android, precum și pentru a controla dispozitive Android atașate. [17]
Îmbunătățirile pentru SDK-ul Android merg concomitent cu dezvoltarea generală a platformei Android. SDK acceptă, de asemenea, versiuni mai vechi ale platformei Android în cazul în care dezvoltatorii doresc să vizeze aplicațiile lor la dispozitive mai vechi. Instrumentele de dezvoltare sunt componente care pot fi descărcate, astfel încât, după descărcarea ultimei versiuni și platformă, platformele și instrumentele mai vechi pot fi descărcate și pentru testarea compatibilității. [17]

Aplicațiile Android sunt disponibile în format .apk și stocate în folderul /data/app în sistemul de operare Android (folderul este accesibil numai utilizatorilor de tip administrator din motive de securitate). Pachetul APK conține fișiere .dex (fișiere de coduri byte compilate executabile Dalvik), fișiere de resurse etc. [17]

2.3.3 Android NDK

Bibliotecile scrise în C, C ++ și alte limbaje pot fi compilate în codul nativ ARM, MIPS sau x86 și sunt instalate utilizând kitul nativ de dezvoltare Android (NDK). Aceste biblioteci native pot fi folosite în cod Java care rulează sub Dalvik VM utilizând apelul System.loadLibrary, care face parte din clasele standard Java din Android. [17]

Aplicații complete pot fi compilate și instalate utilizând instrumentele de dezvoltare tradiționale. Cu toate acestea, conform documentației Android, NDK nu ar trebui să fie folosit exclusiv pentru că dezvoltatorul preferă să programeze în C / C ++, deoarece utilizarea NDK crește complexitatea, în timp ce majoritatea aplicațiilor nu ar beneficia de utilizarea acestuia. [17]

Debugger-ul ADB oferă un root shell sub Emulator Android, care permite încărcarea și executarea codului nativ ARM, MIPS sau x86. Codul nativ poate fi compilat folosind GCC sau compilatorul Intel C ++ pe un PC standard. Rularea codului nativ este complicată de utilizarea de către Android a unei biblioteci C non-standard (libc, cunoscută sub numele de Bionic). [17]

Debugger-ul ADB oferă suport pentru emulatorul Android, care permite încărcarea și executarea codului nativ ARM, MIPS sau x86. Codul nativ poate fi compilat folosind GCC sau compilatorul Intel C ++ pe un PC standard. Rularea codului nativ este complicată datorită utilizării de către Android a unei biblioteci non-standard de C (libc, cunoscută sub numele de Bionic). Biblioteca grafică utilizată de Android pentru a arbitra și a controla accesul la acest dispozitiv se numește Skia Graphics Library (SGL) și a fost lansată sub licență open source. Skia are backend-uri pentru Win32 și Unix, permițând dezvoltarea de aplicații multi-platformă și este motorul grafic care stă la baza browserului web Google Chrome. [17]

Este posibilă să utilizarea Android Studio cu Gradle pentru a dezvolta proiecte bazate pe NDK. Alte instrumente ale unor parți terțe permit integrarea NDK în Eclipse și Visual Studio. [17]

2.3.4 Gradle

Gradle este un sistem de construcție automatizat de tip open source care se bazează pe conceptele Apache Ant și Apache Maven și introduce un limbaj specific domeniului Groovy (DSL) în locul formularului XML folosit de Apache Maven pentru declararea configurației proiectului. Gradle utilizează un graf aciclic direcționat ("DAG") pentru a determina ordinea în care pot fi executate sarcini. [18]

Gradle a fost proiectat pentru construirea mai multor proiecte care pot crește la dimensiuni destul de mari și sprijină construirea incrementală prin determinarea inteligentă a părților din “build tree” până la data actuală, astfel încât orice sarcină care depinde de aceste părți nu va trebui să fie reexecută. Plugin-urile inițiale sunt concentrate în primul rând în jurul dezvoltării și implementării Java, Groovy și Scala. [18]

2.3.5 Limbajul XML

Extensible Markup Language (XML) este un limbaj de tip markup care definește un set de reguli pentru codificarea documentelor într-un format care poate fi citit de om și poate fi citit de mașină. Un exemplu de document XML este vizibil în Figura 2.15. [19]

Figura 2.15. Exemplu de document XML [19]

Obiectivele de proiectare ale XML subliniază simplitatea, generalitatea și utilitatea pe Internet. Este un format de date textual cu suport puternic prin intermediul Unicode pentru diferite limbaje umane. Deși proiectarea XML se concentrează pe documente, limbaul este folosită pe scară largă pentru reprezentarea structurilor de date arbitrare, cum ar fi cele utilizate în serviciile web. Există mai multe sisteme schematice care ajută la definirea limbajelor bazate pe XML, în timp ce programatorii au dezvoltat numeroase interfețe de programare a aplicațiilor (API) pentru a ajuta la prelucrarea datelor XML. [19]

Terminologii și componente în cadrul limbajului XML:

Caracter: Un document XML este un șir de caractere. Aproape fiecare caracter acceptat de Unicode poate apărea într-un document XML.

Procesor și aplicație: Procesorul analizează marcajul și transmite informații structurate unei aplicații. Specificația plasează cerințe privind ceea ce un procesor XML trebuie să facă și ceea ce nu trebuie să facă, dar aplicația este în afara domeniului său de aplicare. Procesorul (așa cum îl numește specificația) este adesea referit în mod colocvial ca un parser XML.

Marcaj și conținut: Caracterele care compun un document XML sunt împărțite în marcaj și conținut, care se pot distinge prin aplicarea regulilor simple sintactice. În general, șirurile care constituie marcare fie încep cu caracterul < și se termină cu un caracter >, fie încep cu caracterul & se termină cu caracterul ;. Șirurile de caractere care nu sunt marcate sunt de tip conținut. Cu toate acestea, într-o secțiune CDATA, delimitatorii <! [CDATA [ și ]]> sunt clasificați ca marcaj, în timp ce textul dintre acestea este clasificat drept conținut. În plus, spațiile libere înainte și după cel mai exterior element sunt clasificate ca marcaje.

Etichetă (Tag): O etichetă este o construcție de tip marcaj care începe cu caracterul < și se termină cu caracterul >. Etichetele vin în trei forme: etichetă de început, cum ar fi < secțiune >, etichetă de sfârșit, cum ar fi < / secțiune >, etichetă de tip element gol, cum ar fi < line-break >,

Element: Un element este o componentă a unui document logic care începe fie cu o etichetă de început și se termină cu o etichetă de finală potrivită, fie constă doar dintr-o etichetă cu element gol. Caracterele dintre eticheta de început și eticheta de final, dacă există, sunt conținutul elementului și pot conține marcaje, inclusiv alte elemente, numite elemente copil.

Atribut: Un atribut este un constructor de marcaje constând dintr-o pereche de nume / valoare care există într-o etichetă de început sau etichetă cu element gol. Un atribut XML poate avea o singură valoare și fiecare atribut poate apărea cel mult o dată pe fiecare element. În situația obișnuită în care este dorită o listă de valori multiple, aceasta trebuie făcută prin codificarea listei într-un atribut XML bine format cu un format dincolo de ceea ce XML definește. De obicei, aceasta este o listă delimitată cu virgulă, cu punct și virgulă sau, dacă se știe că valorile individuale nu conțin spații, poate fi utilizată o listă delimitate cu spații.

Declarația XML: Documentele XML pot începe cu o declarație XML care descrie unele informații despre ele însele, de exemplu: <? Xml version = "1.0" encoding = "UTF-8"?>.

Comentarii: Comentariile pot apărea oriunde într-un document în afara elementelor de marcaj. Comentariile nu pot apărea înainte de declarația XML. Comentariile încep cu <! – și se termină cu ->. Pentru compatibilitatea cu SGML, șirul "–" (dublu-cratimă) nu este permis în interiorul comentariilor; aceasta înseamnă că comentariile nu pot fi imbricate. Ampersandul nu deține semnificații speciale în cadrul comentariilor, astfel încât referințele entității și caracterelor nu sunt recunoscute ca atare și nu există modalități de a reprezenta caracterele în afara setului de caractere al codificării documentului. [19]

2.4 Representational state transfer (REST)

2.4.1 Prezentare generală

“Representational state transfer” (REST) ​​sau “RESTful Web Services” reprezintă o modalitate de a asigura interoperabilitatea între sistemele informatice de pe Internet. Serviciile web compatibile cu REST permit sistemelor solicitante să acceseze și să manipuleze reprezentările textuale ale resurselor web folosind un set uniform și predefinit de operații. Există și alte forme de servicii web care își expun propriile seturi de operații, cum ar fi WSDL și SOAP. [20]

"Resursele web" au fost definite pentru prima dată pe World Wide Web ca documente sau fișiere identificate prin adresele lor URL, dar astăzi au o definiție mult mai generică și abstractă care cuprinde toate lucrurile sau entitățile care pot fi identificate, numite, adresate sau manipulate, în orice caz, pe Web. Într-un serviciu web RESTful, solicitările făcute către un URI al unei resurse vor genera un răspuns care ar putea fi în XML, HTML, JSON sau în alt format definit. Răspunsul poate confirma că s-a făcut o modificare a resursei stocate și poate furniza legături hypertext la alte resurse sau colecții de resurse conexe. Folosind HTTP, după cum este cel mai frecvent, tipul de operațiuni disponibile include cele predefinite de verbele HTTP GET, POST, PUT, DELETE și așa mai departe. [20]

Folosind un protocol fără statură și operațiuni standard, sistemele REST urmăresc performanța, fiabilitatea și capacitatea de creștere rapidă prin reutilizarea componentelor care pot fi gestionate și actualizate fără a afecta sistemul în ansamblul său, chiar și în timp ce rulează. [20]
Termenul transfer de stat reprezentativ a fost introdus și definit în anul 2000 de Roy Fielding în disertația sa de doctorat. Fielding a folosit REST pentru a proiecta HTTP 1.1 și identificatori de resurse uniforme (URI). Termenul are ca scop evocarea unei imagini a modului în care se comportă o aplicație web bine concepută: este o rețea de resurse web (o mașină virtuală de stat) în care utilizatorul avansează prin aplicație, selectând linkuri, cum ar fi /user/tom, sau operații cum ar fi GET sau DELETE (tranziții de stare), rezultând că resursa următoare (reprezentând următoarea stare a aplicației) este transferată utilizatorului pentru utilizarea ei. [20]

2.4.2 Proprietăți arhitecturale

Proprietățile arhitecturale afectate de constrângerile stilului arhitectural REST sunt:

Interacțiunile de tipul performanță-componente pot fi factorul dominant în performanța percepută de utilizator și eficiența rețelei

Scalabilitate pentru a suporta un număr mare de componente și interacțiuni între componente. Roy Fielding, unul dintre principalii autori ai caietului de sarcini HTTP, descrie efectul REST asupra scalabilității după cum urmează: separarea de preocupări în cadrul arhitecturii client-server a serviciilor REST simplifică implementarea componentelor, reduce complexitatea semanticii conectorilor, îmbunătățește eficacitatea reglării performanței și mărește scalabilitatea componentelor serverului pur. Constrângerile de sistem stratificate permit intermediarilor, de exemplu, proxy-urilor, gateway-urilor și firewall-urilor să fie introduse în diferite puncte ale comunicării fără a schimba interfețele dintre componente, permițându-le astfel să asiste în traducerea comunicării sau să îmbunătățească performanța prin cache-ul la scară largă.
REST permite procesarea intermediară prin constrângerea mesajelor să fie auto-descriptivă: interacțiunea este lipsită de statură între solicitări, metodele standard și tipurile de suporturi media sunt utilizate pentru a indica semantica și schimbul de informații.

Simplitatea unei interfețe uniforme

Modificabilitatea componentelor pentru a răspunde nevoilor în schimbare (chiar și în timp ce aplicația rulează

Vizibilitatea comunicării între componente prin intermediul agenților de servicii

Portabilitatea componentelor prin mutarea codului de program cu datele aferente

Fiabilitatea este rezistența la defecțiuni la nivelul sistemului în prezența unor defecțiuni în componente, conectori sau date [20]

2.4.3 Modelul Client-server

Primele constrângeri adăugate acestui stil hibrid sunt cele ale stilului arhitectural client-server. Separarea preocupărilor este principiul din spatele constrângerilor client-server. Prin separarea preocupărilor legate de interfața cu utilizatorul de problemele de stocare a datelor, îmbunătățim portabilitatea interfeței cu utilizatorul pe mai multe platforme și se îmbunătățește scalabilitatea prin simplificarea componentelor serverului. Poate că cel mai semnificativ pentru web este totuși faptul că separarea permite componentelor să evolueze independent, sprijinind astfel cerința pe scară largă pe internet a mai multor domenii organizaționale. [20]

Modelul client-server este o structură distribuită a aplicațiilor care împarte sarcini de lucru între furnizorii unei resurse sau servicii, numite servere și solicitanți de servicii, numiți clienți. Deseori, clienții și serverele comunică printr-o rețea de calculatoare pe hardware separat, dar atât clientul, cât și serverul pot locui în același sistem. O gazdă de server rulează unul sau mai multe programe server care împărtășesc resursele lor clienților. Un client nu împărtășește nici una dintre resursele sale, ci solicită o funcție de conținut sau de serviciu a unui server. Prin urmare, clienții inițiază sesiuni de comunicare cu servere care așteaptă cererile primite. Exemple de aplicații informatice care utilizează modelul client-server sunt E-mail, imprimare în rețea și World Wide Web. [21]

Caracteristica client-server descrie relația programelor care cooperează într-o aplicație. Componenta server oferă o funcție sau un serviciu unui sau mai multor clienți, care inițiază cereri pentru astfel de servicii. [21]

Serverele sunt clasificate după serviciile pe care le furnizează. De exemplu, un server web servește pagini web și un server de fișiere servește fișiere de calculator. O resursă partajată poate fi orice software și componente electronice ale computerului serverului, de la programe și date la procesoare și dispozitive de stocare. Partajarea resurselor unui server constituie un serviciu.
Indiferent dacă un computer este un client, un server sau ambele, este determinat de natura aplicației care necesită funcțiile de serviciu. De exemplu, un singur computer poate rula serverul și softul de fișiere al serverului pentru a pune la dispoziție diferite date clienților care
transmit diferite cereri la server. Software-ul clientului poate comunica, de asemenea, cu software-ul de tip server în cadrul aceluiași computer. Comunicarea între servere, cum ar fi sincronizarea datelor, este uneori numită comunicare inter-server sau server-to-server. [21]

În general, un serviciu este o abstractizare a resurselor de calcul și un client nu trebuie să se preocupe cu modul în care serverul efectuează în timp ce îndeplinește cererea și transmite răspunsul. Clientul trebuie doar să înțeleagă răspunsul bazat pe protocolul bine cunoscut al aplicației, adică conținutul și formatarea datelor pentru serviciul solicitat. [21]

Clienții și serverele fac schimb de mesaje într-un model de mesagerie cerere-răspuns. Clientul trimite o solicitare, iar serverul returnează un răspuns. Acest schimb de mesaje este un exemplu de comunicare între procese. Pentru a comunica, computerele trebuie să aibă un limbaj comun și trebuie să respecte reguli, astfel încât atât clientul, cât și serverul să știe ce să aștepte. Limbajul și regulile de comunicare sunt definite într-un protocol de comunicații. Toate protocoalele client-server funcționează în stratul de aplicație. Protocolul stratului de aplicație definește tiparele de bază ale dialogului. Pentru a formaliza și mai mult schimbul de date, serverul poate implementa o interfață de programare a aplicațiilor (API). API este un strat de abstractizare pentru accesarea unui serviciu. Prin limitarea comunicării la un anumit format de conținut, facilitează analiza. Prin abstractizarea accesului, facilitează schimbul de date între platforme. [21]

Un server poate primi solicitări de la mai mulți clienți distinși într-o perioadă scurtă de timp. Un computer poate efectua numai un număr limitat de sarcini în orice moment și se bazează pe un sistem de planificare pentru a acorda prioritate cererilor primite de la clienți pentru a le acomoda. Pentru a preveni abuzurile și a maximiza disponibilitatea, software-ul serverului poate limita disponibilitatea clienților. Refuzurile unor atacuri ale serviciilor sunt concepute pentru a exploata obligația unui server de a procesa cererile prin supraîncărcarea acestuia cu rate excesive de solicitare. [21]

2.4.4 Formatul JSON

JSON (JavaScript Object Notation) este un format ușor de schimb de date. Este ușor pentru oameni să citească și să scrie. Este ușor pentru mașini să parseze și să genereze. Se bazează pe un subset al limbajului de programare JavaScript. JSON este un format text complet independent de limbăj, dar utilizează convenții care sunt familiare programatorilor familiei de limbaje C, inclusiv C ++, C #, Java, JavaScript, Perl, Python și multe altele. Aceste proprietăți fac din JSON un limbaj ideal de schimb de date. [22]

JSON este construit pe două structuri:

O colecție de perechi de nume / valoare. În diverse limbaje, acest lucru este realizat ca un obiect, record, struct, dicționar, tabelă hash, listă cu chei sau matrice asociativă.

O listă ordonată de valori. În majoritatea limbajelor, acest lucru este realizat ca o matrice, vector, listă sau secvență. [22]

Acestea sunt structuri de date universale. Practic, toate limbajele de programare moderne le susțin într-o formă sau alta. Are sens că un format de date care este interschimbabil cu limbajele de programare să se bazează, de asemenea, pe aceste structuri. [22]

În JSON, acestea pot avea următoarele forme:

Un obiect, care este un set neordonat de perechi de nume / valoare. Un obiect începe cu { (acoladă deschisă la stânga) și se termină cu } (acoladă închisă la dreapta). Fiecare nume este urmat de : (două puncte) și perechile nume / valoare sunt separate prin , (virgulă). Un exemplu este vizibil în Figura 2.16. [22]

Figura 2.16. Obiectul în format JSON [22]

Un vector, care este o colecție ordonată de valori. Un vector începe cu [ (paranteză pătrată deschisă la stânga) și se termină cu ] (paranteză pătrată închisă la dreapta). Valorile sunt separate prin , (virgulă). Un exemplu este vizibil în Figura 2.17. [22]

Figura 2.17. Vectorul în format JSON [22]

O valoare poate fi un șir între ghilimele duble, un număr, adevărat sau fals, nul, un obiect sau un vector. Aceste structuri pot fi imbricate. Un exemplu este vizibil în Figura 2.18. [22]

Figura 2.18. O valoare în format JSON [22]

Un string, care este o secvență de caractere de zero sau mai multe caractere Unicode, înfășurate în ghilimele duble, utilizând escape-uri de tip backslash. Un caracter este reprezentat ca string de dimensiune un caracter. Un string în JSON este foarte asemănător unui string din C sau Java. Un exemplu este vizibil în Figura 2.19. [22]

Figura 2.19. String în format JSON [22]

Un număr, care este foarte asemănător unui număr din C sau Java, cu excepția faptului că nu se utilizează formatele octale sau hexazecimale. Un exemplu este vizibil în Figura 2.20. [22]

Figura 2.20. Număr în format JSON [22]

2.5 Baze de date MySQL

2.5.1 Prezentare generală

MySQL este un sistem de gestionare a bazelor de date relaționale open-source (RDBMS). Numele este o combinație între "My", numele fiicei cofondatorului Michael Widenius și "SQL", abrevierea pentru Language Structured Query. Proiectul de dezvoltare MySQL și-a făcut disponibil codul sursă în termenii Licenței Publice Generale GNU, precum și în baza a numeroase acorduri de proprietate. MySQL a fost deținut și sponsorizat de o singură firmă cu scop lucrativ, compania suedeză MySQL AB, deținută acum de Oracle Corporation. Pentru uz propriu, sunt disponibile mai multe ediții plătite și oferă funcționalități suplimentare. [23]

MySQL este o componentă centrală a pachetului LAMP open-source pentru aplicații web (și alte stive "AMP"). LAMP este un acronim pentru "Linux, Apache, MySQL, Perl / PHP / Python". Aplicațiile care utilizează baza de date MySQL includ: TYPO3, MODx, Joomla, WordPress, phpBB, MyBB și Drupal. MySQL este, de asemenea, utilizat în numeroase site-uri de înaltă profil, inclusiv Google (deși nu pentru căutări), Facebook, Twitter, Flickr și YouTube. [23]

MySQL este scris în C și C ++. Parserul său SQL este scris în yacc, dar utilizează un analizor lexical de origine. MySQL funcționează pe multe platforme de sistem, inclusiv AIX, BSDi, FreeBSD, HP-UX, eComStation, i5 / OS, IRIX, Linux, MacOS, Microsoft Windows, NetBSD, Novell NetWare, OpenBSD, OpenSolaris, OS / 2 Warp, QNX, Oracle Solaris, Symbian, SunOS, SCO OpenServer, SCO UnixWare, Sanos și Tru64. Există, de asemenea, un port de MySQL la OpenVMS. [23]

Software-ul de servere MySQL în sine și bibliotecile clienților utilizează distribuția cu licență dublă. Acestea sunt oferite în versiunea 2 GPL, începând cu 28 iunie 2000 (care a fost extinsă în 2009 cu o excepție de licență FLOSS) sau pentru a utiliza o licență de proprietate. [23]

Sprijin poate fi obținut din manualul oficial. Suportul gratuit este disponibil în diferite canale și forumuri IRC. Oracle oferă suport plătit prin intermediul produselor sale MySQL Enterprise. Acestea diferă în ceea ce privește domeniul serviciilor și prețurile. În plus, există o serie de organizații terțe care oferă asistență și servicii, inclusiv MariaDB și Percona. [23]

MySQL a primit recenzii pozitive, iar recenzenții au observat că aceasta "se comportă extrem de bine în cazul mediu" și că "interfața pentru dezvoltatori este acolo, iar documentația (ca să nu mai vorbim de feedback-ul în lumea reală prin intermediul site-urilor Web și altele asemenea) este foarte bună". De asemenea, a fost testat pentru a fi un "server de baze de date SQL rapid, stabil, cu adevărat multi-user și multi-threaded ". [23]

2.5.2 Limitări

Atunci când se utilizează unele motoare de stocare, altele decât cele implicite ale InnoDB, MySQL nu respectă standardul complet SQL pentru unele dintre funcționalitățile implementate, inclusiv referințe la chei străine și constrângeri de verificare. [23]

Până la MySQL 5.7, declanșatoarele sunt limitate la câte unul pe acțiune / sincronizare, ceea ce înseamnă că cel mult un declanșator poate fi definit ca executat după o operație INSERT și una înainte de INSERT pe același tabel. Nu pot fi definiți declanșatori pe views. [23]

Funcțiile de bază ale bazei de date MySQL precum UNIX_TIMESTAMP() vor reveni la 0 după 03:14:07 UTC la 19 ianuarie 2038. [23]

2.5.3 Implementare

MySQL poate fi construit și instalat manual din codul sursă, dar este mai frecvent instalat dintr-un pachet binar dacă nu sunt necesare personalizări speciale. În majoritatea distribuțiilor Linux, sistemul de gestionare a pachetelor poate descărca și instala MySQL cu un efort minim, deși este necesară adesea o configurare suplimentară pentru a ajusta setările de securitate și optimizare. [23]

Figura 2.21. Componentele software LAMP [23]

Deși MySQL a început ca o alternativă low-end la bazele de date mai puternice, a evoluat treptat pentru a susține și nevoile la scară mai largă. Acesta este încă cel mai frecvent utilizat în implementări single-server pe scară mică sau medie, fie ca o componentă într-o aplicație Web bazată pe LAMP (ale cărui componente software pot fi remarcate in Figura 2.21), fie ca server de bază de date autonom. O mare parte din atractivitatea oferit de MySQL provine din simplitatea sa relativă și ușurința de utilizare, care este permisă de un ecosistem de instrumente open source cum ar fi phpMyAdmin. În gama medie, MySQL poate fi scalată prin implementarea pe un hardware mai puternic, cum ar fi un server multiprocesor de capacitate mare. [23]

Există, totuși, limite în ce măsură performanța poate fi scalată pe un singur server ("scaling up"), astfel încât pe scalări mai mari, implementările MySQL ("scaling out") multi-server sunt necesare pentru a oferi performanțe și fiabilitate îmbunătățite. O configurație tipică de tip high-end poate include o bază de date puternică care gestionează operațiile de scriere a datelor și este reprodusă mai multor servere care manipulează toate operațiile de citire. Serverul principal împinge în mod continuu evenimente binlog la serverele conectate, astfel încât, în caz de eșec, un server poate fi promovat pentru a deveni noul server principal, minimizând timpul de nefuncționare. Îmbunătățiri suplimentare în performanță pot fi obținute prin reținerea rezultatelor din interogările bazei de date din memorie sau descompunerea unei baze de date în bucăți mai mici numite shards care pot fi răspândite pe mai multe clustere ale serverelor distribuite. [23]

2.5.4 MariaDB

MariaDB este o ramificație dezvoltată în comunitate a sistemului de gestionare a bazelor de date relaționale MySQL destinat să rămână liber sub GNU GPL. Fiind o raificație a unui sistem software open source, este remarcabil că este condus de dezvoltatorii originali ai MySQL, care l-au scos din cauza preocupărilor legate de achiziția sa de către Oracle. [23]

Colaboratorii trebuie să-și împărtășească drepturile de autor cu Fundația MariaDB. MariaDB intenționează să mențină compatibilitate ridicată cu MySQL, asigurând o capacitate de înlocuire "drop-in" cu echivalența binară a bibliotecii și potrivirea exactă cu API-urile și comenzile MySQL. Există însă unele diferențe și incompatibilități documentate între versiunile MySQL și MariaDB, iar unele instrumente pentru interacțiunea cu MySQL, cum ar fi MySQL Workbench,
nu sunt pe deplin compatibile cu MariaDB. [23]

Acesta include motorul de stocare XtraDB pentru înlocuirea lui InnoDB, precum și un nou motor de stocare, Aria, care intenționează să fie atât un motor tranzacțional, cât și un motor non-tranzacțional, chiar inclus în viitoarele versiuni ale MySQL. [23]

2.5.5 PhpMyAdmin

În ingineria software, o ramificație a unui proiect se întâmplă atunci când dezvoltatorii iau o copie a codului sursă dintr-un singur pachet software și încep să dezvolte o dezvoltare independentă, creând un software distinct și separat – o versiune nouă (parte terță). Termenul implică deseori nu doar crearea unei ramuri de dezvoltare, ci și o împărțire în comunitatea dezvoltatorilor (o formă de schism). Un astfel de exemplu este si PhpMyAdmin a cărui interfața poate fi remarcata în Figura 2.22. [23]

Figura 2.22. Interfața phpMyAdmin [24]

PhpMyAdmin este un instrument gratuit și open source scris în PHP destinat să gestioneze administrarea MySQL cu ajutorul unui browser web. Acesta poate efectua diverse sarcini, cum ar fi crearea, modificarea sau ștergerea bazelor de date, tabele, câmpuri sau rânduri, executarea instrucțiunilor SQL, sau gestionarea utilizatorilor și a permisiunilor. Software-ul, disponibil în 78 de limbi, este menținut de Proiectul phpMyAdmin. [23]

Acesta poate importa date din CSV și SQL și poate transforma datele stocate în orice format utilizând un set de funcții predefinite, cum ar fi afișarea datelor BLOB ca imagini sau link-uri de descărcare. [23]

Capitolul 3. Prezentarea soluției

3.1 Descrierea arhitecturii și modulele funcționale ale soluției

Soluția prezentată sub numele de ICare funcționează pe baza unei arhitecturi de tipul client-server, astfel se întâlnesc două entități funcționale care stau la baza transferului și manipulării date, serverul și clientul. Aceste entități se află într-o strânsă relație de colaborare, fiind dependente una de cealaltă, clienții nu pot funcționa fără server, iar serverul nu are nici o întrebuințare fără clienți.

Conform celor spuse mai sus în Figura 3.1 se poate remarca cu funcționează un astfel de sistem caracterizat de modelul client server, în cazul soluției ICare se remarcă faptul că prin intermediul internetului se asigură o conexiune cu serverul web, clienții fiind de doua tipuri, de tip utilizator, sau de tip medic, în ambele cazuri fiind posibil transferul de date către server prin intermediul cererilor și transferul de date de la server prin intermediul răspunsurilor.

Figura 3.1. Exemplu model client-server [21]

În cadrul soluției proiectului ICare se remarcă existența a patru module sau componente de bază care stau la baza funcționalității soluției propuse, acestea fiind:

O bază de date de tip MySQL în care se regăsesc tabelele care conțin informațiile vehiculate de către server cleinților

O aplicație web, sub formă de server web, bazată pe servlet-uri care răspund la cereri de tipul HTTP și transmit mai departe răspunsuri sub forma de JSON

O aplicație Android, de tip client pentru utilizatorii normali, care beneficiază de serviciile medicale puse la dispoziție, capabilă să insereze și să gestioneze date

O aplicație Android, de tip client pentru medicii specialiști, cei care prestează serviciile medicale pentru utilizatori, având acces la datele lor medicale

Baza de date atașată serverului web este de tip MySQL și are drept scop stocarea datelor medicale prelevate de către utilizatori pentru a le pune la dispoziția medicilor specialiști cu scopul de a remedia și gestiona problemele și neplăcerile care periclitează sănătatea utilizatorilor.

Serverul are scopul de a vehicula informațiile cerute de către clienți pe baza unor cereri de tip HTTP, acest server este de tip web și este bazat pe servlet-uri care respecte principiile de funcționare ale arhitecturii REST. Astfel pentru fiecare tip de cerere primită de la clienți, serverul are atașat un servlet dedicat, capabil să răspundă solicitării de tipul HTTP primită de la clienți și să ofere în consecința informațiile cerute prin răspunsuri de tip JSON, respectând arhitectura REST (Reprezentațional state transfer sau RESTful Web Services).

Aplicația Android destinată utilizatorilor normali care beneficiază de serviciile medicale, este în sine un client care se bazează pe comunicația cu serverul web pus la dispoziție pentru a putea gestiona și manipula datele medicale necesare, astfel cu ajutorul cererilor de tip HTTP trimise către server, poate primi de la acesta sub forma de JSON informațiile pentru a putea gestiona datele utilizatorilor, precum și pentru citirea și scrierea în baza de date.

Aplicația Android destinată medicilor specialiști care prestează servicii medicale pentru utilizatori, este în sine tot cu client și este foarte asemănătoare cu aplicația Android destinată utilizatorilor, deoarece folosește aceeași logică și principii de funcționare, adică se bazează tot pe cereri de tip HTTP pentru a putea furniza și primi date din baza de date prin intermediul serverului web dedicat, astfel răspunsurile primite care conțin datele medicale ale utilizatorilor sunt structurate tot în format JSON.

3.1 Baza de date

Baza de date utilizată de către proiectul ICare este de tip MySQL, aceasta are drept scop stocarea informațiilor provenite de la aplicațiile Android de tip client, prin intermediul serverului web. Singura posibilitate de acces în cadrul bazei de date este prin intermediul serverului web dedicat, pentru a prevenii orice fel de probleme sau atacuri rău intenționate care ar putea să dăuneze integrității acesteia, precum și împiedicarea furtului sau coruperii datelor existente.

Astfel aplicațiile Android de tip client nu pot interacționa în mod direct cu baza de date, ci doar prin intermediul serverului web, care se asigură că datele primite și transmise sunt pentru utilizatori autorizați, acest lucru nu le permite utilizatorilor să comunice în mod direct cu baza de date, din motive de securitate.

Structura completă a bazei de date utilizată în cadrul proiectului ICare este vizibilă în Figura 3.2. În acea figură se pot observa toate tabele, inclusiv câmpurile și tipul lor, dar mai ales se remarcă legăturile dintre ele.

Figura 3.2. Structura bazei de date

Baza de date utilizată conțină un număr considerabil de tabele utilizate pentru a stoca datele prelevate de aplicațiile Android de tip client, acestea conțin toate câmpurile necesare pentru o stocare cât mai optimă și mai sigură. Aceste tabele precum și întreaga lor funcționalitate urmează să fie explicate în paragrafele următoare.

Tabelul users este unul dintre cele mai importante din cadrul bazei de date, întrucât el conține datele personale, precum și datele necesare pentru logare ale tuturor utilizatorilor aplicației Android destinată lor. Datele sunt introduse aici prin utilizarea opțiunii de inregistrare din cadrul aplicației Android, acestea fiind transmise bazei de date prin intermediul serverului web dedicat.

Acest tabel stă la baza mai multor legături între tabele, prin intermediul câmpului id_users, pe care se bazează multiple chei străine.

Acest tabel are următoarele câmpuri:

id_users este un câmp de tip int, precum și cheia primară a tabelului, în cadrul căruia se regăsesc identificatorii unici (ID) ai tuturor utilizatorilor, aceștia sunt inserați automat în ordine crescătoare prin intermediul opțiunii auto_increment, atunci când un utilizator își creează un cont nou

first_name este un câmp de tip text ce conține prenumele utilizatorilor înregistrați

last_name, este un câmp de tip text ce conține numele de familie ale utilizatorilor înregistrați

gender este un câmp de tip varchar de dimensiune maxim 6 caractere ce conține genul utilizatorilor, acesta este predefinit și poate fi ”male” pentru persoanele de sex masculin și ”female” pentru persoanele de sex feminin

date_of_birth este un câmp de tip date ce conține datele de naștere ale utilizatorilor

phone_number este un câmp de tip varchar de maxim 10 caractere ce conține numerele de telefon ale utilizatorilor

email, este un câmp de tip text ce conține adresele de email ale utilizatorilor, acest câmp este foarte important deoarece pe baza valorii lui se poate face logarea utilizatorilor în aplicația Android destinată lor, identificatorul contului fiind dat de adresa de email a utilizatorilor

password este un câmp de tip text ce conține parolele conturilor utilizatorilor, importanța acestui câmp este majoră, deoarece el trebuie verificat de fiecare dată când se încearcă o autentificare de către utilizatori

Tabelul doctors este unul crucial pentru baza de date, deoarece acesta conține toate datele personale ale medicilor specialiști ce prestează servicii medicale pentru utilizatorii sistemului, tot aici se regăsesc și datele necesare pentru logarea în cadrul conturilor lor. Aceste date sunt introduse în baza de date prin intermediul serverului web, care primește datele prin opțiunea de înregistrare disponibilă în aplicația Android dedicată medicilor. Acest tabel stă baza mai multor legături între tabele prin intermediul câmpului id_doctor, pe care se bazează multiple chei străine.

Acest tabel are următoarele câmpuri:

id_doctor este un câmp de tip int, precum și cheia primară a tabelului, în cadrul căruia se regăsesc identificatorii unici (ID) ai tuturor medicilor, aceștia sunt inserați automat în ordine crescătoare prin intermediul opțiunii auto_increment, atunci când un medic își creează un cont nou

first_name este un câmp de tip text ce conține prenumele medicilor înregistrați

last_name, este un câmp de tip text ce conține numele de familie ale medicilor înregistrați

gender este un câmp de tip varchar de dimensiune maxim 6 caractere ce conține genul medicilor, acesta este predefinit și poate fi ”male” pentru medicii de sex masculin și ”female” pentru medicii de sex feminin

date_of_birth este un câmp de tip date ce conține datele de naștere ale medicilor

specializațion este un câmp de tip text care conține specializările medicale ale medicilor

phone_number este un câmp de tip varchar de maxim 10 caractere ce conține numerele de telefon ale medicilor

email, este un câmp de tip text ce conține adresele de email ale medicilor, acest câmp este foarte important deoarece pe baza valorii lui se poate face logarea medicilor în aplicația Android destinată lor, identificatorul contului fiind dat de adresa de email a medicilor

password este un câmp de tip text ce conține parolele conturilor medicilor, importanța acestui câmp este majoră, deoarece el trebuie verificat de fiecare dată când se încearcă o autentificare de către medici

Tabelul drugs este unul dintre cele mai importante tabele din cadrul bazei de date, acesta conține informațiile legate de medicamente, aici se regăsesc în mod simplificat și bine organizat conținutul prospectelor medicamentelor, precum și alte informații explicative pentru utilizatori pentru a permite consumul în siguranță și limitarea posibilității de apariție a efectelor secundare în cadrul programelor de medicamentație. Acest tabel stă la baza unor legături cu alte tabele cu ajutor câmpului id_drug pe care se bazează unele chei străine.

Acest tabel are următoarele câmpuri:

id_drug este un câmp de tip int, precum și cheia primară a tabelului, în cadrul căruia se regăsesc identificatorii unici (ID) ai tuturor medicamentelor, aceștia sunt inserați automat în ordine crescătoare prin intermediul opțiunii auto_increment, atunci când un medicament este inserat în tabel

name este un câmp de tip text, ce conține numele medicamentelor

generic_name este un câmp de tip text, ce conține numele generice ale medicamentelor

brand_name este un câmp de tip text, ce conține numele date de unele companii farmaceutice aceluiași medicament

what_is este un câmp de tip text, ce conține informații legate de scopurile medicamentelor

important_information este un câmp de tip text, ce conține informații importante despre medicamente

before_taking este un câmp de tip text, ce conține informații esențiale pentru utilizatori cu privire la lucruri de care trebuie ținut cont înainte de a lua medicamentele respective

how_to_take este un câmp de tip text, ce conține informații legate de modul de administrare al medicamentelor

dosing_information este un câmp de tip text, ce conține informații legate numărul și cantitatea dozelor ale medicamentelor ce se pot luat la un moment dat

miss_a_dose este un câmp de tip text, ce conține informații legate de posibilele inconveniente în cazul în care se sar anumite doze ale medicamentelor

overdose este un câmp de tip text, ce conține informații legate de posibilele probleme și efecte secundare în cazul în care se administrează doze prea mari ale medicamentelor

avoid_while_taking este un câmp de tip text, ce conține informații legate de substanțele ce trebuie evitate în perioada în care se asimilează medicamentele

side_effects este un câmp de tip text, ce conține informații legate de posibilele efecte secundare care pot apărea în urma administrării medicamentelor

other_drugs este un câmp de tip text, ce conține informații legate de posibilele probleme și efecte secundare în cazul în care se asimilează și alte medicamente în perioada în care se asimilează un anumit medicament

Tabelul symptoms are o importanță deosebit în carul bazei de date, deoarece în cadrul acestui tabel se introduc datele legate de simptomele utilizatorilor, aici apar problemele întâmpinate de către utilizatori în cadrul programelor de medicamentație și nutriție, precum și evenimente neplăcute sau efecte secundare apărute. Acest tabel este legat de tabelul users prin intermediul cheii străine date de câmpul id_user al acestui tabel.

Acest tabel are următoarele câmpuri:

id_symptom este un câmp de tip int, precum și cheia primară a tabelului, în cadrul căruia se regăsesc identificatorii unici (ID) ai tuturor simptomelor întâmpinate de utilizatori, aceștia sunt inserați automat în ordine crescătoare prin intermediul opțiunii auto_increment, atunci când un simptom este inserat în tabel de către utilizatori, prin intermediul serverului web, în cadrul aplicației Android destinate lor

id_user este un câmp de tip int, precum și cheie străină în cadrul acestui tabel, ce conține identificatorul unic al utilizatorului ce inserează simptomele

symptom_date este un câmp de tip datetime ce conține data și ora la care simptomele s-au făcut simțite de către utilizatori

symptom este un câmp de tip text ce conține simptomele inserate de către utilizatori

Tabelul measurements îți face ușor simțită importanța în cadrul bazei de date, prin faptul că stochează date referitoare la diferitele măsurători efectuate de către utilizatori, aceste fiind de 5 tipuri: temperaturile corpului măsurată în grade Celsius (°C), înălțimea corpului măsurată în centimetri (cm), greutatea corpului măsurată în kilograme (kg), nivelul glicemiei din sânge măsurat în miligrame per decilitru (mg/dL) și presiunea sângelui sau tensiunea măsurată în milimetri coloană mercur (mmHg). Acest tabel este legat de tabelul users prin intermediul cheii străine date de câmpul id_user al acestui tabel.

Acest tabel are următoarele câmpuri:

id_measurement este un câmp de tip int, precum și cheia primară a tabelului, în cadrul căruia se regăsesc identificatorii unici (ID) ai tuturor măsurătorilor efectuate de către utilizatori, aceștia sunt inserați automat în ordine crescătoare prin intermediul opțiunii auto_increment, atunci când o masurătoare este inserat în tabel de către utilizatori, prin intermediul serverului web, în cadrul aplicației Android destinate lor

id_user este un câmp de tip int, precum și cheie străină în cadrul acestui tabel, ce conține identificatorul unic al utilizatorului ce inserează măsurătorile

measurement_date este un câmp de tip datetime ce conține data și ora la care măsurătorile au fost realizate de către utilizatori

measuremet_value este un câmp de tip text ce conține măsurătorile, indiferent de tip, împreună cu unitatea de măsură asociată fiecărui tip, obținute de către utilizatori

type este un câmp de tip varchar de maxim 15 caractere ce reține tipul măsurătoriilor efectuate de către utilizatori

Tabelul schedule își face simțită utilitatea în cadrul bazei de date, prin faptul că stochează informațiile legate de programul de nutriție, mai exact orele meselor principale ale zilei, pentru a asigura echilibrul optim între mese, aceste informații fiind transmite de către utilizatori prin aplicația Android dedicată rol, facilitând funcționarea unui manager de notificări, care transmite notificări utilizatorilor atunci când este timpul să mănânce. ). Acest tabel este legat de tabelul users prin intermediul cheii străine date de câmpul id_user al acestui tabel.

Acest tabel are următoarele câmpuri:

id_schedule este un câmp de tip int, precum și cheia primară a tabelului, în cadrul căruia se regăsesc identificatorii unici (ID) ai tuturor orelor la care sunt programate mesele principale ale utilizatorilor, aceștia sunt inserați automat în ordine crescătoare prin intermediul opțiunii auto_increment, atunci când o oră este inserată în tabel de către utilizatori, prin intermediul serverului web, în cadrul aplicației Android destinate lor

id_user este un câmp de tip int, precum și cheie străină în cadrul acestui tabel, ce conține identificatorul unic al utilizatorului ce inserează orele meselor principale ale zilei

clock este un câmp de tip time ce conține orele la care sunt programate mesele principale ale zilei de către utilizatori

type este un câmp de tip varchar de maxim 9 caractere ce reține tipul măsurătoriilor efectuate de către utilizatori, acestea având posibilitatea de a fi: breakfast (mic dejun), lunch (prânz) și dinner (cină).

enabled este un câmp de tip varchar de maxim 3 caractere, care poate avea valorile yes or no, acestea fiind setate de către utilizatori în cadrul aplicației Android dedicată lor prin activarea respectiv dezactivarea alertelor pentru mesele respective

Tabelul diets este printre cele mai importante tabele din cadrul bazei de date, acesta conține alimentele recomandate și nerecomandate pe care utilizatorii necesită să le consume sau nu, datele fiind introduse de către medici pentru utilizatorii în cauză prin intermediul aplicației android destinată medicilor și pot fi vizualizate de către utilizatori prin intermediul aplicației Android destinată utilizatorilor. Acest tabel este legat de tabelul users prin intermediul cheii străine date de câmpul id_user al acestui tabel, precum și de tabelul doctors prin intermediul cheii străine date de câmpul id_doctor al acestui tabel.

Acest tabel are următoarele câmpuri:

id_diet este un câmp de tip int, precum și cheia primară a tabelului, în cadrul căruia se regăsesc identificatorii unici (ID) ai tuturor alimentelor din cadrul dietelor concepute de către medici pentru utilizatori utilizatorilor, aceștia sunt inserați automat în ordine crescătoare prin intermediul opțiunii auto_increment, atunci când un aliment, rețetă sau dietă este inserată în tabel de către medici pentru utilizatori, prin intermediul serverului web, în cadrul aplicației Android destinate lor

id_doctor este un câmp de tip int, precum și cheie străină în cadrul acestui tabel, ce conține identificatorul unic al medicului ce inserează alimentele din cadrul dietelor concepute pentru utilizatori

id_user este un câmp de tip int, precum și cheie străină în cadrul acestui tabel, ce conține identificatorul unic al utilizatorului ce beneficiază de dietele propuse de către medici

item este un câmp de tip text ce conține alimentele dietelor inserate de către medici

type este un câmp de tip varchar de maxim 4 caractere ce reține tipul alimentelo din cadrul dietelor, acestea sunt predefinite având posibilitatea de a fi good în cazul unui aliment sau diete benefice și bad în cazul unui aliment sau diete nepotrivite

Tabelul agreements are un rol crucial de o importanță maximă in cadrul bazei de date, acesta se ocupă de asigurarea accesului medicilor la datele utilizatorilor, astfel în acest tabel se regăsesc acordurile dintre medici și utilizatori, un medic nu poate să vizualizeze absolut nici o informație personala a utilizatorilor, fără ca aceștia să își dea acordul, acord ce poate fi anulat și de către medici și de către utilizatori. Cu alte cuvinte medicii trimit cereri către utilizatori, iar dacă aceștia le acceptă, își dau acordul, doar atunci medici au acces la datele utilizatorilor, în cazul în care cererea este respinsă atunci medicii nu primesc acces la datele utilizatorilor.

Acest tabel este legat de tabelul users prin intermediul cheii străine date de câmpul id_user al acestui tabel, precum și de tabelul doctors prin intermediul cheii străine date de câmpul id_doctor al acestui tabel.

Acest tabel are următoarele câmpuri:

id_agreement este un câmp de tip int, precum și cheia primară a tabelului, în cadrul căruia se regăsesc identificatorii unici (ID) ai acordurilor dintre medici și utilizatori, aceștia sunt inserați automat în ordine crescătoare prin intermediul opțiunii auto_increment, atunci când apar noi cereri trimise de către medici

id_user este un câmp de tip int, precum și cheie străină în cadrul acestui tabel, ce conține identificatorul unic al utilizatorului căruia au fost trimise cereri de către medici

id_doctor este un câmp de tip int, precum și cheie străină în cadrul acestui tabel, ce conține identificatorul unic al medicului ce trimite cereri către utilizatori

status este un câmp de tip varchar de maxim 8 caractere ce conține statusul cererii trimise de către medic către utilizator, acesta este predefinit și poate avea valorile: pending în cazul în care cerea a fost trimisă către utilizator, dar acesta încă nu a acceptat sau refuzat cererea, accepted în cazul în care cererea a fost acceptată de către utilizator sau rejected în cazul în care cerea a fost refuzată de către utilizator

Tabelul medication este deosebit de important în cadrul bazei de date, deoarece acesta conține programele de medicamentație trimise de către medici utilizatorilor cu scopul de a restaura starea de bine a pacienților, aici se află medicamentele, doza, orele la care se necesită administrarea, date începerii și data terminării programelor de medicamentație în cauză. Acest tabel este legat de tabelul users prin intermediul cheii străine date de câmpul id_user al acestui tabel, de tabelul doctors prin intermediul cheii străine date de câmpul id_doctor al acestui tabel, precum și de tabelul drugs prin intermediul cheii străine date de câmpul id_drug al acestui tabel.

Acest tabel are următoarele câmpuri:

id_medication este un câmp de tip int, precum și cheia primară a tabelului, în cadrul căruia se regăsesc identificatorii unici (ID) ai programelor de medicamentație transmise de către medici utilizatorilor, aceștia sunt inserați automat în ordine crescătoare prin intermediul opțiunii auto_increment, atunci când apar programe de medicamentație noi transmise de către medici

id_user este un câmp de tip int, precum și cheie străină în cadrul acestui tabel, ce conține identificatorul unic al utilizatorului căruia au fost transmise programele de medicamentație de către medici

id_doctor este un câmp de tip int, precum și cheie străină în cadrul acestui tabel, ce conține identificatorul unic al medicului ce transmise programele de medicamentație către utilizatori

id_drug este un câmp de tip int, precum și cheie străină în cadrul acestui tabel, ce conține identificatorul unic al medicamentului din cadrul programelor de medicamentație transmise de către medici

time este câmp de tip time ce conține orele la care trebuie luate medicamentele din cadrul programelor de medicamentație

start_date este câmp de tip date ce conține data la care este necesară începerea programulului de medicamentație

end_date este câmp de tip date ce conține data la care se sfârșește programul de medicamentație

medication_quantity este câmp de tip int ce conține dozajul medicamentelor din cadrul programelor de medicamentație

active este câmp de tip varchar de maxim 3 caractere ce conține informații legate de activarea sau dezactivarea programelor de medicamentație de către utilizatori, aceste valori sunt predefinite, acestea pot fi yes în cazul în care utilizatorul activează programul de medicamentație sau no în cazul în care utilizatorul dezactivează programul de medicamentație

Tabelul inventory își dovedește utilitatea în cadrul bazei de date prin stocarea informațiilor utilizatorilor legate de tipul de medicamente pe care le dețin, precum cantitatea acestora, astfel se realizează o gestiune eficientă a medicamentelor deținute de către utilizatori, oferind posibilitatea de vizualizare a lor de către medici cu scopul prescrierii mai multor medicamente în caz că este nevoie. Acest tabel este legat de tabelul users prin intermediul cheii străine date de câmpul id_user al acestui tabel, precum și de tabelul drugs prin intermediul cheii străine date de câmpul id_drug al acestui tabel.

Acest tabel are următoarele câmpuri:

id_entry este un câmp de tip int, precum și cheia primară a tabelului, în cadrul căruia se regăsesc identificatorii unici (ID) ai medicamentelor deținute de către utilizatori, aceștia sunt inserați automat în ordine crescătoare prin intermediul opțiunii auto_increment, atunci când utilizatorii achiziționează medicamente noi

id_user este un câmp de tip int, precum și cheie străină în cadrul acestui tabel, ce conține identificatorul unic al utilizatorului care inserează medicamentele

id_drug este un câmp de tip int, precum și cheie străină în cadrul acestui tabel, ce conține identificatorul unic al medicamentului introdus de către utilizator

quantity este un câmp de tip int ce conține cantitatea medicamentelor introduse de către utilizator

Tabelul quotes are drept scop stocarea de către administratori zilnic a unor citate motivaționale care apar ca primă pagină atât în aplicația android destinată utilizatorilor cât și în cea destinată medicilor cu scopul de a motiva și bine dispune atât utilizatorii cât și medicii pentru o productivitatea cât mai crescută. Acest tabel nu are chei străine astfel nu se află în legătură cu alte tabele, fiind singurul de acest tip în cadrul bazei de date, deoarece nu depinde de alte tabele.

Acest tabel are următoarele câmpuri:

id este un câmp de tip int, precum și cheia primară a tabelului, în cadrul căruia se regăsesc identificatorii unici (ID) ai citatelor introduse de către administratori, aceștia sunt inserați automat în ordine crescătoare prin intermediul opțiunii auto_increment, atunci când utilizatorii achiziționează medicamente noi

quote este un câmp de tip text care conține textul citatelor introduse

author este un câmp de tip text care conține autorii citatelor introduse

3.2 Serverul web

Serverul web implementat în cadrul proiectului ICare cu scopul de a superviza accesul la baza de date de către aplicațiile Android dedicate utilizatorilor și medicilor, este ena dintre componentele de bază deoarece pe baza lui se pot vehicula datele necesare gestiunii programelor de medicamentație și nutriție.

Acesta stă la dispoziția aplicațiilor Android de tip client care trimit cereri de tip HTTP către server, așteptând ca serverul să le trimită răspunsuri sub format JSON cu informațiile cerute, astfel apare în relief modelul client-server pe care este dispus proiectul ICare. din acest punct de vedere se remarcă o delimitare clară între partea de server, în cazul soluției propuse fiind utilizat un server web și partea de client, clienții soluției prezente fiind reprezentați de aplicații Android dedicate atât utilizatorilor cât și medicilor.

Serverul web este bazat pe principiile de funcționare ale arhitecturii REST, resursele utilizate fiind informațiile stocate în baza de date, pentru funcționare folosind protocolul HTTP, acceptând de la clienți cereri de tip HTTP, returnând mesaje de tip JSON furnizând astfel datele și resursele solicitate de către clienți. Servlet-rile, spre deosebire de serviciile web, se află cu un nivel de abstractizare mai jos, se comportă similar și extind capabilitățile arhitecturii REST întrucât dețin de mapare asemănător, funcționează pe modelul client-server, pot gestiona cu ușurință cereri de tip HTTP și pot folosi JSON sau XML pentru răspunsuri (obligatoriu în cadrul arhitecturii REST).

Componenta funcțională a serverului web este reprezentată de servlet. Serverul web pune la dispoziție o serie de servle-uri dedicate pentru fiecare tip de cerere întâmpinată de la aplicațiile Android de tip client. Aceste servlet-uri sunt de tip HTTP, clasa derivată pe care se bazează clasele din cadrul serverului web este HttpServlet, care la rândul ei implementează interfața Servlet.

Clasa HttpServlet face parte din librăria javax.servlet.http, aceasta funcționând pe baza cererilor de tip HTTP transmise de către clienți pe care le primește prin intermediul unui obiect de tip HttpServletRequest disponibil în cadrul aceleiași librării, transmiterea mesajelor către clienți realizându-se pe baza unui obiect de tip HttpServletResponse, disponibil în cadrul aceleiași librării.

Serverul web este în sine o aplicație web bazată pe java, folosind Java EE (Java Enterprise Edition), platformă ce oferă un mediu API și runtime pentru dezvoltarea și funcționarea aplicațiilor de rețea la scară largă, multi-nivel, scalabile, fiabile și securizate. Acesta este pus în execuție cu ajutorul lui Apache Tomcat, deseori denumit Tomcat Server, care este un container Java Servlet de tip open source dezvoltat de Apache Software Foundation (ASF). Tomcat implementează mai multe specificații Java EE, inclusiv Java Servlet, Pagini JavaServer (JSP), Java EL și WebSocket și oferă un mediu de server HTTP "pur Java" în care poate rula codul Java.

Pentru a putea accesa un servlet prin intermediul unei cereri de la clienți, acesta trebuie să dețină o adresă la care să se poată referi cererea, această adresă este asignată servletuli prin intermediul unui document XML, web.xml în care aplicația definește relațiile dintre clasele efective ale servlet-urilor și adresele la care acestea pot fi găsite. În figura 3.3 se poate remarca cum pentru clasele servlet-urilor se alege un nume pentru ca mai apoi cu ajutorul acelui nume să se poată face maparea clasei cu adresa la care poate fi accesată. Astfel pentru clasa de tip HttpServlet Quote se primește numele servlet-ului ca fiind quoteServlet și prin intermediul acestui nume se realizează maparea către adresa /servlet/Quote, același procedeu se realizează și pentru servletul Symptoms prezent în exemplu, precum și pentru toate celelalte servlet-uri din cadrul serverului web.

Figura 3.3. Exemplu web.xml

Figura 3.4. Cerere HTTP fără parametri Figura 3.5. Cerere HTTP cu parametri

Servlet-urile utilizate primesc date de la clienți prin cereri sub forma de URL, exemplu în Figura 3.4, unde se remarcă structura apelului, care conține protocolul http, urmat de adresa IP a sistemului de calcul care găzduiește serverul (192.168.0.106 în acest caz), portul la care se face conectarea (8080 în acest caz), urmat de adresa servlet-ului la care a fost asignat (/servlet/Quote).

Acea cerere de tip HTTP din figura 3.4 este una fără parametri, care nu transmite date către server, ci doar așteaptă ca acesta să transmită date către client, dar există și posibilitatea de a transmite date către server pentru a specifica ce date să vehiculeze, în acest caz este nevoie de parametri, care se pot specifica la sfârșitul URL-ului cu ajutorul caracterului ?, care delimitează zona de unde încep parametri, lucru ușor vizibil în cadrul acelei figuri care după caracterul ? transmite parametru cu numele id_user de valoare 3 pentru a oferii informații suplimentare în legătură cu datele solicitate. În cazul în care se transmit mai mulți parametri este nevoie de caracterul & pe post de separator.

În urma cererilor primite serverul trebuie să proceseze datele cerute, în acest sens în clasa servlet-ului este necesară utilizarea a două metode: doGet și doPost, acestea sunt foarte asemănătoare cu metodele GET și POST din cadrul limbajului PHP, astfel și aici este mult mai indicată utilizarea metodei doPost deoarece este cu mult mai sigură decât metoda doGet, datele transmise în acest fel nefiind vizibile.

Figura 3.6. Implementarea metodei doPost fără parametri

Pentru implementarea logicii din spatele servletului se poate remarca în Figura 3.6 implementarea metodei doPost fără a necesita parametri suplimentari de la clienți, această metodaă fiind cea care asigură transferul de informații de la server. În antetul funcției se remarcă cele două obiecte necesare pentru buna funcționare, request de tip HttpServletRequest și response de tip HttpServletResponse, se mai semnalează faptul că această metodă poate să genereze excepții de tip input sau output.

În continuare se setează tipul răspunsului ca fiind de tip text/html, adică conferă posibilitatea mesajului să conțină text sau cod html, această opțiune fiind și cea mai indicată și cea mai utilizată, evident în cadrul servlet-urilor utilizate de server, răspunsul este de tip text scris sub format JSON. Apoi se creează și inițializează un obiect writer de tip PrintWriter care o să fie folosit la transferul mesajului. Urmează implementarea logii în sine, se JDBC pentru accesul la baza de date, după care se face selecția informațiilor necesare din aceasta, în cazul nostru ultimul citat, precum și autorul acestuia inserat în baza de date. După selecție se verifică daca au fost extrase date, în funcție de care se generează raspunsul în format JSON, acest raspuns conține un status, care poate fi false în cazul în care nu s-au găsit date în baza de date, sau au intervenit evenimente neplăcute, fapt ce generează scrierea unui obiect JSON qoute, în care valoarea staus este false, fapt ce semnalează aplicațiile de tip client că ceva nu a mers bine pentru a putea oferii mesaje și acțiuni sugestive. Dar în cazul în care informațiile sunt găsite, valoarea status, a obiectului JSON quote, devine true, la care se adauză un apt obiect JSON numit description care o să conțină informațiile cerute, citatul și autorul acestuia.

Figura 3.7. Obiectul JSON transmis în Figura 3.6

În urma executării metodei din Figura 3.6 mesajul care conține obiectul JSON este vizibil în figura 3.7, acolo se remarcă cu ușurință datele transmise, modul și formatul în care au fost transmise. Obiectul cu numele quote, având valoarea status egală cu true, pentru a semnala faptul că datele au fost găsite și transmise cu succes, precum și obiectul description în care se regăsesc datele solicitate, citatul și autorul său.

Figura 3.8. Implementarea metodei doPost cu parametri

Totuși există ți posibilitatea transmiterii cererilor împreună cu parametri, precum în Figura 3.8, pentru a putea oferii informații suplimentare în legătură cu ce informații se doresc, sau pentru a insera, modifica sau șterge date din baza de date. În Figura 3.8, modul de funcționare este similar celui din Figura 3.6, însă se remarcă ca și deosebiri faptul că se extrage într-un string numit userId, prin intermediul obiectului request, cu ajutorul proprietății getParameter(), care solicită valoarea parametrului cu numele id_user, trimis de către client. În continuare în mod asemănător se vehiculează date din baza de date prin intermediul JDBC, doar că de data aceasta datele cerute sunt dependente de valoarea parametrului transmis. În cadrul formării obiectului JSON, în cazul în care datele nu au fost găsite în baza de date obiectul transmis este similar, surpriza fiind însă în cazul în care datele sunt găsite, deoarece datele sunt introduse într-un vector, din cadrul obiectului JSON transmis, format în mod dinamic pe măsură ce se parcurg datele preluate din baza de date. Obiectul JSON transmis conține simptomele, id-urile lor precum și data la care au apărut în funcție de id-ul utilizatorului trimis ca parametru.

Astfel se transmit multiple înregistrări din baza de date utilizatorilor care solicită acele date prin intermediul aplicațiilor Android de tip client, furnizând ca și parametru id-ul asignat contului lor, pentru a putea vedea doar datele personale, nu și ale altor utilizatori, în afară de medicii care au primit acordul utilizatorilor.

Figura 3.9. Obiectul JSON transmis în Figura 3.8

În urma execuției metodei din Figura 3.8 se poate remarca în Figura 3.9 obiectul JSON conținut de răspunsul la cerea trimisă cu parametru id_user de valoare 3, cu alte cuvinte se transmite true a lui status, pentru a semnala că extragerea informațiilor din baza de date s-a efectual cu succes. Dar se remarcă că în cadrul lui items sunt conținute informațiile cerute sub formă de vector, adică simptomele înregistrate de utilizatorul cu id-ul 3.

În cadrul componentelor serverului web, se remarcă o multitudine de servlet-uri de tip HttpServlet, pe lângă cele prezentate anterior, care dețin propriile funcționalități și care permit o multitudine de operații în vederea răspunderii cererilor solicitate de către utilizatori sau medici, prin intermediul aplicațiilor Android dedicate pentru nevoile lor.

Astfel serverul pune la dispoziție servlet-uri pentru:

facilitarea logării atât utilizatorilor cât și medicilor, primind de la aceștia ca și parametri informațiile necesare pentru a se putea loga în cadrul aplicațiilor Android destinate lor, acesta verificând veridicitatea și corectitudinea informațiilor transmise permițând accesul în cazul în care sunt corecte, precum și furnizarea datelor personale atașate conturilor în care se face logarea

a permite înregistrarea de conturi noi, atât de către utilizatori, cât și de către medici, primind de la aceștia datele introduse în cadrul aplicațiilor Android ca și parametri, pentru a verifica corectitudinea și unicitatea datelor necesare, astfel înregistrând în baza de date conturile valide și unice

transmiterea citatelor cerute de către aplicații atunci când se loghează utilizatorii sau medicii cu scopul de a bine dispune

permit transmiterea simptomelor pentru a putea fi vizualizate de către utilizatori și de către medicii care dețin acorduri cu utilizatorii menite să permită acest lucru, înregistrate de către utilizatori, cu ajutorul parametrului ce conține id-ul utilizatorului

inserarea în baza de date a unor simptome noi resimțite de către utilizatori cu ajutorul unor parametri ce conțin id-ul utilizatorului, simptomul întâlnit, data și ora la care și-a făcut apariția

modificarea unor simptome de către utilizatori, introduse în mod incorect, prin utilizarea, unor parametri ce conțin id-ul simptomul care trebuie modificat, precum și noul simptomul modificat ce urmează să îl înlocuiască pe cel eronat

ștergerea din baza de date de către utilizatori a unor simptome introduse care nu mai sunt de actualitate, sau sunt incorecte sau inexacte prin intermediul parametrului ce conține id-ul simptomului ce necesită a fi șters

transmiterea măsurătorilor pentru a putea fi vizualizate de către utilizatori și de către medicii care dețin acorduri cu utilizatorii menite să permită acest lucru, înregistrate de către utilizatori, cu ajutorul parametrilor ce conțin id-ul utilizatorului precum și tipul măsurătorilor cerute (temperatura, înălțimea, greutatea, glicemia sau tensiunea)

inserarea în baza de date a unor măsurători noi de către utilizatori cu ajutorul unor parametri ce conțin id-ul utilizatorului, valoarea măsurătorii împreuna cu unitatea de măsură, data și ora la care s-a efectuat măsurătoarea, precum și tipul măsurătorii

modificarea unor măsurători de către utilizatori, care au fost introduse în mod incorect, prin utilizarea unor parametri ce conțin id-ul măsurătorii ce trebuie modificată, precum și noua măsurătoare ce urmează să o înlocuiască pe cea eronată

ștergerea din baza de date de către utilizatori a unor măsurători introduse care nu mai sunt de actualitate, sau sunt incorecte sau inexacte, prin intermediul parametrului ce conține id-ul măsurătorii ce necesită a fi ștearsă

transmiterea unei liste cu medicamentele aflate în sistem, atât utilizatorilor cât și medicilor fără a necesita parametri

transmiterea datelor ce constituie prospectul unui medicament, atât utilizatorilor cât și medicilor, prin intermediul parametrului ce conține id-ul medicamentului

transmiterea medicamentelor și cantitatea acestora deținute de către utilizatori, atât utilizatorilor cât și medicilor care dețin acorduri cu utilizatorii menite să permită acest lucru, prin intermediul parametrului ce conține id-ul utilizatorului

inserarea de noi medicamente deținute de către utilizatori, precum și cantitatea acestora, prin intermediul parametrilor ce conțin id-ul utilizatorului, id-ul medicamentului și cantitatea deținută

modificarea cantității medicamentelor deținute de către utilizatori, prin intermediul parametrilor ce conțin id-ul înregistrării din tabel ce urmează să fie modificată și noua cantitate ce trebuie inserată

ștergerea medicamentelor deținute de către utilizatori, prin intermediul parametrului ce conține id-ul înregistrării din tabel ce urmează a fi ștearsă

transmiterea datelor personale ale utilizatorilor, atât utilizatorilor cât și medicilor care dețin acorduri cu utilizatorii menite să permită acest lucru

transmiterea datelor personale ale medicilor, atât medicilor cât și utilizatorilor care dețin acorduri cu medicii menite să permită acest lucru

modificarea datelor personale atât utilizatorilor cât și medicilor, prin intermediul parametrilor ce conțin datele ce necesită modificări

transmiterea unui liste cu medicii care dețin acorduri cu utilizatorul care transmite cererea, prin intermediul parametrului ce conține id-ul utilizatorului

transmiterea unui liste cu utilizatorii care dețin acorduri cu medicul care transmite cererea, prin intermediul parametrului ce conține id-ul medicului

posibilitatea de a transmite de către medici, cereri de acorduri noi între utilizatori și medici anumitor utilizatori

posibilitatea de a accepta sau refuza de către utilizator cererile de acorduri noi transmise de către medici acelui utilizator

inserarea de noi alimente de către medici în cadrul programelor de medicamentație propuse utilizatorilor, precum și vizualizarea acestora atât de către medicii care le-au transmis, cât și de către utilizatorii care le-au primit

inserarea și modificarea de către utilizatori a unor planuri noi ce privesc orele la care se transmit notificări în scopul de a respecta mesele principale ale zilei

inserarea, modificarea și ștergerea de către medici a programelor de medicamentație concepute de aceștia pentru utilizatorii, precum și posibilitatea de activare sau dezactivare de către utilizatori ale notificărilor generate de aceste programe cu scopul de a respecta orele la care trebuie luate medicamentele în cauză

3.3 Aplicația Android dedicată utilizatorilor

Aplicația Android dedicată utilizatorilor este realizată în Android Studio, mediul de dezvoltare integrat oficial pentru acest sistem, prin intermediul limbajului Java pe care a fost creată întreaga logică, precum și toate funcționalitățile și prin intermediul limbajului XML pe care au fost create toate elementele vizuale care țin de design și de interfața cu utilizatorul.

La pornirea aplicației ICare instalată pe un dispozitiv mobil de tip smartphone sau tabletă pe care rulează sistemul de operare Android, primul lucru afișat este interfața destinată logării, vizibilă în Figura 3.10, care necesită adresa de email pe baza căreia a fost creată contul, precum și parola contului, ca în Figura 3.11. Această interfață grafică poartă numele Activity, fiind similară cu ferestrele din alte sisteme. Câmpul în care se introduce adresa de email, permite inserarea unui string care are ca și format modelul unui adrese de email, adică un set de caractere, urmate de caracterul @, urmat de alt set de caractere care se termină cu caracterul . și în final un alt set de caractere, în caz contrar câmpul afișează mesaje de avertizare.

Câmpul care reține parola permite inserarea acesteia fără a face vizibile caractere. Există și posibilitatea vizualizării lor prin utilizarea controlul sub formă de pictogramă din partea dreaptă al câmpului password. Parola introdusă este validată și necesită un format prestabilit pentru a fi acceptată, minim 8 caractere, o literă mică, o literă mare, o cifră și cel puțin un caracter special, în caz contrar câmpul afișează mesaje de avertizare.

Figura 3.10. Interfața pentru logare Figura 3.11. Datele necesare pentru logare

În cazul în care ambele câmpuri au fost complete corespunzător, se poate începe procesul de logare prin apăsarea butonului Log In care apelează la un task asincron pentru a transmite o cerere de logare către server cu datele introduse de către utilizator. În cazul în care datele sunt veridice atunci autentificarea are loc, în caz contrat se afișează un mesaj corescpunzător care specifică că datele introduse nu sunt sorecte.

Interfața mai pune la dispoziție și posibilitatea de înregistrare a unui utilizator nou prin apăsarea pe textul Create a new account, care aduce în prin plan o altă interfață grafică destinată înregistrării, vizibilă în figura 3.12.

Figura 3.12. Interfața pentru înregistrare Figura 3.13. Mesaje de avertizare

În cadrul acestei interfețe se pun la dispoziție diferite câmpuri care permit inserarea datelor personale ale utilizatorului, acesta fiind prenumele în cadrul câmpului First Name și numele de familie în cadrul câmpului Last Name, care pot să conțină doar text, acest lucru fiind verificat.

Genul se stabilește prin selectarea butonului radio potrivit, Male pentru un utilizator de genul masculin și Female pentru un utilizator de genul feminin, acestea funcționând după principiul de excludere mutuală. Data nașterii se stabilește prin alegerea valorii zilei, lunii și anului, din cadrul celor trei obiecte spinner puse la dispoziție. Numărul de telefon poate să conțină doar cifre, în total 10 caractere, orice altă dimensiune este respinsă cu un mesaj de avertizare, adresa de email și parola sunt validate în același mod ca și cele din interfața din Figura 3.10.

La apăsarea butonului Register, dacă toate câmpurile sunt introduse și validate cu succes, se folosește un task asincron care trimite o cerere la server cu datele introduse de către utilizator ca și parametri, dacă datele destinate autentificării sunt veridice și unice atunci contul este creat, dacă nu sunt se transmite un mesaj de avertizare corespunzător utilizatorului. Dacă nu au fost introduse toate datele, sau dacă unele date nu sunt validate cu succes atunci se transmit mesaje de avertizare specifice ca în Figura 3.13.

Dacă în urma cererii de autentificare trimise către server în cazul apăsării butonului Log In din cadrul interfeței grafice destinate logării din figura 3.10, autentificarea se realizează cu succes, atunci se primesc datele personale ale utilizatorului printr-un răspuns de tip JSON și se trece la o altă interfață grafică, cea de bază a aplicației, vizibilă în Figura 3.14.

Figura 3.14. Interfața principală

În momentul creării interfeței din Figura 3.14 se utilizează un task asincron care face o cerere către server și primește de la acesta în format JSON citatul zilei, precum și autorul acestuia.

În partea din dreapta sus se remarcă o iconiță sub formă de trei puncte suprapuse care demască un meniu contextual cu o singură opțiune numită Log Out, vizibilă în Figura 3.15, care drept scop delogarea utilizatorului din cadrul aplicației, care o să revină la interfața grafică din Figura 3.10.

Dacă această opțiune este selectată, o să apară o casetă de dialog, de tipul AlertDialog care pune la dispoziție opțiunea de yes, în cazul în care se dorește delogarea din aplicație, sau opțiunea no care anulează procesul fără a face schimbări.

Figura 3.15. Opțiunea de Log Out Figura 3.16. Confirmare Log Out

Interfața principală din Figura 3.14 mai pune la dispoziție un alt meniu mult mai complex, de tip NavigaionDrawler, meniu vizibil în Figura 3.17 și Figura 3.18, care se face vizibil prin swipe din partea stângă, în cadrul acestuia aflându-se principalele opțiuni și funcționalități puse la dispoziție de aplicația ICare.

Figura 3.17. Prima parte a meniului Figura 3.18. A doua parte a meniului

Opțiunile prezentate în cadrul meniului sunt create sub formă de fragmente cu ajutorul unui manager de fragmente. Fragmentele sunt echivalentul conținutului unui ferestre sau interfețe grafice, un activity este ca un container pentru elementele grafice pe care le deține, prin fragmente se poate schimba doar conținutul unui activity, fără a schimba a schimba sau pierde și alte elemente atribuite lui, cum ar fi bara de sus, sau meniul în sine. Astfel se asigură disponibilitatea meniului indiferent de conținut interfeței curente.

În continuare urmează prezentarea fiecărei opțiuni disponibile din meniu, precum și întreaga lor funcționalitate.

Personal Info are drept scop aducerea în prin plan a datelor personale ale utilizatorului care folosește aplicația, primite în cadrul răspunsului serverului în momentul în care autentificarea s-a efectuat cu succes, lucru vizibil în Figura 3.19.

Figura 3.19. Datele personale Figura 3.20. Editarea datelor personale

Butonul Edit are drept scop permiterea modificării datelor personale de către utilizatori, care prin apăsarea lui aduce în prin plan o fereastră, vizibilă în Figura 3.20, care pune la dispoziție posibilitatea modificării lor. Dacă se apasă pe opțiunea cancel atunci nu se întâmpla nici o modificare, însă dacă se apasă pe opțiunea ok, se verifică corectitudinea datelor și dacă totul este corect definit, se utilizează un task asincron care trimite o cerere la server împreună cu datele modificate pentru a face update în baza de date. Dacă datele introduse nu sunt corecte atunci se primesc mesaje corespunzătoare

Opțiunea Home are drept scop aducerea în prin plan a interfeței grafice din Figura 3.14 indiferent de locația curentă în cadrul aplicației.

Symptoms are drept scop aducerea simptomelor înregistrate de către utilizator din cadrul bazei de date, prin intermediul unui task asincron care realizează o cerere către server, primind un răspuns de tip JSON care conține un vector cu toate simptomele înregistrate de către acesta, permițând astfel stocarea și gestiunea datelor inserate. Acest lucru este vizibil în Figura 3.21, în care interfața grafică conține un element grafic de tip listă, care găzduiește informațiile aduse.

Figura 3.21.Simptomele Figura 3.22. Inserarea simptomelor

Figura 3.23. Editare simptomelor Figura 3.24. Ștergerea simptomelor

Aplicația pune la dispoziție posibilitatea inserării simptomelor prin apăsarea butonului rotund din stânga jos, cu o iconiță sub formă de plus, vizibil în interfața din figura 3.21, care deschide o fereastră ca în Figura 3.22, în care se permite inserarea simptomului, ora fiind inserată automat în funcție de ceasul dispozitivului. Se mai pune la dispoziție și editarea datelor inserate prin apăsarea pe simptomul dorit din listă, care aduce în prin plan o fereastră de editare ca în figura 3.23. În care opțiunile puse la dispoziție sunt: edit care modifică simptomul selectat cu altul nou introdus în câmpul dedicat, cancel care închide fereastra fără a face modificări și delete care are drept scop ștergerea simptomului inserat. La apăsarea lui delete se aduce în prin plan o altă fereastra, de confirmare a ștergerii ca în Figura 3.24, care prin opțiunea yes realizează ștergerea simptomului selectat, iar prin no închide fereastra fără a face modificări.

Doctors este o altă opțiune din meniul principal, care pune la dispoziție lista cu medicii utilizatorului, cărora le-au fost acordat dreptul de acces la datele utilizatorului, de către utilizatorul însăși, ca în Figura 3.25.

Figura 3.25. Lista medicilor Figura 3.26. Cerere nouă de la medic

În cazul unor cereri de transmise de medici către utilizator acestea apar ca în aplicația utilizatorului sub forma unei ferestre care conține datele personale ale medicului care a transmis cererea, ca în Figura 3.26. Utilizatorul având posibilitatea de a amâna răspunsul cererii prin opțiunea skip, de a refuza cererea prin opțiunea cancel și de a accepta cererea prin opțiunea ok. Dacă acesta a acceptat cererea medicului, atunci medicul apare în lista utilizatorului și acesta primește dreptul de a vedea datele inserate de către utilizator, cu scopul de a presta servicii medicale.

Figura 3.27. Datele medicului Figura 3.28. Ștergerea medicului

Figura 3.29. Apel către medic

La selectarea unui medic din lista disponibilă în interfața grafică din Figura 3.25, se deschide o fereastra ce conține datele personale ale medicului, ca în Figura 3.27. În această fereastră sunt disponibile opțiunile: call care aduce în prin plan posibilitatea de a efectua un apel telefonic către medicul selectat ca în Figura 3.29, cancel care închide fereastra fără a face modificări și delete care șterge medicul din listă și îi anulează acestuia dreptul de a putea vizualiza datele introduse de către utilizator. La selectarea opțiunii delete se deschide o fereastă de confirmare cu două opțiuni: no care închide fereastra și yes care efectuează ștergerea.

Opțiunilor din categoria Measurements din carul meniului principal, vizibile în Figura 3.17 și Figura 3.18, Temperature, Weight, Height, Blood Pressure, Blood Glucose sunt realizate pe aceleași principi ca și opțiunea Symptoms, astfel afișarea, inserarea, modificarea și ștergerea a temperaturilor, greutăților, înălțimilor, tensiunilor respectiv glicemiilor se realizează identic ca în cazul simptomelor.

Opțiunea Temperature aduce în prin plan o listă cu temperaturile corpului înregistrare de către utilizator, ca în Figura 3.30. Operațiile de inserare, modificare și ștergere ale temperaturilor se realizează în mod identic ca în cazul simptomelor. Exemplu pentru inserare este disponibil în Figura 3.31, pentru modificare este disponibil în Figura 3.32 și pentru ștergere este disponibil în Figura 3.33.

Figura 3.30. Lista temperaturilor Figura 3.31. Inserarea temperaturii

Figura 3.32. Modificarea temperaturii Figura 3.33. Ștergerea temperaturii

Opțiunea Weight aduce în prin plan o listă cu greutățile corpului înregistrare de către utilizator, ca în Figura 3.34. Operațiile de inserare, modificare și ștergere ale greutăților se realizează în mod identic ca în cazul simptomelor. Exemplu pentru inserare este disponibil în Figura 3.35, pentru modificare este disponibil în Figura 3.36 și pentru ștergere este disponibil în Figura 3.37.

Figura 3.34. Lista greutăților Figura 3.35. Inserarea greutății

Figura 3.36. Modificarea greutății Figura 3.37. Ștergerea greutății

Opțiunea Height aduce în prin plan o listă cu înălțimile corpului înregistrare de către utilizator, ca în Figura 3.38. Operațiile de inserare, modificare și ștergere ale înălțimilor se realizează în mod identic ca în cazul simptomelor. Exemplu pentru inserare este disponibil în Figura 3.39, pentru modificare este disponibil în Figura 3.40 și pentru ștergere este disponibil în Figura 3.41.

Figura 3.38. Lista înălțimilor Figura 3.39. Inserarea înălțimii

Figura 3.40. Modificarea înălțimii Figura 3.41. Ștergerea înălțimii

Opțiunea Blood Pressure aduce în prin plan o listă cu tensiunile arteriale înregistrare de către utilizator, ca în Figura 3.42. Operațiile de inserare, modificare și ștergere ale tensiunilor se realizează în mod identic ca în cazul simptomelor. Exemplu pentru inserare este disponibil în Figura 3.43, pentru modificare este disponibil în Figura 3.44 și pentru ștergere este disponibil în Figura 3.45.

Figura 3.42. Lista tensiunilor Figura 3.43. Inserarea tensiunii

Figura 3.44. Modificarea tensiunii Figura 3.45. Ștergerea tensiunii

Opțiunea Blood Glucose aduce în prin plan o listă cu glicemiile înregistrare de către utilizator, ca în Figura 3.46. Operațiile de inserare, modificare și ștergere ale glicemiilor se realizează în mod identic ca în cazul simptomelor. Exemplu pentru inserare este disponibil în Figura 3.47, pentru modificare este disponibil în Figura 3.48 și pentru ștergere este disponibil în Figura 3.49.

Figura 3.46. Lista glicemiilor Figura 3.47. Inserarea glicemiei

Figura 3.48. Modificarea glicemiei Figura 3.49. Ștergerea glicemiei

În cadrul grupului Medication al meniului principal, se găsesc opțiuni specifice programelor de medicamentație. Aici se află funcționalitățile care reușesc să ajute utilizatorii în legătură cu gestiunea orelor la trebuie luate medicamente, cu evidența tipului și cantității medicamentelor deținute ți cu informații despre fiecare medicament.

Opțiunea program aduce din baza de date prin intermediul unui task asincron datele programelor de medicamentație create de medici pentru utilizator, cu ajutorul unui cereri către server, care transmite datele sub format JSON pentru a fi afișate sub forma unui liste care conține numele și orele la care necesită luate medicamentele, ca în Figura 3.50.

Figura 3.50. Lista programelor

Figura 3.51. Activarea alertelor Figura 3.52. Dezactivarea alertelor

Dacă este selectat din listă un program de medicamentație, atunci apare o fereastră cu informațiile acelui program, medicament, cantitate, oră, medicul care a creat programul, date de început și data de sfârșit a programului, precum și posibilitatea de a activa, ca în Figura 3.51, sau de a dezactiva, ca în Figura 3.52, alerte de tip notificări menite să atenționeze utilizatorul atunci când este timpul să ia un medicament.

Figura 3.53. Notificare pentru luarea medicamentelor

În cazul în care programul ce medicamentației este activat, la ora la care acesta este setat se transmite o notificare utilizatorului, ca în Figura 3.53, care atenționează în legătură cu faptul ca este timpul ca utilizatorul să ia medicamentele. În momentul în care se accesează notificarea atunci apare o interfață ce conține planul de medicamentație, ca în Figura 3.54, în care apar datele programului precum și cantitatea, medicamentului care trebuie luat, pe care o deține utilizatorul.

Sunt puse la dispoziție două opțiuni, prima fiind Take it! care o să notifice faptul că utilizatorul a luat medicamentele și modifică automat cantitatea, medicamentului care trebuie luat, deținută de utilizator prin scăderea cantității ce trebuie luate, iar a doua fiind Don’t take it! care semnalează faptul că utilizatorul nu poate lua medicamentul în acel moment. În cazul în care utilizatorul nu deține o cantitate necesară din cadrul medicamentului ce trebuie luat, atunci la accesare notificării o să apară interfața din Figura 3.55 care are doar opțiunea Don’t take it!, precum și un mesaj de alertă în legătură cu insuficiența cantității medicamentului.

Figura 3.54. Planul de medicamentație Figura 3.55. Lipsa medicamentelor necesare

O altă opțiune din cadrul meniului principal este Inventory, aceasta are drept scop stocarea și gestiunea datelor referitoare la cantitățile medicamentelor deținute de către utilizator. Aceasta aduce în prin plan o listă cu cantitățile medicamentelor deținute de către utilizator, ca în Figura 3.56. Operațiile de modificare și ștergere ale cantităților medicamentelor deținute se realizează în mod identic ca în cazul simptomelor diferența fiind că la adăugarea unei noi cantități trebuie specificat medicamentul a cărui cantitate se introduce. Exemplu pentru inserare este disponibil în Figura 3.57, pentru modificare este disponibil în Figura 3.58 și pentru ștergere este disponibil în Figura 3.59.

Figura 3.56. Lista cantităților deținute Figura 3.57. Inserarea unei noi cantități

Figura 3.58. Modificarea cantității Figura 3.59. Ștergerea cantității

O opțiune importantă în cadrul meniului principal este Drugs, aceasta conține o listă cu medicamentele disponibile în sistem ca în Figura 3.60. Importanța deosebită iese la iveală atunci când este selectat un medicament din lista respectivă, deoarece apare o interfață grafică, ca în Figura 3.61, care conține toate informațiile referitoare la prospectul medicamentului, aici incluzând moduri de administrare, cantitatea dozele, efectele secundare, interacțiuni cu alte medicamente și cu alimente, precum și alte informații importante.

Figura 3.60. Lista medicamentelor Figura 3.61. Prospectul medicamentului

Ultimul grup din cadrul meniului principal este Diets, acesta având o importanță deosebită deoarece aici se găsesc indicațiile medicilor în cadrul programelor de nutriție, precum și planificarea meselor principale ale zilei, pentru a putea primi notificări atunci când utilizatorul trebuie să respecte orele impuse.

Opțiunea Schedule pune la dispoziție o interfață grafică în care utilizatorul își poate introduce orele la care dorește să fie notificat în legătură cu respectarea, meselor ale zilei, mic dejun, prânz și cină. Dacă acestea nu au fost configurate niciodată de către utilizator atunci câmpurile care afișează orele meselor o să conțină valoarea Insert data! ca în Figura 3.62.

Configurarea orelor se face prin selectarea câmpurilor dedicate pentru fiecare masă principală a zilei, fapt ce determină apariția unei ferestre ce permite introducerea orei dorite, pentru micul dejun ca în Figura 3.63, pentru prânz ca în Figura 3.64 și pentru cină ca în Figura 3.65.

Figura 3.62. Notificări neconfigurate Figura 3.63. Setarea notificării pentru mic dejun

Figura 3.64. Setarea notificării pentru prânz Figura 3.65. Setarea notificării pentru cină

Figura 3.66. Activarea notificărilor Figura 3.67. Dezactivarea notificărilor

După ce au fost introduse orele la care se doresc setate notificările pentru fiecare masă principală ale zilei, acestea pot fi activate prin intermediul slider-urului dedicat pentru fiecare masă principală în parte, ca în Figura 3.66, sau pot fi dezactivate, fiecare în parte, tot prin intermediul slider-urilor dedicate, ca în Figura 3.67.

Figura 3.68. Notificare pentru mic dejun Figura 3.69. Informații despre mic dejun

Figura 3.70. Notificare pentru prânz Figura 3.71. Informații despre prânz

În cazul în care notificările au fost activate pentru mesele principale ale zilei, atunci pentru micul dejun se generează notificarea din Figura 3.68, pentru prânz se generează notificarea din Figura 3.70 și pentru cină se generează notificarea din Figura 3.72. Dacă notificările sunt selectate de către utilizator atunci se accesează o interfață cu date utile despre acea masă a zilei, pentru micul dejun ca în Figura 3.69, pentru prânz ca în Figura 3.71 și pentru cină ca în Figura 3.73.

Figura 3.72. Notificare pentru cină Figura 3.73. Informații despre cină

În cadrul opțiunii Recommendations din cadrul meniului principal se pune la dispoziție o listă cu alimentele recomandate pentru utilizatorul aplicației împreună cu numele medicilor propunători, ca în Figura 3.74, de către medii specialiști care dețin acorduri cu utilizatorul, în cadrul programelor de nutriție create cu scopul de a asigura o alimentație cât mai optimă pentru utilizatorul în cauză.

Figura 3.74. Lista cu alimente recomandate Figura 3.75. Lista cu alimente interzise

Ultima opțiune din cadrul meniului principal, numită Bans, pune la dispoziție o listă cu alimentele interzise pentru utilizatorul aplicației împreună cu numele medicilor propunători, ca în Figura 3.75, de către medii specialiști care dețin acorduri cu utilizatorul, în cadrul programelor de nutriție create cu scopul ca utilizatorul alimentele periculoase sau nesănătoase care pot dăuna sănătății acestora.

După cum se poate observa după numărul impresionant de opțiuni și funcționalități implementate în cadrul aplicației Android, de tip client, dedicată utilizatorilor, beneficiari de servicii medicale ale medicilor specialiști. Aplicația încearcă să formeze un ecosistem complex și prielnic gestionării datelor legate de programele de medicamentație și nutriție transmise de către medici, cu ajutorul datelor legate de starea de sănătate transmise de către utilizatori, astfel se realizează un echilibru între datele furnizate medicilor și datele primite de la medici care favorizează îmbunătățirea sănătății și a calității vieții utilizatorilor.

3.3 Aplicația Android dedicată medicilor

Aplicația Android dedicată medicilor a fost creată în Android Studio, mediul oficial de dezvoltare integrat destinat creării aplicațiilor pentru sistemul de operare Android, cu ajutorul limbajul Java, care stă la baza logicii ți a funcționalităților existente, dar și cu ajutorul limbajului XML, care stă la baza tuturor elementelor de interfață grafică.

Această aplicație are drept scop permiterii medicilor specialiști să folosească expertiza lor medicală în folosul utilizatorilor, utilizând datele medicale introduse de către aceștia pentru a putea asigura un grad cât mai optim și exact de servicii medicale.

În cadrul acestei aplicații se înregistra doar medici, această aplicației creând un mediu prielnic și singur în care utilizatorii își pot expune datele cu caracter medical unor specialiști dornici să își ofere serviciile medicale. Astfel acest serviciu medical are avantaje de ambele părți, utilizatorii găsesc medici competenți gata să rezolve probleme medicale întâmpinate de aceștia, în vreme ce medicii câștigă reputație precum și un număr impresionant de pacienți noi care pot aduce profituri substanțiale în cazul în care unii medici își oferă serviciile medicale contra cost. Din acest punct de vedere proiectul ICare poate deveni o afacere sustenabilă pe viitor.

Aplicația destinată medicilor poartă numele sugestiv de ICare Doctors, din care reiese faptul ca este vorba de aplicația ICare, a utilizatorilor, reinterpretată cu scopul de a maximiza performanțele medicilor, precum și ușurința în utilizare. Astfel medicii au un mediu dedicat în care să poată profesa fără existența barierelor legate de timpul liber tot mai scăzut, sau de distanțele mari dintre aceștia și pacienții lor.

Această aplicația este veriga lipsă din cadrul proiectului ICare, fără de care nu poate exista, întrucât ea reprezintă ”scena, pe care actorii principali (medicii) creează spectacolul de neuitat (serviciile medicale) pentru publicul (utilizatorii) tot mai numeros și în nevoie”.

Deoarece aceasta se bazează pe aplicația ICare prezentată în subcapitolul anterior, împarte cu aceasta mai multe elemente de logică cât și de design, astfel există unele elemente identice sau repetitive, dar baza cărora s-au implementat și altele unice și disponibile doar în această aplicație conform necesităților medicilor care o utilizează pentru prestarea serviciilor medicale de care aceștia sunt capabili.

În continuare este prezentată aplicația în mod complet, accentul picând pe elementele unice și inedite care creează unicitatea și funcționalitatea aceste aplicații, elementele comune cu aplicația destinată utilizatorilor fiind doar amintite.

La pornirea aplicației ICare Doctors, prima interfață grafică întâmpinată este cea de logare, ca în Figura 3.76 care obligă medicul să se autentifice înainte de a putea utiliza aplicația. Pentru autentificare este necesară introducerea adresei de email și a parolei, ca în Figura 3.77, procedeul de autentificare fiind același ca în aplicația anterioară pornind de la butonul Log In, dacă ambele câmpuri au fost introduse și validate cu succes.

Figura 3.76. Interfața pentru logare Figura 3.77. Datele necesare pentru logare

La accesarea opțiunii Create a new account se aduce în prin plan o interfață grafică ca în Figura 3.78 care permite înregistrarea unui acont nou în mod similar cu aplicația precedentă, doar că aici este necesară introducerea specializării medicului într-un câmp nou numit specialization, procesul de înregistrare pornind în momentul apăsării butonului Register, dacă toate câmpurile au fost introduse și validate cu succes. În cazul în care nu sunt introduse toate datele sau datele sunt incorecte se primesc mesaje de avertizare ca în Figura 3.79.

Figura 3.78. Interfața pentru înregistrare Figura 3.79. Mesaje de avertizare

Dacă autentificarea a fost realizată cu succes atunci se aduce în prin plan interfața grafică principală, de tip activity, ca în Figura 3.80, care în momentul creării cu ajutorul unui task asincron care cere de la server citatul de întâmpinare.

Figura 3.80. Interfața grafică principală Figura 3.81. Meniul interfeței principale

Figura 3.82. Opțiunea de Log Out Figura 3.83. Confirmare Log Out

Interfața principală conține, similar ca în aplicația precedentă, un meniu contextual în partea dreaptă sus cu o opțiune numită Log Out, ca în Figura 3.82, care permite medicilor să se delogheze după ce acceptă mesajul de confirmare din Figura 3.83.

Meniul interfeței principale din cadrul aplicației pentru medici este tip NavigationDrawler, fiind vizibil în Figura 3.81. Acesta pune la dispoziție o serie restrânsă de opțiuni care vizează atenția medicilor, informațiile pacienților aflându-se în opțiunea Pacients. În cadrul acestui meniu se vor prezenta pe rând fiecare opțiune disponibilă în rândurile ce urmează, opțiunile fiind de tip Fragment utilizate cu ajutorul unui FragmentManager.

Opțiunea Personal Info aduce în prin plan o interfață grafică ce pune la dispoziție vizualizarea datelor personale ale medicului, ca în Figura 3.84. Permite și modificarea acestor date prin intermediului butonului Edit care creează o fereastră ce face posibilă modificare datelor personale ale medicului, lucru vizibil în Figura 3.85, prin câmpurile dedicate pentru tipurile de informații, dacă se apasă pe opțiunea ok din cadrul ferestrei.

Figura 3.84. Datele personale Figura 3.85. Editarea datelor personale

Opțiunea Home are drept scop aducerea în prin plan a interfeței grafice din Figura 3.80 indiferent de locația curentă în cadrul aplicației.

O opțiune importantă este este Drugs, aceasta conține o listă cu medicamentele disponibile în sistem ca în Figura 3.86. Această opțiune este disponibilă și în aplicația pentru utilizator fiind importată și aici. Atunci când este selectat un medicament din lista respectivă apare o interfață grafică, ca în Figura 3.87, care conține toate informațiile referitoare la prospectul medicamentului, aici incluzând moduri de administrare, cantitatea dozele, efectele secundare, interacțiuni cu alte medicamente și cu alimente, precum și alte informații importante.

Figura 3.86. Lista medicamentelor Figura 3.87. Prospectul medicamentului

Opțiunea Patients este cea mai importantă din cadrul întregii aplicații, deoarece conține lista pacienților medicului, precum și toate datele inserate de către aceștia, date cruciale pentru stabilirea programelor de medicamentație și nutriție. Aceasta pune la dispoziție o interfață grafică ce conține lista pacienților care au acceptat cereri de la medicul respectiv, lucru vizibil în Figura 3.88. Se pune la dispoziție un buton în partea dreaptă jos cu o iconiță în formă de plus care are drept scop inserarea pacienților noi.

În momentul în care butonul este apăsat acesta creează o fereastră ca în Figura 3.89, care pune la dispoziție un câmp pentru a insera un pacient în funcție de adresa sa de email. Dacă se apasă pe opțiunea ok, atunci se trimite o cerere către utilizatorul în cauză, dacă și numai dacă acesta acceptă cererea de la medic atunci este introdus în lista medicului pentru a putea vizualiza datele acestuia pentru a presta servicii medicale.

Dacă se selectează un pacient din listă atunci apare o altă interfață grafică de tip activity care conține datele pacientului selectat, exact ca în Figura 3.90. În această interfață se pun la dispoziție doua opțiuni. Prima opțiune este numită Call care facilitează crearea unui apel către pacientul selectat, ca în Figura 3.91, iar a doua se numește Delete și are drept scop ștergerea pacientului selectat din listă.

Dacă se selectează opțiunea Delete se transmite o fereastră de confirmare ca în Figura 3.92, care efectuează ștergerea pacientului, doar la apăsarea opțiunii yes.

Figura 3.88. Lista pacienților Figura 3.89. Adăugarea unui pacient

Figura 3.90. Datele pacientului Figura 3.91. Apelarea unui pacient

Figura 3.92. Ștergerea unui pacient

Figura 3.93. Prima parte a meniului Figura 3.94. A doua parte a meniului

Interfață grafică din Figura 3.90 este de tip activity și implementează un alt meniu de tip NavigationDrawler, vizibil în Figura 3.93 și Figura 3.94. Acest meniu este foarte similar cu cel din aplicația destinată utilizatorilor, în el regăsindu-se informațiile stocate de către pacientul selectat, astfel medicul având acces asupra acestor date cu scopul de a transmite programe de medicamentație și nutriție. În cadrul acestui meniu, opțiunile fiind de tip Fragment utilizate cu ajutorul unui FragmentManager.

În continuare urmează prezentarea fiecărei opțiuni disponibile, accentul picând pe funcționalitățile noi disponibile doar medicului prin această aplicație.

Opțiunea Patient Info are drept scop aducerea în prin plan a interfeței grafice din Figura 3.90 indiferent de locația curentă în cadrul aplicației.

Opțiunea Home are drept scop aducerea în prin plan a interfeței grafice din Figura 3.80 indiferent de locația curentă în cadrul aplicației.

În cadrul opțiunii Symptoms se creează o interfață grafică ce conține o listă cu toate simptomele înserate de către pacientul selectat, ca în figura 3.95.

La selectarea opțiunii Temperature apare o interfață grafică ce conține o listă cu toate temperaturile corpului înserate de către pacientul selectat, ca în figura 3.96.

Prin utilizarea opțiunii Weight apare o interfață grafică ce conține o listă cu toate greutățile corpului înserate de către pacientul selectat, ca în figura 3.97.

La apăsarea pe opțiunea Height se creează o interfață grafică ce conține o listă cu toate înălțimile corpului înserate de către pacientul selectat, ca în figura 3.98.

Figura 3.95. Lista simptomelor Figura 3.96. Lista temperaturilor

Figura 3.97. Lista greutăților Figura 3.98. Lista înălțimilor

La selectarea opțiunii Blood Pressure apare o interfață grafică ce conține o listă cu toate tensiunile arteriale înserate de către pacientul selectat, ca în figura 3.99.

La apăsarea pe opțiunea Blood Glucose se creează o interfață grafică ce conține o listă cu toate valorile glicemiilor înserate de către pacientul selectat, ca în figura 3.100.

Figura 3.99. Lista tensiunilor Figura 3.100. Lista glicemiilor

Opțiunea Program are o importanță deosebită în cadrul stabilirii programelor de medicamentație de către medic pentru pacienții săi. În momentul accesării, aceasta pune la dispoziție o interfață grafică care conține o listă cu programele de medicamentație prescrise de către medicul în cauză, ca în Figura 3.101, nu și programele prescrise de către alți medici.

Inserarea unui program de medicamentație pentru pacientul selectat se realizează prin utilizarea butonului rotund din dreapta jos. La apăsarea acestuia se deschide o fereastră ca în Figura 3.102, în care sunt disponibile câmpuri dedicate pentru introducerea datelor necesare: medicamentul în cauză, dozajului, ora la care trebuie luat medicamentul, date la care începe programul și data la care se sfârșește programul. Acest lucru se poate face doar dacă pacientul deține o cantitate suficientă din cadrul medicamentului prescris.

La selectarea unui program de medicamentație din listă, apare fereastră care conține datele curente în câmpuri dedicate ca în Figura 3.103, lăsând posibilitatea modificării programului selectat, prin schimbarea oricărui parametru. Modificarea se face la selectarea opțiunii edit, în caz că se alege opțiunea delete, atunci se afișează o fereastra de confirmare ca în Figura 3.104, dacă se alege opțiunea yes atunci programul de medicamentație o să fie șters.

În cadrul meniului principal, dacă se alege opțiunea Inventory, atunci se afișează o interfață grafică care pune la dispoziție o listă cu medicamentele și cantitățile acestora deținute de către pacientul selectat, ca în Figura 3.105.

Figura 3.101. Lista programelor Figura 3.102. Adăugarea unui program

Figura 3.103. Modificarea unui program Figura 3.104. Ștergerea unui program

Figura 3.105. Lista medicamentelor deținute

Figura 3.106. Lista alimentelor recomandate Figura 3.107. Inserarea unui aliment

Opțiunea Recommendations aduce în prin plan o listă cu alimentele recomandate înregistrare de către medic pentru utilizatorul selectat, ca în Figura 3.306, dar nu pe cele înregistrate de alți medici. Operațiile de inserare, modificare, ștergere ale alimentelor se realizează în mod identic ca în aplicația precedentă. Exemplu pentru inserare este disponibil în Figura 3.107, pentru modificare este disponibil în Figura 3.108 și pentru ștergere este disponibil în Figura 3.109.

Figura 3.108. Modificarea unui aliment Figura 3.109. Ștergerea unui aliment

Figura 3.110. Lista alimentelor interzise Figura 3.111. Inserarea unui aliment

Opțiunea Bans aduce în prin plan o listă cu alimentele interzise înregistrare de către medic pentru utilizatorul selectat, ca în Figura 3.310, dar nu pe cele înregistrate de alți medici. Operațiile de inserare, modificare și ștergere ale alimentelor se realizează în mod identic ca în cazul aplicației precedente. Exemplu pentru inserare este disponibil în Figura 3.111, pentru modificare este disponibil în Figura 3.112 și pentru ștergere este disponibil în Figura 3.113.

Figura 3.112. Modificarea unui aliment Figura 3.113. Ștergerea unui aliment

Concluzii

Scopul principal al lucrării prezente, monitorizarea datelor pentru facilitarea supervizării programelor de medicamentație si nutriție, a fost atins cu succes în cadrul soluției propuse prin intermediul sistemelor mobile, mai exact prin cadrul aplicațiilor ce respectă modelul client-server care fac posibil acest lucru, acestea fiind serverul web și cele două aplicații Android dedicate utilizatorilor respectiv medicilor.

Obiectivele enunțate în deschiderea lucrării de licență au fost îndeplinite prin funcționalitățile puse la dispoziție de către soluția propusă, în care se oferă suport pentru toate datele medicale introduse de către utilizatori, permițând intervenția medicilor prin programe de medicamentație și nutriție pentru soluționarea problemelor medicale descrise.

Se poate remarca scopul nobil și umanitar al ideii care stă la baza temei lucrării de licență, tratarea persoanele aflate în suferință, din punct de vedere medical, dar și susținerea valorificării medicilor prin expunerea lor la un mediu plin de potențiali pacienți. Un factor important în acest sens fiind utilitatea soluției, care își propune să remedieze cât mai multe cazuri medicale.

Dezvoltarea proiectului ICare a necesitat utilizarea multor cunoștințe dobândite în cei trei ani de studiu, dintre care se amintesc: principii de programare, algoritmi, programe orientată pe obiect, tehnici avansate de programare, protocoale de comunicații, modelul client-server, structuri de date, baze de date, limbaje de programare, sisteme de operare mobile, tehnologii web, calcul paralel și sincronizare între firele de execuției, precum și multe altele. Acest proiect a permis și dobândirea multor cunoștințe teoretice noi, precum și utilizarea unor tehnologii noi.

Dezvoltarea bazei de date a pus probleme substanțiale în cadrul grupării și gestionării datelor primite de la aplicațiile Android, datorită faptului că eficientizarea gestionării acestora a fost prioritare pentru asigurarea unei bune funcționalități în cadrul proiectului, totuși a permis fixarea noțiunilor teoretice legate de limbajul MySQL și familiarizarea cu PhpMyAdmin în cadrul gestionării acesteia.

Serverul, prin dezvoltarea sa, a ridicat probleme în ceea ce privește transferul de date și arhitectura pe care o respectă, deoarece a necesitat un timp îndelungat și multe experiențe pentru a putea înțelege arhitectura REST și protocolul de comunicație utilizat. Dar a permis asimilării de cunoștințe noi în cadrul arhitecturii REST, aplicațiilor web, modelului client-server ți protocoalelor de comunicației.

În cadrul dezvoltării aplicațiilor Android dedicate utilizatorilor respectiv medicilor problemele au apărut în cadrul creării interfețelor grafice și a funcționalităților atașate lor, acestea fiind o noutate, a mai ridicat probleme și în cazul gestionării resurselor utilizate, în cadrul transmiterii de informații către server, dar mai ales în cadrul securității și a protecției datelor utilizate. În schimb a facilitat învățarea tehnicilor de programare necesare dezvoltării aplicațiilor Android, precum și familiarizarea cu gestiunea sistemelor complexe bazate pe componente.

Acest proiect poate să devină motivul unei afaceri sustenabile, întrucât elimină barierele dintre utilizatori și medici, sporind productivitatea celor implicați, dar și pentru faptul că poate crea noi oportunități și locuri de muncă prin atragerea medicilor în cadrul acestui sistem, în cazul transformării lui într-un serviciu plătit.

Ca și tendințe de viitor dezvoltarea proiectului poate fi continuată astfel încât să intre în producție, generând un sistem medical complex plin de beneficii atât pentru utilizatori cât și pentru medici. Se pot dezvolta în primul rând un sistem de securitate mult mai performant și eficient pentru a securiza datele vehiculate în cadrul platformei, la care se poate adăuga un sistem mai inteligent de notificări capabil să semnaleze și să acționeze în consecință atunci când apar modificări în baza de date. Se pot stratifica și grupa date în cadrul unor categorii mai eficiente și mai ușor de utilizat, interfețele grafice pot fi dezvoltate mai amănunțit pentru a fi mai ușor de utilizat și mult mai atractive, precum și un opțiuni suplimentare care să permită personalizarea conținutului și interfețelor conform necesităților utilizatorilor și medicilor.

Pot fi implementate și funcționalități diferite de cele existente pentru a sporii gradul de utilizate al platformei, astfel mărind productivitatea prin opțiuni care permit o mult mai bună gestiune a datelor vehiculate în cadrul platformei pentru o supervizare a programelor de medicamentație și nutriție cât mai optimă.

Un aspect foarte important în cadrul dezvoltării viitoare este și punerea la dispoziție a platformei realizate unei populații cât mai vaste de utilizatori, acest lucru fiind posibil prin implementarea soluției și pe alte sisteme, prin integrarea acestora pe alte sisteme mobile, cum ar fi IOS sau Windows Phone, dar mai ales pe Web, pentru a putea permite utilizarea și pe platforme de tip desktop, astfel cu o componentă centrală, serverul web la care se adaugă un număr cât mai mare de tipuri de aplicații client pe multiple platforme suportate se elimină limitările soluției și se permite o utilizare cât mai variată a funcționalităților oferite.

Ca o concluzie generală declar că în urma realizării acestei lucrări de licență am asimilat multe cunoștințe teoretice și practice, am descoperit și utilizat tehnologii noi, dar mai ales am învățat să îmi gestionez timpul și resursele, astfel timpul dedicat realizării lucrării de licență a fost bine utilizat și foarte productiv. Cunoștințele acumulate sunt vaste și din domenii diferite, acestea fiind: informatică, nutriție și medicină. După această experiență consider că sunt cu mult mai informat în ceea ce privește un stil de viață sănătos și ce presupune acesta, reușind să corectez anumite deprinderi greșite în ceea ce privește programele de medicamentație și nutriție.

Bibliografie

Dina Spector. ”Here's how many days a person can survive without water”, http://www.businessinsider.com/how-many-days-can-you-survive-without-water-2014-5 (Accesat la 2017.05.08)

Ann Pietrangelo, Elea Carey, Kimberly Holland. ”The Effects of Fast Food on the Body” http://www.healthline.com/health/fast-food-effects-on-body (Accesat la 2017.05.08)

”Medical Definition of Body mass index” http://www.medicinenet.com/script/main/art.asp?articlekey=16125

(Accesat la 2017.05.12)

”Medicine Problems”

http://www.webmd.com/a-to-z-guides/tc/prescription-medications-medication-problems

(Accesat la 2017.05.13)

”Drug Side Effects”,

https://www.drugs.com/sfx/ (Accesat la 2017.05.15)

Jim Morelli, MS, RPh. ”Allergy Drugs: Prescription and OTC Medications” http://www.rxlist.com/allergy_medications/drugs-condition.htm (Accesat la 2017.05.18)

” Drug interaction”.

https://en.wikipedia.org/wiki/Drug_interaction (Accesat la 2017.05.18)

”Drug-Food Interactions”,

https://familydoctor.org/drug-food-interactions/ (Accesat la 2017.05.18)

Fincke, Benjamin Graeme, Miller, Donald R., Spiro, Avron (Martie 1998). "The interaction of patient perception of overmedication with drug compliance and side effects". Jurnal de medicină internă generală.

Gosling, James, Joy, Bill, Steele, Guy, Bracha, Gilad, Buckley, Alex (2014). ”The Java® Language Specification”

”Write once, run anywhere?”

http://www.computerweekly.com/feature/Write-once-run-anywhere

(Accesat la 2017.05.25)

”The Java Language Environment”

http://www.oracle.com/technetwork/java/intro-141325.html (Accesat la 2017.05.25)

“Java (programming language)”

https://en.wikipedia.org/wiki/Java_(programming_language) (Accesat la 2017.05.25)

“Android (operating system)”

https://en.wikipedia.org/wiki/Android_(operating_system) (Accesat la 2017.05.28)

“Android Studio”

https://en.wikipedia.org/wiki/Android_Studio (Accesat la 2017.05.28)

“Create a Project”

https://developer.android.com/studio/projects/create-project.html (Accesat la 2017.06.02)

“Android software development”

https://en.wikipedia.org/wiki/Android_software_development (Accesat la 2017.06.02)

“Gradle”

https://en.wikipedia.org/wiki/Gradle (Accesat la 2017.06.02)

“XML”

https://en.wikipedia.org/wiki/XML (Accesat la 2017.06.03)

“Representational state transfer”

https://en.wikipedia.org/wiki/Representational_state_transfer (Accesat la 2017.06.04)

“Client–server model”

https://en.wikipedia.org/wiki/Client%E2%80%93server_model (Accesat la 2017.06.04)

“Introducing JSON”

http://www.json.org/ (Accesat la 2017.06.05)

“MySQL”

https://en.wikipedia.org/wiki/MySQL (Accesat la 2017.06.05)

“Backing Up Your Database”

https://codex.wordpress.org/Backing_Up_Your_Database (Accesat la 2017.06.05)