Licenta Informatica

UNIVERSITATEA OVIDIUS CONSTANA
FACULTATEA DE MATEMATIC I INFORMATIC

SPECIALIZAREA INFORMATIC
Servicii web utilizate ntr-o aplicaie

medical pentru SO Android
Coordonator tiinific,
Lect. Univ. Dr. Crengua M. Bogdan
Asist. Univ. Gabriela Ciobanu
Absolvent,
Nedelcu Florin Cristian
CONSTANA
2
2012
Cuprins
1. Introducere..........................................................................................................................5
1. 1 Structura lucrarii...........................................................................................................5
2. Definirea problemei............................................................................................................6
2.1 Descrierea problemei.....................................................................................................6
2.2 Obiectivele sistemului....................................................................................................6
2.3 Participanti.....................................................................................................................6
2.4 Scenarii de baza.............................................................................................................7
3. Analiza software..................................................................................................................8
3.1 Documentul de cerinte...................................................................................................8
3.1.1 Descrierea sistemului.............................................................................................8
3.1.2 Actorii software......................................................................................................9
3.1.3 Functile sistemului.................................................................................................9
3.1.3 Cereri nefunctionale.............................................................................................11
3.1.4 Descrierea cazurilor de utilizare..........................................................................11
3.2 Diagrame de secvente de sistem..................................................................................18
3.3 Modelul domeniului.....................................................................................................22
3.3.1 Concepte..............................................................................................................22
3.3.2 Identificarea claselor............................................................................................23
3.3.3 Identificarea atributelor........................................................................................24
3.3.4 Relatii de asociere................................................................................................24
3.3.5 Diagrama de clase a modelului de domeniu........................................................25
4. Servicii web......................................................................................................................26
4.1 Descrierea serviciilor web............................................................................................26
4.2 Avantajele si dezavantajele utilizarii serviciilor web...................................................28
4.3 Arhitectura SOA...........................................................................................................29
5.1 Identificarea serviciilor web candidate........................................................................31
5.1.1 Identificarea serviciilor web candidate pentru cazul de utilizare Trimitere
cerere...........................................................................................................................32
5.1.2 Identificarea serviciilor web candidate pentru cazul de utilizare Primire cerere
.......................................................................................................................................33
radiografie...................................................................................................................34
5.1.4 Identificarea serviciilor web candidate pentru cazul de utilizare Primire
radiografie...................................................................................................................35
5.1.5 Identificarea serviciilor web candidate pentru cazul de utilizare Creare fisa
medicala......................................................................................................................36
5.1.6 Identificarea serviciilor web candidate pentru cazul de utilizare Modificare
fisa...............................................................................................................................37
5.1.7 Identificarea serviciilor web candidate pentru cazul de utilizare Vizualizare
fisa...............................................................................................................................38
5.1.8 Identificarea serviciilor web candidate pentru cazul de utilizare Adaugare
radiolog.......................................................................................................................39
5.1.9 Identificarea serviciilor web candidate pentru cazul de utilizare Creare cont. 40
5.1.10 Identificarea serviciilor web candidate pentru cazul de utilizare Autentificare
.......................................................................................................................................41
5.2 Stabilirea serviciilor web.............................................................................................41
6.1 Diagrame de interactiuni..............................................................................................44
6.1.1 Proiectarea cazului de utilizare Trimiterea unei cereri.....................................44
6.1.2 Proiectarea cazului de utilizare Primire cerere................................................46
3
6.1.3 Proiectarea cazului de utilizare Trimitere radiografie......................................50

6.1.4 Proiectarea cazului de utilizare Primire radiografie........................................52
6.1.5 Proiectarea cazului de utilizare Creare fisa medicala......................................52
6.1.6 Proiectarea cazului de utilizare Modificare fisa medicala...............................53
6.1.7 Proiectarea cazului de utilizare Vizualizare fisa medicala...............................54
6.1.8 Proiectarea cazului de utilizare Adaugare radiolog in lista proprie................54
6.1.9 Proiectarea cazului de utilizare Creare cont.....................................................55
6.1.9 Proiectarea cazului de utilizare Autentificare...................................................56
6.2 Proiectarea bazei de date..............................................................................................56
7.1 Contributii proprii........................................................................................................59
8. Anexe................................................................................................................................60
a. Sistemul de operare Android..........................................................................................60
b. SOAP.............................................................................................................................61
c. WSDL............................................................................................................................63
Bibliografie...........................................................................................................................65
1. Introducere
Lucrarea de fata isi propune sa prezinte posibilitatea utilizarii unor platforme
light in cadrul unor aplicatii distribuite. Se urmareste atat analiza si constructia unui
astfel de sistem, cat si prezentarea tehnologiilor folosite si modul lor de aplicare.
In plus, in lucrare este prezentata si construirea unei aplicatii concrete, denumita
eMedicalCenter, aplicatie distribuita cu modulul client pentru sistemul de operare Android
si modulul server dezvoltat pe platforma Java.
1. 1 Structura lucrarii
Structura lucrarii este impartita in 8 capitole ce vor fi prezentate in continuare.
Al doilea capitol prezinta definirea scurtafinitia succinta a problemei, obiectivele pe
care sistemul trebuie sa le atingaindeplineasca, participantii si o scurta prezentare a
modului de lucru in aplicatie.
Capitolul cu numarul trei prezinta analiza software a sistemului. Aici se sprezinta se
identifica documentul de cerinte, se identifica actorii software si interesele lor
(functiilecerintele functionale ale sistemului), se realizeaza atat analiza si descrierea
cazurilor de utilizare, cat si diagramele de secvente de sistem. Tot aici se construieste
diagrama de clase a modelului de domeniu prin identificarea conceptelor si a claselor,
precum si a relatiilore dintre acestea.
Capitolul patru aduce la cunostinta termenul de serviciu web. Este prezentata
structura serviciilor web in general, tehnologiile utilizate, modul de declarare al serviciilor,
precum si avantajele si dezavantajele utilizarii serviciilor web. Tot aici este introdus si
termenul de arhitectura SOA, principiile si metodele de dezvoltare descrise de aceasta
arhitectura.
Capitolul cinci prezinta analiza software orientata spre servicii web a sistemului. Se
incearca stabilirea serviciilor web ce vor fi implementate mai tarziuulterior prin
identificarea serviciilor web candidate, iar din acestea serviciile web concrete.
Proiectarea si implementarea aplicatiei sunt este descrisea in capitolul sase.
ElAcesta cuprinde proiectarea fiecarui caz de utilizare, precum si proiectarea si structura
bazei de date. In plus, capitolul contine cele mai importante secvente ale codului aplicatiei.
Urmatorul capitol exprima concluziile trase stabilite in urma analizei, proiectarii si
implementarii aplicatiei, precum si contributiile proprii in dezvoltarea acesteia.
Capitolul cu numarul opt descrie pe scurt tehnologiile utilizate, cum ar fi SOAP si
6
WSDL, precum si o scurta descriere a ceea ce inseamna sistemul de operare Android.

Lucrarea se incheie cu bibliografia utilizata la redactarea acesteia precum si la
dezvoltarea sistemului descris in prezenta lucrare.
2. Definirea problemei
2.1 Descrierea problemei

Se considera o platforma de calcul light (smartphone, tableta, etc.) pe care este
instalat sistemul de operare Android.
Se doreste studierea posibilitatilor de utilizare a unor asemenea platforme in cadrul unor
aplicatii medicale distribuite scrise in Java.
2.2 Obiectivele sistemului

Sistemul trebuie sa indeplineasca urmatoarele cerinte:
1.
Ssa identifice sevicii (interfete Java) in retea;
2.
sa isi descarce din retea obiecte in stare sa colaboreze cu serverele ce asigura
serviciile cautate si apoi,

3.
sa ceara executia serviciilor.

Sistemul trebuie, de asemenea, sa dea posibilitatea platformelor light de a primi
evenimente pentru care in prealabil s-au inscris. Ori de cate ori se conecteaza la retea,
platforma isi cauta evenimentele cerandu-le unui server de gestiune a evenimentelor care
pastreaza un eveniment pana la descarcarea lui de catre toti abonatii inscrisi pentru acel tip
de eveniment.
2.3 Participanti
Participantii unui sistem informational sunt oameni care influenteaza direct sau
indirect sau sunt afectati sau influentati de dezvoltarea si/sau utilizarea sistemului. In raport
cu mediul (intreprindere, organizatie, etc.) in care va fi executat sistemul informational,
participantii pot fi:
externi, precum clienti, furnizori, dezvoltatori ai sistemelor care interactioneaza cu

sau integreaza sistemul informational, sau
interni, precum angajati ai departamentelor care suporta proiectul, personalul de

conducere, reprezentanti ai departamentelor financiare, etc.
Si dezvoltatorii sunt de asemenea participanti, deoarece participa in procesul software care

conduce la crearea sistemului final.
Pentru sistemul eMedicalCenter participantii sunt: analistul, proiectantul, programatorul
8
sistemului, medicul stomatolog, medicul radiolog si pacientul.

Participantii unui proces de dezvoltare a unui sistem informational pot fi clasificati n
functie de rolul1 lor. In cazul sistemului eMedicalCenter, rolurile sunt:
- care provider: participantii cu acest rol au dreptul de a crea noi fise medicale si de a
adauga informatii in fisele medicale existente. Participantii acestui rol sunt asimilati cu
medicul stomatolog;
- care consumer: participantii cu acest rol (asimilat cu un pacient) pot vizualiza fisa
medicala proprie si toate evenimentele continute in aceasta.
Totodata, medicul stomatolog poate avea si rolul de care consumer, putand vizualiza
informatiile continute in fisa medicala. Acelasi medic stomatolog are si rolul de a trimite
cereri catre medicul radiolog.
Rolul medicului radiolog cuprinde un singur drept, si anume de a trimite radiografiile
medicului stomatolog.
2.4 Scenarii de baza
Presupunem ca medicul stomatolog Antonescu Marian are un pacient pentru care
are nevoie de o radiografie digitala.
Pentru realizarea acesteia, medicul trimite prin intermediul telefonului o cerere de
executarealizare a unei radiografii pentru pacient. Sistemul inregistreaza cererea si o
trimite mai departe mai multor radiologi care in prealabil au fost introdusistabiliti de catre
medic.
Medicul ii va spune pacientului sa mearga pentru executarea radiografiei la oricare dintre
radiologii inscrisi la medicul respectiv. Dupa prezentarea pacientului la medicul radiolog
Petrescu Ion, acesta executarealizeaza radiografia, iar apoi o trimite medicului stomatolog
cu ajutorul telefonului mobil.
Sistemul inregistreaza radiografia si avertizeaza medicul stomatolog. Dupa ce este anuntat,
medicul stomatolog, tot prin intermediul telefonului, poate vizualiza radiografia si decide
cum sa continue tratamentul asupra pacientului.
Acelasi medic stomatolog pastreaza evidenta pacientilor folosind un set de fise. Pentru
fiecare pacient foloseste o fisa medicala in care noteaza atat datele generale ale lui, cat si
tratamentele stomatologice efectuate. Unui pacient ii va putea fi creata o singura fisa
medicala, tratamentele ulterioare fiind adaugate in fisa deja existenta. Medicul are, de
1
Un rol este o responsabilitate definita ce poate fi asumata de unul sau mai participanti (oameni, echipa sau
organizatie) intr-un context bine-definit: aparitia unui eveniment, o actiune care trebuie dusa la indeplinire
sau un sablon de relatii.
asemenea, posibilitatea de a modifica sau sterge informatiile continute intr-o fisa medicala.
Dupa crearea unei fise medicale, pacientul caruia ii apartine poate accesa informatiile
continute in fisa cu ajutorulfolosind aplicatiaei doar pentru vizualizarea informatiilor.
10
3. Analiza software
Analiza software reprezinta primul pas in procesul de dezvoltare in care are loc
definirea a ceea ce trebuie dezvoltat. Principalele obiective urmarite sunt:
intelegerea problemelor curente ale organizatiei client (in cazul nostru, sistemul
medical);
asigurarea unei viziuni comune asupra problemei si a viitoarei solutii;
culegerea si actualizarea cerintelor pentru viitorul produs software si traducerea

cerintelor clientului in cerinte software pe care echipa dezvoltatoare le va putea
intelege si integra in produs.
3.1 Documentul de cerinte

Documentul de cerinte este o descriere a functiilor si a proprietatilor sistemului ce
urmeaza a fi dezvoltat, in general ceea ce doresc participantii stakeholder-ii ca sistemul sa
execute.
Documentul cerintelor cuprinde:
descrierea sistemului: cateva fraze in care se prezinta o imagine generala asupra

sistemului;
actorii software: un actor reprezinta o abstractizare a unui utilizator sau grup de

utilizatori care interactioneaza in acelasi mod cu sistemul;
functiile sistemului: reprezinta toate functionalitatile pe care sistemul le va executa;
constrangerile impuse asupra sistemului: reprezinta conditiile de care se va tine

cont pe tot parcursul dezvoltarii (platforma hardware, software etc.).
3.1.1 Descrierea sistemului

Sistemul ofera posibilitatea comunicarii intre medicul stomatolog si radiolog in
vederea efectuarii de radiografii si introducerea acestora in fisa medicala a pacientului. De
asemenea, permite pacientului vizualizarea fisei medicale proprii.
3.1.2 Actorii software

Actorii software pentru sistemul curent sunt: medicul stomatolog, radiologul si
pacientul.
11
Pacientul reprezinta orice cetatean, iar stomatologul, respectiv radiologul, pot

deveni in anumite situatii pacienti, in acest caz avand aceeasi posibilitate de utilizare a
sistemului ca orice alt cetatean.
Niciunul dintre actorii software nu are nevoie de cunostinte despre limbajul de
programare in care va fi implementata aplicatia si nici de pregatire in prealabil de folosire a
acesteia.
3.1.3 Functile sistemului

F1 Trimiterea unei cereri de catre medicul stomatolog catre radiolog
F1.1 Cere introducerea datelor unui mesajului/cerereii
F1.2 Verifica datele introduse
F1.3 Trimite un mesajul
F1.4 Confirma trimiterea unui mesajului
F1.5 Daca datele introduse de catre medic nu sunt corecte din punct de vedere
sintactic, afiseaza un mesaj de eroare
F2 Primirea cererilor de catre radiolog
F2.1 Avertizeaza primirea unei cereri
F2.2 Afiseaza detaliile unui mesajului
F2.3 Seteaza mesajul drept vizualizat
F3 Trimiterea radiografiei de catre radiolog
F3.1 Cere introducerea datelor necesare
F3.3 Trimite radiografia
F3.4 Confirma trimiterea radiografiei
F4 Primirea radiografiei de catre medic
F4.1 Avertizeaza primirea unei radiografii
F4.2 Vizualizeazaarea o radiografieei
F4.3 Setarea acesteia drept 'Vizualizat'
F5 Crearea unei noi fise medicale de catre medic
F5.1 Cere introducerea datelor necesare
12
F5.3 Creaza o fisa medicala

F5.4 Confirma crearea unei fisei
F6 Modificarea unei fise medicale
F6.1 Cere introducerea unor date de cautare a fisei
F6.2 Cauta fisa dupa filtrul introdus
F6.3 Afiseaza fisele rezultate in urma cautarii
F6.4 Afiseaza informatiile de modificat
F6.5 Verifica datele modificate
F6.6 Salveaza modificarile
F6.7 Confirma efectuarea modificarilor
F7 Vizualizarea unei fise de catre pacient
F7.1 Cauta fisa corespunzatoare pacientului logat in sistem
F7.2 Permite cautarea datelor unei in fisea dupa anumite criterii
F7.3 Cauta in fisa medicala dupa criteriul introdus
F7.4 Afiseaza evenimentele gasite in urma cautarii, lasand posibilitatea de selectare
a unui eveniment pentru vizualizarea detaliilor
F7.5. Afiseaza detaliile evenimentului selectat
F8 Adaugarea radiologilor de catre medicul stomatolog in lista proprie
F8.1 Cere introducerea datelor unui radiologului
F8.3 Salveaza informatiile despre un radiologul
F8.4 Confirma memorarea informatiilorsalvarea
F9 Creare cont
F9.1 Cere introducerea datelor necesare crearii unui cont
F9.3 Creaza un contul
F9.4 Confirma crearea unui contului
F10 Autentificare
F10.1 Cere introducerea datelor de autentificare
13
F10.3 Autentifica utilizatorul
3.1.3 Cereri nefunctionale

Aplicatia va fi implementata folosind limajul Java;
Aplicatia va rula atat pe platforme de calcul light cu sistem de operare Android

(aplicatia client), catdar si pe sisteme de calcul cu sistem de operare Windows
(aplicatia server);
La logare, sistemul verifica drepturile de utilizare a aplicatiei (vizualizare fisa,

creare fisa etc.) de catre actorul software.
3.1.4 Descrierea cazurilor de utilizare

Caz utilizare: trimiterea unei cereri
Descriere: descrie interactiunea sistemului dintre utilizator (medic) si sistem in
vederea trimiterii unui mesaj de cerere efectuare a unei radiografii
Actori: medicul stomatolog
Eveniment: utilizatorul cere trimiterea unui mesaj
Preconditii: sistemul a verificat posibilitatea trimiterii unei cereri pe baza
drepturilor de utilizator
Postconditii: sistemul a trimis mesajul
Referinte incrucisate: F1.1 F1.5
Flux principal:
Medic stomatolog
Sistem
1. Cere trimiterea unui mesaj
2. Cere introducerea datelor mesajului
3. Introduce si trimite datele
4. Verifica datele introduse [A1]

5. Memoreaza mesajul
6. Afiseaza un mesaj de confirmare a
trimiterii mesajului
Flux alternativ:
[A1]. Datele introduse sunt incorecte:
1. Sistemul afiseaza un mesaj de eroare
2. Fluxul continua cu pasul 2 din fluxul principal
Caz utilizare: primirea unei cereri de catre radiolog
14
Descriere: descrie interactiunea sistemului cu radiologul in cazul primirii unei

cereri
Actori: radiologul
Eveniment: radiologul cere afisarea mesajului
Preconditii: sistemul a memorat o noua cerere care nu a fost vizualizata
Postconditii: radiologul a vizualizat cererea
Referinte incrucisare: F2.1 F2.2
Flux principal:
Radiolog
Sistem
2. Cere afisarea mesajului [A1]
1. Avertizeaza primirea unui mesaj nou

3. Afiseaza detaliile mesajului
4. Seteaza mesajul drept "Vizualizat"
Flux alternativ:
[A1] Radiologul cere inchiderea notificariiavertizarii
1. Fluxul principal se incheie
Caz utilizare: trimiterea unei radiografii
Descriere: descrie interactiunea sistemului cu radiologul in vederea trimiterii unei
radiografii
Actori: radiologul
Eveniment: radiologul cere sistemului trimiterea unei radiografii
Preconditii: sistemul a verificat dreptul utilizatorului de trimitere a unei radiografii
Postconditii: radiografia a fost trimisa
Flux principal:
Radiolog
Sistem
1. Cere trimiterea unei radiografii
2. Cere introducerea datelor necesare
3. Introduce si trimite datele cerute

5. Trimite radiografia
6. Confirma trimiterea radiografiei
Flux alternativ:
[A1] Datele introduse sunt incorecte
15
Caz utilizare: primirea unei radiografii de catre medic

Descriere: descrie interactiunea sistemului cu medicul in situatia primirii unei
radiografii
Actor: medicul
Eveniment: medicul cere afisarea radiografiei
Preconditii: sistemul functioneaza
Postconditii: doctorul a vizualizat radiografia
Flux principal:
Medic
Sistem
2. Cere afisarea radiografiei [A1]
1. Avertizeaza primirea unei radiografii

3. Afiseaza radiografia
4. Seteaza radiografia drept "Vizualizata"
Flux alternativ:
[A1] Medicul cere inchiderea avertizarii
1. Sistemul inchide avertizarea
2. Fluxul principal se incheie
Caz utilizare: crearea unei noi fise medicale
Descriere: descrie interactiunea sistemului cu medicul in situatia crearii unei noi
fise medicale
Actor: medicul
Eveniment: medicul a cerut sistemului crearea unei noi fise medicale
Preconditii: sistemul a verificat dreptul utilizatorului de crearea a unei noi fise
medicale
Postconditii: fisa medicala a fost creata
Flux principal:
Medic
Sistem
1. Cere crearea unei noi fise
2. Cere introducerea datelor necesare

5. Creaza fisa medicala
6. Afiseaza un mesaj de confirmare a crearii
fisei medicale
16
Flux alternativ:
2. Fluxul se continua cu pasul 2 din fluxul principal
Caz utilizare: modificarea unei fise medicale
Descriere: descrie interactiunea sistemului cu medicul in situatia modificarii unei
fise medicale
Actori: medicul
Eveniment: medicul a cerut modificarea unei fise
Preconditii: sistemul a verificat dreptul utilizatorului de modificare a unei fise
medicale
Postconditii: fisa medicala a fost modificata
Refeinte incrucisate: F6.1 F6.7
Flux principal:
Medic
Sistem
1. Cere modificarea unei fise
2. Cere introducerea unui criteriu de cautare

cautarea fisei
3. Introduce filtrul de cautare
3. Cauta fisele dupa filtrul introdus [A1]

4. Afiseaza fisele corespunzatoare cautarii
5.
Selecteaza
fisa
care
se
doreste 6. Cere selectarea informatiilor din fisa care
modificatadorita
se doresc a fi modificate
7. Selecteaza informatiile de modificat
8. Afiseaza informatiile de modificat
9. Modifica si trimite noile date
10. Verifica datele trimise [A2]

11. Salveaza modificarile facute
12. Afiseaza un mesaj de confirmare a
realizarii modificarilor
Flux alternativ:
[A1] Sistemul nu gaseste nicio fisa corespunzatoare cautarii
1. Sistemul afiseaza un mesaj
17
Caz utilizare: vizualizare fisa de catre pacient

Descriere: descrie interactiunea sistemului cu pacientul in cazul vizualizarii propriei
fise medicale
Actori: pacientul
Eveniment: pacientul cere sistemului afisarea propriei fise
Preconditii: sistemul a realizat logarea a cei putin unui pacientfunctioneaza
Postconditii: pacientul a putut vizualiza fisa medicala
Flux principal:
Pacient
1. Cere afisarea fisei medicale
Sistem
2. Cauta fisa medicala dupa informatiile
contului cu care pacientul s-a logat
3. Afiseaza o interfata de cautare in fisa
medicala dupa anumite criterii
4. Introduce si trimite criteriul de cautare
5. Cauta in fisa medicala dupa criteriul

introdus [A1]
6. Afiseaza evenimentele gasite in urma
cautarii
7. Selecteaza un eveniment pentru a vedea 8. Afiseaza detaliile evenimentului

toate informatiile pe care le contine
Flux alternativ:
[A1] Cautarea nu returneaza niciun rezultat:
1. Sistemul afiseaza un mesaj
Caz utilizare: adaugarea unui radiolog de catre medic in lista proprie
Descriere: interactiunea sistemului cu medicul in cazul adaugarii unui radiolog in
lista proprie
Actori: medicul stomatolog
Eveniment: medicul a cerut introducerea unui nou radiolog
Postconditii: introducerea radiologului de catre medic s-a efectuat cu succes
Flux principal:
18
Medic
Sistem
1. Cere introducerea unui nou radiolog
2. Cere introducerea datelor radiologului

5. Salveaza noul radiolog
6. Confirma introducerea radiologului
Flux alternativ:
[A1] Datele introduse sunt incorecte:
Caz utilizare: creare cont
Descriere: interactiunea sistemului cu utilizatorul in cazul crearii unui cont nou
Actori: utilizatorul
Eveniment: utilizatorul a cerut crearea unui cont nou
Postconditii: contul a fost creat si memorat
Flux principal:
Utilizator
1. Cere crearea unui cont nou
Sistem
2. Cere introducerea datelor contului
5. Salveaza contul
6. Confirma salvarea contului
Flux alternativ:
Caz utilizare: autentificare
Descriere: interactiunea sistemului cu utilizatorul in cazul autentificarii
Actori: utilizatorul
Eveniment: utilizatorul a cerut autentificarea in sistem
Postconditii: utilizatorul s-a autentificat
Flux principal:
Utilizator
Sistem
19
1. Cere autentificarea in sistem

2. Cere introducerea datelor de autentificare

5. Autentifica utilizatorul in sistem
Flux alternativ:
In Fig 1. Figura 1 prezentam diagrama cazurilor de utilizare software ale sistemului
eMedicalCenter.
Fig 1. Figura 1Diagrama cazurilor de utilizare
3.2 Diagrame de secvente de sistem

O diagrama de secventea de sistem este o digrama de secvente ce reprezinta
colaborarea dintre actorii software si sistem, prin mesajele transmise intre acestia.
Conceptele diagramei de secvente sunt:
linie de viata este o (perioada de existenta a unui obiect);
activare descrie (perioada de executie a unei operatii de catre un obiect sau de alte
obiecte cu care acesta colaboreaza;)
mesaj modeleaza un (flux de informatrie de la un obiect la alt obiect.)

Diagrama de secvente de sistem descrie, in general, un caz de utilizare. In
20
continuare, prezentam diagramele de secvente de sistem ale cazurilor de utilizare

indeplinite de catre sistem.
Trimitere cerere
Primire cerere
Trimitere radiografie
21
Primire radiografie
Creare fisa medicala
22
Modificare fisa medicala
Vizualizare fisa medicala
Adaugare radiolog in lista proprie
23
Creare cont
Autentificare
24
3.3 Modelul domeniului

Modelul de domeniu ilustreaza modelarea celor mai importante clase din definitia
problemei. Un model de domeniu contine reprezentarea conceptelor din lumea reala si nu a
componentelor software.
Pentru identificarea conceptelor, se identifica substantivele din descrierea problemei. Apoi
substantivele sunt transformate in clase, atribute sau valori de atribute.
3.3.1 Concepte
Am Se identificat din definitia problemeia si descrierile cazurilor de utilizare
urmatoarele concepte:
Fisa medicala (clasa)
Cetatean (clasa)
Stare de sanatate (atribut

pacient)
Drepturi (atribut)
Modificari (atribut)
Inaltime (atribut pacient)
Care provider (rol medic)
Medic (rol cetatean)
Timestamp (atribut
eveniment)
Autor fisa medicala (rol
Mesaj (clasa)
formal)
Care consumer (rol cetatean)
Container (atribut eveniment) Cerere (clasa)
Radiolog (rol cetatean)
Radiografie (clasa)
Tip radiografie (atribut

radiografie)
Pacient (rol care consumer)
Nume (atribut cetatean)

25
Data nasterii (atribut
cetatean)
Sex (atribut pacient)
Inaltime (atribut pacient)
Culoare ochi (atribut pacient) Grupa sanguina (atribut
Greutate (atribut pacient)

Eveniment (clasa)
pacient)
Document (clasa)
Imagine (clasa)
Lista evenimente (clasa)
Lista modificari (clasa)
Modificare (clasa)
3.3.2 Identificarea claselor

O clasa reprezinta descrierea unui grup de obiecte cu aceleasi proprietati (atribute)
si acelasi comportament, aceleasi relatii cu obiectele altor clase si o aceeasi semantica. Este
o modalitate de a descrie un nou tip de date.
O clasa va cuprinde definitiile datelor si operatiilor ce caracterizeaza obiectele
clasei respective, fiind astfel un sablon de creare a obiectelor.
Clasele se identifica din lista de concepte de mai sus, acestea fiind:
FisaMedicala
Cetatean
Medic
Mesaj
Cerere
Radiolog
Radiografie
Eveniment
Document
Imagine
Modificare
ListaModificari
ListaEvenimente
Pacient
3.3.3 Identificarea atributelor

Atributele reprezinta proprietati ale claselor pentru care fiecare obiect instantiat are
o valoare, acestea definind starea obiectului respectiv.
Pentru obiectele fiecarei clase din lista de mai sus, se identifica urmatoarele
26
atribute:
Cetatean: Nume
Cerere: Pacient, TipRadiografie, Medic
Radiografie: TipRadiografie
Eveniment: TimeStamp, ListaModificari
Pacient: Inaltime, DataNasterii, Greutate, Sex, CuloareOchi, GrupaSanguina
3.3.4 Relatii de asociere

O legatura in abordarea orientata spre obiecte este o conectare fizica, conceptuala,
sintactica (semantica sau sintactica) sau logica intre doua obiecte.
Doua obiecte sunt in legatura daca:
exista o cale de comunicare intre cele doua obiecte;
un obiect poate modifica starea altui obiect;
un obiect foloseste informatii din alt obiect.
Legatura intre doua obiecte poate fi de doua feluri:
unilaterala: doar unul din obiectele implicate in legatura il cunoaste pe celalalt;
bilateral: cele doua obiecte se cunosc intre ele.
Relatiile identificate intre clasele de mai sus sunt prezentate in urmatorul tabel:
Fisa medicala Pacient
Medic Radiografie
Fisa medicala - Eveniment
Cetatean Pacient
Medic Cetatean
Medic - Cerere
Radiolog Radiografie
Medic Fisa medicala
Eveniment - Document
Eveniment Imagine
Eveniment Modificare
Pacient - Cerere
Mesaj - Radiolog
Mesaj - Medic stomatolog
Eveniment ListaEvenimente
Modificare - ListaModificari
3.3.5 Diagrama de clase a modelului de domeniu

Diagrama de clase a modelului de domeniu a sistemului ce urmeaza a fi creat este
reprezentat in figura imaginea de mai jos:
27
28
4. Servicii web
Un serviciu web este o metoda de comunicare intre doua dispozitive electronice
prin intermediul internetului.
Definitia celor de la W3C pentru servicii web este:
Serviciul web este un sistem software dezvoltat sa suporte interactiuni de tipul
masina-masina prin intermediul unei retele. Contine o interfata descrisa intr-un limbaj
(WSDL) ce poate fi usor procesat de catre masina. Alte sisteme interactioneaza cu serviciul
web intr-un mod prestabilit de acesta utilizand mesaje de tip SOAP, transmise utilizand
protocolul HTTP, serializate in format XML in legatura cu alte standarde Web.
4.1 Descrierea serviciilor web

API-ul JAX-WS pune la dispozitie utilizarea adnotarilor pentru dezvoltarea cat mai
simplificata a unui serviciu web. Adnotarile definesc metodele si variabilele ce vor fi
utilizate in mesajele trimise serviciului web si raspunsurile acestuia.
Adnotarile suportate de JAX-WS sunt aplicabile urmatoarelor entitati Java:
tipuri, cum ar fi clase, tipuri de enumerare enumeratii sau interfete;
metode;
campuri reprezentand instante ale variabilelor cuprinse in clasele Java;
parametri ale metodelor Java.
Orice serviciu web este compus din doua parti:

1.
interfata - contine definitia metodelor ce vor putea fi accesate prin

intermediul serviciului web (SEI Service Endpoint Interface);
2.
clasa ce implementeaza metodele serviciului web.
Pentru a putea publica un serviciu web, clasa ce implementeaza metodele serviciului

trebuie sa fie adnotata cu elementul @WebService, ca in exemplul de mai jos:
@WebService(endpointInterface="SRV.ISrvRadiologi", targetNamespace="SRV")
public class SrvRadiologi implements ISrvRadiologi
{
}
@SOAPBinding(style=SOAPBinding.Style.RPC)
29
public interface ISrvCereri

{
public String TrimiteCerere(
@WebParam(name="IDUserMedic") int IDUserMedic,
@WebParam(name="Continut") String Continut
);
public Cerere[] getCereriNoi(
@WebParam(name="IDUserRadiolog") int IDUserRadiolog
);
public void setCerereCitita(
@WebParam(name="IDCerere") int IDCerere,
@WebParam(name="IDUserRadiolog") int IDUserRadiolog
);
}
Pentru o interpretare cat mai simpla a serviciului web, pot fi folosite adnotari precum
@WebParam, care particularizeaza numele parametrilor folositi de metodele serviciului
web in fisierul WSDL corespunzator. De exemplu, metoda TrimiteCerere in care a fost
utilizata adnotarea @WebParam arata ca in descrierea de mai jos:
<message name="TrimiteCerere">
<part name="IDUserMedic" type="xsd:int"/>
<part name="Continut" type="xsd:string"/>
</message>
Fara utilizarea acestei adnotari, metoda ar fi fost mai greu de interpretat de catre
consumatorii serviciului:
<message name="TrimiteCerere">
<part name="arg0" type="xsd:int"/>
<part name="arg1" type="xsd:string"/>
</message>
Protocolul de structurare a serviciului web este SOAP (Simple Object Access Protocol).,
Acest protocol ce specifica modul de schimb al informatiei structurate in implementarea
serviciului web.
30
Avand protocolul SOAP drept standard de descriere a obiectelor si metodelor serviciului

web, mai avem nevoie de protocolul cu ajutorul caruida accesam resursele serviciului, fiind
in acest caz HTTP (Hypertext Transfer Protocol).
4.2 Avantajele si dezavantajele utilizarii serviciilor web

Cele mai importante avantaje in utilizarea serviciilor web sunt:
interoperabilitate: problema interoperabilitatii este rezolvata de catre serviciile

web, eliminand constrangerile de platforma utilizata, sistem de operare sau limbaj
de programare atunci cand informatia este transmisa de la o masina la alta. Pentru
asta este folosit protocolul SOAP, o extindere a limbajului XML, protocol ce
asigura interpretarea datelor in aceeasi forma de pe platforme diferite.
extindere si reutilizare: serviciile web pot fi foarte usor extinse prin noi
manipulari ale datelor, putand fi vazute drept un modul al propriei aplicatii. De
asemenea, resursele aceluiasi serviciu web pot fi consumate ori de cate ori este
nevoie in oricate aplicatii.
accesare in retea: serviciile web permit logicii business sa fie expusa in retea.
Astfel, exista posibilitatea de alegere a serviciilor de care am nevoie in propria
aplicatie, reducand cu mult timpul si resursele de dezvoltare a acesteia.
usurinta in interpretare si utilizare: limbajul WSDL utilizat in descrierea

structurii unui serviciu web exprima intr-un mod simplu, dar clar modalitatea de
acces a datelor si a metodelor serviciului, avand la baza sintaxa XML. Practic,
pentru utilizarea unui serviciu web, dezvoltatorul gaseste toate informatiile de care
are nevoie pentru a avea acces la resursele acestuia in fisierul WSDL asociat.
localizare facila pe internet: pentru consumarea serviciilor web, trebuie ca acestea

sa fie accesate cu usurinta, sa poata fi usor localizate de posibilii consumatori.
Folosirea registrilor UDDI (Universal Description, Discovery and Integration)
rezolva aceasta problema.
Drept dezavantaje ale utilizarii serviciilor web, cele mai importante ar fi:
desi simplitatea serviciilor web este un avantaj din unele puncte de vedere, este in
acelasi timp si un dezavantaj. Serviciile web utilizeaza text pentru transmiterea
datelor, fiind mult mai mari cererile acestora decat alte cereri ce utilizeaza
protocoale binare. Totusi, acesta este un dezavantaj numai in situatiile conexiunilor
slabe sau foarte solicitate.
31
protocolul HTTP utilizat pentru trimiterea cererilor nu suporta sesiuni de termen

indelungat. Uneori este nevoie de conexiuni pe timp indelungat la serviciu; sunt
situatii in care serviciul ar trebui sa trimita periodic date catre client.
protocolul HTTP nu permite memorarea starilor, altfel spus daca un client trimite o
cerere catre serviciul web, iar apoi acesta pierde conexiunea cu serviciul din diferite
motive, serviciul nu stie ca aplicatia client nu mai este disponibila.
4.3 Arhitectura SOA

SOA (Service Oriented Arhitecture) este un stil arhitectural ce contine un set de
principii si metode de dezvoltare a unor aplicatii software (servicii web) sub forma unor
servicii capabile de interoperabilitate (capacitatea de a lucra impreuna, fara ca utilizatorii
sa stie acest lucru).
Conform OMG[3], SOA este o arhitectura software in care functionalitatile sunt
grupate in jurul unor procese business si impachetate sub forma unor servicii ce pot
interactiona. De asemenea, descrie infrastructura IT care permite diferitelor aplicatii sa faca
schimb de date ca si cum ar participa la acelasi proces business.
Principiile de baza pentru dezvoltarea, mentinerea si utilizarea SOA sunt:
reutilizare
granularitate
modularitate
(proprietatea
sistemului
de
fi
divizat
in
mai
multe
componente/module ce pot fi gestionate in particular fara a afecta celelalte module)
interoperabilitate
identificarea, monitorizarea si disponibilitatea serviciilor
Thomas Erl defineste in cartea [2] opt principii specifice SOA:

1. Contracte standardizate: comunicarea cu serviciul se face in mod standardizat,
definit intr-un fisier de descriere a serviciului.
2. Cuplare slaba (loose coupling): serviciul mentine putine legaturi
cu celelalte
sisteme.
3. Reutilizare: logica este divizata in mai multe servicii pentru promovarea reutilizarii.
4. Abstractizare: logica nu este cunoscuta de catre celelalte sisteme, de asemenea nici
modul de implementare (limbaj, platforma).
5. Autonomie: serviciul controleaza exclusiv logica pe care o incapsuleaza; nu poate
fi modificata de alt sistem, ci doar utilizata, extinsa.
32
6. Fara stare: minimizarea consumului de resurse prin amanarea administrarii starii

serviciului atunci cand este posibila.
7. Gasirea serviciilor in web: serviciul trebuie sa permita o detectie cat mai simpla a
sa in retea prin intermediul unor protocoale (UDDI).
8. Compunere: serviciile web trebuie dezvoltate intr-un mod in care pot fi utilizate in
dezvoltarea altor sisteme/servicii web.
Conceptul SOA are la baza o arhitectura ce defineste un model de interactiune intre trei
entitati: furnizorul de servicii (service provider), cel ce publica descrierea serviciului si
pune la dispozitie resursele acestuia, consumatorul de servicii (service consumer), cel ce
utilizeaza serviciul, descrierea acestuia putand fi accesata cu ajutorul adresei de identificare
(URI uniform resource identifier) sau printr-un registru de servicii. A treia entitate este
reprezentata de agentul ce pune la dispozitie registrul de servicii.
Un serviciu web poate indeplini atat rolul de furnizor de servicii, atunci cand primeste si
raspunde cererilor, cat si rolul de consumator de servicii, atunci cand trimite cereri catre
alte servicii web. Rolul unui serviciu web se poate schimba foarte des atunci cand este
integrat intr-un sistem complex ce include mai multe servicii web.
Un serviciu web este alcatuit de obicei din:
un contract de servicii (service contract) constand intr-o definitie WSDL. Acesta

expune metodele (operatiile) continute, putand fi usor comparat cu un API,
logica programului, care poate fi dezvoltata tinandu-se cont de destinatia acesteia

(publicarea intr-un serviciu web); in caz contrar, este nevoie de un interpretor al
acestuia pentru a putea fi adaptat si integrat intr-un serviciu web,
un procesor al mesajelor primite si trimise de serviciul web, avand principala

responsabilitate de a deserializa cererile primite si de a serializa raspunsurile
serviciului.
33
5. Analiza orientata spre servicii web

Serviciile web au aparut din necesitatea dezvoltarii unor solutii software distribuite
slab conectate care sa permita integrarea aplicatiilor.
Necesitatea dezvoltarii acestor servicii web intr-un mod cat mai eficient a dus la
proiectarea unor standarde de indeplinire a cerintelor legate de vehicularea, intretinerea,
securitatea si disponibilitatea datelor, standarde descrise de arhitectura orientata spre
servicii.
5.1 Identificarea serviciilor web candidate

In aceasta etapa urmeaza a fi create serviciile web candidate si nu serviciile web
propriu-zise. Activitatea de identificare porneste de la analiza cazurilor de utilizare
descompuse in structuri atomice independenteactivitati.
AVom analizam fiecare operatieactivitate candidata, iar cele care pot fi efectuate in
intregime fara interventia vreunui actor software, vom incerca sa o incadram in una din
urmatoarele categorii:
- task-centric: serviciul respectiv realizeaza una din activitatile unui caz de utilizare
software;
- entity-centric: serviciul respectiv inlesneste accesul la entitatile unui caz de
utilizare, cum ar fi obiecte business;
- infrastructurale: serviciul este independent de orice caz de utilizare software.
Pe parcursul identificarii serviciilor web candidate, vor fi folosite diagrame UML de
activitati cu legenda din imaginea de mai jos:
34

cerere
Nume serviciu candidat
Operatie de sistem
Categorie
VerificareDateSW
CerereNouaSW
NotificareSW
efectuata
Verifica datele introduse
Inregistreaza cerere
Avertizeaza radiologii de
Entity-centric
Task-centric
Infrastructural
existenta unui nou mesaj
35
5.1.2 Identificarea serviciilor web candidate pentru cazul de utilizare Primire cerere
Operatie de sistem
Categorie
CerereSW
CerereSW
NotificareSW
efectuata
Afiseaza detaliile cererii
Seteaza cerere drept citita
Anunta primirea unei cereri
Entity-centric
Entity-centric
Infrastructural
noi
36

radiografie
Operatie de sistem
Categorie
VerificareDateSW
RadiografieNouaSW
NotificareSW
efectuata
Inregistreaza radiografie
Avertizeaza medicul de
Entity-centric
Task-centric
Infrastructural
primirea unei noi radiografii
37
5.1.4 Identificarea serviciilor web candidate pentru cazul de utilizare Primire

radiografie
Operatie de sistem
Categorie
NotificareSW
efectuata
Avertizeaza primirea unei
Infrastructural
RadiografieSW
RadiografieSW
radiografii
Afiseaza radiografia
Seteaza radiografia drept
Entity-centric
Entity-centric
vizualizata
38
5.1.5 Identificarea serviciilor web candidate pentru cazul de utilizare Creare fisa
medicala
Operatie de sistem
Categorie
VerificareDateSW
FisaMedicalaSW
efectuata
Creare fisa medicala
Entity-centric
Task-centric
39
5.1.6 Identificarea serviciilor web candidate pentru cazul de utilizare Modificare

fisa

CautareFisaSW
Operatie de sistem efectuata

Cauta fisa dupa datele
Categorie
Task-centric
FisaMedicalaSW
VerificareDateSW
FisaMedicalaSW
introduse
Afiseaza informatiile selectate
Salveaza modificarile
Task-centric
Entity-centric
Entity-centric
40
5.1.7 Identificarea serviciilor web candidate pentru cazul de utilizare Vizualizare

fisa

CautareFisaSW
CautareFisaSW
CautareFisaSW
FisaMedicalaSW
Operatie de sistem efectuata

Cauta fisa dupa pacient
Cauta in fisa dupa datele introduse
Afisare rezultate gasite
Afiseaza detaliile evenimentului
selectat
41
Categorie
Task-centric
Task-centric
Task-centric
Task-centric
5.1.8 Identificarea serviciilor web candidate pentru cazul de utilizare Adaugare

radiolog
Operatie de sistem
Categorie
CautareRadiologSW
RadiologSW
efectuata
Cauta radiolog
Salveaza date radiolog
Task-centric
Task-centric
42
5.1.9 Identificarea serviciilor web candidate pentru cazul de utilizare Creare cont
Operatie de sistem
Categorie
VerificareDateSW
ContNouSW
efectuata
Creaza contul
Entity-centric
Task-centric
43
5.1.10 Identificarea serviciilor web candidate pentru cazul de utilizare Autentificare
Operatie de sistem
Categorie
VerificareDateSW
AutentificareSW
efectuata
Autenfica utilizator
Entity-centric
Task-centric
5.2 Stabilirea serviciilor web

Dupa analiza serviciilor web candidate, se identifica serviciile web ce vor urma a fi
implementate si publicate. Totalitatea acestora trebuie sa cuprinda toate functionalitatile
serviciului web descrise la punctul 5.1.
In acelasi timp, pentru a minimiza numarul de cereri catre serviciul web necesar pentru
indeplinirea unui task, vom avea operatii ce pot cuprinde mai multe activitati descrise in
diagramele de la punctul 5.1 ca fiind consumatoare de servicii web. De exemplu,
activitatile VerificareDateSW si AutentificareSW de la punctul 5.1.10 vor fi integrate
si implementate in serviciul web intr-o singura operatie.
Asadar, serviciile web ce vor fi implementate in sistemul eMedicalCenter sunt:
SrvConturi: cuprinde operatii de gestiune a conturilor si de autentificare;
SrvCereri: cuprinde operatii de trimitere/primire cerere, precum si de gestiune a

44
status-ului acestora;
SrvRadiografii: cuprinde operatii de trimitere/primire a radiografiilor, precum si de

gestiune a status-ului acestora;
SrvMedici: cuprinde operatii de interogare a medicilor;
SrvRadiologi: cuprinde operatii de interogare si gestiune a radiologilor;
SrvFisaMedicala: cuprinde operatii de gestiune a fiselor medicale.
45
6. Proiectare si implementare
Evolutia
metodelor de proiectare este consecinta schimbarilor calitative si
cantitative in planul abordarii sistemelor informatice, aparitiei si extinderii utilizarii

tehnicilor rapide de proiectare si a evolutiei permanente a limbajelor de programare.
Analiza orientata spre obiecte s-a concentrat in invatarea efectuarii lucrurilor
potrivite, care consta in intelegerea obiectivelor sistemului nostru, a regulilor si
constrangerilor legate de acesta. In schimb, in activitatea de proiectare se pune accentul pe
efectuarea lucrurilor asa cum se doreste prin proiectarea unei solutii care sa satisfaca
cererea.
Centrul solutiei proiectarii obiectelor il constituie crearea diagramelor de
interactiune, care ilustreaza cum colaboreaza obiectele pentru a indeplini cerintele
functionale si nefunctionale ale sistemului.
In timpul proiectarii vor fi construite si diagrame de clase de proiectare care, mai
departe, vor fi implementate.
Pentru a putea gasi o solutie optima de implementare, in timpul proiectarii trebuie
luate in considerare cateva principii de organizare a claselor, cum ar fi distribuirea
responsabilitatilor. De asemenea, pentru cresterea eficientei si a reutilizarii codului , se pot
folosi modele de proiectare.
Un mModelul de proiectare reprezinta a abstractizare a unui stil frecvent utilizat in
construirea unei solutii software.
O categorie de modele de proiectare care pot fi folosite in stabilirea
responsabilitatilor claselor software (GRASP) sunt:
1. Expert: o responsabilitate este atribuita acelei clase care are informatiile
necesare indeplinirii ei. Astfel, responsabilitatile vor fi divizate folosind o descompunere
functionala iar fiecare subresponsabilitate este atribuita clasei care detine cele mai multe
informatii pentru a o indeplini.
2. Creator: raspunde la intrebarea Cine trebuie sa fie responsabil de crearea unui
obiect a unei clase?. Clasa B va avea responsabilitatea de creare a unui obiect al clasei A
daca cel putin una din urmatoarele afirmatii este adevarata:
- B agrega obiecte ale lui A
- B contine obiecte ale lui A
- B inregistreaza obiecte ale lui A
- B contine date de initializare despre A, atribuindu-le acestuia cand va fi creat
46
3. Cuplare si coeziune: cuplarea reprezinta masura legaturilor unui element cu alte

elemente. Cuplarea creste (cuplare inalta) odata cu numarul acestor legaturi.
De obicei se doreste o cuplare joasa intre clasele unui sistem, putand fi astfel usor
reutilizate. Pericolul mentinerii unei cuplari joase o reprezinta cresterea complexitatii
sistemului. Pentru pastrarea unei complexitati cat mai simple a sistemului, se foloseste
coeziunea inalta.
4. Controller: obiect responsabil cu primirea si gestiunea evenimentelor din sistem.
Regula este de a asociere a cate unui controller (sau obiect de control) fiecarui caz de
utilizare. In situatia unui caz de utilizare complex, se pot adauga mai multe obiecte de
control, impartind fluxul de control in parti gestionabile si mai usor de inteles.
6.1 Diagrame de interactiuni

In timpul construirii diagramelor de interactiune pentru realizarea cazurilor de
utilizare, este posibila atat indentificarea specificatiilor claselor si interfetelor software care
participa la solutie, cat si imbogatirea lor cu detalii de proiectare, cum ar fi metode.
Modelul de domeniu nu ilustreaza clasele software, dar poate inspira prezenta si
numele unor clase software din modelul proiectarii. In timpul crearii diagramelor de
interactiune, dezvoltatorii se pot inspira din modelul de domeniu pentru a numi cateva
clase de proiectare, astfel incat sa creeze o proiectare cu un decalaj mic intre proiectarea
software a conceptelor din lumea reala de care este legata aplicatia.
O diagrama de clase de proiectare ilustreaza specificatiile pentru clasele si
interfetele software intr-un sistem. Informatiile caracteristice includ:
clase, asociatii si atribute
interfete, cu operatii si constante
metode
informatii cu privire la tipul de date al atributelor
dependente
In contrast cu clasele din modelul de domeniu, clasele de proiectare sunt software si
nu descrieri ale conceptelor din lumea reala.
6.1.1 Proiectarea cazului de utilizare Trimiterea unei cereri

Pentru crearea diagramei de secvente de evenimente a acestui caz, este nevoie de
introducerea unor noi clase:
47
frmMain: interfata grafica care permite accesul la toate functionalitatile sistemului,

functionalitati ce pot fi disponibile sau nu, in functie de tipul de utilizator logat
frmCerere: interfata grafica ce permite gestiunea si vizualizarea cererilor
ControllerFrmCerere: clasa controller din client ce se ocupa cu gestiunea

evenimentelor ferestrei frmCerere
srvCereri: clasa ce permite comunicarea cu modulul server al sistemului ce are ca

atributii gestiunea cererilor
ControllerCerere: clasa controller a serviciului web ce se ocupa cu gestiunea

evenimentelor acestui caz de utilizare
ManagerCerere: permite accesul la informatiile din baza de date necesare acestui

caz de utilizare.
Diagrama de secvente rezultata in urma proiectarii acestui caz este urmatoarea:
In constructia diagramei de mai sus am folosit pattern-ul Creator: clasa frmMain

are responsabilitatea crearii clasei frmCerere. Clasa frmCerere are responsabilitatea crearii
clasei ControllerFrmCerere. De asemenea, clasa srvCereri are responsabilitatea crearii
clasei ControllerCerere, iar clasa ControllerCerere are responsabilitatea crearii clasei
ManagerCerere. Clasa ControllerFrmCerere, impreuna cu ControllerCerere sunt clasele
descrise de pattern-ul Controller pentru acest caz de utilizare.
Pentru construirea serviciului utilizat in acest caz de utilizare (srvCereri) sunt utilizate
urmatoarele clase:
- interfata de definire a serviciului
package SRV;
import general.Cerere;
48
import javax.jws.WebParam;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
@WebService
@SOAPBinding(style=SOAPBinding.Style.RPC)
public interface ISrvCereri
{
public String TrimiteCerere(
@WebParam(name="IDUserMedic") int IDUserMedic,
@WebParam(name="Continut") String Continut
);
}
- clasa ce implementeaza interfata serviciului web

package SRV;
import javax.jws.WebService;
import utl.Constante;
import
import
import
import
cereri.ControllerCerere;
erori.ControllerErori;
erori.Eroare;
general.Cerere;
@WebService(endpointInterface="SRV.ISrvCereri", targetNamespace="SRV")
public class SrvCereri implements ISrvCereri {
@Override
public String TrimiteCerere(int IDUserMedic, String Continut) {
String rez = "";
try
{
rez = ControllerCerere.AdaugaCerere(IDUserMedic, Continut);

}
catch (Exception ex)
{
StackTraceElement el = ex.getStackTrace()[0];
ControllerErori.SalveazaEroare(new Eroare(el.getClassName(),
el.getMethodName(), el.getLineNumber(), "Exception: " + ex.getMessage()));
rez = Constante.FlagEroare + "Cererea nu a putut fi trimisa";
}
return rez;
}
}
6.1.2 Proiectarea cazului de utilizare Primire cerere

Clasa nou aparuta in acest caz de utilizare este:
ControllerFrmMain: clasa controller care gestioneaza evenimentele ferestrei

frmMain.
49
Diagrama de secvente a acestui caz de utilizare este:
Pattern-ul Creator este aplicat si in acest caz de utilizare, srvCereri fiind responsabil de
crearea clasei ControllerCerere, clasa ControllerCerere are responsabilitatea crearii clasei
ManagerCerere iar aceasta are responsabilitatea crearii clasei frmCerere.
Pentru primirea cererilor pe modulul client si procesarea informatiei primite, este folosit
codul de mai jos.
- metoda ce apeleaza serviciul web
private SoapObject getCereriNoi()
{
String NAMESPACE = "http://SRV/";
String METHOD_NAME = "getCereriNoi";
String URL = "";
String SOAP_ACTION = "http://SRV/getCereriNoi";
SoapObject ret = null;
50
SharedPreferences settings =
frm.getActivity().getSharedPreferences(frm.getActivity().getString(R.string.APPPREF),
0);
int IDUser = settings != null ?
Integer.parseInt(settings.getString("IDUserLogat", "")) : 0;
SoapObject request = new SoapObject(NAMESPACE, METHOD_NAME);
request.addProperty("IDUserRadiolog", IDUser);
SoapSerializationEnvelope envelope = new
SoapSerializationEnvelope(SoapEnvelope.VER11);
envelope.setOutputSoapObject(request);
envelope.dotNet = false;
envelope.encodingStyle = SoapSerializationEnvelope.XSD;
String serverIP = settings != null ? settings.getString("serverIP", "") : "";
URL = "http://" + serverIP + "/SrvCereri?wsdl";
HttpTransportSE androidHttpTransport = new HttpTransportSE(URL);
try
{
androidHttpTransport.call(SOAP_ACTION, envelope);
ret = (SoapObject) envelope.getResponse();
}
catch (IOException e)
{
e.printStackTrace();
}
catch (XmlPullParserException e)
{
e.printStackTrace();
}
}
return ret;
- metoda de mai sus returneaza un obiect de tip SoapObject ce urmeaza a fi procesat astfel:
final Handler myHandler = new Handler()
{
@Override
public void handleMessage(Message msg)
{
SoapObject obj = (SoapObject) msg.obj;
SimpleAdapter adapterListAlerte = new SimpleAdapter(
frm.getActivity().findViewById(R.id.listAlertaNoua).getContext(),
listAlerteNoi, R.layout.rowcererenoua, new String[] {"DeLa",
"Data","Detalii", "IDCerere"},new int[] {R.id.lblDeLa, R.id.lblData,
R.id.lblDetaliiCerereNoua, R.id.lblIDCerere});
listAlerteNoi.clear();
if (obj != null)
for (int i = 0 ; i < obj.getPropertyCount() ; i++)
{
SoapObject so = (SoapObject) obj.getProperty(i);
SoapObject so2 = (SoapObject) so.getProperty("medic");
so2 = (SoapObject) so2.getProperty("persoana");
String[] tmp =
so.getProperty("dataCerere").toString().substring(0, 10).split("-");
HashMap<String,String>();
HashMap<String,String> temp = new

temp.put("DeLa", so2.getProperty("nume").toString());
51
temp.put("Data", so.getProperty("nrCerere").toString() +
"/" + tmp[2]+"-"+tmp[1]+"-"+tmp[0]);
temp.put("Detalii",
so.getProperty("continutCerere").toString());
temp.put("IDCerere",
so.getProperty("IDCerere").toString());
listAlerteNoi.add(temp);
}
ListView lvAlerte = (ListView)
frm.getActivity().findViewById(R.id.listAlertaNoua);
lvAlerte.setAdapter(adapterListAlerte);
if (((ListView)
frm.getActivity().findViewById(R.id.listAlertaNoua)).getCount() == 0)
{
HashMap<String,String> temp = new
HashMap<String,String>();
temp.put("DeLa", "Nicio cerere");
temp.put("Data","");
temp.put("Detalii", "Nu aveti nico cerere noua
nevizualizata");
temp.put("IDCerere", "0");
listAlerteNoi.add(temp);
}
else
{
lvAlerte.setOnItemClickListener(new OnItemClickListener()
{
@Override
public void onItemClick(AdapterView<?> parent, View
view, int position, long id)
{
FragmentTransaction ft =
frm.getFragmentManager().beginTransaction();
Fragment frmCerere =
frm.getFragmentManager().findFragmentByTag("frmVizualizareCerere");
if (frmCerere != null)
{
ft = ft.remove(frmCerere);
frmCerere = new
frmCerere(StareFereastraCereri.Vizualizare);
}
frmCerere = new
frmCerere(StareFereastraCereri.Vizualizare);
ft.add(android.R.id.content, frmCerere,
"frmVizualizareCerere");
ft.hide(frm);
ft.commit();
Cerere c = new Cerere();
c.setIDCerere(Integer.parseInt(((TextView)view.findViewById(R.id.lblIDCerere)).getText()
.toString()));
Medic m = new Medic();
Persoana p = new Persoana();
p.setProperty(1,
((TextView)view.findViewById(R.id.lblDeLa)).getText().toString());
m.setPersoana(p);
c.setMedic(m);
c.setContinutCerere(((TextView)
view.findViewById(R.id.lblDetaliiCerereNoua)).getText().toString());
c.setNrDataCerere(((TextView)
view.findViewById(R.id.lblData)).getText().toString());
52
((frmCerere) frmCerere).setCerereDeAfisat(c);
frm.getActivity().getActionBar().setTitle("");
((eMedicalMain)frm.getActivity()).stareFereastra =
StareFereastraPrincipala.VizualizareCerere;
}
});
}
}
};
(new Thread(new Runnable()
{
@Override
public void run()
{
Message msg = myHandler.obtainMessage();
msg.obj = getCereriNoi();
}
})).start();
myHandler.sendMessage(msg);
Apelarea metodei getCereriNoi() se face pe un alt thread, iar trimiterea datelor primite in
thread-ul principal pentru afisarea acestora se face cu ajutorul unui obiect de tip Handler.
6.1.3 Proiectarea cazului de utilizare Trimitere radiografie
Pentru cazul de utilizare Trimitere radiografie, vom adauga clasele:
frmRadiografie: interfata grafica ce permite gestiunea si vizualizarea radiografiilor
ControllerFrmRadiografie: clasa controller din client ce se ocupa cu gestiunea

evenimentelor ferestrei frmRadiografie
srvRadiografie: clasa ce permite comunicarea cu modulul server al sistemului ce

are ca atributii gestiunea radiografiilor
ControllerRadiografie: clasa controller din serviciul web ce se ocupa cu gestiunea

evenimentelor acestui caz de utilizare
ManagerRadiografie: permite accesul la informatiile din baza de date necesare

acestui caz de utilizare.
Diagrama de secvente a acestui caz de utilizare este data in continuare.
53
Pentru cazurile de utilizare Trimitere radiografie si Primire radiografie, unde este nevoie de
trimiterea unor fisiere de tip imagine prin retea, este folosita o conversie a imaginii intr-un
sir de caractere, acesta fiind cel trimis apoi prin retea. De exemplu, pentru citirea
radiografiei selectate si convertirea acesteia in sir de caractere se foloseste urmatoarea
secventa de cod:
String radiografie = "";
try
{
Intent intent = Intent.getIntent(URIIMagineDeTrimis);
Uri uri = intent.getData();
Bitmap bmp = MediaStore.Images.Media.getBitmap(
owner.getActivity().getContentResolver(), uri);
ByteArrayOutputStream bos = new ByteArrayOutputStream();
bmp.compress(CompressFormat.PNG, 0, bos);
54
bmp.recycle();
byte[] img = bos.toByteArray();
bos.close();
radiografie = Base64.encodeBytes(img);
}
catch (URISyntaxException e1) { e1.printStackTrace(); }
catch (FileNotFoundException e) { e.printStackTrace(); }

catch (IOException e) { e.printStackTrace(); }
6.1.4 Proiectarea cazului de utilizare Primire radiografie
Pentru cazul de utilizare Primire radiografie vom introduce doua clase noi:
srvRadiografie: clasa ce permite comunicarea cu modulul server al sistemului; are

ca atributii gestiunea radiografiilor;
frmRadiografie: interfata grafica ce permite gestiunea si vizualizarea radiografiilor;
ControllerFrmRadiografie:
clasa
Controller
ce
se
ocupa
cu
gestiunea
evenimentelor din fereastra frmRadiografie.

Diagrama de secvente pentru acest caz de utilizare este urmatoarea:
In urma analizei si a acestui caz de utilizare, prin folosirea pattern-ului Creator:, frmMain
primeste ca responsabilitate crearea clasei frmRadiografie, aceasta din urma avand
responsabilitatea crearii clasei ControllerFrmRadiografie.
6.1.5 Proiectarea cazului de utilizare Creare fisa medicala

Pentru acest caz de utilizare, vom introduce patru noi clase:
-
frmFisaMedicala: interfata grafica ce permite gestiunea si vizualizarea fiselor

medicale
ControllerFrmFisaMedicala: clasa Controller ce se ocupa cu gestiunea

evenimentelor ferestrei frmFisaMedicala
srvFisaMedicala: clasa ce permite comunicarea cu modulul server al sistemului;

55
are ca atributii gestiunea fiselor medicale;

-
ControllerFisaMedicala: clasa care se ocupa cu gestiunea evenimentelor acestui

caz de utilizare;
ManagerFisaMedicala: clasa care se ocupa cu accesul informatiilor din baza de

date necesare acestui caz de utilizare.
Diagrama de secvente pentru acest caz este urmatoarea:
In urma analizei acestui caz si a utilizarii pattern-ului Creator, frmMain primeste ca

atributie responsabilitate crearea clasei frmFisaMedicala; , frmFisaMedicala primeste ca
atributie
crearea
clasei
ControllerFrmFisaMedicala;,
srvFisaMedicala
are
responsabilitatea crearii clasei ControllerFisaMedicala, iar aceasta are responsabilitatea

crearii clasei ManagerFisaMedicala.
De asemenea ControllerFisaMedicala, alaturi de ControllerFrmFisaMedicala, sunt clasele
descrise de pattern-ul Controller pentru acest caz de utilizare.
6.1.6 Proiectarea cazului de utilizare Modificare fisa medicala

Acest caz de utilizare nu necesita introducerea unor noi clase. Clasele ce vor fi
folosite au fost descrise in cazul de utilizare anterior.
Diagrama de secvente a acestui caz de utilizare este:
56
Atributiile claselor pentru acest caz de utilizare sunt similare celor descrise in cazul de
utilizare anterior.
6.1.7 Proiectarea cazului de utilizare Vizualizare fisa medicala

Clasele componente acestui caz de utilizare sunt similare celor descrise in ultimele
doua cazuri.
Diagrama de secvente pentru acest caz de utilizare este:
6.1.8 Proiectarea cazului de utilizare Adaugare radiolog in lista proprie

Ca si cazul de utilizare anterior, acesta nu aduce nicio modificare in atributiile
claselor implicate.
Pentru a proiecta a analiza acestui caz de utilizare, introducem urmatoarele clase:
57
frmRadiolog: interfata grafica ce permite gestiunea si vizualizarea radiologilor din

lista proprie;
ControllerFrmRadiolog: clasa Controller ce se ocupa cu gestiunea evenimentelor

ferestrei frmRadiolog;
srvRadiolog: clasa ce permite comunicarea cu modulul server al sistemului; are ca

atributii gestiunea fiselor medicale;
ControllerRadiolog: clasa care se ocupa cu gestiunea evenimentelor acestui caz de

utilizare;
ManagerRadiolog: clasa ce se ocupa cu accesul informatiilor din baza de date

necesare acestui caz de utilizare.
In urma analizei si acestui caz de utilizare, clasa frmMain va primi ca atributie crearea
clasei frmRadiolog, frmRadiolog primeste atributia responsabilitatea de creare a clasei
ControllerFrmRadiolog.
6.1.9 Proiectarea cazului de utilizare Creare cont

Pentru analiza proiectarea acestui caz de utilizare, introducem urmatoarele clase:
-
frmContNou: interfata grafica ce permite gestiunea conturilor;
ControllerFrmContNou: clasa Controller ce se ocupa cu gestiunea evenimentelor

ferestrei frmContNou;
srvConturi: clasa ce permite comunicarea cu modulul server al sistemului; are ca

atributiei gestiunea conturilor;
ControllerCont: clasa care se ocupa cu gestiunea evenimentelor acestui caz de

utilizare;
ManagerCont: clasa ce se ocupa cu accesul informatiilor din baza de date necesare

58
acestui caz de utilizare.

6.1.9 Proiectarea cazului de utilizare Autentificare

Pentru analiza proiectarea acestui caz de utilizare, introducem urmatoarele clase:
-
frmAutentificare: interfata grafica ce permite autentificarea in sistem;
ControllerFrmAutentificare:
clasa
Controller
ce
se
ocupa
cu
gestiunea
evenimentelor ferestrei frmAutentificare.

6.2 Proiectarea bazei de date

Sistemul utilizeaza o baza de date construita in SQL Server 2008 R2. Schema bazei
de date este prezentata in figura urmatoare.
59
FK_StatusCereri_Radiologi
Radiografii *
IDRadiografie
Radiologi *
FK_MedicRadiologi_Radiologi
NrRadiografie
IDRadiolog
ConstanteConfig
FK_Radiografii_Radiologi DataRadiografie
IDPersoana
IDRadiolog
AdresaCabinet
IDMedic
IDConfig
Pacient
Nume
Imagine
Valoare
Extensie
Activ
FK_Radiografii_Medici Observatii
ModificariContinutFisaMedicala *
IsPrimita
Medici *
IDModificare
Denumire
Atasament
Continut
IDTipModificare
IDPersoana
MedicRadiologi *
IDEroare
IDMedic
DataEroare
IDRadiolog
ClassName
IDFisaMedicala
IDPacient
na cala_ContinutFisaMedicala
FK_ModificariCGrupaSangui
ontinutFisaMedi
DataNastere
Sex
CuloareOchi
StareSanatate
Inaltime
Greutate
ModificariFiseMedicale *
IDModificare
FK_ModificariFiseMedi
calefi_FicariseMedi
calecale_Pacienti
FK_Modi
FiseMedi
IDPacient
AdresaCoresp
GrupaSanguina
Telefon
CuloareOchi
StareSanatate
FK_ContinutFisaMedicala_FiseMedicale
Inaltime
Greutate
IDTipModificare
FiseMedicale_TipModificare
ContiFK_Modi
nutFificarisaMedi
cala *
IDContinut
IDFisaMedicala
Denumire
TipModificare *
IDTipModificare
IDLogare
FK_Logari_Useri
IDUser
DataLogare
FK_Useri_TipuriCont
TipuriCont *
IDTipCont
Denumire
Nume
CNP
ModificariPersoane *
FK_ModificariPacienti_Pacienti
DataNastere
Sex
Logari *
IDUser
IDPersoana
AlteInformatii
IDPacient
IDPersoana
NrCerere
Useri *
Persoane *
LineNumber FK_Pacienti_Persoane
Pacienti *
IDFisaMedicala
DataCerere
IsCitita
LoginName
ContinutCerere
IDMedic
IDRadiolog
FK_Useri_Persoane
MethodName
FiseMedicale *
IDCerere
IDCerere
IDPersoana
FK_Cereri_Medici
IDTipCont
Erori
AdresaCabinet
FK_MedicRadiologi_Medici
IDMedicRadiolog
FK_StatusCereri_Cereri
IDStatusCerere
Parola
IDMedic
IDContinut
Cereri *
StatusCereri *
IDModificare
IDPersoana
ModificariPacienti *
IDModificare
FK_ModificariPersoane_Persoane
Nume
CNP
IDPacient
IDTipModificare
AdresaCoresp
Telefon
IDTipModificare
FK_ModificariPacienti_TipModificare
FK_ModificariPersoane_TipModificare
Denumire
Atasament
Continut
Dupa cum se poate observa din schema descrisa in imaginea de mai sus, baza de date
60
contine urmatoarele tabele:

-
nomenclator pentru persoane, tipuri de cont si tipuri de modificare;
tabela ConstanteConfig, ce contine valori de configurare a cererilor (ultimul numar

dat unei cereri) si a radiografiilor (ultimul numar dat unei radiografii);
tabelele Cereri si Radiografii contin cererile si radiografiile trimise de medici,

respectiv radiologi;
deoarece exista posibilitatea trimiterii unei cereri mai multor radiologi, dar in
acelasi timp este urmarita si starea cererii in raport cu fiecare radiolog, se creeaza o
tabela asociere intre cereri si radiologi, numita StatusCereri;
pentru a putea trimite cererea mai multor radiologi, este nevoie de o asociere intre
medici si radiologi. Pentru asta avem tabela MedicRadiologi, in care sunt
inregistrati radiologii inscrisi de catre fiecare medic pentru trimiterea cererilor;
tabela Useri contine datele conturilor cu care utilizatorii sistemului se pot

autentifica;
legatura intre contul de autentificare si persoana care se autentifica, care poate fi un

medic, radiolog sau pacient, nu se face in mod direct, ci printr-o legatura de tipul
Useri-TipCont-Persoane-[Medici, Radiologi, Pacienti];
pentru fiecare pacient, avem inregistrat in baza de date o fisa medicala, ce va

contine atat date generale (tabela FiseMedicale), cat si evenimente medicale
(radiografii,
interventii
medicale)
ce
sunt
inregistrate
in
tabela
ContinutFisaMedicala;
-
pentru stocarea modificarilor facute asupra fiselor medicale, pacientilor si

persoanelor avem tabele in care sunt inregistrate toate modificarile facute asupra
acestora, precum si tipul de modificare (adaugare, modificare, stergere) si data
modificarii;
baza de date contine si o tabela in care sunt salvate toate erorile aparute in serviciul
web.
In plus, Bbaza de date cuprinde si doua proceduri stocate, care incrementeaza valorile
ultimei cereri si a ultimei radiografii din tabela ConstanteConfig, proceduri apelate in
momentul trimiterii unei cereri, respectiv unei radiografii.
In baza de date sunt configurate si constrangeri de introducere a valorilor de tip NULL,
precum si de introducere a unor valori implicite atunci cand o instructiune de tip insert nu
specifica o valoare pentru un anumit camp.
De exemplu, in campul DataOperarea din tabela ModificariPersoane nu trebuie introdus
nicio valoare, introducandu-se automat data curenta.
61
7. Concluzii
eMedicalCenter introduce in domeniul medical o noua abordare in comunicarea
dintre medici si radiologi, gestiunea informatiilor schimbate intre acestia, precum si fisele
medicale, fise medicale care pot fi usor consultate de catre pacienti. Abordarea consta in
dezvoltarea unei ahitecturi software client-server orientata spre servicii web.
Pentru maximizarea usurintei de utilizare si acces la sistem, modulul client a fost dezvoltat
pentru platforme light pe care ce ruleaza sistemul de operare Android.
De asemenea, pentru centralizarea tuturor informatiilor, este folosita o baza de date in fata
careia se gaseste modulul de gestiune a datelor continute in aceasta, dezvoltat cu ajutorul
sub forma unui serviciiloru web utilizand arhitectura SOA.
7.1 Contributii proprii

Contributiaile propriie in dezvoltarea imaginea sistemului eMedicalCenter final
consta in:
analiza software si analiza orientata spre servicii;
proiectarea aplicatiei (modulul client, modulul server si baza de date);
implementarea aplicatiei;
gasirea unei solutii optime de implementare a modulului server care sa aiba atat
cerinte minime de sistem, cat si posibilitatea de a fi usor de utilizat intr-o aplicatie
pentru sistemul de operare Android;
identificarea solutiei de apelare a unui serviciu web din sistemul de operare

Android.
62
63
8. Anexe
a. Sistemul de operare Android

Android este un sistem de operare ce are la baza Linux dezvoltat pentru dispozitive
mobile, cum ar fi smartphone-uri sau tablete, iar mai nou televizoare. Este dezvoltat de
catre Open Handset Alliance, un constortiu intre peste 80 de firme ce activeaza pe aceasta
piata, in frunte cu Google.
Android este un sistem de operare free-source, ce are la baza Android Open Source Project,
proiect de dezvoltare si mententanta a acestuia.
Prima versiune comerciala a sistemului de operare Android este Android 1.0 (Astro),
introdus pe telefonul HTC Dream spre sfarsitul anului 2008. A urmatUrmeaza Android 1.1,
care a venitine cu rezolvari de bug-uri in sistem.
Fiecarei versiuni ii este atribuita si un pseudonume, acestea urmand in ordine alfabetica,
astfel: Android 1.5 (Cupcake), Android 1.6 (Donut), Android 2.0/2.1 (Eclair), Android
2.2.x (Froyo), 2.3.x (Gingerbread), 3.0 Honeycomb si 4.0.x (Ice Cream Sandwich).
Daca pana la versiunea 2.3 inclusiv, sistemul era compatibil doar cu telefoane mobile,
versiunea 3.0 face trecerea la tablete, aceasta nefiind compatibila insa cu telefoanele
mobile. In rezolvarea acestei probleme Google lanseaza versiunea 4 a sistemului de
operare Android, creand o versiune compatibila cu ambele tipuri de dispozitive, usurand
facilitand astfel dezvoltarea aplicatiilor pentru sistemul de operare Android.
Android consta intr-un nucleu bazat pe nucleul Linux versiunea 2.6, cu modificari
asupra arhitecturii de catre cei de la Google. Include API-uri si librarii scrise in C ce
ruleaza intr-un framework cu librarii compatibile Java. Android foloseste DVM (Dalvik
Virtual Machine) pentru rularea aplicatiilor Android. DVM ruleaza fisere de tip .dex
(Dalvik Executable), fisiere generate din interpretarea fisierelor .class compilate de catre
JVM.
Platforma poate fi utilizata pe sisteme cu ecran de diferite densitati, rezolutii si marimi.
Principala forma de stocare a datelor este baza de date relationala SQLite.
Fiecare aplicatie ruleaza intr-un sandbox, o zona separata de sistemul de operare, de
unde nu poate avea acces la resursele sistemului de operare decat dupa ce utilizatorul
permite acest lucru in momentul instalarii aplicatiei. De asemenea, fiecare proces ruleaza
pe o masina virtuala proprie. Astfel, sistemul Android implementeaza pricipiul
privilegiilor minime.
Interfata grafica este construita din View-uri si ViewGroup-uri. Un View poate fi un
64
camp de text, un buton, o imagine etc. Un ViewGroup reprezinta de fapt o multime de

View-uri asezate dupa un anumit layout.
b. SOAP
SOAP este acronimul expresiei Simple Object Access Protocol (Protocol simplu de
accesare al obiectelor).
SOAP specifica modalitatea de a transmite schimb de informatiie structuratea (obiecte)
prin retea. Are la baza structura XML pentru constructia mesajelor.
SOAP a luat nastere in urma cercetarilor facute de catre companiilelor Microsoft si IBM in
procesul de dezvoltare a unui protocol de comunicare bazat pe XML pentru dezvoltarea
serviciilor web.
Protocolul SOAP este compus din trei parti:
1.
Un plicO coperta (envelope) care descrie ce contine mesajul si cum este acesta
procesat;
2.
Un set de reguli de codare a informatiilor instantiate in mesaj;
3.
O conventie de reprezentare al apelurilor si a raspunsurilor serviciului web.
Protocoalele de transport ce pot fi utilizate impreuna cu SOAP sunt diverse, printere care
enumeram: HTTP, HTTPS, FTP, TCP etc.
Cel mai raspandit protocol de transport utilizat impreuna cu SOAP este HTTP.
SOAP nu impune un anumite model de programare, putand fi utilizat atat in aplicatii
desktop dezvoltate dupa arhitectura orientata spre obiecteobject oriented, cat si aplicatii
web.
De asemenea, SOAP este un protocol cross-platforminteroperabil, sistemele ce
interactioneaza putand fi implementate pe platforme diferite; aceasta libertate este data de
faptul ca SOAP este un protocol bazat pe XML ce poate fi usor interpretat de masini cu
configuratii diferite.
SOAP defineste un standard de reprezentare RPC (Remote Procedure Call), acest lucru
implicand descrierea structurii pentru un apel de procedura la distanta precum si structura
raspunsului acesteia. De aceea, SOAP poate fi privit ca o extensie a modelului RPC in
schimbul de mesaje in retea prin apelul de proceduri.
Urmatorul exemplu ilustreaza modul in care functioneaza SOAP.
<definitions xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/
xmlns:tns="SRV" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http:
//schemas.xmlsoap.org/wsdl/" targetNamespace="SRV"name="SrvConturiService
">
65
<import namespace=http://SRV/
location="http://192.168.6.101:9000/SrvConturi?wsdl=1" />
<binding xmlns:ns1="http://SRV/" name="SrvConturiPortBinding"
type="ns1:ISrvConturi">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="rpc
"/>
<operation name="CreazaCont">
<soap:operation soapAction=""/>
<input>
<soap:body use="literal" namespace="http://SRV/"/>
</input>
<output>
</output>
</operation>
<operation name="Autentifica">
<input>
</input>
<output>
</output>
</operation>
</binding>
<service name="SrvConturiService">
<port name="SrvConturiPort" binding="tns:SrvConturiPortBinding">
<soap:address location="http://192.168.6.101:9000/SrvConturi"/>
</port>
</service>
</definitions>
<definitions xmlns:tns=http://SRV/
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.xmlsoa
p.org/wsdl/" targetNamespace="http://SRV/">
<types>
<xsd:schema>
<xsd:import namespace="http://SRV/"
schemaLocation="http://192.168.6.101:9000/SrvConturi?xsd=1"/>
</xsd:schema>
</types>
<message name="CreazaCont">
<part name="loginName" type="xsd:string"/>
<part name="parola" type="xsd:string"/>
<part name="numeUser" type="xsd:string"/>
<part name="CNP" type="xsd:string"/>
<part name="Adresa" type="xsd:string"/>
<part name="IDTipCont" type="xsd:int"/>
</message>
<message name="CreazaContResponse">
<part name="return" type="xsd:string"/>
</message>
<message name="Autentifica">
<part name="loginName" type="xsd:string"/>
<part name="parola" type="xsd:string"/>
</message>
<message name="AutentificaResponse">
<part name="return" type="tns:user"/>
</message>
<portType name="ISrvConturi">
<operation name="CreazaCont" parameterOrder="loginName parola numeUser
CNP Adresa IDTipCont">
<input message="tns:CreazaCont"/>
66
<output message="tns:CreazaContResponse"/>
</operation>
<operation name="Autentifica" parameterOrder="loginName parola">
<input message="tns:Autentifica"/>
<output message="tns:AutentificaResponse"/>
</operation>
</portType>
</definitions>
<xs:schema xmlns:tns="http://SRV/" xmlns:xs="http://www.w3.org/2001/XMLSc
hema" version="1.0" targetNamespace="http://SRV/">
<xs:element name="user" type="tns:user"/>
<xs:complexType name="user">
<xs:sequence>
<xs:element name="IDUser" type="xs:int"/>
<xs:element name="loginName" type="xs:string" minOccurs="0"/>
<xs:element name="persoana" type="tns:persoana" minOccurs="0"/>
<xs:element name="tipCont" type="tns:tipCont" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="persoana">
<xs:sequence>
<xs:element name="CNP" type="xs:string" minOccurs="0"/>
<xs:element name="IDPersoana" type="xs:int"/>
<xs:element name="nume" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="tipCont">
<xs:sequence>
<xs:element name="denumireTip" type="xs:string" minOccurs="0"/>
<xs:element name="IDTipUser" type="xs:int"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
c. WSDL
WSDL este acronimul expresiei Web Service Definition Language. Acesta este un
format XML care are ca scop descrierea serviciilor web.
Un document WSDL descrie un serviciu web drept o colectie de puncte finale (endpoints) .
Elementele utilizate in documentul WSDL pentru definirea serviciilor web sunt:
-
types: un container in care sunt definite tipurile de date utilizate, tot aici se observa
si structura datelor complexe (obiectele serializate);
message: o abstractizare a tipului de date pe care serviciul il primeste prin retea

pentru indeplinirea unui task, precum si raspunsul acestuia (acolo unde este cazul);
operation: o descriere abstracta a unei operatii pe care serviciul il suporta;
port type: un set de operatii pe care un endpoint le poate executa; aici este descrisa
si forma (ordinea parametrilor) sub care serviciul web poate fi apelat;
binding: un protocol si specificare a formatului de date pentru un anumit port

type;
67
port: un punct final definit ca o combinatie dintr-o adresa de retea si un binding;
service: o colectie de unul sau mai multe port-uri.
Utilizarea acestor elemente este demonstrata in exemplul de mai jos, ce contine definirea
unui serviciu web cu o singura operatie (AdaugaFisaMedicala):
<binding xmlns:ns1="http://SRV/"
name="SrvFisaMedicalaPortBinding" type="ns1:ISrvFisaMedicala">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" styl
e="rpc"/>
<operation name="AdaugaFisaMedicala">
<input>
<soap:body use="literal" namespace="http://SRV/"/
>
</input>
<output>
<soap:body use="literal" namespace="http://SRV/"/
>
</output>
</operation>
</binding>
<service name="SrvFisaMedicalaService">
<port name="SrvFisaMedicalaPort" binding="tns:SrvFisaMedicalaPortBi
nding">
<soap:address location="http://192.168.6.103:9000/SrvFisaMedi
cala"/>
</port>
</service>
<message name="AdaugaFisaMedicala">
<part name="NumePacient" type="xsd:string"/>
<part name="CNPPacient" type="xsd:string"/>
<part name="AdresaCorespondenta" type="xsd:string"/>
<part name="TelefonPacient" type="xsd:string"/>
<part name="GrupaSanguina" type="xsd:string"/>
<part name="dataNastere" type="xsd:string"/>
<part name="sex" type="xsd:string"/>
<part name="inaltime" type="xsd:int"/>
<part name="greutate" type="xsd:int"/>
<part name="culoareOchi" type="xsd:string"/>
<part name="stareSanatate" type="xsd:string"/>
</message>
<types>
<xsd:schema>
<xs:complexType name="continutFisaMedicala">
<xs:sequence>
<xs:element name="areAtasament" type="xs:boolean"/>
<xs:element name="atasament" type="xs:base64Binary" minOccurs="0"/>
<xs:element name="continut" type="xs:string" minOccurs="0"/>
<xs:element name="data" type="xs:string" minOccurs="0"/>
<xs:element name="denumire" type="xs:string" minOccurs="0"/>
<xs:element name="IDContinutFisa" type="xs:int"/>
</xs:sequence>
</xs:complexType>
</xsd:schema>
</types>
WSDL permite importul altor documente WSDL in definitia unui singur serviciu, astfel:
68
<import namespace="http://SRV/" location="http://192.168.6.103:9000/SrvFisaMedica

la?wsdl=1"/>
Acest lucru permite separarea diferitelor elemente in documente independente.
69
Bibliografie
[1] http://www.techit.ro/analiza_software2.php
[2] Thomas Erl, Service-Oriented Architecture: Concepts, Technology, and Design,
Thomas Erl, editura, anul publicarii
[3] http://www.omg.org/technology/readingroom/SOA.htm
[4] http://www.omg.org/news/meetings/workshops/proceedings.htm
[5] http://www.opendrum.upt.ro/labs/poo/lab4.html
[6] http://nikojava.wordpress.com/2010/03/13/a-simple-web-service-in-java/
[7] http://en.wikipedia.org/wiki/Service-oriented_architecture
[8] http://www.soaprinciples.com/
[9] http://www.ibm.com/developerworks/webservices/library/ws-soa-design1/
[10] http://www.w3.org/TR/wsdl
[11] Wei Meng Lee, Beginning Android 4 Application Development, Wei Meng Lee,
editura, anul publicarii
[12] Thomas Erl, SOA Principles of service design, Thomas Erl editura, anul publicarii
[13] Crenguta Bogdan, Note de curs Proiectarea arhitecturilor software, Bogdan
Crenguta , note de curs, 2011
[14] Lenuta Alboaie, Sabin Buraga, Servicii Web - Concepte de baza si implementari,
Lenuta Alboaie, Sabin Buraga editura, anul publicarii
70

Licenta Informatica

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Licenta Informatica

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSITATEA OVIDIUS CONSTANA

FACULTATEA DE MATEMATIC I INFORMATIC

Servicii web utilizate ntr-o aplicaie

6.1.3 Proiectarea cazului de utilizare Trimitere radiografie......................................50

WSDL, precum si o scurta descriere a ceea ce inseamna sistemul de operare Android.

2.1 Descrierea problemei

2.2 Obiectivele sistemului

Ssa identifice sevicii (interfete Java) in retea;

sa isi descarce din retea obiecte in stare sa colaboreze cu serverele ce asigura

serviciile cautate si apoi,

sa ceara executia serviciilor.

externi, precum clienti, furnizori, dezvoltatori ai sistemelor care interactioneaza cu

interni, precum angajati ai departamentelor care suporta proiectul, personalul de

Si dezvoltatorii sunt de asemenea participanti, deoarece participa in procesul software care

sistemului, medicul stomatolog, medicul radiolog si pacientul.

asigurarea unei viziuni comune asupra problemei si a viitoarei solutii;

culegerea si actualizarea cerintelor pentru viitorul produs software si traducerea

3.1 Documentul de cerinte

descrierea sistemului: cateva fraze in care se prezinta o imagine generala asupra

actorii software: un actor reprezinta o abstractizare a unui utilizator sau grup de

functiile sistemului: reprezinta toate functionalitatile pe care sistemul le va executa;

constrangerile impuse asupra sistemului: reprezinta conditiile de care se va tine

3.1.1 Descrierea sistemului

3.1.2 Actorii software

Pacientul reprezinta orice cetatean, iar stomatologul, respectiv radiologul, pot

3.1.3 Functile sistemului

F5.3 Creaza o fisa medicala

F10.3 Autentifica utilizatorul

3.1.3 Cereri nefunctionale

Aplicatia va rula atat pe platforme de calcul light cu sistem de operare Android

La logare, sistemul verifica drepturile de utilizare a aplicatiei (vizualizare fisa,

3.1.4 Descrierea cazurilor de utilizare

1. Cere trimiterea unui mesaj

2. Cere introducerea datelor mesajului

3. Introduce si trimite datele

4. Verifica datele introduse [A1]

Descriere: descrie interactiunea sistemului cu radiologul in cazul primirii unei

2. Cere afisarea mesajului [A1]

1. Avertizeaza primirea unui mesaj nou

1. Cere trimiterea unei radiografii

2. Cere introducerea datelor necesare

3. Introduce si trimite datele cerute

4. Verifica datele introduse [A1]

Caz utilizare: primirea unei radiografii de catre medic

2. Cere afisarea radiografiei [A1]

1. Avertizeaza primirea unei radiografii

1. Cere crearea unei noi fise

2. Cere introducerea datelor necesare

3. Introduce si trimite datele

4. Verifica datele introduse [A1]

1. Cere modificarea unei fise

2. Cere introducerea unui criteriu de cautare

3. Introduce filtrul de cautare

3. Cauta fisele dupa filtrul introdus [A1]

doreste 6. Cere selectarea informatiilor din fisa care

7. Selecteaza informatiile de modificat

8. Afiseaza informatiile de modificat

9. Modifica si trimite noile date

10. Verifica datele trimise [A2]

Caz utilizare: vizualizare fisa de catre pacient

4. Introduce si trimite criteriul de cautare

5. Cauta in fisa medicala dupa criteriul

7. Selecteaza un eveniment pentru a vedea 8. Afiseaza detaliile evenimentului

1. Cere introducerea unui nou radiolog