+ All Categories
Home > Documents > FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE...

FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE...

Date post: 25-Oct-2019
Category:
Upload: others
View: 19 times
Download: 0 times
Share this document with a friend
74
FACULTATEA DE AUTOMATIC ˘ SI CALCULATOARE DEPARTAMENTUL CALCULATOARE Managementul studiilor clinice bazat pe tehnologia blockchain LUCRARE DE LICEN ¸ T ˘ A Absolvent: Alin Dan ¸ TANDEA Conduc˘ ator ¸ stiin¸ tific: asis. Ing. Cosmina Ivan 2018
Transcript
Page 1: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

FACULTATEA DE AUTOMATICA SI CALCULATOAREDEPARTAMENTUL CALCULATOARE

Managementul studiilor clinice bazat pe tehnologia blockchain

LUCRARE DE LICENTA

Absolvent: Alin Dan TANDEAConducator stiintific: asis. Ing. Cosmina Ivan

2018

Page 2: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al
Page 3: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

Cuprins

Lista figurilor 11

Lista tabelelor 13

Glosar 14

Capitolul 1 Introducere - Contextul proiectului 151.1 Contextul proiectului . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.2 Continutul lucrarii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Capitolul 2 Obiectivele Proiectului 192.1 Obiective principale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2 Obiective secundare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Capitolul 3 Studiu Bibliografic 213.1 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.1 Structura de date . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.1.2 Topologia retelei . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.1.3 Functii de hash si criptografie . . . . . . . . . . . . . . . . . . . . . 233.1.4 Mecanism de consens . . . . . . . . . . . . . . . . . . . . . . . . . . 233.1.5 Smart contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1.6 Implementari ale tehnologiei blockchain . . . . . . . . . . . . . . . . 253.1.7 Ethereum, Hyperledger Fabric, Corda . . . . . . . . . . . . . . . . . 26

3.2 Scenarii de utilizare ale tehnologiei blockchain . . . . . . . . . . . . . . . . 283.3 Tehnologia blockchain ın studiile clinice . . . . . . . . . . . . . . . . . . . . 28

3.3.1 Modelarea cercetarii clinice sub forma unei retele deafaceri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Capitolul 4 Analiza si Fundamentare Teoretica 314.1 Cerinte sistem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1.1 Cerinte functionale . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.1.2 Cerinte non-functionale . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2 Cazuri de utilizare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

8

Page 4: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

4.2.1 Cercetator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.2.2 Agent de reglementare . . . . . . . . . . . . . . . . . . . . . . . . . 344.2.3 Sponsor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2.4 Descrierea cazurilor de utilizare . . . . . . . . . . . . . . . . . . . . 36

4.3 Tehnologii utilizate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.3.1 Hyperledger Fabric . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.3.2 Hyperledger Composer . . . . . . . . . . . . . . . . . . . . . . . . . 394.3.3 MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.3.4 Loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.3.5 Passport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.3.6 OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.3.7 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.3.8 Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Capitolul 5 Proiectare de Detaliu si Implementare 455.1 Arhitectura conceptuala a sistemului . . . . . . . . . . . . . . . . . . . . . 45

5.1.1 Definitia retelei de afaceri . . . . . . . . . . . . . . . . . . . . . . . 465.2 Retea blockchain Hyperledger Fabric . . . . . . . . . . . . . . . . . . . . . 515.3 Interactiunea cu reteaua blockchain . . . . . . . . . . . . . . . . . . . . . . 525.4 Management utilizatori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.5 Arhitectura aplicatiei client . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.5.1 Servicii HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.5.2 Componentele aplicatiei client . . . . . . . . . . . . . . . . . . . . . 58

Capitolul 6 Testare si Validare 616.1 Testarea retelei blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . 616.2 Testare la nivelul API-ului REST . . . . . . . . . . . . . . . . . . . . . . . 626.3 Testare la nivelul aplicatiei client . . . . . . . . . . . . . . . . . . . . . . . 63

Capitolul 7 Manual de Instalare si Utilizare 657.1 Cerinte preliminare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657.2 Instalare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7.2.1 Instalare mediu de rulare Hyperledger Fabric . . . . . . . . . . . . . 657.2.2 Instalare Hyperledger Composer . . . . . . . . . . . . . . . . . . . . 667.2.3 Instalare definitie retea . . . . . . . . . . . . . . . . . . . . . . . . . 667.2.4 Configurare server REST . . . . . . . . . . . . . . . . . . . . . . . . 677.2.5 Configurare interfata utilizator . . . . . . . . . . . . . . . . . . . . 68

7.3 Manual de utilizare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Capitolul 8 Concluzii 718.1 Rezultate obtinute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718.2 Dezvoltari ulterioare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

9

Page 5: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

Bibliografie 73

Anexa A Profil de conexiune Hyperledger Composer 75

Anexa B Configurare server REST cu utilizatori multiplii 77

Anexa C Modul pentru testarea aplicatiei client 78

10

Page 6: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

Lista figurilor

3.1 Lant proof-of-work folosit de Bitcoin[1] . . . . . . . . . . . . . . . . . . . . 223.2 Retea client-server vs peer-to-peer[2] . . . . . . . . . . . . . . . . . . . . . 223.3 Retele de afaceri centralizate[2] . . . . . . . . . . . . . . . . . . . . . . . . 293.4 Retele de afaceri decentralizate[2] . . . . . . . . . . . . . . . . . . . . . . . 30

4.1 Cazuri de utilizare cercetator . . . . . . . . . . . . . . . . . . . . . . . . . 344.2 Cazuri de utilizare agent de reglementare . . . . . . . . . . . . . . . . . . . 354.3 Cazuri de utilizare sponsor . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.4 Implementarea unei retele blockchain uitlizand Hyperledger Composer . . . 414.5 Model abstract de functionare al protocolului OAuth[3] . . . . . . . . . . . 42

5.1 Arhitectura de nivel ınalt a sistemului . . . . . . . . . . . . . . . . . . . . . 455.2 Arhitectura conceptuala a sistemului . . . . . . . . . . . . . . . . . . . . . 465.3 Modelul de date al aplicatiei . . . . . . . . . . . . . . . . . . . . . . . . . . 475.4 Studiu clinic modelat subforma unui asset . . . . . . . . . . . . . . . . . . 475.5 Generarea unui sir de caractere aleator ın limbajul TypeScript . . . . . . . 485.6 Exemplu regula de acces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.7 Adaugarea unui nou responsabil pentru un studiu clinic . . . . . . . . . . . 505.8 Parametrul tranzactiei din figura 5.7 . . . . . . . . . . . . . . . . . . . . . 515.9 Ciclul de viata al unei retele blockchain . . . . . . . . . . . . . . . . . . . . 515.10 Raspuns server REST pentru utilizator neautorizat . . . . . . . . . . . . . 545.11 Procesul de autentificare al unui utilizator . . . . . . . . . . . . . . . . . . 555.12 Pagina pentru asocierea identitatii unui utilizator utilizator . . . . . . . . . 565.13 Procesul de asociere al unei identitati . . . . . . . . . . . . . . . . . . . . . 565.14 Serviciul HTTP al aplicatiei client . . . . . . . . . . . . . . . . . . . . . . . 575.15 Componenta de configurare . . . . . . . . . . . . . . . . . . . . . . . . . . 585.16 Diagrama de componente a aplicatiei client . . . . . . . . . . . . . . . . . . 585.17 Decoratorul @Component . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.18 Reutilizarea unei componente Angular . . . . . . . . . . . . . . . . . . . . 59

6.1 Testare functionalitate de adaugare a unui nou participant . . . . . . . . . 616.2 Testare apeluri tranzactii . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626.3 Documentatie API generata folosind Swagger . . . . . . . . . . . . . . . . 63

11

Page 7: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

6.4 Interfata web pentru rulare teste . . . . . . . . . . . . . . . . . . . . . . . 64

7.1 Pagina de autentificare a serviciului extern . . . . . . . . . . . . . . . . . . 687.2 Pagina principala a cercetatorului . . . . . . . . . . . . . . . . . . . . . . . 697.3 Butoane pentru operatii asupra inregistrarilor . . . . . . . . . . . . . . . . 697.4 Pagina dedicata studiilor clinice . . . . . . . . . . . . . . . . . . . . . . . . 70

12

Page 8: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

Lista tabelelor

3.1 Comparatie la nivel ınalt: PoW vs BFT . . . . . . . . . . . . . . . . . . . 243.2 Comparatie la nivel ınalt a implementarilor tehnologiei blockchain . . . . . 263.3 Comparatie Ethereum, Hyperledger Fabric, Corda conform cu[4] . . . . . . 27

4.1 Asociere functionalitati - cazuri de utilizare . . . . . . . . . . . . . . . . . . 334.2 Definitii ale resurselor disponibile ın limbajul de modelare . . . . . . . . . 40

5.1 Imagini Docker utilizate ın mediul de dezvoltare . . . . . . . . . . . . . . . 525.2 Puncte de acces ın reteaua blockchain . . . . . . . . . . . . . . . . . . . . . 535.3 Puncte de acces interogari . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

13

Page 9: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

Glosar

API Application Programming Interface. Set de functii si metode cu rol ın stabilirea unuicontract ıntre diferite programe pentru realizarea comunicarii.

blockchain baza de date distribuita, ıntretinuta de o serie de participanti care valideazaınregistrarile din cadrul retelei folosind comunicare peer-to-peer.

BNA Business Network Archive. Implementarea cazurilor de utilizare ıntr-o retea blockchainHyperledger Fabric.

CRUD Create, Read, Update, Delete. .

HTTP HyperText Transfer Protocol. Protocol pentru transmiterea de mesaje.

Hyperledger Fabric framework pentru implementarea unei retele blockchain.

JSON JavaScript Object Notation. Format folosit pentru schimbul de informatii ıntrediferite sisteme.

peer-to-peer Arhitectura de retea pentru aplicatii distribuite.

REST REpresentational State Transfer Endpoint. Stil arhitectural pentru servicii bazatepe protocolul HTTP.

14

Page 10: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

Capitolul 1

Introducere - Contextul proiectului

La momentul actual, domeniul medical beneficiaza pe deplin de instumentele digi-tale puse la dispozitie pentru a oferi servicii pacientilor. Instrumentele digitale au dus lasimplificarea procedurilor si metodologiilor din domeniu. In ultimii ani institutiile medi-cale au ınceput sa renunte la ınregistrarile stocate ın format fizic si au adoptat ınregistraridigitale. Aceasta abordare creste eficienta personalului medical, simplifica activitatea aces-tora si necesita mai putin spatiu pentru stocarea informatiilor. Totusi, odata cu adoptareauneltelor digitale, apar si ıngrijorarile cu privire la siguranta datelor cu caracter personalale pacientilor.

1.1 Contextul proiectului

Studiile clinice reprezinta o parte importanta a cercetarii ın domeniul medical.Aceasta parte din cercetarea medicala presupune implicarea pacientilor pentru testareaanumitor tratamente. Aceste tratamente pot fi fie un medicament nou, o procedura med-icala noua sau un dispozitiv medical. Scopul studiilor clinice este de a oferi cercetatorilorposibilitatea de a evalua eficienta si siguranta acestor noi tratamente. De cele mai multeori studiile clinice sunt folosite pentru a determina daca un anumit medicament este maieficient decat altul deja existent pentru o anumita boala sau daca un medicament are maiputine efecte secundare.

Importanta acestui domeniu reiese si din investitiile atrase ın acest domeniu. Anual,domeniul studiilor clinice atrage investitii majore. In anul 2016 industria studiilor cliniceera evaluata la 40.0 de miliarde de dolari, fiind estimat ca pana ın anul 2025 sa ajunga la65.2 miliarde. Din acest motiv, exista riscul aparitiei fraudelor sau al falsificarii datelorcolectate ın cadrul unui studiu clinic.

Exista numeroase platforme care au ca scop simplificarea metodologiilor din cadrulunui studiu clinic. Acestea simplifica activitati precum planificarea studiilor clinice, man-agementul pacientilor ınrolati sau colectarea de date. Aceste ınregistrari au o importantamajora ın cadrul cercetarii clinice si al reglementarii acestora. De aceea, sistemele folosite

15

Page 11: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

16

trebuie sa asigure corectitudinea datelor colectate si sa reduca riscul de falsificare al aces-tora.

1.2 Continutul lucrarii

Aceasta sectiune prezinta structura documentului de licenta. Documentul estestructurat pe urmatoarele capitole:

Capitolul 1(Introducere)

Primul capitol al lucrarii are ca scop identificarea contextului temei propuse. Suntpreentate aspecte generale legate de subiect alaturi de dificultatile ıntalnite ın domeniu.Pe langa aceste aspecte, se prezinta pe scurt continutul acestui document.

Capitolul 2(Obiectivele Proiectului)

Obiectivele principale si secundare ale proiectului alaturi de motivatia pentru alegereatemei lucrarii sunt prezentate ın acest capitol.

Capitolul 3(Studiu Bibliografic)

Tehnologia blockchain se afla la baza sistemului implementat. De aceea, acest capi-tol prezinta o analiza a particularitatilor tehnologiei si a relevantei acestora pentru dome-niul studiilor clinice. Sunt prezentate implementari ale tehnologiei alaturi de o comparatiea avantajelor si dezavantajelor oferite de aceste implementari, cu aplicare pe domeniulstudiilor clinice.

Capitolul 4(Analiza si Fundamentare Teoretica)

In acest capitol sunt prezentate cerintele functionale si non-functionale specifice unuisistem pentru managementul studiilor clinice. Sunt prezentati principalii actori din sistemalaturi de cazurile de utilizare asociate fiecaruia. Capitolul se ıncheie prin prezentareape scurt a tehnologiilor si uneltelor utilizate pentru implementarea unui sistem care saındeplineasca cerintele functionale si non-functionale impuse.

Capitolul 5(Proiectare de Detaliu si Implementare)

Componentele principale ale sistemului si interactiunea dintre acestea sunt prezen-tate ın acest capitol. Capitolul descrie modul de implementare al definitiei unei reteleblockchain, unele fluxuri de executie precum si o descriere a componentelor interfetei uti-lizator.

Page 12: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

1.2. CONTINUTUL LUCRARII 17

Capitolul 6(Testare si Validare)

Definirea unor procese de testare este necesara pentru a asigura calitatea sistemuluiimplementat. Acest capitol prezinta uneltele de testare puse la dispozitie pentru testareaunei retele blockchain, a punctelor de acces ın retea si ale aplicatiei client.

Capitolul 7(Manual de Instalare si Utilizare)

Capitolul descrie dependintele hardware si software ale sistemului implementat.Sunt descrisi pasii necesari pentru punerea ın functiune a componentelor sistemului. Capi-tolul contine, de asemenea un manual de utilizare al aplicatiei cu scopul de a familiarizautilizatorii cu aplicatia client a sistemului.

Capitolul 8(Concluzii)

Capitolul contine o analiza critica asupra avantajelor si dezavantajelor aduse desistemul implementat. Sunt prezentate, de asemenea posibilitatile de ımbunatatire si ex-tindere a sistemului.

Page 13: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al
Page 14: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

Capitolul 2

Obiectivele Proiectului

2.1 Obiective principale

Obiectivul principal al lucrarii este implementarea unui sistem distribuit pentrumanagementul studiilor clinice cu scopul de a simplifica munca entitatilor implicate ınactivitatile din cadrul studiilor clinice si al celor responsabile de aplicarea reglementarilorspecifice domeniului. In acest sens, obiectivele specifice necesare atingerii obiectivuluiprincipal sunt:

1. Dezvoltarea unui sistem care ofera posibilitatea desfasurarii activitatilor din cadrulunui studiu clinic precum: managementul pacientilor, specificarea responsabilitatilorutilizatorilor implicati.

2. Implementarea unui mecanism de colectare a datelor flexibil. Utilizatorilor li se oferaflexibilitatea de a defini formulare de colectare a datelor specifice nevoilor ıntalniteintr-un studiu clinic.

3. Facilitarea accesului entitatilor responsabile de reglementarea studiilor clinice. Aceastapresupune implementarea unui mecanism care sa furnizeze utilizatorilor istoricul ıntimp al activitatilor din cadrul studiilor clinice.

2.2 Obiective secundare

Unul dintre obiectivele secundare ale sistemului este controlul accesului utilizatorilorla serviciile oferite de sistem. Mecanismul de autentificare al utilizatorilor trebuie sa ofereaccesul la resurse doar utilizatorilor care au drepturile necesare definite ın regulile de accesale sistemului. Sunt definite 4 tipuri de utilizatori ai aplicatiei:

• Administrator: Responsabil de emiterea si revocarea identitatii celorlalti utilizatoridin sistem.

19

Page 15: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

20 CAPITOLUL 2. OBIECTIVELE PROIECTULUI

• Cercetator: Foloseste functionalitatile pentru managementul studiilor clinice oferitede sistem.

• Agent de reglementare: Supervizeaza activitatile din cadrul unui studiu clinic. Uti-lizeaza istoricul ın timp al activitatilor din cadrul unui studiu clinic pentru a-siındeplini obiectivele.

• Sponsor: Interesat de rezultatele obtinute ın cadrul unui studiu clinic. Poate vizual-iza rapoarte legate de activitatea din studiile clinice.

Managementul identitatii participantilor este de asemenea unul din obiectivele sis-temului implementat. Fiecare utilizator al sistemului foloseste cheia asociata identitatiilor pentru a autoriza operatiile ın cadrul sistemului. In acest fel este posibila generareaunui istoric ın timp al activitatilor din sistem, alaturi de utilizatorii responsabili de acesteactivitati.

Protectia datelor cu caracter personal ale pacientilor este un alt obiectiv al sistemuluiimplementat. Utilizatorilor le este permis accesul doar la resursele de care au nevoie pentrua-si desfasura activitatea. Aplicatia utilizeaza liste de acces care definesc regulile de citiresi scriere asociate participantilor definiti anterior asupra resurselor sistemului. In acest feleste asigurata protectia datelor fara a fi afectata activitatea utilizatorilor aplicatiei.

Un alt obiectiv este folosirea unei arhitecturi distribuite, sub forma unei retele departicipanti ın care fiecare contribuie la memorarea si validarea datelor din sistem. Fiecarenod din retea detine o copie a informatiilor, fiind astfel dificila falsificarea datelor fara caaceasta sa fie observata de ceilalti participanti. Redundanta asigura de asemenea tolerantala erori prin eliminarea punctului unic de esec.

Page 16: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

Capitolul 3

Studiu Bibliografic

In acest capitol sunt prezentate o serie de concepte si tehnologii necesare pentru omai buna ıntelegere a temei alese si a modului ın care au fost utilizate pentru implementareasistemului. Capitolul continua prin descrierea aplicarii acestor concepte ın anumite domeniiprecum si ın domeniul studiilor clinice. Sunt prezentate unele beneficii aduse de acestetehnologii, alaturi de o comparatie a implementarilor existente ale acesteia.

3.1 Blockchain

Termenul de blockchain a devenit cunoscut odata cu cresterea ın popularitate a mon-edelor virtuale, ın special a monedei virtuale Bitcoin1. O retea blockchain poate fi definitaca fiind o baza de date distribuita, intretinuta de o serie de participanti care valideazainregistrarile din cadrul retelei folosind o comunicare de tip peer-to-peer. Inregistrarile dincadrul retelei sunt securizate prin metode criptografice care asigura imutabilitatea datelor.Rezolvarea conflictelor care pot aparea ıntre ınregistrarile din retea are loc prin utilizareaunor algoritmi de consens. Aceasta sectiune analizeaza urmatoarele aspecte ale tehnologiei:structura de date, aspecte legate de criptografie, topologia retelei, algoritmi de consens,smart contracts, permisiuni si implementari ale tehnologiei.

3.1.1 Structura de date

Structura de date folosita reprezinta unul dintre mijloacele care asigura integritateadatelor din reteaua blockchain. Documentatia monedei virtuale Bitcoin descrie structurade date folosita ca fiind o lista invers inlantuita ın care fiecare element, numit bloc, continehash-ul blocului anterior, un timestamp si radacina unui arbore Merkle [5]. Frunzelearborelui sunt hash-uri ale tranzactiilor iar nodurile din arbore sunt hash-uri ale nodurilorfiu. In acest fel este asigurata integritatea tranzactiilor din structura de date. Figura 3.1prezinta structura de date folosita de Bitcoin[1].

1https://bitcoin.org

21

Page 17: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

22 CAPITOLUL 3. STUDIU BIBLIOGRAFIC

Figura 3.1: Lant proof-of-work folosit de Bitcoin[1]

Fiecare bloc din structura de date este identificat prin functia hash a header-uluiblocului curent si a blocului anterior. Conceptul implementat de moneda virtuala Bitcoineste urmat de alte implementari(Ethereum2, Hyperledger Fabric3, Corda4, etc) care auadus unele modificari acestei structuri, dar pastreaza unele concepte de baza introduse deBitcoin.

3.1.2 Topologia retelei

O caracteristica importanta a unei retele blockchain este lipsa unei autoritati cen-trale care sa intermedieze tranzactiile din cadrul retelei. Pentru validarea si propagareatranzactiilor este folosita o retea peer-to-peer de participanti[6]. In cadrul unei astfelde retele fiecare participant are aceleasi responsabilitati si privilegii, spre deosebire de otopologie client-server unde reteaua are un nod central cu capabilitati si responsabilitatidiferite fata de clientii din retea. Figura 3.2 ilustreaza diferenta dintre cele doua toplogii.

Figura 3.2: Retea client-server vs peer-to-peer[2]

2https://www.ethereum.org/3https://hyperledger-fabric.readthedocs.io/en/latest/4https://www.corda.net/

Page 18: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

3.1. BLOCKCHAIN 23

Fiecare peer detine o copie a informatiilor din retea. Acest lucru face dificila modi-ficarea abuziva a datelor, orice modificare fiind vizibila pentru ceilalti participanti.

3.1.3 Functii de hash si criptografie

O functie de hash reprezinta o metoda unidirectionala de mapare a unui sir decaractere de lungime arbitrara la un sir de caractere cu lungime fixa. Proprietatile necesarepentru o functie de hash sunt:

• Calcul rapid: efortul computational pentru calcularea rezultatului trebuie sa fiemic indiferent de sirul de intrare.

• Unidirectionala: obtinerea sirului original din hash nefezabila

• Determinista: rezultatul pentru un anumit sir de intrare este acelasi indiferent decate ori este calculat.

• Rezistenta la coliziuni: oricare ar fi sirurile de intrare a,b functia de hash h(a)= h(b) doar daca a = b. Cu alte cuvinte un sir de intrare produce ıntotdeauna unrezultat unic.

• Schimbarile mici din sirul de intrare produc schimbari majore ın rezultatulfunctiei de hash.

Printre algoritmii de hash folositi de diferitele implementari ale tehnologiei blockchain senumara SHA256(Bitcoin)[1] sau Keccak-256(Ethereum)[7]. Aceste functii sunt folosite siın cadrul mecanismelor pentru stabilirea consensului.

Pentru controlarea accesului ın reteaua blockchain este folosita metoda de crip-tografie cu cheie publica. Aceasta presupune folosirea unei perechi de chei formata dintr-ocheie privata si o cheie publica, derivata din cheia privata. Partea publica a cheii poate fifolosita pentru criptarea datelor. Datele criptate pot fi decriptate doar cu ajutorul partiiprivate a cheii[8].

3.1.4 Mecanism de consens

O proprietate importanta a unei retele blockchain este lipsa unei autoritati centralecare sa valideze tranzactiile efectuate de participanti. Din aceasta cauza apare nevoiaexistentei unor mecanisme responsabile de rezolvarea conflictelor care apar ın cadrul reteleiıntre ınregistrarile detinute de participantii din retea. Algorimii de consens cei mai folositisunt: Proof of Work(PoW) si Bizantine Fault Tolerance(BFT).

PoW este algoritmul aflat ın spatele unor monede virtuale precum Bitcoin si Ethereum.Algoritmul este conceput sub forma unei competitii ın care participantii din retea ısi folos-esc puterea de calcul pentru rezolvarea unei probleme[9]. Primul participant care rezolva

Page 19: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

24 CAPITOLUL 3. STUDIU BIBLIOGRAFIC

problema primeste dreptul de a crea urmatorul bloc din structura de date alaturi de o an-umita recompensa. Rezolvarea problemei presupune efort masiv de calcul[10] si din acestmotiv este folosita drept masura de siguranta. Pentru a modifica intrarile deja salvate ınblockchain un atacator are nevoie de mai mult de 50% din puterea de calcul a ıntregii retele,un astfel de atac fiind nefezabil. In acest mod este asigurata corectitudinea informatiilor,ınsa metoda folosita este ineficienta.

BFT asigura ajungerea la consens ın cazul ın care doar o parte din patricipanti suntatacatori. Un algoritm pentru problema cunoscuta sub numele de ”Problema generalilorbizantini”[11] a fost implementat ın anul 1999 de Miguel Castro si Barbara Liskov subnumele de Practical Bizantine Fault Tolerance(PBFT)[12]. Algoritmul ıncearca ajungereala un consens ın cadrul sistemului, pastrand ın acelasi timp o latenta scazuta si eficientaridicata. Pasii algoritmului sunt urmatorii:

• Un client trimite o cerere

• Cererea este transmisa celorlalti clienti

• Ceilalti clienti executa cererea si transmit raspunsul clientului care a initiat cererea

• Clientul asteapta pana cand primeste F + 1 raspunsuri identice, unde F este numarulmaxim de noduri malitioase tolerate

Conditia pentru functionarea corecta a sistemului este ca numarul de noduri malitioasedin sistem sa fie mai mic decat 1/3 din numarul total de noduri din sistem.

O comparatie la nivel ınalt a celor doua mecanisme de stabilire a consensului esteprezentata in tabelul 3.1. Tabelul prezinta o comparatie a celor doi algoritmi luand ınconsiderare unele proprietati importante ale unei retele blockchain: identitatea nodurilor,performanta, scalabilitatea, rezistenta la atacuri sau puterea consumata.

Tabelul 3.1: Comparatie la nivel ınalt: PoW vs BFT

Proof of Work Bizantine Fault Tolerance

Managementul identitatiinodurilor

deschis, decentralizat fiecare nod trebuie sacunoasca informatii desprecelelalte noduri

Scalabilitate excelenta limitataPerformanta(throuput) limitata excelenta(mii de tranzacti-

i/secPerformanta(latenta) latenta crescuta excelenta(similara cu cea in-

dusa de retea)Putere consumata Ridicata(PoW necesita put-

ere de calcul ridicata)Scazuta

Numar total de atacatoritolerati

25% din puterea de calcul 33% din numarul de noduricare voteaza

Page 20: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

3.1. BLOCKCHAIN 25

Se poate observa faptul ca algoritmii reprezinta doua abordari diferite ın cadrul uneiretele blockchain. PoW pune accent pe scalabilitate dar prezinta o performanta scazutaın timp ce BFT asigura performanta ridicata dar cu o scalabilitate redusa. Decizia ın cepriveste tipul de algoritm folosit depinde de nevoia sistemelor implementate.

3.1.5 Smart contract

Un smart contract reprezinta ”un set de promisiuni ın format digital ın care partileimplicate actioneaza conform acestor promisiuni”[13]. Altfel spus aceste contracte sunto reprezentare digitala a unor clauze contractuale, integrate ın software pentru a mediaactiuni prin operatii bazate pe reguli. Odata ce preconditiile pentru un smart contract suntındeplinite si acesta este initiat actiunile din cadrul lui sunt executate, ele fiind irevocabile.

3.1.6 Implementari ale tehnologiei blockchain

Prima implementare cu succes a tehnologiei blockchain a fost realizata de monedavirtuala bitcoin. Odata cu cresterea acesteia ın popularitate au aparut diverse implemen-tari ale acestei tehnologii, fiecare avand unele particularitati si scopuri de utilizare diferite.

Tipuri de implementari. Exista 3 tipuri de implementari ale tehnologiei blockchain:public, privat si bazat pe permisiuni[14][15]. Tabelul 3.2 prezinta o analiza la nivel ınalta celor 3 tipuri de implementari. Sunt luate ın considerare aspecte precum drepturile deacces, performanta, costurile implicate, avantajele si dezavantajele fiecarei implementariprecum si numarul de puncte de esec ın cazul fiecareia.

Blockchain public. In cadrul unul blockchain public nu exista nevoia definiriiunor drepturi de acces. Orice entitate are drepturi de acces egale ın cadrul retelei si poateparticipa la procesul de validare a tranzactiilor. Din acest punct de vedere un blockchainpublic foloseste o topologie decentralizata nefiind prezenta o autoritate centrala care samedieze tranzactiile din retea. O astfel de implementare este folosita de catre monedelevirtuale Bitcoin sau Ethereum. In cadrul acestor retele participantii efectuaza tranzactiifara a fi implicata o a treia entitate ın acest proces. Pentru a se ajunge la un consens, unmecanism de tip PoW este folosit, acesta avand un impact asupra performantei retelei sia consumului de enegie si resurse[10].

Blockchain privat. Spre deosebire de un blockchain public, cel privat folosesteo topologie centralizata. Accesul la retea este controlat de o autoritate centrala, aceastaavand dreptul de a lua decizii si de a implementa reguli ın cadrul retelei. Un astfel deblockchain poate fi folosit ın cazul ın care este necesara restrictionarea accesului publiculuilarg la retea. O astfel de retea se bazaza pe stabilirea unui nivel ridicat de ıncredere ınautoritatea centrala responsabila de administrarea retelei. Deoarece doar o singura entitateeste responsabila de procesul de validare a tranzactiilor, apare avantajul performanteicrescute ın comparatie cu un blockchain public.

Blockchain bazat pe permisiuni. Acesta abordare poate fi vazuta ca un hibridıntre un blockchain privat si unul public. Autoritatea ın retea este detinuta de un set

Page 21: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

26 CAPITOLUL 3. STUDIU BIBLIOGRAFIC

de entitati care pot face parte din organizatii diferite. Aceste entitati stabilesc drepturilede acces la retea si participa la validarea tranzactiilor. Drepturile de acces depind deidentitatile participantilor, fiind nevoie de executarea unor smart contracts ınainte de exe-cutarea unor tranzactii pentru validarea identitatii participantilor. Hyperledger Fabric[16]si Corda sunt implementari ale unui astfel de blockchain. Ambele sunt solutii open-sourcecare pot fi folosite pentru stocarea sı partajarea datelor ıntre participantii retelei. Ambeleofera solutii pentru implementarea unei retele distribuite pentru stocarea ınregistrarilor,punanad accent pe protejarea datelor si siguranta acestora.

Tabelul 3.2: Comparatie la nivel ınalt a implementarilor tehnologiei blockchainPublic Privat Bazat pe permisiuni

Topologie retea decentralizatapartialdecentralizata

partialdecentralizata

Definire

Oricine are accesla datele din retea.Toate nodurileparticipa la validare

Permisiunile de accessunt controlate de osingura entitate deıncredere din retea

Permisiunile de accessunt controlate de unnumar prestabilitde noduri cu autoritate

Beneficii

- Sigur, deoarece totiparticipantii contribuiela validarea tranzactiilor- Transparent, toatetranzactiile fiind publiceiar entitatile implicateanonime

- Verificare eficientaa tranzactiilor de catreautoritatea centrala- Autoritatea centraladecide entitatile careau acces la retea

- Eficient, deoarece unnumar relativ mic denoduri verifica tranzactiile- Drepturile de acces suntcontrolate de un setpredeterminat de noduri- Controlul nu este detinutde catre o autoritate centrala

Provocari Eficienta scazutaControlul este detinutde o singura entitate

Cost scazut ridicat mediuPerformanta scazuta excelenta ridicataPuncte deesec

n 1 * (nodurile cu autoritate)

Se observa ca eficienta si performanta retelei scad odata cu cresterea decetralizariiacesteia. Aceasta se datoreaza metodei de stabilire a consensului si a numarului de entitatiimplicate ın acest mecanism.

3.1.7 Ethereum, Hyperledger Fabric, Corda

In continuare este prezentata o comparatie ıntre principalele solutii disponibile pen-tru implementarea unei retele distribuite folosind tehnologia blockchain. Aceste solutiisunt: Ethereum, Hyperledger Fabric si Corda[4]. Tabelul 3.3 prezinta o comparatie acaracteriticilor celor 3 solutii:

Page 22: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

3.1. BLOCKCHAIN 27

Tabelul 3.3: Comparatie Ethereum, Hyperledger Fabric, Corda conform cu[4]

Caracteristica Ethereum HyperledgerFabric

Corda

descriere platforma gener-ica blockchain

platforma mod-ulara blockchain

solutie dis-tribuita pentrudomeniul finan-ciar

mod de operare fara permisiuni,public, privat

bazat pe permi-siuni, privat

bazat pe permi-siuni, privat

consens PoW suport pentrudiferite mecan-isme

consens real-izat de ”notarynodes”

smart contract Solidity Go, Java Kotlin, Javamoneda virtuala Ether fara, poate fi

implementata cuajutorul smartcontract

fara

Ethereum si Hyperledger Fabric sunt gandite pentru utilizarea ıntr-un spectru largde cazuri de utilizare. Spre deosebire de acestea, Corda are ca utilizare principala domeniulfinanciar[17].

In ce priveste mecansimul de consens Hyperledger Fabric ofera posibilitatea utilizariia diferite mecansime de consens. Stabilirea consensului are loc la nivelul tranzactiilor siimplica doar partile care sunt responsabile de tranzactie. Nodurile din retea detin roluridiferite ın obtinerea consensului. Hyperledger Fabric ımparte nodurile din sistem ın 3 cat-egorii: peer, orderer, client [2][16]. Nodurile de tip peer mentin registrul cu date si primescmesaje pentru actualizarea registrului. Nodurile de tip client reprezinta utilizatorii reteleisi au capabilitatea de a invoca tranzactii. Comunicarea ıntre peer -uri prin intermediulcanalelor de comunicare este asigurata de nodurile de tip orderer.

Corda foloseste o abordare similara cu Hyperledger Fabric pentru stabilirea consen-sului. Aceasta are loc la nivelul tranzactiilor si utilizeaza doar partile implicate. Consensultrebuie determinat ıntre participantii retelei numiti notary nodes [17], existand libertateaalegerii algoritmului folosit.

Spre deosebire de cele doua abordari de mai sus, Ethereum foloseste un mecanismPoW. Acest aspect duce la scaderea performantei procesarii tranzactiilor.

Lucarea foloseste ın continuare platforma Hyperledger Fabric pentru implementareasistemului. Principala motivatie pentru utilizarea acestei platforme este flexibilitatea ofer-ita ın implementarea cazurilor de utilizare. Spre deosebire de Corda, cu specializare pedomeniul financiar, Hyperledger Fabric si Ethereum pot fi aplicate ıntr-un spectu larg dedomenii. Performanta este un alt motiv pentru alegerea platformei Hyperledger Fabric.Posibilitatea de alegere a mecanismului de consens, spre deosebire de Ethereum, duce la

Page 23: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

28 CAPITOLUL 3. STUDIU BIBLIOGRAFIC

imbunatatirea performantei ın ce priveste timpul de procesare a tranzactiilor.

3.2 Scenarii de utilizare ale tehnologiei blockchain

Sectiunea curenta descrie unele scenarii de utilizare ın anumite domenii care potbeneficia de pe urma utilizarii tehnologiei blockchain. Sunt prezentate aspecte ale tehnolo-giei blockchain care pot ajuta la imbunatatirea metodologiilor din aceste domenii.

Determinarea identitatii digitale. In prezent, detaliile despre identitatea uneipersoane sunt stocate de catre diferite institutii. Din acest motiv o persoana poate avea oserie de identitati asupra carora nu detine controlul. Apar provocari ın ce priveste sigurantadatelor cu caracter personal si a existentei unui punct unic de esec.

Tehnologia blockchain poate imbunatatii procedurile din acest domeniu. Prin oferireacontrolului absolut asupra identitatii lor, participantii pot alege detaliile care vor sa le par-tajeze despre identitatea lor. Aceasta identitate a unui utilizator nu va fi stocata de o altaentitate, ci aceste entitati vor contribui doar la validarea detaliilor despre identitatea uneipersoane.

Managementul datelor financiare. Domeniul financiar este predispus fraudelordeoarece sistemele de contabilitate sunt controlate de entitatile care le folosesc. Estenecesar, de asemenea un efort uman considerabil pentru medierea tranzactiilor ıntre sistemeincompatibile. Toate acestea determina costuri ridicate de mentenanta, efort uman si timp.

Utilizarea smart contracts ın domeniul financiar poate imbunatatii timpul de proce-sare a tranzactiilor, corectitudinea datelor si transparenta acestora. Este eliminata nevoiaexistentei entitatilor care sa medieze tranzactiile ıntre anumite parti, acestea avand posi-bilitatea de a tranzactiona ın mod direct. Fraudarea datelor este mai dificila, sistemul decontabilitate fiind controlat de toate entitatile implicate.

Determinarea provenientei bunurilor. Determinarea originii anumitor bunuriıntr-un lant de aprovizionare ıntampina dificultati din cauza complexitatii procesului demanagement al unui lant de aprovizionare si dorintei de a partaja informatii doar cu en-titatile relevante(institutii de reglementare, vamale, etc). Din cauza dificultatilor ıntalniteın determinare originii produselor riscul existentei fraudelor este ridicat.

Urmarirea provenientei produselor poate fi imbunatatita prin folosirea unei reteleblockchain pentru ınregistrarea datelor referitoare la originea produselor. Accesul la in-formatii este simplificat, entitatile din retea participand la validarea si memorarea tranza-ctiilor ın registrul de date comun. Detectarea fraudelor este imbunatatita, fiecare entitateavand acces la tranzactiile din sistem.

3.3 Tehnologia blockchain ın studiile clinice

Principalele provocari ıntampinate ın cadrul studiilor clinice sunt legate de protectiadatelor cu caracter personal si reducerea numarului de fraude din acest domeniu.

Page 24: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

3.3. TEHNOLOGIA BLOCKCHAIN IN STUDIILE CLINICE 29

Tehnologia blockchain poate avea un impact global asupra cercetarii clinice deoarecepermite urmarirea, partajarea si protectia informatiilor. Prin utilizarea unui sistem de-centralizat folosit pentru urmarirea activitatilor din cadrul unui studiu clinic si a uneiretele peer-to-peer pentru partajarea informatiilor sunt asigurate transparenta si protectiadatelor personale ale pacientilor. Un sistem bazat pe aceasta tehnologie poate imbunatatimetodologiile din cercetarea clinica si protectia datelor cu caracter sensibil.

3.3.1 Modelarea cercetarii clinice sub forma unei retele deafaceri

O retea de afaceri reprezinta o retea complexa de companii ”unde scopul este dea sustine cerintele informationale si operationale ale afacerii cum ar fi cele de marketing,contabilitate ...”[18]. Un alt aspect important al unei retele de afaceri este ca aceastanu ınglobeaza doar afacerea ın sine ci implica si unele entitati din exterior care sustinactivitatea retelei cum ar fi furnizorii sau distribuitorii.

In cazul studiilor clinice o retea de afaceri poate fi formata din participantii directila activitati(ex. centrele medicale ın care se desfasoara studiile clinice), precum si partilecare sustin activitatea studiilor clinice(ex. furnizori, institutii de reglementare...) Reteleleexistente de afaceri folosesc ın prezent metode similare pentru stocarea informatiilor. En-titatile implicate tranzactioneaza ıntre ele, ınsa mentin ınregistrari proprii referitoare latranzactiile efectuate. In cele mai multe cazuri o autoritate centrala ın care toate partileimplicate au ıncredere intermediaza tranzactiile si schimbul de informatii din cadrul retelei.Conceptul descris mai sus este ilustrat in figura 3.3.

Figura 3.3: Retele de afaceri centralizate[2]

Page 25: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

30 CAPITOLUL 3. STUDIU BIBLIOGRAFIC

Aceasta metoda prezinta o complexitate redusa dar produce ın acelasi timp uneledezavantaje. Partajarea informatiilor este efectuata indirect, responsabila de acest lucrufiind autoritatea centrala. Din acest motiv procesul este ıncetinit, implicand costuri supli-mentare. Stabilirea corectitudinii informatiilor devine dificila ın momentul ın care partileimplicate detin ınregistrari diferite referitoare la tranzactii. Printre sistemele care folosesco astfel de abordare se numara Oracle Siebel Clinical Trial Management System[19]. Sis-temul ofera posibilitatea cercetatorilor de a organiza si colecta date ın cadrul unui studiuclinic, fiind astfel simplificata activitatea acestora. Datele sunt colectate intr-o baza dedate centrala . Partajarea datelor ıntre participanti are loc fie prin implicarea unei au-toritati centrale, fie prin folosirea unor mijloace nesigure. Aceste mijloace sunt ineficientesi reprezinta un risc ın ce priveste protejarea datelor cu caracter sensibil.

Retele de afaceri decentralizate. O alta abordare pentru realizarea unei retelede afaceri reprezinta utilizarea unei retele decentralizate. O astfel de metoda presupunefolosirea unui registru comun, replicat de catre fiecare participant din reteaua de afaceri.Procesul de salvare a tranzactiilor ın cadrul registrului este de asemenea partajat, fiecareparticipant la retea contribuind la procesul de validare si memorare a tranzactiilor efectu-ate. Este eliminata astfel nevoia unei autoritati centrale, partile implicate avand ıncredereca tranzactiile salvate ın registrul comun sunt valide.Figura 3.4 ilustreaza structura unei retele de afaceri decentralizate. O astfel de retea estesimilara cu o retea blockchain.

Figura 3.4: Retele de afaceri decentralizate[2]

Page 26: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

Capitolul 4

Analiza si Fundamentare Teoretica

Acest capitol prezinta cerintele unui sistem pentru managementul studiilor clinice.Sunt prezentati actorii principali ai sistemului, alaturi de cazurile de utilizare asociatefiecaruia. Capitolul se ıncheie printr-o prezentare a tehnologiilor folosite pentru imple-mentarea cazurilor de utilizare, respectand constrangerile specificate de cerintele sistemu-lui.

4.1 Cerinte sistem

Sectiunea prezinta o analiza a sistemului pentru managementul studiilor clinice.Cerintele unui sistem pot fi clasificate ın cerinte functionale si non-functionale. Cerintelefunctionale descriu comportamentul sistemului din punctul de vedere al utilizatorilor. Cer-intele non-functionale descriu proprietati si impun constrangeri asupra sistemului.

4.1.1 Cerinte functionale

In continuare sunt prezentate cerintele functionale ındeplinite de modulul client alaplicatiei. Aceste functionalitati sunt disponibile pentru utilizatorii sistemului:

1. Autentificare: Accesul la functionalitatile aplicatiei este disponibil doar pentru uti-lizatorii autentificati. Identitatea utilizatorului are o importanta majora ın cadrulretelei blockchain. In acest mod este asigurata posibilitatea urmariri activitatii par-ticipantilor si salvarea unui istoric a tuturor operatiilor efectuate de acestia.

2. Management identitate: Utilizatorii autentificati au nevoie de o identitate emisade organizatia din care fac parte pentru a putea accesa reteaua. Cu ajutorul acesteiautilizatorii sunt identificati ın reteaua blockchain si supusi regulilor de acces la resursedefinite ın sistem. Identitatea unui participant poate fi revocata, acesta pierzandaccesul la serviciile oferite de sistem.

31

Page 27: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

32 CAPITOLUL 4. ANALIZA SI FUNDAMENTARE TEORETICA

3. Management studii clinice: Utilizatorii au posibilitatea de a crea un nou studiuclinic folosind interfata utilizator dupa introducerea informatiilor necesare. Utiliza-torii autentificati care au drepturile de acces necesare pot accesa informatiile despreun studiu clinic si datele legate de activitatea desfasurata ın cadrul acestora.

4. Inrolare pacienti: Posibilitatea de a asocia un pacient la un studiu clinic.

5. Colectare date: Cercetatorii pot defini ın cadrul unui studiu clinic formulare decolectare a datelor de la pacienti. Aceste formulare ofera cercetatorului flexibilitateade a defini campuri de text si ıntrebari cu variante de raspuns relevante pentru studiulclinic. Folosind formularele definite, cercetatorii au posibilitatea de a colecta date dela un anumit pacient.

6. Drepturi de acces: Permite administratorilor sistemului sa defineasca drepturilede acces la resursele si serviciile oferite de aplicatie.

7. Gestionare fisiere: Utilizatorii care detin drepturile necesare pot salva ın sistemfisiere de protocol si contracte de sponsorizare. Protocolul unui studiu clinic descriemodul de desfasurare al acestuia. Utilizatorii care detin drepturile de acces necesarepot ıncarca un fisier de protocol si ıl pot descarca prin intermediul interfetei utilizator.

8. Istoric activitati: Sistemul colecteaza ın mod automat un istoric ın timp al oper-atiilor efectuate de utilizatori.

4.1.2 Cerinte non-functionale

1. Utilizabilitatea. Procesele din cadrul unui studiu clinic au o complexitate ridicata.Din acest motiv sistemul are nevoie de o interfata utilizator intuitiva, care sa per-mita cercetatorilor sa ısi desfasoare activitatea rapid. Un alt aspect important estecorrectitudinea informatiilor care poate fi imbunatatita prin validari si mesaje deeroare.

2. Securitatea. Protectia datelor cu caracter sensibil are o importanta majora ınstudiile clinice. Accesul pentru citirea si scrierea datelor este oferit doar utilizatorilorautentificati. In plus, accesul la resurse este controlat de listele de acces care definescreguli de scriere sı citire.

3. Fiablitate. Timpul i care serviciile oferite de sistem sunt indisponibile trebuie sa fieminim. Acest lucru poate fi asigurat prin replicarea nodurilor din reteaua blockchain.

4. Performanta. Performanta sistemului este masurata folosind mijloace specificetehnologiei utilizate. Aceasa poate fi masurata ın numarul de tranzactii/secundasau resursele de sistem consumate.

Page 28: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

4.2. CAZURI DE UTILIZARE 33

5. Compatibilitate. Cerinta non-functionala care specifica posibilitatea de utilizarea sistemului din platforme multiple. In cazul sistemului de management a studiilorclinice este posibil accesul utilizatorilor din orice browser modern, mobil sau desktop.

4.2 Cazuri de utilizare

Sectiunea descrie cazurile de utilizare ale aplicatiei analizand actorii implicati ınrealizarea acestora. Sistemul pentru managementul studiilor clinice are definite 4 tipuriprincipale de utilizatori: administrator, cercetator, agent de reglementare si sponsor.

Tabelul 4.1: Asociere functionalitati - cazuri de utilizare

Functionalitate Cazuri de utilizare ActoriAutentificare Autentificare utilizator Cercetator, Agent Regle-

mentare, Sponsor, Adminis-trator

Mapare identitate la contulutilizatorului

Cercetator, Agent Regle-mentare, Sponsor

Management identitate Emitere identitate AdministratorRevocare identitate Administrator

Management studiu clinic Creare studiu clinic CercetatorVizualizare studiu clinic Cercetator, Agent Regle-

mentare, SponsorCautare studii clinice Cercetator, Agent Regle-

mentare, SponsorModificare studiu clinic Cercetator

Inrolare pacienti Creare pacient Cercetator, AdministratorCautare pacient Cercetator, Administrator

Inrolare pacient ın studiuclinic

Cercetator

Colectare date Creare formular personalizat CercetatorVizualizare formulare Cercetator, Agent Regle-

mentareCompletare formular CercetatorVizualizare date colectate Cercetator, Agent Regle-

mentare, SponsorDrepturi de acces Asignare cercetator la studiu

clinicCercetator

Asignare agent reglementare AdministratorGestionare fisiere Adaugare fisier Cercetator, Sponsor

Descarcare fisier Cercetator, Sponsor

Page 29: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

34 CAPITOLUL 4. ANALIZA SI FUNDAMENTARE TEORETICA

Istoric activitati Creare istoric SistemVizualizare istoric Cercetator, Agent Regle-

mentare, SponsorFiltrare istoric Cercetator, Agent Regle-

mentare, Sponsor

Aceste 3 tipuri de utilizatori apartin unor organizatii diferite din reteaua blockchain.Tabelul 4.1 prezinta o asociere ınte functionalitatile sistemului, cazurile de utilizare siutilizatorii care participa la realizarea acestora.

4.2.1 Cercetator

Utilizatorul apartine organizatiilor din domeniul medical ın cadrul retelei blockchain.Responsabilitatea sa principala este managementul activitatilor din cadrul unui studiuclinic. In figura 4.1 sunt prezentate cazurile de utilizare asociate utilizatorului.

Figura 4.1: Cazuri de utilizare cercetator

4.2.2 Agent de reglementare

Utilizatorul apartine intitutiilor care se ocupa de aplicarea regulilor asupra unuistudiu clinic. Acestia supervizeaza acivitatile care au loc ın cadrul unui studiu clinic cuscopul de a gasi eventualele nereguli. Figura 4.2 prezinta cazurile de utilizare si respons-abilitatile asociate agentului de reglementare.

Page 30: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

4.2. CAZURI DE UTILIZARE 35

Figura 4.2: Cazuri de utilizare agent de reglementare

4.2.3 Sponsor

Interesat de rezultatele studiilor clinice finantate. Doreste sa poata vizualiza rezul-tatele obtinute ın timpul unui studiu clinic. Participa la ıncheierea contractelor de spon-sorizare cu institutiile responsabile de organizarea studiilor clinice. In figura 4.3 suntreprezentate cazurile de utilizare asociate utilizatorului de tip sponsor.

Figura 4.3: Cazuri de utilizare sponsor

Page 31: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

36 CAPITOLUL 4. ANALIZA SI FUNDAMENTARE TEORETICA

4.2.4 Descrierea cazurilor de utilizare

Caz de utilizare 1 - Autentificare

Este prezentata ın continuare o descriere a mecanismului de autentificare a utilizato-rilor ın sistem. Aceasta descriere contine scenariul principal de succes alaturi de extensiilecazului de utilizareNumele cazului de utilizare: Autentificare utilizatorActor principal: Utilizator al sistemuluiStakeholders:

• Utilizatorul: doreste sa acceseze serviciile oferite de sistem

• Administrator: doreste ca doar utilizatorii cu identitati emise sa poata accesa sis-temul

Preconditii: faraPostconditii: sistemul determina identitatea utilizatorului, o afiseaza si ofera acces laserviciile sistemuluiScenariu de succes:

1. Utilizatorul selecteaza optiunea de autentificare

2. Aplicatia redirectioneaza utilizatorul spre sistemul extern de autentificare

3. Utilizatorul introduce credentialele de acces

4. Sistemul extern furnizeaza un token de autentificare

5. Aplicatia afiseaza identitatea utilizatorului si ıi permite accesul

Scenarii alternative:

• 3a. Utilizatorul introduce credentiale gresite:

1. Sistemul extern afiseaza un mesaj de eroare si solicita credentialele

• 3b. Utilizatorul este la prima autentificare ın sistem

1. Sistemul extern cere permisiunea pentru autorizarea aplicatiei

2. Utilizatorul selecteaza optiunea de autorizare acces

3. Sistemul extern furnizeaza un token de autentificare

• 5a. Utilizatorul nu are o identitate definita ın retea

1. Aplicatia cere un cod de inrolare i sistem

2. Utilizatorul introduce codul furnizat de administratia organizatiei din care faceparte

3. Aplicatia salveaza o asociere ıntre identitatea utilizatorului si contul acestuia

Page 32: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

4.2. CAZURI DE UTILIZARE 37

Caz de utilizare 2 - Creare formular personalizat

Cercetatorii au la dispozitie o functionalitate prin care pot defini un formular ınfunctie de nevoile ıntalnite ın cadrul unui studiu clinic. In continuare sunt descrisi actoriiimplicati, alaturi de pasii care trebuie urmati ın definirea unui formular. Numele cazuluide utilizare: Creare formular personalizatActor principal: CercetatorStakeholders:

• Cercetator: doreste ca sistemul sa ii ofere flexibilitatea de a defini campurile de careare nevoie ıntr-un formular

• Agent de reglementare: interesat de corectitudinea datelor colectate. Doreste sa aibaacces la informatii

• Sponsor: interesat de structura formularului de colectare a datelor

Preconditii: Utilizator autentificat, cu drepturi de citire si scriere asupra unui studiuclinicPostconditii: Formularul definit este salvat ın baza de date si poate fi vizualizat ın oricemomentScenariu de succes:

1. Utilizatorul selecteaza optiunea de creare a unui formular nou

2. Utilizatorul introduce numele formularului

3. Utilizatorul selecteaza tipul de camp pe care doreste sa ıl creeze: text field, choicesau selection

4. Sistemul cere definirea campului

5. Utilizatorul introduce numele si, dupa caz, variantele de raspuns pentru campulrespectiv

6. Utilizatorul repeta pasii 3-5 pana cand confirma salvarea formularului

7. Sistemul afiseaza un mesaj de confirmare a salvarii

Scenarii alternative:

• 1-5a. Utilizatorul anuleaza crearea formularului

1. Sistemul inlatura informatiile introduse de utilizator

• 2a. Utilizatorul nu introduce un nume pentru formular

1. Sistemul notifica utilizatorul printr-un mesaj de eroare

• 5a. Utilizatorul nu introduce datele necesare sau introduce date gresite

1. Sistemul notifica utilizatorul printr-un mesaj de eroare

Page 33: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

38 CAPITOLUL 4. ANALIZA SI FUNDAMENTARE TEORETICA

Caz de utilizare 3 - Adaugare fisier

Numele cazului de utilizare: Adaugare fisierActor principal: Cercetator, SponsorStakeholders:

• Cercetator: doreste o modalitate de stocare si partajare a fisierului de protocol cupartile interesate

• Sponsor: interesat de anumite fisiere stocate. Doreste sa poata avea acces la acestea

• Agent reglementare: doreste sa aiba posibilitatea de a verifica fisierele incarcatepentru a putea aplica regulile ın vigoare

Preconditii: Utilizator autentificat, cu drepturi de citire si scriere asupra unui studiuclinicPostconditii: Sistemul salveaza fisierul, acesta fiind disponibil pentru descarcare pentruutilizatorii cu drepturi de accesScenariu de succes:

1. Utilizatorul selecteaza optiunea de ıncarcare a unui fisier nou

2. Sistemul cere calea spre fisierul dorit

3. Utilizatorul selecteaza fisierul si confirma selectia

4. Sistemul afiseaza informatii despre fisier

5. Utilizatorul selecteaza optiunea de confirmare a salvarii

Scenarii alternative:

• 3a. Utilizatorul selecteaza un tip invalid de fisier

1. Sistemul notifica utilizatorul printr-o eroare

2. Sistemul revine la pasul 2.

• 4a. Sistemul nu poate gasi fisierul selectat de utilizator

1. Sistemul notifica utilizatorul printr-o eroare

2. Sistemul revine la pasul 2.

• 5a. Salvarea fisierului esueaza

1. Sistemul notifica utilizatorul printr-o eroare

2. Sistemul revine la starea initiala

Page 34: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

4.3. TEHNOLOGII UTILIZATE 39

4.3 Tehnologii utilizate

In continuare sunt descrise tehnologiile, resursele si serviicile necesare pentru imple-mentarea sistemului si respectarea cerintelor functionale si non-functionale ale acestuia.

4.3.1 Hyperledger Fabric

Hyperledger Fabric este platforma folosita pentru implementarea retelei de afac-eri pentru studii clinice. Reprezinta un registru distribuit cu o arhitectura modularacare permite participantilor sa gestioneze tranzactii ın sistem cu ajutorul smart contracts.Framework-ul permite implementarea de componente modulare precum algoritmi de con-sens.

In comparatie cu Bitcoin, Hyperledger Fabric ofera posibilitatea implementarii unuiblockchain privat sau bazat pe permisiuni de acces. Acest lucru este realizat de serviciulde furnizare identitati folosit pentru a valida si autentifica participantii din retea. Incontinuare sunt prezentate caracteristicile care au dus la alegerea framework-ului pentruimplementarea sistemului.

Registru distribuit. Fiecare participant din retea detine o copie a registrului.Acesta este format din doua componente: starea curenta a retelei si istoricul tranzactiilor.Starea curenta a retelei poate fi interpretata drept baza de date a registrului la un anumitpunct din timp. Baza de date stocheaza structurile de date din retea sub forma unorperechi cheie-valoare. Istoricul tranzactiilor contine tranzactiile care au realizat modificariasupra starii curente a retelei.

Smart contracts. Hyperledger Fabric foloseste un limbaj propriu pentru smartcontracts numit chaincode. Acesta este responsabil de modelarea structurilor de date dinretea si de gestionarea logicii retelei.

Protectia datelor. Framework-ul separa tranzactiile din sistem ın functie de par-ticipantii care au acces la acestea. Sunt furnizate canale pentru efectuarea tranzactiilorcare permit accesul doar participantilor care au acest drept.

Mecanism de consens. Este permisa configurarea mai multor algoritmi de con-sens. Hyperledger Fabric asigura suport pentru diferite implementari: Solo, Kafka, SimpleBizantine Fault Tolerant, etc[2]. Aceasta caracteristica ofera un avantaj major din punct devedere al performantei ın comparatie cu mecanismul PoW folosit de Bitcoin sau Ethereum.

4.3.2 Hyperledger Composer

Hyperledger Composer1 este un framework care are ca scop simplificarea imple-mentarii cazurilor de utilizare si a logicii unei aplicatii care ruleaza ın cadrul platformeiHyperledger Fabric.

1https://hyperledger.github.io/composer/latest/

Page 35: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

40 CAPITOLUL 4. ANALIZA SI FUNDAMENTARE TEORETICA

Figura 4.4 prezinta artefactele necesare pentru implementarea unei retele blochaincu ajutorul Hyperledger Composer. Un fisier cu extensia .bna(Business Network Archive)este rezultatul implementarii cazurilor de utilizare si al logicii aplicatiei.

Model File. Folosit pentru modelarea layer-ului de date al aplicatiei. Hyper-ledger Composer utilizeaza un limbaj orientat-obiect propriu pentru definirea resurselordin retea. Tabelul 4.2 prezinta resursele care pot fi definite folosind limbajul de modelareal Hyperledger Composer alaturi de definitii si exemple pentru acestea.

Tabelul 4.2: Definitii ale resurselor disponibile ın limbajul de modelare

Denumire Definitie Exemplu

Asset bunuri tangibile sau intan-gibile, servicii, etc

studiu clinic

Participant Actor din sistem cercetator, agent de regle-mentare

Tranzactie Logica pentru interactiunileıntre participanti

creare studiu clinic

Concept clase abstracte, nu pot fistocate direct ci doar caparte a unui asset, partici-pant sau tranzactie

adresa

Limbajul permite crearea unor relatii ıntre obiectele definite. O relatie este reprezen-tata prin namespace-ul unui tip, numele tipului referit si identificatorul unei instante dinacest tip. Aceste relatii pot fi folosite pentru filtrarea resurselor cu ajutorul interogarilor.

Script File. Acest artefact defineste logica executata ın cadrul tranzactiilor dinsistem. Aceasta logica este descrisa folosind limbajul JavaScript. Parametrul de intrareal unei tranzactii este definit ın fisierul de model al aplicatiei. Tranzactiile definite ınacest fisier pot emite evenimente prin care poate fi notificata interfata utilizator de uneleschimbari efectuate asupra resurselor.

Acces control rules. Contine regulile de scriere si citire asupra resurselor dinsistem. Aceste reguli sunt aplicate asupra participantilor din sistem si pot asigura protectiadatelor cu caracter sensibil. Regulile sunt aplicate asupra participantilor si resurselordefinite in fisierul de model.

Query Definitions. Reprezinta interogari ale starii curente a retelei similare cuinterogarile din SQL. Aceste interogari sunt definite ın sintaxa proprie Hyperledger Com-poser si pot fi folosie pentru a filtra informatiile din retea conform unor conditii.

Page 36: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

4.3. TEHNOLOGII UTILIZATE 41

Figura 4.4: Implementarea unei retele blockchain uitlizand Hyperledger Composer

4.3.3 MongoDB

MongoDB2 este o baza de date non-relationala conceputa de compania 10gen. Difer-enta principala fata de bazele de date relationale este in stocarea informatiilor nu ın tabeleci ın fisiere care utilizeaza formatul BSON(binary JSON). Aceste fisiere sunt organizatesub forma unor colectii care sunt similare cu tabele din bazele de date relationale. Sistemulpentru managementul studiilor clinice foloseste aceasta baza de date intern pentru a per-sista asocieri ıntre identitatile utilizatorilor ın reteaua blockchain si conturile de utilizatorale acestora.

4.3.4 Loopback

Loopback3 este un framework Node.js care permite generarea rapida a unui serverREST din diferite tipuri de surse de date. Sunt disponibili conectori pentru baze dedate(SQL, MongoDB) sau pentru o sursa de date precum Hyperledger Composer. Loop-back utilizeaza modelul de date scris ın Hyperledger Composer pentru a genera operatii

2https://www.mongodb.com/3https://loopback.io/

Page 37: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

42 CAPITOLUL 4. ANALIZA SI FUNDAMENTARE TEORETICA

CRUD pentru aplicatie si puncte de acces pentru executarea tranzactiilor si a logicii aces-tora.

4.3.5 Passport

Passport4 este un middleware pentru Node.js avand ca scop autentificarea cererilor.Sunt puse la dispozitie diferite stategii de autentificare folosind protocolul OAuth. Printreaceste strategii se numara platforme web populare cum ar fi: Google, Github, etc. Iden-titatea unui utilizator poate fi stocata fie ın cadrul sesiunii unui browser fie ın interiorulunui request.

4.3.6 OAuth

OAuth este un framework de autorizare care permite aplicatiilor sa limiteze acce-sul la anumite resurse doar utilizatorilor autentificati, folosind servicii externe sistemu-lui(Google, Github, etc). Sistemul de management al studiilor clinice utilizeaza acestprotocol pentru gestionarea accesului utilizatorilor la resursele retelei blockchain.

Protocolul OAuth defineste 4 roluri:

1. Resource owner: este utilizatorul care autorizeaza accesul la informatii legate decontul sau

2. Authorization server: reprezinta serverul care gazduieste informatiile despre contulunui utilizator si care expune un API pentru autorizare

3. Client: aplicatia care doreste sa acceseze informatiile legate de contul unui utilizator

4. Resource server: contine resursele accesibile doar utilizatorilor autentificati

Figura 4.5: Model abstract de functionare al protocolului OAuth[3]

4http://www.passportjs.org/

Page 38: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

4.3. TEHNOLOGII UTILIZATE 43

Figura 4.5 prezinta modul de functionare al protocolului:

1. Aplicatia trimite o cerere de autorizare serverului care detine informatii despre uti-lizator

2. In cazul ın care utilizatorul autorizeaza cererea aplicatia primeste acces

3. Aplicatia cere un token de acces prin prezentarea identitatii utilizatorului si a con-firmarii de autorizare

4. Serverul de autorizare returneaza un token de autorizare ın cazul ın care informatiiletrimise de aplicatie sunt valide

5. Aplicatia cere o anumita resursa cu acces limitat prin prezentarea token-ului de acces

6. Serverul de resurse returneaza resursa ceruta ın cazul ın care tokenul de acces estevalid

4.3.7 Docker

Platforma Docker5 furnizeaza o solutie de virtualizare la nivelul sistemului de op-erare. Aceasta permite rularea de pachete software ın interiorul unor containere. Fiecarecontainer dispune de resursele necesare pentru a asigura functionarea corecta a pachetelorsoftware. Containerele sunt izolate unele fata de celelalte ınsa pot comunica prin in-termediul unor canale de comunicare definite. Abordarea folosita de docker pentru dis-tribuirea solutiilor software contribuie la simplificarea procesului de instalare al unei reteleblockchain.

4.3.8 Angular

Angular6 este un framework gandit pentru implementarea de aplicatii web bazatpe TypeScript. Framework-ul permite implementarea de aplicatii web dinamice folosindHTML pentru reprezentarea paginilor web, dar furnizand posibilitatea de extindere a aces-tui limbaj prin implementarea de componente.

5https://www.docker.com/6https://www.angular.io/

Page 39: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al
Page 40: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

Capitolul 5

Proiectare de Detaliu siImplementare

In acest capitol este prezentata arhitectura conceptuala a sistemului si interactiuneadintre componentele acestuia. Sunt descrise responsabilitatile fiecarei componente alaturide arhitectura si detaliile de implementare ale acestora.

5.1 Arhitectura conceptuala a sistemului

Principalele componente ale sistemului de management al studiilor clinice suntmediul de rulare blockchain, serverul REST utilizat ca punct de acces ın reteaua blockchainsi interfata utilizator care permite participantilor sa interactioneze cu reteaua blockchainprin intermediul serverului REST. Arhitectura de nivel ınalt a aplicatiei este prezentata ınfigura 5.1

Figura 5.1: Arhitectura de nivel ınalt a sistemului

Hyperledger Composer pune la dispozitie un set de tool-uri si SDK-uri care sim-plifica interactiunea cu o retea blockchain si procesul de instalare al acesteia. O compo-

45

Page 41: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

46 CAPITOLUL 5. PROIECTARE DE DETALIU SI IMPLEMENTARE

nenta importanta a Hyperledger Composer este framework-ul Loopback folosit ın generareaserverului REST. Figura 5.2 prezinta componentele principale ale sistemului implementatsi interactiunile dintre aceste componente.

Figura 5.2: Arhitectura conceptuala a sistemului

Reteaua blockchain utilizeaza definitia retelei de afaceri (artefactul cu exensia .bna)creat cu ajutorul framework-ului Hyperledger Composer descris ın sectiunea 4.3.2. In-teractiunea ıntre reteaua blockchain si interfata utilizator se realizeaza prin intermediulunui server REST, acesta la randul lui utilizand un connector Loopback pentru a accesareteaua. Managementul utilizatorilor se realizeaza de asemenea la nivelul serverului RESTprin utilizarea unui serviciu extern de autentificare. O baza de date MongoDB asigura per-sistenta identitatii utilizatorilor ın sistem, ın relatie cu identitatea furnizata de serviciulextern de autentificare.

5.1.1 Definitia retelei de afaceri

Aceasta componenta contine implementarea modelului de date al aplicatiei, regulilede acces la resurse, interogarile asupra resurselor si logica aflata ın spatele cazurilor deutilizare.

Modelul de date al aplicatiei. Figura 5.3 prezinta asset-urile, participantii siconceptele principale definite ın modelul de date al aplicatiei. Diagrama contine doarelementele importante din modelul de date al aplicatiei, cele mai putin relevante fiindomise pentru pastra complexitatea diagramei la un nivel redus.

Page 42: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

5.1. ARHITECTURA CONCEPTUALA A SISTEMULUI 47

Figura 5.3: Modelul de date al aplicatiei

Modelarea conceptelor este realizata cu ajutorul limbajului orientat obiect pus ladispozitie de Hyperledger Composer. Figura 5.4 prezinta modelarea unui studiu clinic subforma unui asset, extras din codul aplicatiei.

1 /** Clinic trial represented as an asset*/

2 asset Trial identified by idTrial{

3 o String idTrial

4 o String studyName

5 o String description

6 o TodoElement [] tasks optional

7 o TrialStatus status optional

8 o ResearchSite [] researchSites optional

9 --> ResearchSite organiser

10 --> Patient [] participants optional

11 --> Researcher [] responsibles optional

12 }

Figura 5.4: Studiu clinic modelat subforma unui asset

Caracterul ”o” folosit la ınceputul unei variabile marcheaza o proprietate specificaasset-ului descris. Pe langa valori primitive1 exista posibilitatea de a utiliza descrierile

1ex.: String, Boolean, Double, etc.

Page 43: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

48 CAPITOLUL 5. PROIECTARE DE DETALIU SI IMPLEMENTARE

altor concepte ın cadrul unui concept. Un vector de date este specificat prin utilizareacaracterelor ”[]” dupa definirea tipului unei variabile2. O relatie spre un alt concept estemodelata prin folosirea caracterelor ”–>” ınainte de definirea variabilei.

Fiecare asset este identificat ın sistem prin intermediul unui identificator unic.Deoarece sistemul foloseste o arhitectura distribuita, bazata pe mecanisme de consens,implementarea unei functionalitati pentru generarea automata a identificatorilor similarcu mecanismele folosite de catre bazele de date relationale este dificila. In situatia ın carefiecare peer ıncearca sa genereze urmatorul id ın mod concurent, pot avea loc conflicte,ceea ce ar duce la anularea unor tranzactii, conditii de cursa si dificultati ın depanareaproblemelor. Solutia la aceasta problema este asignarea responsabilitatii de generare aunui ID aleator clientului din sistem. O astfel de abordare duce la cresterea eficientei sievitarea problemelor legate de concurenta. Un client poate folosi o functie simpla pentrugenerarea unui sir de caractere aleator si transiterea lui spre server pentru a fi utilizatca identificator al resursei nou create. Un exemplu de functie care genereaza un sir decaractere aleator este prezentat ın figura 5.5.

1 // generate a random id for new resources

2 generateID () {

3 var id = "";

4 for(var i = 0; i < 4; i++){

5 id += Math.random ().toString (36).slice(-4);

6 }

7 return id;

8 }

Figura 5.5: Generarea unui sir de caractere aleator ın limbajul TypeScript

Reguli de acces la resurse. Limitarea accesului participantilor la resurse esteo caracteristica necesara pentru protectia datelor cu caracter personal ale utilizatorilordin sistem. Regulile de acces ın sistem sunt definite folosind sintaxa proprie HyperledgerComposer. Elementele principale din gramatica unei reguli de acces sunt:

• Descriere: O scurta descriere a regulii de acces folosita pentru o mai buna intelegerea acesteia

• Participant: Specifica tipul de participant din retea asupra caruia se aplica regulade acces

• Operatie: Tipul de operatie efectuata de participant asupra unei resurse: CREATE,DELETE, UPDATE, READ, ANY.

2ex.: String[], ResearchSite[], etc

Page 44: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

5.1. ARHITECTURA CONCEPTUALA A SISTEMULUI 49

• Resursa: Defineste obiectele asupra carora se aplica regulile de acces la operatiilementionate

• Transactie: Specifica tranzactia ın cadrul careia sunt permise operatiile descrise ınregula

• Conditie: O expresie booleana ın limbajul JavaScript care determina declansareaunei anumite reguli

• Action: Determina actiunea care are loc dupa declansarea regulii de acces. Aceastaproprietate poate avea doua valori: ALLOW, DENY.

Figura 5.6 prezinta o regula de acces la resursa de tip studiu clinic, aplicata asupraparticipantilor de tip cercetator. Conditia de declansare a regulii de acces este descrisafolosind limbajul JavaScript. Cu ajutorul functiei some este posibila scanarea vectoruluide participanti. Se poate determina astfel daca se permite accesul unui anumit participantla resursa respectiva. In cazul de mai jos accesul este permis doar cercetatorilor aflati ınlista de responsabili pentru un studiu clinic.

12 rule ResearcherTrialAccess{

3 description: "Grant access to trial resources only to trial

responsibles"

4 participant(p): "ro.utcluj.clinictrial.base.Researcher"

5 operation: READ , UPDATE

6 resource(r): "ro.utcluj.clinictrial.trial.Trial"

7 condition: (

8 r.responsibles.some(function (responsible){

9 return responsible.getIdentifier () == p.getIdentifier ();

10 })

11 )

12 action: ALLOW

13 }

Figura 5.6: Exemplu regula de acces

Interogari. Permit filtrarea resurselor din sistem pe baza unor criterii. Interogariledin retea sunt descrise ın sintaxa Hyperledger Composer, sintaxa similara cu cea ıntalnitaın interogarile SQL. O interogare este compusa din doua proprietati:

• Descriere: Specifica modul de functionare al interogarii

• Statement: Contine conditia interogarii folosind operatori similari cu cei din lim-bajul SQL(SELECT, FROM, WHERE, AND, OR, etc.)

Page 45: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

50 CAPITOLUL 5. PROIECTARE DE DETALIU SI IMPLEMENTARE

Tranzactii. Unele cazuri de utilizare necesita o logica mai complexa decat operati-ile CRUD. In aceste cazuri este necesara implementarea unei logici de procesare aditionale.Acest lucru poate fi realizat prin implementarea unor tranzactii care descriu comportamen-tul cazului de utilizare.

1 /**

2 * Adds a Researcher as responsible for a clinical trial

3 * @param {ro.utcluj.clinictrial.trial.AddResearcherToTrial} tx

4 * @transaction

5 */

6 async function addResearcherToTrial(tx) {

7 console.log( ' Adding researcher to the responsibles list... ' );8 // namespace for transaction

9 const factory = getFactory ();

10 const NS_TRIAL = ' ro.utcluj.clinictrial.trial ' ;11 const NS_BASE = ' ro.utcluj.clinictrial.base ' ;12 let trial = tx.trial;

13 let researcher = tx.researcher;

14 //check for duplicates

15 for (let index in trial.responsibles) {

16 if (trial.responsibles[index]. idResearcher ==

researcher.idResearcher) {

17 throw new Error( ' Duplicate entry ' );18 }

19 }

20 //add relations

21 trial.responsibles

22 .push(factory

23 .newRelationship(NS_BASE , ' Researcher ' , researcher.idResearcher

));

24 console.log( ' Updating trial ... ' );25 const registry = await getAssetRegistry(

26 trial.getFullyQualifiedType ());

27 await registry.update(trial);

28 }

Figura 5.7: Adaugarea unui nou responsabil pentru un studiu clinic

Comentariul unei tranzactii contine pe primul rand o descriere a operatiei efectu-ate de tranzactie. Al doilea rand ıncepe cu adnotarea @param folosita pentru a marcadefinirea parametrului tranzactiei. Adnotarea @param este urmata de numele completal resursei care declanseaza tranzactia(namespace + tip) alaturi de numele parametruluifolosit de tranzactie. Ultimul rand contine adnotarea @transaction care specifica fap-tul ca functia trebuie interpretata ca fiind o tranzactie. Parametru functiei este descrisın modelul de date al aplicatiei. Pentru exemplul din figura 5.7 descrierea parametruluitranzactiei ın limbajul de modelare poate fi observata ın figura 5.9. In acest exemplu pen-

Page 46: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

5.2. RETEA BLOCKCHAIN HYPERLEDGER FABRIC 51

tru crearea unei relatii ıntre un studiu clinic si un cercetator, o tranzactie are nevoie dereferinte spre un studiu clinic si un cercetator ca parametru de intrare.

1 transaction AddResearcherToTrial{

2 --> Trial trial

3 --> Researcher researcher

4 }

Figura 5.8: Parametrul tranzactiei din figura 5.7

5.2 Retea blockchain Hyperledger Fabric

Dupa definirea resurselor din reteaua blockchain si compilarea lor ıntr-un fisier cuextensia .bna, este posibila instalarea acestora ıntr-o retea blockchain. Diagrama ilus-treaza procesul de instalare a retelei blockchain si de instalare a definitiei retelei ın cadrulacesteia. Dupa instalarea definitiei retelei, administratorul are responsabilitatea de a emiteidentitati pentru a permite accesul participantilor la retea. Se poate observa posibilitateade actualizare a retelei blockchain ın timp ce aceasta ruleaza.

Figura 5.9: Ciclul de viata al unei retele blockchain

Reteaua blockchain ruleaza ıntr-un mediu virtual creat cu ajutorul platformei Docker.Configuratia initiala a sistemului din mediul de dezvoltare contine 4 imagini Docker: vali-

Page 47: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

52 CAPITOLUL 5. PROIECTARE DE DETALIU SI IMPLEMENTARE

Tabelul 5.1: Imagini Docker utilizate ın mediul de dezvoltare

Nume imagine Descrierehyperledger/fabric-peer:x86 64-1.1.0 Peer responsabil de validarea si

salvarea tranzactiilorhyperledger/fabric-ca:x86 64-1.1.0 Certificate authority - respons-

abila de emiterea certificatelor deidentitate ın retea

hyperledger/fabric-couchdb:x86 64-0.4.6 Baza de date pentru ınregistrariledin retea

hyperledger/fabric-orderer:x86 64-1.1.0 Asigura comunicarea si stabilireaconsensului ıntre peer-uri

dating peer, ordering peer, certificate authority, CouchDB. Mediul virtual contine un peerresponsabil de validarea si salvarea modificarilor. Comunicarea ıntre peer-uri este asiguratade ordering peer. In final, responsabilitatea pentru emiterea certificatelor de identitate sivalidarea acestora revine certificate authority. Inregisrarile din sistem sunt pastrate ıntr-o baza de date NoSQL care utilizeaza imaginea Docker pentru CouchDB3. Tabelul 5.2contine imaginile instantiate ın mediul de dezvoltare. Aditional acestor imagini, ın mo-mentul instalarii definitiei retelei este creat un peer responsabil de rularea codului pentrusmart contracts.

5.3 Interactiunea cu reteaua blockchain

Dupa instantierea retelei blockchain si instalarea definitiei retelei este importantafurnizarea unei metode de interactiune cu reteaua. Utilizarea unui API REST poate per-mite organizatiilor implicate sa integreze sisteme existente ın reteaua blockchain.

In acest sens Hyperledger Composer furnizeaza o unealta pentru instantierea unuiserver REST. Acest server contine punctele de acces necesare pentru apelul metodelorCRUD, al tranzactiilor si al interogarilor asupra resurselor. Pe langa acestea sunt disponi-bile metode de sistem pentru citirea istoricului tranzactiilor si managementul identitatiiparticipantilor.

Tabelul 5.2 prezinta punctele de acces la resursele definite ın sistem. Este posibilaefectuarea operatiilor CRUD asupra asset-urilor si participantilor din definitia retelei. Op-eratiile efectuate sunt ınregistrate ın istoric si pot fi observate de participantii din retea.Invocarea unei tranzactii este realizata prin utilizarea metodei POST expusa de serviciulREST. Tranzactiile executate sunt salvate ıntr-un registru al tranzactiilor si pot fi accesateprin intermediul metodei GET.

3http://couchdb.apache.org/

Page 48: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

5.3. INTERACTIUNEA CU RETEAUA BLOCKCHAIN 53

Tabelul 5.2: Puncte de acces ın reteaua blockchainTip Resursa Punct de acces MetodeAsset CustomForm /CustomForm GET, POST,

HEAD, PUT,DELETE

FormValue /FormValue GET, POST,HEAD, PUT,DELETE

MedicalHistory /MedicalHistory GET, POST,HEAD, PUT,DELETE

Patient /Patient GET, POST,HEAD, PUT,DELETE

Trial /Trial GET, POST,HEAD, PUT,DELETE

Participant Agent /Agent GET, POST,HEAD, PUT,DELETE

Researcher /Researcher GET, POST,HEAD, PUT,DELETE

ResearcherSite /ResearcherSite GET, POST,HEAD, PUT,DELETE

Supplier /Agent GET, POST,HEAD, PUT,DELETE

SupplyOrganisation /SupplyOrganisation GET, POST,HEAD, PUT,DELETE

Tranzactii AddFormData /AddFormData GET, POSTAddResearcherToTrial /AddResearcherToTrial GET, POSTEnrolPatientTransaction /EnrolPatientTransaction GET, POSTRegisterTrialTransaction /RegisterTrialTransaction GET, POSTRemoveResearcherFromTrial /RemoveResearcherFromTrial GET, POST

Aditional acestor puncte de acces sunt create puncte de acces pentru executarea in-terogarilor definite ın retea. Aceste puncte de acces expun metode GET pentru executareasi preluarea rezultatului interogarilor. Punctele de acces expuse de serverul REST sunt

Page 49: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

54 CAPITOLUL 5. PROIECTARE DE DETALIU SI IMPLEMENTARE

definite ın tabelul 5.3

Tabelul 5.3: Puncte de acces interogari

Interogari Punct de accesselectDataForCustomForm /queries/selectDataForCustomFormselectDataForCustomFormAndPatient /queries/selectDataForCustomFormAndPatientselectFilesByTrial /queries/selectFilesByTrialselectPatientsForTrial /queries/selectPatientsForTrialselectCustomFormsByTrial /queries/selectCustomFormsByTrialselectTrialsByResponsible /queries/selectTrialsByResponsibleselectHistoryByUser queries/selectHistoryByUserselectHistoryByResource queries/selectHistoryByResource

5.4 Management utilizatori

Identitatea utilizatorilor este gestionata la nivelul serverului REST care ruleaza ınmodul cu utilizatori multiplii. Configurarea unui server rest ın modul cu utilizatori multipliieste prezentata ın sectiunea 7.2.4. Dupa activarea modului cu utilizatori multiplii oriceıncercare de apel a metodelor expuse de serverul REST fara ca utilizatorul sa fie autentificatare ca rezultat raspunsul din figura 5.10.

Figura 5.10: Raspuns server REST pentru utilizator neautorizat

In acest fel este permis accesul doar utilizatorilor autentificati. Astfel tranzacti-ile efectuate ın sistem nu sunt semnate folosind identitatea administratorului retelei. Inschimb fiecarui utilizator ıi este asociat un wallet ın care sunt stocate identitatile asociateutilizatorului autentificat. Fiecare utilizator semneaza astfel tranzactiile folosind identi-tatea setata ca default ın wallet-ul detinut de el. Utilizand aceasta abordare pot fi aplicatereguli de acces asupra participantilor, asigurandu-se astfel protejarea datelor cu caractersensibil.

Procesul de autentificare al unui utilizator implica 5 componente din arhitecturasistemului. Interactiunea dintre componente este prezentata cu ajutorul unei diagrame desecventa ilustrata ın figura 5.11. Procesul reprezentat ın figura este realizat ın cazul ıncare utilizatorul are deja definita o identitate ın wallet-ul sau si aceasta poate fi citita de

Page 50: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

5.4. MANAGEMENT UTILIZATORI 55

serverul REST. Dupa terminarea procesului de autentificare token-ul generat de serviciulextern este stocat cu ajutorul unui cookie ın browser-ul utilizatorului. Acest token specificaserver-ului REST identitatea utilizatorului.

Figura 5.11: Procesul de autentificare al unui utilizator

Credentialele utilizatorului sunt gestionate de serviciul exetern de autentificare.Acesta furnizeaza un token prin care serverul REST diferentiaza utilizatorii din sistem.Asocierile dintre utilizatori si token-urile de acces sunt pastrate ın memoria interna aserverului REST. Din acest motiv ın momentul ın care instanta serverului este oprita,asocierile dintre identitatile utilizatorilor si token-ul de autentificare sunt pierdute. Acestaproblema este rezolvata ınsa prin utilizarea unei baze de date MongoDB alaturi de instantaserver-ului pentru a retine token-urile utilizatorilor din sistem. Astfel, aceste asocieri suntpastrate permanent, chiar si dupa un restart al serverului.

Procesul de asociere a unei identitati ın reteaua blockchain presupune parcurgereaurmatorilor pasi:

• Crearea unui participant ın reteaua blockchain

• Emiterea unei identitati pentru participant

• Crearea unui card de acces ın retea folosind identitatea emisa

• Importarea cadrului ın wallet-ul unui utilizator autentificat

Din punctul de vedere al utilizatorului procesul de asociere al contului sau din cadrulaplicatiei externe la reteaua blockchain trebuie sa fie cat mai automatizat si sigur. De aceea,responsabilitatea de creare a participantilor ın reteaua blockchain revine administratoruluiretelei. Utilizatorii sistemului primesc un cod de inrolare cu ajutorul caruia pot asocia oanumita identitate contului folosit ın aplicatie externa de autentificare. Astfel, din punctul

Page 51: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

56 CAPITOLUL 5. PROIECTARE DE DETALIU SI IMPLEMENTARE

de vedere al utilizatorului pasii descrisi mai sus se rezuma doar la introducerea coduluifurnizat de organizatia din care face parte, folosind pagina prezentata ın figura 5.12.

Figura 5.12: Pagina pentru asocierea identitatii unui utilizator utilizator

Procesul de asociere al identitatii la contul din aplicatia externa de autentificare esteprezentat ın diagrama de secventa din figura 5.13. Codul de ınrolare primit de utilizatorreprezinta ID-ul unui participant creat ın reteaua blockchain.

Figura 5.13: Procesul de asociere al unei identitati

Page 52: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

5.5. ARHITECTURA APLICATIEI CLIENT 57

Dupa ce utilizatorul introduce ID-ul furnizat aplicatia client verifica existenta aces-tuia printr-un apel la serverul REST. Acest apel interogheza registrul de participanti stocatın reteaua blockchain si returneaza detaliile despre participant daca acesta exista. Apli-catia client utilizeaza informatiile despre participant pentru a efectua un apel de emiterea identitatii pentru un participant. Reteaua blockchain genereaza cheile private si pub-lice ale participantului si returneaza aplicatiei client informatiile necesare pentru a generaun card de conexiune. Acest card de conexiune este importat ın final ın wallet-ul unuiutilizator. In urma efectuarii acestor operatii utilizatorul poate folosi identitatea asociatacontului sau pentru a semna tranzactiile din sistem.

5.5 Arhitectura aplicatiei client

Aplicatia client a sistemului este implementata cu ajutorul framework-ului Angu-lar. In continuare sunt prezentate aspecte legate de modul de implementare al serviciilorresponsabile de comunicarea cu serverul REST si componentele principale ale aplicatieiclient.

5.5.1 Servicii HTTP

Comunicarea interfetei web cu reteaua blockchain se realizeaza prin intermediulserver-ului REST. Cu ajutorul modulului HttpClient sunt implementate apelurile de metodeREST din aplicatia client.

Figura 5.14: Serviciul HTTP al aplicatiei client

Figura 5.14 prezinta elementele principale ale aplicatiei client, responsabile de in-teractiunea cu serverul rest. Apelurile REST sunt efectuate prin intermediul serviciuluigeneric DataService. Acest serviciu este injectat mai departe ın serviciile rescponsabile deapeluri de interogari, operatii CRUD pe resurse sau apeluri de tranzactii. ComponentaConfiguration contine constante pentru identificarea server-ului REST, simplificand oper-atia de modificare a adresei spre server. In figura 5.15 se pot observa constantele definitepentru configurarea accesului la serverul REST si modul simplu de modificare al acestora.

Page 53: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

58 CAPITOLUL 5. PROIECTARE DE DETALIU SI IMPLEMENTARE

1 @Injectable ()

2 export class Configuration {

3 public ApiIP: string = "http:// localhost";

4 public ApiPort: string = "3000";

5 public AdminApiPort: string = "3001";

6 public Server: string = this.ApiIP+":"+this.ApiPort;

7 public AdminServer: string = this.ApiIP+":"+this.AdminApiPort;

8 public ApiUrl: string = "/api/";

9 public ServerWithApiUrl = this.Server + this.ApiUrl;

10 public AdminServerWithApiUrl = this.AdminServer + this.ApiUrl;

11 }

Figura 5.15: Componenta de configurare

5.5.2 Componentele aplicatiei client

Paginile aplicatiei client sunt alcatuite din componente gandite pentru a beneficiade pe urma posibilitatilor de refolosire a acestora. Figura 5.16 ilustreaza componenteleaplicatiei client si dependintele dintre acestea.

Figura 5.16: Diagrama de componente a aplicatiei client

Componenta radacina a aplicatiei detine responsabilitatea de randare a router-outlet. Componenta router-outlet face parte din mecanismul Angular de rutare al apli-catiei client. In functie de ruta de navigatie router-outlet afiseaza o anumita componentaa aplicatiei.

Posibilitatea de refolosire a codului este asigurata prin implementarea de directiveAngular si componente. Componentele reprezinta o extensie a directivelor. Un exempluın acest sens este implementarea unui tabel pentru pacienti sub forma unei componente.Definitia unei astfel de componente ıncepe folosind decoratorul @Component exemplificat

Page 54: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

5.5. ARHITECTURA APLICATIEI CLIENT 59

ın figura 5.17. Proprietatea selector specifica numele tag-ului HTML care poate fi folositpentru a instantia componenta.

1 @Component ({

2 selector: ' patient-table ' ,3 templateUrl: ' patient-table.component.html '4 })

5 export class PatientTableComponent implements OnInit {

6 @Input () allPatientsDataSource: MatTableDataSource<Patient>;

7 @Input () adminMode: boolean;

8 @Input () idTrial: string;

9 ...

Figura 5.17: Decoratorul @Component

Parametrii care au aplicat decoratorul @Input() pot fi referiti ca atribute ın interi-orul tag-urilor HTML pentru a transmite valori componentei. Astfel, componenta prezen-tata mai sus poate fi folosita ın interiorul unei alte componente prin utilizarea sintaxeiprezentate ın figura 5.18.

1 <p atient-table [allPatientsDataSource]="allPatientsDataSource"

2 [adminMode]=false [idTrial]="trial.idTrial"></p atient-table>

Figura 5.18: Reutilizarea unei componente Angular

Page 55: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al
Page 56: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

Capitolul 6

Testare si Validare

Calitatea produsului sau serviciului oferit poate fi analizata prin testarea obiectivaa functionalitatilor furnizate de produs. In continuare sunt prezentate metodele de testarefolosite pentru verificarea calitatii sistemului.

6.1 Testarea retelei blockchain

Are ca scop testarea definitiei retelei blokchain si a performantei acesteia. Pentrutestarea definitiei unei retele si pentru validarea functionalitatilor acesteia inainte de insta-larea aplicatiei ın productie, dezvoltatorii au la dispozitie tool-ul Composer Playgrounddisponibil pentru utilizare fie online1, fie ıntr-un mediu de dezvoltare local.

Figura 6.1: Testare functionalitate de adaugare a unui nou participant

Acest tool ofera posibilitatea dezvoltatorilor de a testa ın cadrul platformei definitia

1http://composer-playground.mybluemix.net/

61

Page 57: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

62 CAPITOLUL 6. TESTARE SI VALIDARE

retelei. Cu ajutorul platformei pot fi testate operatii CRUD, fiind puse la dispozitie ex-emple si posibilitatea de a adauga date aleatoare pentru testare similar cu cele prezentateın figura 6.1.

O functionalitate importanta oferita de Composer Playground este posibilitateade a testa logica tranzactiilor. Figura 6.2 prezinta functionalitatea oferita de platformapentru testarea logicii tranzactiilor. Sunt oferite, de asemenea, exemple ale parametrilornecesari pentu apelul tranzactiilor. Platforma ofera posibilitatea de interogare a istoriculuitranzactiilor pentru validarea mecanismului de memorare al istoricului tranzactiilor.

Figura 6.2: Testare apeluri tranzactii

6.2 Testare la nivelul API-ului REST

Comunicarea ıntre interfata utilizator si reteaua blockchain se realizeaza prin in-termediul unui server REST. Server-ul REST creat cu ajutorul Hyperledger Composerofera posibilitatea de testare a metodelor din API prin intermediul unei documentatii webcreate cu ajutorul uneltei Swagger2. Figura 6.3 ilustreaza un model de documentatie gen-erat pentru API-ul sistemului de management al studiilor clinice. Documentatia generataprezinta metodele expuse de serverul REST, exemple de apeluri si ofera ın acelasi timp

2https://swagger.io/

Page 58: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

6.3. TESTARE LA NIVELUL APLICATIEI CLIENT 63

posibilitatea de a apela metodele generate. Aceste aspecte simplifica procesul de docu-mentare al unui API. Dezvoltatorii interfetei utilizator pot prelua documentatia generatasi o pot utiliza pentru a integra interata utilizator cu reteaua blockchain.

Figura 6.3: Documentatie API generata folosind Swagger

6.3 Testare la nivelul aplicatiei client

La nivelul aplicatiei client, framework-ul Angular pune la dispozitie unealta pentrutestare Karma3 alaturi de framework-ul Jasmine4. Aceasta unealta permite scrierea descenarii de testare a componentelor interfetei utilizator, a metodelor definite si a serviciilordin aplicatia client. Anexa C prezinta un exemplu cod scris ın limbajul JavaScript pentrutestarea unei componente din interfata utilizator. Pentru executarea testelor definite ınaplicatia client se utilizeaza comanda:

ng t e s t

Aceasta comanda scaneaza directorul sursa al aplicatiei pentru a gasi fisierele ın care suntdefinite cazurile de testare. Aceste fisiere folosesc extensia ”.spec.ts”. Rezultatele testelorpot fi vizualizate pe interfata web a mecanismului de testare. Figura 6.4 prezinta rezultatulobtinut ın urma efectuarii unui test simplu de instantiere a unei componente.

3http://karma-runner.github.io/2.0/index.html4https://jasmine.github.io/

Page 59: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

64 CAPITOLUL 6. TESTARE SI VALIDARE

Figura 6.4: Interfata web pentru rulare teste

Page 60: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

Capitolul 7

Manual de Instalare si Utilizare

7.1 Cerinte preliminare

Instalarea uneltelor de dezvoltare a retelei blockchain si a interfetei utilizator nece-sita indeplinirea urmatoarelor cerinte preliminare :

• Sistem de operare: Ubuntu Linux 14.04 / 16.04 LTS (both 64-bit), Mac OS 10.12

• Docker: Version 17.03+

• Docker-Compose: Version 1.8+

• Node: 8.9+

• npm: 5.x+

• git: 2.9.x+

• Python: 2.7.x+

• Angular CLI: 6.x.x+

• MongoDB: 4.0+

7.2 Instalare

7.2.1 Instalare mediu de rulare Hyperledger Fabric

In continuare sunt prezentati pasii necesari pentru instalarea resurselor mediului derulare si pasii necesari pentru pornirea acestuia.

1. Intr-un director la alegere(ın acest caz /fabric-dev-servers) sunt descarcate resurseleHyperledger Fabric folosind comenzile:

65

Page 61: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

66 CAPITOLUL 7. MANUAL DE INSTALARE SI UTILIZARE

mkdir ˜/ f a b r i c−dev−s e r v e r s && cd ˜/ f a b r i c−dev−s e r v e r s

c u r l −O https : // raw . g i thubuse rcontent . com/ hyper l edger /composer−t o o l s / master / packages / f a b r i c−dev−s e r v e r s / f a b r i c−dev−s e r v e r s. ta r . gz ta r −xvf f a b r i c−dev−s e r v e r s . t a r . gz

2. Este executat script-ul furnizat pentru descarcarea imaginilor Docker executand ur-matoarele comenzi:

cd ˜/ f a b r i c−dev−s e r v e r s. / downloadFabric . sh

3. Dupa executarea comenzilor sunt instalate toate resursele necesare pornirii mediu-lui de rulare Hyperledger Fabric. Pentru pornirea mediului de rulare este necesarapornirea imaginilor Docker descarcate anterior. Acest lucru este realizat prin exe-cutarea urmatoarelor script-uri furnizate:

. / s t a r t F a b r i c . sh

. / createPeerAdminCard . sh

7.2.2 Instalare Hyperledger Composer

Uneltele furnizate de Hyperledger composer sunt instalate cu ajutorul uneltei npm.Este necesara instalarea globala a urmatoarelor pachete:

• Composer CLI:

npm i n s t a l l −g composer−c l i

• Composer REST server:

npm i n s t a l l −g composer−r e s t−s e r v e r

7.2.3 Instalare definitie retea

Definitia retelei blockchain este furnizata sub forma unui fisier cu extensia .bna.Instalarea definitiei ıntr-un peer din retea presupune urmatorii pasi:

1. Este importat fisierul [email protected] obtinut urmand pasii de in-stalare a mediului de rulare Hyperledger Fabric. Pentru a importa acest fisier sefoloseste urmatoarea comanda:

composer card import −f PeerAdmin@fabric−network . card

2. Se instaleaza fisierul cu definitia retelei folosind urmatoarea comanda:

Page 62: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

7.2. INSTALARE 67

composer network i n s t a l l −c PeerAdmin@fabric−network −ac l i n i c −t r i a l −network1 . 0 . 0 . bna

3. Pentru a porni definitia retelei instalate se executa urmatoarea comanda:

composer network s t a r t −−networkName c l i n i c −t r i a l −network−−networkVersion 1 . 0 . 0 −A admin −S adminpw −cPeerAdmin@fabric−network

4. Pasul anterior creaza un card de conexiune la peer-ul din reteaua blockchain sub nu-mele [email protected]. Pentru a putea interactiona cu definitiaretelei este necesara importarea acestui card folosind comanda:

composer card import −f admin@clinic−t r i a l −network . card

7.2.4 Configurare server REST

Sistemul utilizeaza doua servere REST pentru a permite utilizatorilor sa inter-actioneze cu reteaua blockchain utilizand interata utilizator. Unul din servere ruleazaın modul administrator avand rolul de a crea identitati ın reteaua blockchain. Celalaltserver ruleaza ın modul cu utilizatori multiplii.

Configurare server REST ın modul administrator

Pentru instantierea unui server REST ın modul administrator este utilizata urma-toarea comanda:

composer−r e s t−s e r v e r −c admin@clinic−t r i a l −network −n never −p 3001

Configurare server REST ın modul cu utilizatori multiplii

Pentru pornirea unui server REST ın modul cu utilizatori multiplii sunt necesariurmatorii pasi, alaturi de urmatoarele configurari:

1. Serviciul de stocare permanenta a utilizatorilor este pornit folosind comenzile:

sudo s e r v i c e mongod s t a r tmongo

2. Pentru pornirea serverului REST ın modul cu utilizatori multiplii se executa scriptulfurnizat. Continutul scriptului este disponibil ın anexa B.

. / s ta r t−multi−r e s t−s e r v e r

Page 63: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

68 CAPITOLUL 7. MANUAL DE INSTALARE SI UTILIZARE

7.2.5 Configurare interfata utilizator

Inainte de pornirea serverului pentru interfata utilizator este necesara instalareadependintelor acesteia folosind comanda:

npm i n s t a l l

Instantierea serverului pentru interfata utilizator este realizata prin utilizareacomenzii:

ng s e rve

7.3 Manual de utilizare

In aceasta sectiune se prezinta pe scurt unele detalii legate de utilizarea aplicatiei.Aplicatia a fost gandita ın asa fel ıncat sa fie simplu de utilizat, dar unele clarificarireferitoare la functionalitati sunt necesare. Autentificarea utilizatorului se efectueaza prinutilizarea butonului de Login aflat pe pagina de pornire. Utilizatorul este redirectionatspre serviciul de autentificare extern dupa apasarea butonului.

Figura 7.1: Pagina de autentificare a serviciului extern

Dupa autentificare utilizatorii sunt redirectionati ın functie de rolul lor spre paginileprincipale. Cercetatorii sunt redirectionati spre pagina care contine studiile clinice la careau acces.

Page 64: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

7.3. MANUAL DE UTILIZARE 69

Figura 7.2: Pagina principala a cercetatorului

Adaugarea de resurse ın sistem, fie studii clinice noi, fie pacienti sau incarcareade fisiere se poate realiza cu ajutorul butonului din partea dreapta-jos a paginii asociateresursei respective. Acest buton este vizibil ın figura 7.2.

Diferite operatii pot fi realizate asupra resurselor utilizand butoanele asociate fiecareiınregistrari din tabelele de date. Aceste butoane sunt marcate ın figura 7.3. In functie deresursa si drepturile utilizatorului sunt puse la dispozitie prin aceste butoane operatii deeditare, stergere sau vizualizare a unei resurse.

Figura 7.3: Butoane pentru operatii asupra inregistrarilor

Dupa accesarea unui studiu clinic din pagina principala a cercetatorului prezentataın figura 7.2 utilizatorul este redirectionat spre pagina dedicata studiului clinic. Aceastapagina contine o serie de tab-uri, fiecare oferind functionalitati si servicii ın cadrul unuistudiu clinic. In figura 7.4 se poate observa pagina principala din cadrul unui studiu clinicsi tab-urile aociate acestuia.

Page 65: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

70 CAPITOLUL 7. MANUAL DE INSTALARE SI UTILIZARE

Figura 7.4: Pagina dedicata studiilor clinice

Tab-urile puse la dispozitia cercetatorilor care au drepturile de acces necesare la unstudiu clinic sunt:

• Overview: Pagina de prezentare a unui studiu clinic. Contine informatii generaledespre un studiu clinic

• Protocol: Ofera servicii de management a fisierelor de protocol

• Forms: Crearea de formulare personalizate si gestionarea formularelor deja createeste posibila ın cadrul acestei pagini.

• Patients: Ofera servicii pentru managementul pacientilor dintr-un studiu clinic.

• Users: Permite definirea utilizatorilor care au drepturi de acces la studiul clinic.

• Settings: Contine setari generale aplicate studiului clinic.

Page 66: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

Capitolul 8

Concluzii

Capitolul prezinta rezultatele obtinute ın urma implementarii sistemului de man-agement al studiilor clinice. Este prezentata o analiza a sistemului alaturi de unele posibiledezvoltari ulterioare ale acestuia.

8.1 Rezultate obtinute

Sistemul pentru managementul studiilor clinice simplifica modul de interactiuneıntre organizatiile implicate ın procesul de management si reglementare al studiilor clinice.Prin utilizarea unei arhitecturi distribuite ın care fiecare participant din retea detine ocopie a datelor colectate ın sistem, nivelul de incredere ın corectitudinea datelor colectateeste ımbunatatit. Unele din caracteristicile sistemului implementat sunt:

• Protectia datelor cu caracter personal: Listele de acces definite ın aplicatieasigura faptul ca participantii au acces doar la informatiile definite ın regulile deacces aplicate asupra lor

• Partajarea datelor: Procesul de partajare a datelor este simplificat si realizat prinmijloace sigure. Acest lucru este realizat prin utilizarea unei baze de date distribuite.

• Managementul utilizatorilor: Accesul utilizatorilor la resursele sistemului estegestionat la nivelul server-ului. Fiecare utilizator realizeaza operatii ın sistem uti-lizand identitatea detinuta.

• Stocarea sigura a fisierelor: Fisierele stocate ın cadrul retelei blockchain suntimutabile. Modificarea lor nu poate avea loc fara a fi lasata o urma ın sistem.

• Reglementarea studiilor clinice: Agentii de reglementare si sponsorii au acces laistoricul operatiilor efectuate ın sistem. Astfel este eficientizat procesul de aplicarea regulilor asupra studiilor clinice.

71

Page 67: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

72 CAPITOLUL 8. CONCLUZII

• Colectarea datelor: Sistemul ofera flexibilitate ın ce priveste datele colectate decercetatori ın cadrul unui studiu clinic. Cercetatorii au posibilitatea de a-si definipropriile formulare de colectare a datelor.

Analiza asupra tehnologiei blockchain efectuata pe parcursul lucrarii poate ajuta ladezvoltarea pe viitor a altor aplicatii ın cel putin 3 aspecte:

1. Decizia de a folosi sau nu blockchain. Prezentarea avantajelor si dezavantajeloroferite de tehnologia blockchain poate ajuta dezvoltatorii de aplicatii sa decida dacautilizarea tehnologiei blockchain ın implementare ar aduce unele imbunatatiri asupracalitatii sistemului.

2. Alegerea tipului de implementare blockchain. Lucrarea prezinta diferite im-plementari ale tehnologiei blockchain si particularitati ale acestora. Aceasta analizaofera un punct de pornire pentru alegerea platformei blockchain potivite sistemuluiimplementat.

3. Integrarea componentelor sistemului. Analiza detaliilor de implementare dincadrul lucrarii poate ajuta dezvoltatorii de aplicatii sa ajunga la o mai buna intelegerea modului de functionare al tehnologiilor prezentate ın cadrul acestei lucrari.

8.2 Dezvoltari ulterioare

Pentru mentinerea ın timp a calitatii sistemului implementat este necesara o con-tinua extindere si configurare a functionalitatilor si serviciilor oferite de sistem. Printreeventualele functionalitati care pot fi adaugate sistemului pot fi mentionate:

• Integrarea unui algoritm de consens conceput pentru instalarea ın produc-tie : Implementarile existente de algoritmi de consens la momentul scrierii lucrarii nusunt pregatite pentru instalarea ın productie. Platforma Hyperledger Fabric permiteimplementarea de algoritmi de consens ın functie de nevoile aplicatiei.

• Automatizare procesului de detectare a nereguilor: Sistemul implementatpermite agentilor de reglementare sa acceseze informatiile colectate ın cadrul unuistudiu clinic. Implementarea unui mecanism de detectare automata a neregulilor arsimplifica si mai mult activitatea de reglementare a studiilor clinice.

• Utilizarea unui mod eficient de stocare a fisierelor: Stocarea directa a fisierelorintr-o retea blockchain nu este recomandata din cauza replicarii datelor. O metodamai eficienta de management a fisierelor este stocarea pe blockchain a rezultatuluiunei functii hash aplicate asupra documentului si stocarea documentului intr-un ser-viciu extern. Pentru verificarea integritatii fisierului este folosit rezultatul functieihash stocat ın reteaua blockchain.

Page 68: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

Bibliografie

[1] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,’ Dec 2008, accessed:2018-07-20. [Online]. Available: https://bitcoin.org/bitcoin.pdf

[2] Hyperledger. (2018) Hyperledger Fabric documentation. [Online]. Available:http://hyperledger-fabric.readthedocs.io/en/latest/

[3] D. R. M. Jones, D. Hardt, The OAuth 2.0 Authorization Framework: Bearer TokenUsage. Norwell, MA, USA: Kluwer Academic Publishers, 2012.

[4] P. S. Martin Valenta, “Comparison of ethereum,hyperledger fab-ric and corda,’ June 2017, accessed: 2018-07-03. [Online]. Avail-able: https://medium.com/@philippsandner/comparison-of-ethereum-hyperledger-fabric-and-corda-21c1bb9442f6

[5] G. Becker and R. universitat Bochum, “Merkle signature schemes, merkle trees andtheir cryptanalysis,’ 2008.

[6] A. Davison, Killer Game Programming in Java. Oeilly Media, Inc., 2005.

[7] G. Wood, “Ethereum: A secure decentralised generalised transaction ledger eip-150revision (759dccd - 2017-08-07),’ 2017, accessed: 2018-01-03. [Online]. Available:https://ethereum.github.io/yellowpaper/paper.pdf

[8] W. Stallings, Cryptography and Network Security: Principles and Practice, 6th ed.Upper Saddle River, NJ, USA: Prentice Hall Press, 2013.

[9] A. Gervais, G. O. Karame, K. Wust, V. Glykantzis, H. Ritzdorf, and S. Capkun,“On the security and performance of proof of work blockchains,’ 2016, accessed:2018-07-20. [Online]. Available: https://eprint.iacr.org/2016/555.pdf

[10] K. J. Owyer and D. Malone, “Bitcoin mining and its energy footprint,’ 2014. [Online].Available: http://karlodwyer.com/publications/pdf/bitcoin KJOD 2014.pdf

[11] L. Lamport, R. Shostak, and M. Pease, “The byzantine generals problem,’ ACMTrans. Program. Lang. Syst., vol. 4, no. 3, pp. 382–401, Jul. 1982. [Online]. Available:http://doi.acm.org/10.1145/357172.357176

73

Page 69: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

74 BIBLIOGRAFIE

[12] M. Castro and B. Liskov, “Practical byzantine fault tolerance,’ in Proceedings of theThird Symposium on Operating Systems Design and Implementation, ser. OSDI 9.Berkeley, CA, USA: USENIX Association, 1999, pp. 173–186. [Online]. Available:http://dl.acm.org/citation.cfm?id=296806.296824

[13] L. Luu, D.-H. Chu, H. Olickel, P. Saxena, and A. Hobor, “Making smart contractssmarter,’ in Proceedings of the 2016 ACM SIGSAC Conference on Computer andCommunications Security, ser. CCS 6. New York, NY, USA: ACM, 2016, pp.254–269. [Online]. Available: http://doi.acm.org/10.1145/2976749.2978309

[14] T. Swanson, “Consensus-as-a-service: a brief report on the emergence ofpermissioned, distributed ledger systems,’ Apr 2015, accessed: 2018-07-03. [Online].Available: http://www.ofnumbers.com/wp-content/uploads/2015/04/Permissioned-distributed-ledgers.pdf

[15] J. Saba, “Public, permissioned, and private blockchains,’ Oct 2016, accessed: 2018-07-03. [Online]. Available: https://medium.com/@JackSaba/public-permissioned-and-private-blockchains-e35a5c31aa1d

[16] E. Androulaki, A. Barger, V. Bortnikov, C. Cachin, K. Christidis, A. De Caro,D. Enyeart, C. Ferris, G. Laventman, Y. Manevich, S. Muralidharan, C. Murthy,B. Nguyen, M. Sethi, G. Singh, K. Smith, A. Sorniotti, C. Stathakopoulou,M. Vukolic, S. W. Cocco, and J. Yellick, “Hyperledger fabric: A distributed operatingsystem for permissioned blockchains,’ in Proceedings of the Thirteenth EuroSysConference, ser. EuroSys 8. New York, NY, USA: ACM, 2018, pp. 30:1–30:15.[Online]. Available: http://doi.acm.org/10.1145/3190508.3190538

[17] Corda. (2018) Corda documentation. [Online]. Available: https://docs.corda.net/

[18] J. Word, Business Network Transformation: Strategies to Reconfigure Your BusinessRelationships for Competitive Advantage. San Francisco, CA, USA: Jossey-Bass Inc.,Publishers, 2009.

[19] G. W. Fegan and T. A. Lang, “Could an open-source clinical trial data-managementsystem be what we have all been looking for?’ PLOS Medicine, vol. 5, no. 3, pp.1–3, 03 2008. [Online]. Available: https://doi.org/10.1371/journal.pmed.0050006

Page 70: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

Anexa A

Profil de conexiune HyperledgerComposer

{

"name": "fabric-network",

"x-type": "hlfv1",

"version": "1.0.0",

"peers": {

"peer0.org1.example.com": {

"url": "grpc://localhost:7051",

"eventUrl": "grpc://localhost:7053"

}

},

"certificateAuthorities": {

"ca.org1.example.com": {

"url": "http://localhost:7054",

"caName": "ca.org1.example.com"

}

},

"orderers": {

"orderer.example.com": {

"url": "grpc://localhost:7050"

}

},

"organizations": {

"Org1": {

"mspid": "Org1MSP",

"peers": [

"peer0.org1.example.com"

],

75

Page 71: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

76 ANEXA A. PROFIL DE CONEXIUNE HYPERLEDGER COMPOSER

"certificateAuthorities": [

"ca.org1.example.com"

]

}

},

"channels": {

"composerchannel": {

"orderers": [

"orderer.example.com"

],

"peers": {

"peer0.org1.example.com": {

"endorsingPeer": true,

"chaincodeQuery": true,

"eventSource": true

}

}

}

},

"client": {

"organization": "Org1",

"connection": {

"timeout": {

"peer": {

"endorser": "300",

"eventHub": "300",

"eventReg": "300"

},

"orderer": "300"

}

}

}

}

Page 72: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

Anexa B

Configurare server REST cuutilizatori multiplii

export COMPOSER_PROVIDERS='{"github": {

"provider": "github",

"module": "passport-github",

"clientID": "[ID]",

"clientSecret": "[SECRET]",

"authPath": "/auth/github",

"callbackURL": "/auth/github/callback",

"successRedirect": "http://localhost:4200?loggedIn=true",

"failureRedirect": "/"

}

}'

export COMPOSER_DATASOURCES='{"db": {

"name": "mydb",

"connector": "mongodb",

"database": "mydb",

"host": "localhost"

}

}'

composer-rest-server -c admin@clinic-trial-network -n never -m true

77

Page 73: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

Anexa C

Modul pentru testarea aplicatieiclient

describe('OrganisationFormComponent', () => {

let component: OrganisationFormComponent;

let fixture: ComponentFixture<OrganisationFormComponent>;

beforeEach(async(() => {

TestBed.configureTestingModule({

imports: [

FormsModule,

ReactiveFormsModule,

AppMaterialModule,

RouterTestingModule,

HttpClientModule,

BrowserAnimationsModule

],

declarations: [OrganisationFormComponent],

providers:[

ResearchSiteService,

SupplyOrganisationService,

DataService,

Configuration

]

})

.compileComponents();

}));

beforeEach(() => {

fixture = TestBed.createComponent(OrganisationFormComponent);

component = fixture.componentInstance;

78

Page 74: FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_ATAndea.pdf · structurat pe urmatoarele capitole: Capitolul 1(Introducere) Primul capitol al

79

fixture.detectChanges();

});

it('should create', () => {

expect(component).toBeTruthy();

});

});


Recommended