Indicatii Terapeutice Bazate PE Reguli Si Imbunatatirea Securitatii Intr Un Sistem DE Gestiune A Pacientiilor

INDICATII TERAPEUTICE BAZATE PE REGULI SI IMBUNATATIREA SECURITATII INTR-UN SISTEM DE GESTIUNE A PACIENTIILOR

LUCRARE DE LICENȚĂ

2016

Absolvent: Prenumele NUMELE

TITLUL LUCRĂRII DE LICENȚĂ

Enunțul temei: Scurtă descriere a temei lucrării de licență și datele inițiale

Conținutul lucrării: (enumerarea părților componente) Exemplu: Pagina de prezentare, aprecierile coordonatorului de lucrare, titlul capitolului 1, titlul capitolului 2,… titlul capitolului n, bibliografie, anexe.

Locul documentării: Exemplu: Universitatea Tehnică din Cluj-Napoca, Departamentul Calculatoare

Consultanți:

Data emiterii temei: 1 noiembrie 2015

Data predării: 30 Iunie 2016 (se va completa data predării)

Declarație pe proprie răspundere privind

autenticitatea lucrării de licență

Subsemnatul(a)________________________________________________________________________________________________________________________, legitimat(ă) cu _______________ seria _______ nr. ___________________________
CNP _______________________________________________, autorul lucrării ____________________________________________________________________________________________________________________________________________________________________________________________elaborată în vederea susținerii examenului de finalizare a studiilor de licență la Facultatea de Automatică și Calculatoare, Specializarea ________________________________________ din cadrul Universității Tehnice din Cluj-Napoca, sesiunea _________________ a anului universitar __________, declar pe proprie răspundere, că această lucrare este rezultatul propriei activități intelectuale, pe baza cercetărilor mele și pe baza informațiilor obținute din surse care au fost citate, în textul lucrării, și în bibliografie.

Declar, că această lucrare nu conține porțiuni plagiate, iar sursele bibliografice au fost folosite cu respectarea legislației române și a convențiilor internaționale privind drepturile de autor.

Declar, de asemenea, că această lucrare nu a mai fost prezentată în fața unei alte comisii de examen de licență.

In cazul constatării ulterioare a unor declarații false, voi suporta sancțiunile administrative, respectiv, anularea examenului de licență.

De citit înainte (această pagină se va elimina din versiunea finală):

Cele trei pagini anterioare (foaie de capăt, foaie sumar, declarație) se vor lista pe foi separate (nu față-verso), fiind incluse în lucrarea listată. Foaia de sumar (a doua) necesită semnătura absolventului, respectiv a coordonatorului. Pe declarație se trece data când se predă lucrarea la secretarii de comisie.

Pe foaia de capăt, se va trece corect titulatura cadrului didactic îndrumător (consultați pagina de unde ați descărcat acest document pentru lista cadrelor didactice cu titulaturile lor).

Documentul curent a fost creat în MS Office 2007. Dacă folosiți alte versiuni e posibil sa fie mici diferențe de formatare, care se corectează (textul conține descrieri privind fonturi, dimensiuni etc.).

Cuprinsul începe pe pagina nouă, impară (dacă se face listare față-verso), prima pagina din capitolul Introducere tot așa, fiind numerotată cu 1. Pentru actualizarea cuprinsului, click dreapta pe cuprins (zona cuprinsului va apare cu gri), Update field->Update entire table.

Vizualizați (recomandabil și în timpul editării) acest document după ce activați vizualizarea simbolurilor ascunse de formatare (apăsați simbolul din Home/Paragraph).

Fiecare capitol începe pe pagină nouă, datorită simbolului ascuns Section Break (Next Page) care este deja introdus la capitolul precedent. Dacă ștergeți din greșeală simbolul, se reintroduce (Page Layout -> Breaks).

Folosiți stilurile predefinite (Headings, Figura, Tabel, Normal, etc.)

Marginile la pagini nu se modifică (Office 2003 default).

Respectați restul instrucțiunilor din fiecare capitol.

Cuprins

Introducere

Domeniul general de activitate al acestui sistem informatic prezentat in lucrarea de fata este cel medical, iar prin urmare utilizatorii ce beneficiaza de functionalitatile si procesele automatizate ale sistemului sunt fie pacienti aflati sub supraveghere sau internati in spital, fie personalul spitalului care se asigura ca fiecare pacient primeste ingrijirea corespunzatoare. Ramura medicinei pe care este specializat insa acest sistem, este oncologia, mai precis sectia cancerului de san.

Oncologia este o ramura a medicinei, care are ca scop studierea diagnosticului, tratamentului, etiologiei, patogenezei, clinicii, abilitarii si profilaxiei cancerului. Cuvantul cancer provine din grecescul „karkinos” (karkinos inseamna crab, analogia fiind facuta cu modul de deplasare in toate directiile) mentionat in scrierile lui Hippocrate din Kos. Cancerul chiar daca in zilele noastre a devenit una dintre cele mai mari probleme de sanatate publica, nu se poate spune despre aceasta ca reprezinta o afectiune moderna deoarece exista de cateva mii de ani. Este cunoscut ca, cancerul in trecut nu reprezenta un pericol asa de mare pentru populatie deoarece frecventa acestuia era foarte redusa, insa spre sfarsitul secolului al XIX-lea acesta a inceput sa se extinda si sa ii determine pe oamenii de stiinta sa studieze aceasta anomalie mai indeaproape. In secolul XX apar si primele centre de oncologie si este implementat sistemul oncologic, metodele de tratement se extind la operatii chirurgicale, chimeoterapie. Conform Cancer Research UK Institut numarul de noi cazuri de cancer de orice tip din 2012 pana in prezent ce s-a inregistrat la nivel mondial este 14.1 milioane, in urma carora 8.2 milioane de oameni si-au pierdut viata. In secolul XXI, metodele de tratare a cancerului devin tot mai diversificate si specializate pe anumite tipuri de cancer, dar cu toate acestea datorita stilului de viata dezordonat, mediului de viata si al alimentelor pe care oamenii le consuma, numarul bolnavilor de cancer este in crestere. Potrivit Organizatiei Mondiale a Sanatatii, peste 100 de tipuri de cancer au fost descoperite pana in prezent, iar in cazul barbatilor cele mai frecvente tipuri de cancer sunt: cancerul la plamani si la stomac, iar in cazul femeilor cele mai frecvente tipuri de cancer sunt: cancerul la san si la plaman.

Odata cu dezoltarea tehnologiei digitale, si in stiinta medicinii acest lucru a avut un impact mare datorita tot mai multor dispozitive medicale si solutii software folosite, care vin in ajutarea fie a tratarii pacientilor, fie in depistarea eventualelor afectiuni ale acestora, dar si in optimizarea unor procese medicale efectuate de catre specialisti.

Astfel, sistemul software pentru gestiune a pacientilor pe care se bazeaza aceasta lucrare face parte si el din aceasta categorie, fiind un portal web care se foloseste in cadrul Institutului Oncologic „Prof. Dr. Ion Chiricuta” Cluj-Napoca, sectia Cancer de Sân. Cancerul de san reprezinta la ora acutala cel mai raspandit tip de cancer prezent la femei, astfel in urma unui numar foarte mare de pacienti aceste sisteme informatice sunt foarte eficiente. Avand stocate in sistem datele medicale despre un pacient in urma analizelor efectuate, doctorii acceseaza portalul in cadrul sedintelor saptamanale, unde se iau deciziile medicale asupra pacientilor internati. Prin folosirea portalului si a functionalitatilor de care dispune, cum ar fi aceea de vizualizare a fisei pacientului, de vizualizare a istoricului medical, acesta contribuie la luarea deciziei. Ulterior aceasta decizie va fi introdusa in istoricul medical al pacientului, si va reprezenta un factor important in cadrul urmatoarei sedinte pentru un anumit pacient. Totodata, copii ale deciziei si a observatiilor adunate din cadrul sedintelor vor fi trimise la medicii prezenti via email. Pe viitor se doreste ca acest sistem sa fie folosit si in alte orase mai mici, unde spitalele nu dispun de un personal la fel de numeros si de bine pregatit ca cel din Cluj. Acolo, sistemul ii va ajuta pe doctori sa ia deciziile potrivite stabilind sedinte comune cu specialisti aflati in alte orase la momentul respectiv.

In cadrul acestei lucrari se va prezenta acest sistem informatic si serviciile noi implementate. Primul serviciu va reprezenta un mecanism de stabilire a indicatiilor terapeutice automat pentru tratamentele de tip standard, ce va folosi un instrument de gestiune a regulilor si va face posibila adaugarea de scenarii, respectiv reguli noi si de catre utilizatori neexperimentati tehnic. Deoarece pentru pacienti este vital timpul de raspuns al doctorilor si tratamentele de care au parte in spitale, adaugarea sistemului automat de generare a indicatiilor terapeutice este foarte folositor pentru acele indicatii care se stabilesc de fiecare data dupa aceleasi reguli si parametrii, adica sunt standard. Al doilea serviciu va avea rolul de a imbunatatii securitatea sistemului: asigurarea confidentialitatii datelor pacientiilor, prevenirea si luarea de masuri in cazul unor atacuri cibernetice.

Titlul capitolului se bazează pe Heading 1 style, numerotat cu o cifra (x. Nume capitol), font Times New Roman de 14, Bold.

Ce se scrie aici:

Contextul

Conturarea domeniului exact al temei

reprezintă cca. 5% din lucrare

Contextul proiectului (Heading 2 style)

Fontul folosit implicit în acest document este Times New Roman, dimensiune de 12, conform Normal style, cu spațiere la 1 rând (Paragraph, Line spacing de 1.0) și Justify.

Pentru prima linie din fiecare paragraf se folosește indentare (implicit in Normal Style), iar între paragrafe succesive nu se lasă distanță suplimentară.

(Heading 3 style)

Fiecare tabel introdus în lucrare este numerotat astfel: Tabel x.y, unde x reprezintă numărul capitolului iar y numărul tabelului din capitol. Se lasă un rând liber între tabel și paragraful anterior, respectiv posterior.

Tabel 1.1 (Insert caption->Tabel)

Fiecare figură introdusă în text este citată (de ex: în figura x.y este prezentată … ) și numerotată. Numerotarea se face astfel Figura x.y unde x reprezintă numărul capitolului iar y numărul figurii în acel capitol. Folosiți (Insert caption->Figura).

Figura 1.1 Numele figurii (insert->reference->caption->Figura)

Fiecare capitol începe pe pagină nouă.

Obiectivele Proiectului

În acest capitol se prezintă tema propriu zisă (sub forma unei teme de proiectare/cercetare, formulată exact, cu obiective clare – 2-3 pagini și eventuale figuri explicative).

Reprezintă cca. 10% din lucrare.

Studiu Bibliografic

Documentare bibliografica are ca obiectiv prezentarea stadiului actual al domeniului/sub-domeniului în care se situează tema. În redactarea acestui capitol (în general a întregului document) se va ține cont de cunoștințele acumulate la disciplinele dedicate din semestrul 2, anul 4 (Metodologia Întocmirii Proiectelor, etc.), precum si la celelalte discipline relevante temei abordate.

Acest capitol reprezintă cca. 15% din lucrare.

Referințele se scriu în secțiunea Bibliografie. Formatul referințelor trebuie sa fie de tipul IEEE sau asemănător. Introducerea și formatarea referințelor în bibliografie, respectiv citarea în text, se poate face manual sau folosind instrumentele de lucru menționate în ultimele paragrafe din acest capitol.

In secțiunea Bibliografie sunt exemple de referințe pentru articol la conferințe sau seminarii [1], articol în jurnal [2], sau cărți [3]. Referințele spre aplicații sau resurse online (pagini de internet) trebuie sa includă cel puțin o denumire sugestivă pe lângă link-ul propriu zis [4], plus alte informații dacă sunt disponibile (autori, an, etc.). Referințele care prezintă doar link spre resursa online se vor plasa în footer-ul paginii unde sunt referite.

Citarea referințelor în text este obligatorie, vezi exemplul de mai jos (în funcție de tema proiectului se poate varia modul de prezentare a metodei/aplicației).

În articolul [1] autorii prezintă un sistem pentru detecția obstacolelor în mișcare folosind stereoviziune și estimarea mișcării proprii. Metoda se bazează pe …trecere în revistă a algoritmilor, structurilor de date, funcționalitate, aspecte specifice temei proiectului etc….. Discuție avantaje – dezavantaje.

În capitolul 4 al [3], se prezintă …..

Instrumentele de lucru pentru MS Word 2003 și instrucțiuni de folosire găsiți la:

How to use JabRef (BibTeX) with Microsoft Word 2003

Bibtex4Word

BibWord makes it easier to create and manipulate Microsoft Word citation and bibliography styles

Pentru MS Word 2007 și MS Word 2010 se poate folosi sistemul integrat de gestiune bibliografiei, References, Citations & Bibliography. Mai multe informații se găsesc în documentația online de la MS Office.

Analiză și Fundamentare Teoretică

Arhitectura generala a sistemului

Prezentarea generală a arhitecturii de tip client-server

Aplicațiile de tip client-server au o structură de aplicații distribuite unde sarcinile și cantitatea de date de procesat e realizata de către furnizorii de resurse sau de servicii numite și servere iar cei care solicită serviciile sunt numiți clienți. Cel mai adesea comunicația dintre server și client se face peste o rețea de calculatoare pe hardware separat(Figura 4.1), dar atât clientul cât și serverul se pot afla în același sistem.

Figură 4.1 Arhitectura client-server

Clienții și serverele comunică unele cu altele prin intermediul mesajelor, într-un model de mesaje de tip cerere-răspuns. Astfel, clientul trimite o cerere iar serverul returnează un răspuns. Pentru a comunica cele două entități, calculatoarele trebuie sa aibă un limbaj comun și sa fie stabilite niște reguli de comunicare ce reprezintă împreună protocolul de comunicații. Aceste protocoale operează la nivel de aplicație iar unul dintre cel mai folosit este protocolul Hypertext Transfer Protocol (HTTP).

Arhitectura pe nivele

ASP.NET Model-view-controller (MVC)

Motor de reguli de business

Prezentarea generala

Definiții

Un motor de reguli („rules engine”) reprezintă in esența sa, un sistem software ce execută reguli de business într-un mediu de producție aflat în execuție. O regulă de business este o regulă ce definește sau constrânge unele aspecte ale afacerii si care sunt întotdeauna rezolvate prin a fi fie adevărate, fie false. Aceste reguli au forma unor declarații simple orientate spre afacere si care codifică anumite tipuri de decizii de afaceri fiind de foarte multe ori formulate sub forma condițională dacă / apoi. In general motoarele de reguli suportă reguli, excludere reciprocă, fapte, condiții prealabile și alte funcții.

Într-un sistem informatic, regulile de business se pot modifica cel mai frecvent decât orice altă componentă din codul aplicației. Sistemele de reguli reprezentate prin motoare de reguli sau motoare de interfețe alcătuiesc componente software conectabile care execută reguli de afaceri ce sunt externalizate sau separate de restul codului aplicației. Această externalizare sau separare permite utilizatorilor cu cunoștințe de business să modifice regulile de business fără să fie nevoie de intervenția personalului de la departamentul de IT. In ansamblu, sistemul devine mult mai ușor adaptabil cu astfel de reguli de business externe, dar acest lucru include verificări suplimentare de către departamentul de QA, unde se vor face diferite tipuri de testări.

Un motor de reguli se recomandă să se folosească pentru aplicațiile în care:

logica de business se modifică frecvent

sunt persoane care înțeleg în cel mai mic detaliu problemele pe care business-ul lor le rezolvă, dar care poate nu au cunoștințe tehnice în domeniul IT

e nevoie de o soluție ce ține de metodologia Agile, iar motorul de reguli permite cu ușurința schimbări a logicii de business într-o abordare iterativă

problema este mult prea complexă pentru orice altă soluție

Un motor de reguli nu se recomandă să se folosească atunci cand:

aplicația nu are o complexitate așa de mare, iar în urma unei analize rezultă că nici in viitor complexitatea nu v-a crește foarte tare

echipa de dezvoltatori nu are multă experiența cu aceste sisteme de reguli, iar proiectul are termeni limită foarte stricți sau este de profil mare; se recomandă mai întâi să se înceapă cu un prototip sau cu proiecte mai mici

pur si simplu nu este tehnologia potrivită pentru proiectul de față

Avantaje

Unul dintre principalele avantaje pentru folosirea unui motor de reguli este acela că separă datele folosite in aplicație de logica aplicației: datele se vor afla in obiectele de domeniu, iar logica se va afla in reguli. Astfel, logica poate fi mult mai ușor administrată si întreținută acolo unde vor exista schimbări în viitor, pentru că totul este prevăzut în reguli. În cazul în care logica este cross-domain sau multi-domain, în loc ca logica să fie răspândită în mai multe obiecte de domeniu sau de controlere, aceasta poate fii organizată într-unul sau mai multe fișiere de reguli distincte.

Un alt avantaj îl constituie viteza și scalabilitatea aplicației prin algoritmii eficienți implementați în cadrul acestor sisteme. Un exemplu de astfel de algoritm este algoritmul Rete, ce oferă modalități eficiente de potrivite a modelelor de reguli cu obiectele de date din domeniu. Este extrem de eficient atunci când există seturi de date ce nu se schimbă în întregime astfel că motorul de reguli își poate aminti potrivirile din trecut.

De altfel, un alt avantaj ar fi că se pot scrie reguli ale căror sintaxa arată foarte aproape de limbajul natural și prin urmare sunt ușor de înțeles. Prin folosirea regulilor, se crează un depozit de cunoștințe executabil unde se centralizează, iar acest lucru pentru politica de afaceri reprezintă un singur punct de adevăr. In mod ideal, regulile sunt atât de ușor de citit încât ele pot să servească și ca documentație.

Algoritmul Rete

Prezentare generală

Conform [6] limbajele de programare bazate pe reguli precum sunt CLIPS, ART sau OPS5 folosesc un algoritm foarte eficient pentru a potrivii faptele cu modelele din reguli astfel încât să se determine ce regulă are condiția satisfăcută. Acest algoritm se numește Rete și a fost inventat de catre Dr. Charles Forgy. Este un algoritm de potrivire a modelelor pentru punerea in aplicare a sistemelor de reguli în producție. Acesta este folosit pentru a determina care dintre regulile sistemului trebuie să se declanșeze bazat pe datele ținute în memoria acestuia. Numele acestui algoritm provine de la cuvântul „rete” care înseamnă în latină „net” sau „rețea”.

Într-un limbaj bazat pe reguli procesul de potrivire are loc in mod repetat (Figura 4.?2), iar lista de fapte se va actualiza la fiecare ciclu astfel încât faptele noi vor fi adăugate din listă iar faptele vechi vor fi șterse cauzând modificări modelelor anterioare să fie satisfăcute și viceversa. Pentru fiecărui ciclu, în timp ce se modifică faptele setul de reguli satisfăcute trebuie actualizat. Motorul de interfață (Interface Engine – Figura 4.?2) verifică fiecare regulă direct și caută în memoria de lucru faptele după fiecare ciclu de execuție rezolvând astfel aceasta problemă.

Figură 4.?2 Potrivirea modelului între reguli si fapte

Dezavantajul principal pe care aceasta tehnică îl aduce este acela că timpul de execuție a întregului proces poate sa fie foarte mare, reducând astfel performanța. Acest lucru se datorează cantității mari de calcule care nu sunt necesare deoarece modificarea faptelor la fiecare ciclu de execuție poate influența doar o cantitate mica de reguli, iar cu toate asta procesul se execută și pentru ele. Majoritatea sistemelor expert bazate pe reguli prezintă o proprietate numită redundanță temporală.

Algoritmul Rete de potrivire a modelului este proiectat sa profite de redundanța temporală prezentată de sistemul expert. Astfel, el este mult mai optim decât alți algoritmi care prezintă problema descrisă anterior. Daca într-un set de modele se găsește două sau trei fapte într-un singur ciclu, nu va mai fi necesară să fie făcută o verificare în următorul ciclu pentru două fapte care au fost deja găsite, ci doar al treilea va stârni interes. Starea unui proces de potrivire este actualizată doar dacă faptele sunt adăugate sau șterse, iar dacă numărul faptelor adăugate și șterse este mic comparativ cu numărul total de fapte și modele, atunci procesul de potrivire se va activa rapid. În cel mai rău caz, dacă toate faptele sunt nevoite să fie schimbate, atunci procesul de potrivire ar funcționa ca și în cazul în care toate faptele urmau să fie comparate cu toate modele. Daca doar actualizarea în lista de fapte ar fi procesată, atunci fiecare regulă ar trebui să rețină ce anume le-au potrivit deja. Astfel, dacă un fapt nou a potrivit un al treilea model a unei reguli, atunci informația care trebuie să potrivească primele două modele trebuie să fie disponibilă pentru a finaliza procesul de potrivire. Acest tip de stare a informației ce indică faptele care s-au potrivit în modelul precedent al unei reguli este numit potrivire parțială. Potrivirea parțială a unei reguli reprezintă orice set de fapte care ce satisfac modelele regulii, începând cu primul model al regulii și sfârșind cu până la orice model și inclusiv ultimul. Algoritmul Rete de asemenea îmbunătățește eficiența a sistemelor bazate pe reguli profitând de avantajul similitudinii structurale a regulilor. Acest lucru se referă la faptul că multe reguli adesea conțin un număr similar de modele sau un grup de modele, iar algoritmul Rete folosește această proprietate pentru a crește eficiența prin punerea în comun a componentelor astfel încât ele sa nu fie calculate mai mult decât o singură dată.

Conform [3] un program sistem de producție constă dintr-o colecție neordonata de declarații de tip daca-atunci (if-then) numite producții. Datele operate de către producții sunt ținute într-o bază de date la nivel global numită memorie de lucru. Prin convenție, partea de declarații de tip „dacă” (if) a unei producții este numita partea stânga (LHS – left hand side) iar partea de declarații de tip „atunci”(then) este numită partea dreapta (RHS – right hand side).

Graful Rete constă in două nivele: rețeaua Alfa ce constă în nodurile care fac parte din LHS si reprezintă noduri de clasă si noduri de discriminare, iar cel de-al doilea nivel este rețeaua Beta ce constă în nodurile care fac parte din RHS si reprezintă noduri ce unesc și care au două intrări.

Rețea Alfa

Rețea Beta

Algoritmul Rete folosit de Drools

Drools, descris în subcapitolul 4.2.3 folosește un algoritm Rete optimizat. Dr. Charles Forgy în lucrarea [6] descria 4 tipuri de bază de noduri, și anume: nodul rădăcină, nodul 1 de intrare, nodul 2 de intrare și nodul terminal. Nodul rădăcină reprezintă nodul prin care toate obiectele intră în rețea, iar de aici urmează să meargă la ObjectType (Figura 4.?3). Scopul nodurilor de tip ObjectType este să se asigure că motorul de reguli nu face mai multă treabă decât este nevoie. Dacă motorul de reguli ar trebui să încerce să evalueze fiecare nod cu fiecare obiect, ar rezulta într-o pierdere de prea multe cicluri. Pentru a fi mai eficient, motorul de reguli ar trebui să trimită obiectul doar la nodurile care se potrivesc cu tipul de obiect. Acest lucru se realizează prin crearea unui nod de tip ObjectType care să aibă toate nodurile de tip 1 intrare si 2 intrare moștenite din el. În Drools când un obiect este activat acesta preia o listă validă de noduri de tip ObjectTypes printr-o căutare într-un HashMap din clasa obiectului. În cazul în care această listă nu există se scanează toate nodurile de tip ObjectType pentru a găsi toate potrivirile la care le face caching în listă. Acest lucru ii permite lui Drools să se potrivească cu orice tip de clasă care trece de un control de instanță.

Figură 4.?3 Tipuri de noduri din graful Rete

Nodurile de tip ObjectType se pot propaga până la noduri de tip Alfa, LeftInputAdapter sau Beta. Nodurile de tip Alpha sunt folosite la evaluarea condițiilor literale. Drools extinde algoritmul Rete prin optimizarea propagării de la nodurile de tip ObjectType la nodurile de tip AlphaNode folosind hashing-ul. Astfel, de fiecare dată când un nod de tip Alfa este adăugat într-un nod de tip ObjectType el adaugă valuarea literalilor ca o cheie pentru HashMap având ca valoarea nodul Alfa. Atunci când o nouă instanță intră în nodul de tip ObjectType, mai degrabă decât propagarea la fiecare nod de tip Alfa, ea poate în schimb să primească nodul Alfa corect de la HashMap si astfel evitându-se controale ale literalilor ce nu sunt necesare.

Nodurile de tip Beta sunt reprezentate de două tipuri de noduri de intrare, și anume nod de tip Join și nod de tip Not. Aceste noduri sunt folosite pentru a compara două obiecte și câmpurile acestora, unele cu altele.

Drools

KIE Workbench

KIE Execution Server

Securitatea datelor prin criptare

Prezentare generala

Algoritmul AES

Descriere generala

Mod de functionare

Avantaje si dezavantaje

Împreună cu capitolul următor trebuie sa reprezinte aproximativ 60% din total.

Scopul acestui capitol este de a explica principiile funcționale ale aplicației implementate. Aici se va descrie soluția propusă dintr-un punct de vedere teoretic – explicați și demonstrați proprietățile și valoarea teoretică:

algoritm utilizat sau propus,

protocoale utilizate,

modele abstracte,

explicații/argumentări logice ale soluției alese,

structura logică și funcțională a aplicației.

NU SE FAC referiri la implementarea propriu-zisă.

NU SE PUN descrieri de tehnologii preluate cu copy-paste din alte surse sau lucruri care nu țin strict de proiectul propriu-zis (materiale de umplutură).

Proiectare de Detaliu si Implementare

Modificarile si functionalitatile noi aduse sistemului de gestiune a pacientilor vor fi prezentate in detaliu in cadrul acestui capitol, in care va descrie fiecare componenta implementata si explicat care este rolul acesteia.

Arhitectura generala a aplicatiei

Proiectul este structurat intr-o serie de componente principale, in cadrul carora la randul lor sunt implementate o serie de servicii. In Figura 5.1 este prezentata arhitectura conceptuala a aplicatiei care cuprinde aceste componente si modul in care ele comunica.

Figură 5-1 Arhitectura conceptuala a aplicatiei

Arhitectura este de tip client/server folosita este specifica aplicatiilor web, si reprezinta o arhitectura de retea unde toate procesele si toate calculatoarele din retea sunt fie un client, fie un server. Clientul, care este fie un calculator personal (PC) sau o statie de lucru de pe care utilizatorul ruleaza aplicatia, in cazul de fata aceasta fiind accesata printr-un navigator web instalat pe calculator, cere server-ului efectuarea si procesarea de operatii. Astfel, serverul reprezinta un program de aplicatie ce furnizeaza servicii aplicatilor client aflate pe acelasi calculator sau pe calculatoare dedicate de putere mare.

In arhitectura sistemului de gestionare a pacientilor, se folosesc doua straturi prin care trec datele pana sa ajunga in contact cu utilizatorul: nivelul de prezentare a aplicatiei, unde se foloseste in principal modelul arhitectural Model-view-controller si respectiv nivelul de acces la date unde se foloseste in principal modelul arhitectural Repository. Directia prin care trec datele din baza de date pana sa ajunga in interfata cu utilizatorul este urmatoarea: datele stocate intr-o baza de date relationala de tip SQL trec mai intai prin nivelul de acces la date, iar ulterior ajung in nivelul de prezentare a aplicatiei unde sunt transmise navigatorului web putand fi accesibile astfel utilizatorilor finali.

Baza de date folosita in aceasta aplicatie este una relationala de tip SQL, si are nu mai putin de 38 de tabele ce se afla in stransa legatura unele cu altele pentru a asigura o functionare corespunzatoare care sa satisfaca toate cerintele utilizatorilor. In aceasta directie, s-au adaugat o serie de trigger-uri la nivel de baza de date pentru a automatiza cat mai mult procesul de generare automata a indicatiilor terapeutice bazate pe reguli. Acestea vor fi prezentate in subcapitolele urmatoare. Cele doua noi mari servicii adaugate, cel de reguli si cel de securitate folosesc tabele dedicate din baza de date astfel s-au mai adaugat noi tabele pe langa cele existente sistemului.

Nivelul de acces al datelor

In nivelul de acces al datelor (Data Access Layer) are loc comunicatia directa dintre aplicatie si baza de date SQL prin intermediul framework-ului Entity Framework dezvoltat de Microsoft. In aplicatia prezentata, Entity Framework este implementat prin abordarea „Database first” ceea ce inseamna ca pentru ca schimbarile din baza de date SQL si codul aplicatiei sa se sincronizeze, este necesar ca mai intai sa se execute modificarile direct pe baza de date SQL prin intermediul unui tool de management al bazei de date, si abia ulterior sa se reflecte schimbarea in codul aplicatiei prin actualizarea fisierului .edmx care este generat de catre Entity Framework. Acest fisier este un fisier XML ce defineste modelul conceptual, modelul de stocare si relatiile dintre modele.

Entitatile din baza de date si datele sunt folosite in cadrul implementarii modelului de design „Repository Pattern” care este aplicat in acest nivel si care aduce astfel o serie de avantaje importante pentru dezvoltarea ulterioara:

se maximizeaza cantitatea de cod care poate fi testata prin testare automata

se izoleaza nivelul de date pentru a facilita unit testing

se imbunatateste lizibilitatea codului

se reduce cantitatea de cod duplicat, iar astfel la eventualele schimbari a bazei de date impactul va fi mai mic

In cadrul acestui model, fiecare entitate are un „depozit” care implementeaza cate o interfata specifica in care sunt declarate metodele ce pot fi apelate de catre celalalte componente. Acest modul a fost optimizat, prin adaugarea unei clase de baza generice (Figura 5.2) si implicit a unei interfete implementate de aceasta.

Pentru ca in cadrul solutiei existente cantitatea de cod din cadrul metodelor ce tin de modelul de design „Repository Pattern” era mult prea mare, aceasta schimbare ce ar trebui sa se fi produs in fiecare clasa din acesta ar fi adus un risc in plus aplicatiei pentru noua versiune. Astfel, impactul fiind prea mare s-a renuntat la modificarea codului existent, dar in schimb am decis sa se foloseasca pentru noile entitati adaugate in baza de date.

Figură 5.2 Implementarea clasei de baza pentru „Repository Pattern”

Aceasta metoda reduce duplicarea codului pentru fiecare model, expunand o serie de de metode generice care comunica direct cu baza de date: extrage toate elementele din baza de date, adauga element in baza de date, sterge element din baza de date si respectiv editeaza element din baza de date. Clasa generica „T” va reprezenta modelul din baza de date al entitatii pentru care „depozitul” ii poarta numele. Toate „depozitele” noi vor extinde clasa de baza si astfel in constructorul lor vor trimite mai departe contextul bazei de date permitand astfel ca BaseRepository (Figura 5.2) sa aibă acces la baza de date prin intermediul framework-ului Entity Framework care prin doar cateva linii de cod in fiecare din cele 4 metode implementate executa interogariile SQL dorite.

Singura exceptie prin care nu se comunica cu baza de date prin „Repository Pattern” , respectiv Entity Framework este la nivelul de logari, deoarece acolo se foloseste pachetul log4net care pune la dispozitie o metoda simpla si eficienta de a loga pe mai multe nivele si despre care voi vorbi in subcapitolele urmatoare.

Nivelul de prezentare a aplicatiei

Acest nivel este implementat printr-o aplicatie web cu .NET Framework 4.5 instalat, si care ruleaza sub un server IIS ce se afla pe masina server in care e hostata aplicatia. Modelul de design principal folosit este „Model-view-controller Pattern”, care se imparte in trei subcomponente dupa cum ii spune si numele : modeluri, view-uri si controlere. MvcApplication din Figura 5.3 reprezinta conceptual nucleul aplicatiei web, iar in momentul de inceput in care aplicatia incepe sa ruleze pe server se executa o serie de operatii ce incarca resursele necesare cu care aceasta comunica.

Figură 5.3 Arhitectura nivelului de prezentare

Pentru rezolvarea dependintelor, aplicatia foloseste „dependency injection container” (container de injectare dependinte) Unity, al carui container este initializat la startup in clasa UnityConfig. Caracteristicile acestui framework atat de popular in aplicatiile .NET MVC, ar fi: inregistrare, rezolver implicit / special container-e personalizate sau injectare de proprietati precum si configurare XML. In cadrul de fata, acesta foloseste la rezolvarea dependintelor intre interfetele si implementarile acestora din modelul de design „Repository Pattern” aflat in nivelul de acces al datelor, precum si al contextului bazei de date ce este folosit de Entity Framework. Tot in cadrul initializarii container-ului, deoarece se intampla odata pe perioada de runtime a aplicatiei, se initializeaza si serviciul de logare Log4Net.

In acest nivel, am optimizat modul de lucru al stilurilor aplicatiei astfel incat s-a inlocuit pachetul NuGet Bootstrap by Twitter cu pachetul NuGet Twitter.Bootstrap.Less, introducand astfel o noua tehnologie si anume : LESS. Toate stilurile de pana acum nu se pierd, deoarece stilurile de baza ale celor doua pachete Bootstrap sunt identitce, doar sintaxa si modul de import al acestora se schimba, fiind foarte asemenatoare cu limbajul Cascading Style Sheets. Pentru a compila codul LESS (Figura 5.4), va fi nevoie de instalarea extensiei pentru Visual Studio – Web Essentials, respectiv pentru Visual Studio 2015 – Web Compiler.

Figură 5.4 Antetul clasei de baza Site.less

In urma compilarii, va rezulta fisierul Site.css care va cuprinde astfel toate stilurile din Bootstrap si stilurile proprii scrise in clasa Site.less. Pentru a putea fi folosite de catre aplicatia MVC, acestea sunt configurate in BundleConfig alaturi de scripturile aplicatiei. In urma acestui procedeu, stilurile si scripturile se grupeaza purtand un nume generic reprezentativ, iar urmand mai apoi sa fie referentiate in paginile web a aplicatiei, mai exact in view-ul de Layout comun tuturor celorlalte pagini. Fisierele de stiluri se vor referentia la inceputul paginii alaturi de cateva fisere de scripturi fara de care pagina nu poate sa ruleze corespunzator, iar restul script-urilor la sfarsitul paginii dupa continutul acesteia, deoarece chiar daca script-urile au trecut prin procedeul de minificare, incarcarea lor poate sa influenteze drastic timpul de incarcare al paginii si astfel sa blocheze afisarea continutului pentru o perioada mai lunga de timp decat in mod normal.

Pentru partea de autentificare si autorizare se foloseste framework-ul implementat de catre Microsoft, si anume ASP.NET Identity. Acesta se configureaza la startup-ul aplicatiei, prin intermediul configuratiilor din clasa Startup.Auth in care se initializeaza contextul bazei de date pentru acest modul si serviciile adiacente ce sunt legate de utilizator. Acest framework pune la dispozitie o serie lunga de metode standard „out of the box” ce sunt folosite pentru managementul utilizatorilor si respectiv autentificare si autorizare.

View-urile sunt structurate pe ierarhii, ele pot fi partiale sau intregi. Pentru incarcarea stilurilor si a scripturilor dar si pentru a pastra un design specific pe fiecare pagina, se foloseste un view-ul Layout ce randeaza in partea de continut restul paginilor. Apelurile ce se fac din interfata cu utilizatorul trec prin protocolul HTTP si ajung la metodele din controlere.

Un controller este un obiect de interfata de baza non-utilizator responsabil pentru primirea si gestionarea unui eveniment de sistem. In aplicatia de fata, se foloseste modelul de design „Controller Pattern” iar astfel numele fiecaruia leaga actiunile aflate in acesta de o entitate anume, sau un grup de use case-uri. Modificarea la nivel de controlere ce a avut loc este adaugarea unui controler de baza care nu afecteaza functionalitatea celor care il extind, dupa cum se poate vedea si in Figura 5.4, deoarece si acesta la randul lui implementeaza System.Web.Controller . La nivel de infrastructura este folosit pentru a loga exceptiile ce au loc in cadrul aplicatiei MVC, lucru despre care se va vorbi in subcapitolele urmatoare, cand se vor descrie modulele si serviciile in detaliu.

Figură 5.4 Arhitectura bloc pentru Controllers

Serviciul pentru determinarea indicatiilor terapeutice automat

Diagrama de activitate pentru asignarea indicatiilor terapeutice generate automat

In acest subcapitol va fi descris lantul de evenimente pe care un actor trebuie sa il urmeze pentru a realiza cu succes asignarea recomandarilor terapeutice determinate automat pacientilor. Actorii principali care vor avea acces la aceasta functionalitate sunt utilizatorii cu rolul de supervizor de board sau membru de comisie.

Preconditii

Utilizatorul trebuie sa fie autentificat in sistem si autorizat cu rolul de Supervizor de comisie sau Membru de comisie pentru a avea acces la generarea automata de recomandari terapeutice. Pentru a confirma recomandariile terapeutice pentru un anumit pacient, utilizatorul trebuie sa aibă neaparat rolul de Supervizor de comisie, altfel utilizatorului nu ii va aparea optiunea de a confirma si astfel vor putea indeplinii doar o parte din sarcinile descrise in acest lant de evenimente. Totodata, fisa pacientului pentru care se doreste sa se stabileasca recomandariile automate de tratament trebuie sa aibă completate toate datele ce ar putea sa influenteze recomandarea. Ca o ultima preconditie dar foarte importanta, este ca serverul de executie al regulilor ce se apeleaza din aplicatia web sa fie pornit iar regulile sa fie introduse corect.

Postconditii

Entitatiile ce sunt implicate in cadrul scenariului trebuie sa ramane in stare consistenta daca operatia s-a terminat cu succes, dar si daca aceasta s-a terminat cu erori.

Fluxul de evenimente

Figură 5.5 Diagrama de activitate pentru generarea si asignarea indicatiilor terapeutice pacientilor

Fluxul de baza (principal)

Start. Acest caz de utilizare incepe cand un actor doreste sa asigneze asigneze o indicatie terapeutica generata automat pentru un anumit pacient.

5.2.1.4.1. Actorul initiaza cautarea de pacient, prin selectarea criteriilor de cautare: numele pacientului, prenumele pacientului, CNP etc.

5.2.1.4.2. Sistemul cauta pacientul iar actorul executa 5.2.1.4.2.1 sau 5.2.1.4.2.2.

5.2.1.4.2.1. Daca exista pacientul cu valorile cautate, actorul executa 5.2.1.4.3.

5.2.1.4.2.2. Daca nu exista pacienti cu valorile cautate, atunci actorul revine la 5.2.1.4.1.

5.2.1.4.3. Actorul acceseaza sumarul pacientului dorit din lista de pacienti rezultata.

5.2.1.4.4. Actorul selecteaza recomandare automata de tratamentu iar pe ecran apar datele medicale ale pacientului. Actorul executa 5.2.1.4.4.1 sau 5.2.1.4.4.2.

5.2.1.4.4.1. Daca se confirma datele pacientului, atunci se executa 5.2.1.4.5.

5.2.1.4.4.2. Daca nu se confirma datele pacientului, actorul executa 5.2.1.4.4.2.1 sau 5.2.1.4.4.2.2.

5.2.1.4.4.2.1. Daca actorul doreste sa caute alt pacient, revine la 5.2.1.4.1.

5.2.1.4.4.2.2. Daca actorul nu doreste sa caute alt pacient, revine la 5.2.1.4.3.

5.2.1.4.5. Sistemul genereaza indicatiile terapeutice automate si le adauga in lista cu cele existente daca e cazul, iar actorul executa 5.2.1.4.5.1. sau 5.2.1.4.5.2.

5.2.1.4.5.1. Daca actorul confirma o indicatie terapeutica, se executa 5.2.1.4.6.

5.2.1.4.5.2. Daca actorul nu confirma o indicatie terapeutica, acesta revine la 5.2.1.4.5 dar indicatia terapeutica va ramane neconfirmata si aceasta se va putea confirma ulterior sau sterge.

5.2.1.4.6. Sistemul salveaza propunerea terapeutica in indicatii terapeutice iar actorul executa 5.2.1.4.6.1 sau 5.2.1.4.6.2.

5.2.1.4.6.1. Daca actorul doreste sa ramana in continuare pe pagina cu sumarul pacientului unde e inclusa si lista de indicatii terapeutice generate, acesta revine la 5.2.1.4.5

5.2.1.4.6.2. Daca actorul nu doreste sa mai ramana in continuare pe pagina cazul de utilizare se termina.

Stop. In urma executiei pasilor din acest caz de utilizare, indicatiile terapeutice selectate de actor raman salvate pentru pacientul selectat.

Fluxul alternativ

5.2.1.5.1. Eroare la generarea indicatiilor terapeutice

Acest sir de evenimente apare in momentul in care serverul de pe care ruleaza serviciul de executie al regulilor nu este pornit din motive tehnice software sau hardware, sau daca orice alta eroare intervine in procesul de comunicare intre cele dou sisteme.

Acest eveniment poate sa apara in pasul 5.2.1.4.5. din Fluxul de baza.

5.2.1.5.2. Sistemul afiseaza un mesaj de eroare pentru a instinta actorul, iar in procesul din background se logheaza exceptia folosind sistemul de logari implementat.

Actorul va reveni la pasul 5.2.1.4.3. din Fluxul de baza.

Prezentarea arhitecturii serviciului si integrarea lui in proiect

Rolurile pe care acest serviciu trebuie sa le indeplineasca sunt: comunicarea cu serverul de executie al regulilor prin apeluri de tip REST, realizarea listei de recomandari generate automat, automatizarea procesului de modificare al modelului pe baza caruia se alcatuiesc regulile si returnarea adreselor unde se afla editorul de reguli din cadrul caruia se vor administra regulile.

Figură 5.6 Arhitectura generala a motorului de reguli

Aplicatia web comunica cu acest serviciu direct, stabilindu-se dependinte intre cele doua. Pentru a rezolva dependintele se foloseste dependency injection container Unity din cadrul aplicatiei web, unde sunt inregistrate serviciile pe rand, de exemplu: container.RegisterType<IKieService, KIEService>(); Singurele locuri din care se folosesc metode sau obiecte din cadrul acestui motor de regui, din nivelul de prezentare al aplicatiei web sunt SheetController, respectiv HomeController.

Din HomeController se folosesc metodele ce sunt implicate in procesul de automatizare a modelului, mai precis tot ce tine de JarService si totodata se folosec Helper-ele pentru returnarea adreselor cu locatia editorului de reguli din cadrul caruia se vor administra regulile.

SheetController are la randul lui dependinte cu serviciul de reguli, deoarece de aici se realizeaza generarea automata a recomandarilor terapeutice si se construieste modelul de date ce va fi trimis catre serverul de executie. Entitatea din baza de date Sheet se va folosi ca model pentru generatorul de reguli, deoarece reprezinta fisa pacientului iar in cadrul acesteia sunt toate datele necesare ce apar in protocolul autorizat de Institutul Oncologic. Din arhitectura serviciului (Figura 5.6), entitatile de business Treatment si Command cu clasele acestora impreuna au rolul de a serializa / deserializa datele trimise si primite de la serverul de executie. Metodele din cadrul KieService sunt apelate direct din acest controler prin interfata pe care o implementeaza, iar in cadrul lui se gasesc toate metodele ce contribuie la generarea automata a recomandarilor terapeutice.

Comunicarea cu serviciul extern pentru obtinerea de recomandari de tratament

Aplicatia web prin intermediul KieService (Figura 5.6) comunica cu serverul de executie al regulilor numit Kie Execution Server. Kie Execution Server-ul este o componenta independenta, out-of-the-box ce se foloseste pentru a executa si instantia reguli prin interfetele puse la dispozitie de acesta, de tip REST, JMS sau o aplicatie client Java. Acesta este pus la dispozitie in trei tipuri de fisiere WAR descrise in capitolul 4 al acestei lucrari, iar alegerea mea pentru acesta a fost sa folosesc WildFly pentru a hosta componenta.

Utilizatorul care doreste sa genereze o recomandare automata de tratament, prin intermediul framework-ului ASP.NetMVC va face un apel folosind protocolul HTTP la metoda AddRecomandation din SheetController. In cadrul acestei metode se va apela seriviciul KieServer ilustrat in Figura 5.6 iar rezultatul primit va fi o lista de tratamente generate automat ce se vor adauga in lista de propuneri terapeutice si vor putea fi ulterior confirmate sa nu de catre utilizatorii cu drepturi.

Apelarea serviciului pentru obtinerea tuturor seturilor de reguli

In cadrul [1] sunt prezenti mai multi arbori de decizie, fiecare dintre el reprezentand un protocol de stabilire a unui tip de tratament automat. Astfel, pentru fiecare in parte dintre acei arbori va trebui sa avem cate un set de reguli care sa fie introdus in memoria server-ului de executie prin intermediul editorului de reguli Kie Workbench. In cadrul serverului de executie, fiecare set de reguli este cuprins in cate un container ce reprezinta medii autonome ce sunt prevazute sa detina instante ale regulilor ambalate si implementate. Pentru a fi siguri ca se declanseaza toate regulile din toate seturile de reguli, va trebui apelat pe rand fiecare container si inregistrat raspunsul primit astfel incat rezultatul sa fie o lista de indicatii terapeutice pentru care datele pacientului s-au incadrat cel putin una din reguli. Astfel, avem nevoie de lista tuturor containere-lor pe care serverul le detine, iar acest lucru se face in cod prin intermediul interfetei REST expusa de Kie Execution Server.

Metoda responsabila pentru acest lucru este getAvailableContainersId din cadrul clasei KieService. In aceasta metoda se executa un apel REST de tip GET la un endpoint cunoscut ce e alcatuit in felul urmator: URL-ul serverului de executie la care se adauga “services/rest/server/containers”.

Figură 5.7 Exemplu de raspuns la apelul pentru obtinerea listei de containere

In antetul mesajului de cerere, valoarea proprietatii X-KIE-ContentType joaca un rol important deoarece aceasta determina formatul in care mesajul de raspuns va fi alcatuit. Acesta poate sa aiba mai multe valori, de ex: XML, JAXB, JSON etc. In proiectul de fata deoarece se foloseste deserializatori si serializatori JSON valoarea acestei proprietati va fi setata pe “JSON”.

Mesajul de raspuns returnat va arata ca in Figura 5.7 si va fi in format JSON , iar daca nu au aparut erori in cadrul procesului atunci tipul va fi „SUCCESS” iar mesajul va fi „List of created cointainers”. Dupa care va urma lista de containere, cu statusul aferent acestuia (STARTED daca e pornit, STOPPED daca e oprit) si identificatorul lui. In cadrul metodei getAvailableContainersId despre care vorbim, dupa ce am obtinut cu success un raspuns se parcurg pe rand toata lista de containere rezultata din mesajul de raspuns si se verifica care containere sunt pornite. Pentru acele containere care sunt pornite se va adauga in lista de siruri de caractere containersIdList identificatorii fiecaruia, urmand mai apoi sa fie folosita in urmatorul pas din acest proces pe care subcapitolul 5.2 il descrie.

Apelarea serviciului pentru declansarea tuturor regulilor si adaugarea rezultatului final ca tratament

Conform metodei descrise in subcapitolul anterior getAvailableContainersId, aceasta obtine identificatorii tuturor containere-lor pornite din cadrul serverului de executie, urmand sa fie luate pe rand si declansate regulile lor. Metoda MakeRequestToKieServer(CommandLIstWrapper commandList, string containerId) are acest rol, de a declansa toate regulile si de a salva intr-o variabila rezultatul. Parametrul containerId reprezinta identificatorul container-ului curent, iar commandList reprezinta obiectul model care se foloseste in crearea regulilor. Constructia acestui obiect pe langa model contine o structura fixa pe care serverul trebuie sa il foloseasca in executia regulilor. Structura acestuia cat si modalitatea prin care se formeaza acesta este descrisa in lucrarea [2].

Deoarece interfata serviciului de executie a regulilor suporta metode de tip REST, ceea ce inseamna ca se folosesc cereri HTTP de GET, PUT, POST sau DELETE iar in cadrul acestui modul se foloseste pachetul NuGet RESTSharp pentru a ajuta la aceasta comunicare. Pentru a declansa regulile, se va folosi un apel de tip POST catre serverul de executie al regulilor, ce va avea in continutul mesajului obiectul commandList serializat sub forma de JSON. Endpoint-ul apelului se alcatuieste in felul urmator: URL-ul serverului de executie, urmat de „services/rest/server/containers/instances/{id}” unde id reprezinta identificatorul container-ului pentru care se declanseaza regulile.

Pentru a initia un apel REST folosind acest framework, prima data se instanteaza un obiect de tip RestClient ce are rolul de a translata cererile REST in cereri HTTP si de a procesa raspunsul primit. Deoarece KIE Execution Server are implementat un mecanism de autorizare si autentificare, fiecare apel din aplicatia catre acesta trebuie sa contina in antet un user si o parola care sa fie inregistrat in fisierul de configuratie iar user-ul sa aibă drepturile necesare. Folosind RESTSharp, acest lucru se realizeaza astfel:

client.Authenticator = new HttpBasicAuthenticator(username, password);

Astfel RestClient-ul este configurat si urmeaza sa se creeze cererea. Cererea va trebui sa fie un mesaj HTTP, astfel incat se insanteaza un obiect de tip RestRequest ce primeste ca parametru endpoint-ul catre care se face cererea si tipul mesajului, in cazul de fata acesta va fi POST. In antetul mesajului se mai adauga proprietatile: Content-type:application/json si X-KIE-ContentType:json ce specifica tipul media al continutului mesajului. Obiectul commandList este serializat sub forma de JSON si setat ca continutul mesajului. Pentru a executa apelul, se foloseste metoda:

IRestResponse response = client.Execute(request);

Raspunsul (Figura 5.8) va reprezenta indicatia terapeutica pentru care datele pacientului se incadreaza, aceasta poate sa existe sau nu.

Figură 5.8 Exemplu de raspuns la metoda ce declanseaza regulile

Este foarte important ca in continutul mesajului trimis sa apara eticheta fire-all-rules ceeea ce inseamna ca toate regulile din container-ul apelat sa se execute si sa rezulte in final un singur tratament. Un set de reguli reprezinta un arbore decizional din protocol si este cuprins intr-un container, ceea ce in termeni practici inseamna ca fiecare ramura din acel arbore este cate o regula complexa la finalul careia se afla un anumit tip de tratament ca rezultat. Dupa cum e descris in capitolul 4 in cadrul motorului de interfata din arhitectura motorului de reguli Drools se foloseste un algoritm Rete extins, astfel, in momentul in care se executa acest apel daca sunt mai multe reguli cu valoarea adevarat atunci se folosesc strategii de rezolvare a conflictelor iar in final doar una singura e returnata. Este foarte important ca seturile de reguli sa fie introduse corect in editorul de reguli pana sa se ajunga la acest pas, deoarece in caz contrar vor aparea date gresite in baza de date iar recomandarile vor fi respinse de catre membrii de comisie si supervizorii de board.

Raspunsul primit se deserializeaza si se adauga intr-o lista de recomandari terapeutice. Acest proces se repeta pana cand au fost parcursi toate container-ele si astfel datele pacientului au trecut prin toti arborii de decizie. Obiectul in care se salveaza raspunsul are urmatoarele campuri:tipul tratamentului, subtipul tratamentului, observatii, doza de administrare, durata tratamentului, numarul de cicluri, numele probei si alte valori medicale. Aceasta lista va fi rezultata de metoda _kieService.GetTreatment iar datele vor putea fi prelucrate in continuare in controler-ul aplicatiei web. Pe rand, din lista rezultata se salveaza fiecare in baza de date ca propunere terapeutica in tabela TherapeuticProposal ceea ce inseamna ca stocarea acesteia va fi persistenta si daca ulterior vor aparea erori. In finalul procesului se returneaza un Json cu proprietatea success setata adevarat daca in cadrul procesului nu au intervenit erori, si valoarea fals daca au fost inregistrate erori. Erorile se vor loga folosind serviciul de logari in baza de date, iar de acolo administratorul va lua masurile necesare pentru a rezolva in timp util problema. Pe pagina de sumar al pacientilor se va face refresh iar in lista de propuneri terapeutice vor aparea afisate si indicatiile terapeutice generate automat in cadrul acestui proces. Daca utilizatorul are dreptul de Supervizor de board, atunci acesta va avea vizibil si buton de „Confirma” in dreptul propunerii iar apasand acest buton se va accepta acea propunere terapeutica generata automat si va fi copiata in tabela TherapeuticIndication din baza de date ceea ce inseamna ca pacientului ii va mai fi asignata o indicatie terapeutica confirmata cu intreaga comisie.

Managementul seturilor de reguli

Etapa premergatoare automatizarii pentru schimbarea modelului ce e folosit de sistemul de reguli

Deoarece modelul pe care se bazeaza sistemul de reguli este alcatuit din campurile fiselor medicale ale pacientiilor din baza de date, trebuie tratat cazul in care entitatea Sheet (fisa medicala) se modifica de catre dezvoltatorii aplicatiei din cauze subiective sau obiective. Acest proces trebuie sa fie cat mai automatizat cu putinta, pentru a simplifica munca dezvoltatorilor software in cazul aparitiei unei schimbari la nivel de baza de date, si trebuie sa le ofere transparenta utilizatorilor. Astfel in cadrul acestui subcapitol se va vorbi despre etapa premergatoare acestui proces. Intregul proces de automatizare este descris in continuare in lucrarea [2].

Baza de date pe care aplicatia o foloseste este de tip relational Microsoft SQL. Pentru a pregatii datele si a atentiona ulterior administratorii sistemului ca s-a produs o modificare in baza de date la nivel de design pe tabela ce reprezinta fisa pacientului, se foloseste un trigger la nivel de baza de date complex si o procedura stocata ajutatoare.

Trigger-ul implementat la nivel de baza de date este alcatuit din doua parti. In prima parte (Figura 5.9) se logheaza in tabela RuleEngineTablesLog schimbarile de design ce s-au produs la nivelul tabelei Sheet. Nu toate tipurile de schimbari se logheaza, ci doar daca au avut loc adaugari sau stergeri de coloane. Astfel informatiile logate sunt: data la care s-a produs modificarea, numele tabelului in cadrul caruia s-a produs modificarea (va putea fi folosit pentru dezvoltari ulterioare), numele utilizatorului SQL ce a produs modificarea si cel mai important descrierea evenimentului prin afisarea comenzii TSQL ce a avut loc.

Figură 5.9 Fragment din trigger-ul SQL pentru logarea schimbarilor de design ce au loc in tabela ce reprezinta fisa pacientului

Acest trigger este de tip Data Definition Language (DDL) si este ca orice trigger la baza care declanseaza proceduri stocate ca raspuns la un eveniment. Diferenta consta insa in faptul ca trigger-ele obisnuite ce sunt declansate ca raspuns la comenzile de update, delete sau insert pe un tabel sau pe un view, trigger-ele DDL sunt declansate ca raspuns la o varietate de evenimente de tip Data Definition Language (DDL). Aceste evenimente corespund in primul rand la comenziile Transact-SQL ce incep cu cuvintele cheie create, alter sau drop. Pentru cazul de fata, acest trigger se declanseaza in momentul in care exista un eveniment Transact-SQL ce tine de modificarea unui tabel existent, prin comanda ALTER_TABLE. Acest trigger este tinut la nivelul bazei de date si nu la nivel de tabel.

Dupa cum se poate observa si in Figura 5.9, variabila ed este declarata de tip XML iar aceasta e atribuita cu valoarea a ce returneaza functia de sistem EVENTDATA(). Aceasta functie returneaza informatii despre server sau despre evenimentele ce au loc in cadrul bazei de date curente. Aceste date returnate sunt in format XML, iar pentru a obtine date specifice in trigger-ul curent se foloseste de limbajul XQuery. Acest limbaj este bazat pe limbajul XPath ce se foloseste in mod obisnuit la alcatuirea de expresii pentru a selecta noduri diverse din fisierul XML. Folosind XQuery pe variabila ed se obtin informatiile referitoare la ultimul eveniment ce a avut loc, adica acelasi eveniment pentru care trigger-ul DDL prezentat in Figura 5.9 a fost declansat. Informatiile extrase din structura XML ce a rezultat in urma functiei EVENTDATA() sunt: TSQLCommand pentru campul in care se va descrie evenimentul, ObjectName pentru numele tabelului care a suferit modificari si LoginName pentru numele utilizatorului care a declansat evenimentul.

Cea de-a doua parte din cadrul trigger-ului are rolul de a adauga sau sterge date in tabela RuleEngineSheet. Cu ajutorul datelor din aceasta tabela, se genereaza fisierul JAR cu clasa modelului folosit de editorul de reguli, conform lucrarii [2]. Datele ce se introduc in aceasta tabela sunt: numele exact al coloanei adaugate din tabela Sheet, tipul de date a noii coloane adaugate in tabela Sheet. O a treia informatie ar fi IsInUse, dar in acest trigger se seteaza implicit pe valoarea fals. Pentru aceste date se foloseste din nou variabila ed declarata in cadrul acestui trigger si care continte informatii despre ultimul eveniment la nivelul bazei de date. Astfel, folosind XQuery se selecteaza datele despre comanda Transact-SQL efectuata, iar aceasta este parsata prin procedura stocata func_split dupa caracterul spatiu pentru a obtine un vector ce va contine cuvintele comenzii TSQL. Se verifica daca are loc o actiune de adaugare sau de stergere a unei coloane.

In cazul unei adaugari de coloane din tabela Sheet, se stocheaza in variabilele propetryNameToAdd numele noii coloane iar in propetryTypeToAdd tipul acestei noi proprietati. Conform [2] in tabela RuleEngineSheet in cadrul coloanei PropetryType va fi necesar ca tipurile de date sa fie compatibile cu limbajul Java. Astfel in cadrul valorii variabilei PropetryTypeToAdd se va face conversia tipurilor de date din limbaj SQL in limbaj Java astfel: tipul char va deveni string, tipul int va deveni int32, tipul decimal va ramane lafel iar tipul bit va deveni bool. Dupa ce se obtin datele corect, acestea vor fi inserate in tabela RuleEngineSheet.

In cazul stergerii unei coloane din tabela Sheet, se va folosi aceeasi procedura stocata func_split pentru a parsa datele din comanda TSQL, si se va extrage intr-o variabila locala numele coloanei care a fost stearsa. Avand numele acestei proprietati, se va cauta in tabela RuleEngineSheet randul care o contine, iar daca aceasta a fost gasita atunci va fi stearsa si din aceasta tabela.

Serviciul pentru imbunatatirea securitatii sistemului de gestiune a pacientiilor

Deoarece aceasta aplicatie are intrebuintare in domeniul medical, toate datele aflate in baza de date sunt extrem de sensibile si ele trebuie tinute confidential pentru restul peroanelor care nu au roluri in aceasta aplicatie. Totodata odata cu avansarea tehnologiei si inlocuirea a tot mai multor procese din viata de zi cu zi, numarul atacurilor cibernetice au crescut iar masuri in aceasta directie trebuie luate. In acest capitol se propun solutii pentru imunatatirea securitatii.

Log pentru activitatea utilizatorilor

Pentru a putea urmari ca administrator al aplicatiei intreaga activitate pe care un user o face de-a lungul unei sesiuni, s-a implementat acest modul de logare a actiunilor. Astfel, se iau masuri de securitate in cazul in care vreun cont a fost spart in sensul ca toate actiunile pe care atacatorul le face vor putea fi urmarite iar la final se vor analiza iar o parte din actiuni vor putea fi corectate. De altfel, daca siteul primeste atacuri cibernetice, toate apelurile lui catre server vor fi de asemenea logate chiar daca nu este logat in aplicatie cu nici un user.

Acest modul este implementat printr-un atribut customizat ce are ca si atribut de baza un ActionFilterAttribute. Metodele pe care acesta le expune si care se pot suprascrie sunt: OnActionExecuting, OnActionExecuted, OnResultExecuting, OnResultExecuted. Atributul creat se numeste UserTrackerLogAttribute si suprascrie clasa ce deriva din atributul de baza, mai precis clasa OnActionExecuted. Aceasta metoda este apelata dupa ce o actiune din controler a fost executata. Se foloseste in cadrul modelului de design Model-view-controler conform caruia toate actiunile ce sunt exercitate de catre utilizator din interfata cu utilizatorul vor trece prin aceste clasa de controler.

Pentru a loga doar actiunile care sunt considerate critice sau care pot sa aibă un impact mare asupra aplicatiei, se logheaza doar mesajele de tip HTTP POST, PUT, DELETE ce comunica cu controler-ele. In cazul in care administratorul aplicatiei doreste totusi sa primeasca informatii legate si de alte actiuni de exemplu de tip GET, prin interventia in cod se poate realiza acest lucru foarte usor. In primul rand pentru a fi sigur ca nu „scapa” metode de tipul precizat mai sus de mecanismul de logare a actiunilor utilizatorilor, UserTrackerLogAttribute se va inregistra in colectia de filtre globale a aplicatiei MVC astfel:

public static void RegisterGlobalFilters(GlobalFilterCollection filters)

{

filters.Add(new UserTrackerLogAttribute());

}

Aceasta metoda statica se gaseste in clasa FilterConfig din cadrul fisierului de configuratii App_Start si va fi apelata o singura data la rularea aplicatiei din Global.asax in metoda Application_Start(). Acest lucru asigura ca pe toate metodele din controler-ele aplicatiei web sa se aplice acest atribut.

In cadrul acestui atribut exista o proprietate publica de tip sir de caractere ActionName ce poate fi logata optional in baza de date. Aceasta are rolul ca pe langa numele simplu al actiunii din cod si al controler-ului din care aceasta face parte, sa se descrie mai pe larg actiunea pe care acest atribut se aplica. Pentru a putea beneficia de aceasta functionalitate, este nevoie ca metodele sa fie decorate fiecare in parte cu acest atribut UserTrackerLogAttribute sub forma:

[UserTrackerLog(ActionName = "Schimbarea parolei unui user")]

public async Task<ActionResult> ChangePassword(ChangePasswordViewModel model){…}

Nu e obligatoriu sa se decoreze fiecare metoda in acest fel, dar lucrul acesta ajuta mult administratorul care urmareste logarile deoarece se poate intampla ca numele metodei si al controler-ului sa nu fie intotdeauna suficient pentru ca acesta sa isi dea seama de rolul actiunii vizate.

Logurile pentru activitatea utilizatorilor sunt pastrate in baza de date, in tabela UserTrackerLog. Aceasta tabela are urmatoarele coloane:

Id – reprezinta identificatorul unic al log-ului

UserId – reprezinta o cheie straina catre tabela in care sunt tinuti userii aplicatiei, iar astfel daca acesta este completata va reprezenta userul care a executat actiunea

Date – reprezinta data la care a avut loc actiunea

Action – reprezinta acel atribut ActionName prezentat mai sus care descrie actiunea

IPAddress – reprezinta adresa de retea al dispozitivului de pe care se executa actiunea

CalledUrl – reprezinta intregul URL care a fost apelat pentru a executa actiunea

UserAgent – reprezinta agentul software de pe care actioneaza utilizatorul (de exemplu tipul navigatorului web si versiunea: Firefox47)

SessionId – reprezinta un identificator unic reprezentat printr-un sir de caractere random ce identifica sesiunea utilizatorului

PassedData – reprezinta datele in format JSON ce se afla in continutul mesajului

In cadrul acestui atribut, se suprascrie metoda OnActionExecuted al clasei pe care acesta o mosteneste ActionFilterAttribute iar aceasta clasa primeste ca parametru ActionExecutedContext avand astfel acces la contextul http curent din care s-a facut cererea. Din filterContext se iau toate acele date care trebuie introduse in tabela UserTrackerLog si sunt prelucrate fiecare inainte de a fi inserate pentru a avea formatul asteptat. Identificatorul unic al utilizatorului care apeleaza metoda se obtine din cadrul contextului folosind metoda expusa de catre framework-ul AspNet.Identity GetUserId. Informatiile ce vor fi inserate in coloana PassedData trebuie sa fie in format JSON, astfel incat se parcurge lista de chei a form-ului prezent in contextul http, si se formateaza text pentru a avea o structura de json in final. Restul informatiilor precum identificatorul sesiunii, data la care a avut loc actiunea, url-ul apelat etc. sunt extrase direct din context si sunt inserate intr-un obiect ce reprezinta entitatea din baza de date a log-ului. Informatiile continute in corpul mesajului, cheile luate din context form data sunt folositoare pentru a avea informatii in plus asupra datelor care au fost afecatate de actiunea utilizatorului. Identificatorul de sesiune are un rol important deoarece filtrand dupa acesta se vor putea urmari toate actiunile unui anumit utilizator pe care le-a executat intr-o sesiune.

Inserarea in baza de date a entitatii create UserTrackerLog se face cu ajutorul EntityFramework, folosind metoda de adaugare din cadrul IUserTrackerLogRepository(). Deoarece in cadrul filtrului nu avem acces la aceasta interfata de repository prin container-ul curent Unity, va fi necesar sa se intializeze un nou container valabil doar pe durata acestui apel de adaugare al log-ului in baza de date.

Dupa ce datele au fost adaugate cu succes in baza de date, acestea vor putea fi vizualizate de catre utilizatorii cu drepturile de administratori pe pagina de logare a actiunilor utilizatorilor, ce se afla in meniu in categoria de Administrare. Pe aceasta pagina, se vor putea face sortari si cautari dupa diferite coloane, si va fi util in cazul in care au fost semnalate greseli sau atacuri cibernetice.

Aceste loguri se vor putea sterge si din cadrul aplicatiei, dar doar dupa trecerea unei anumite perioade. Acest lucru se realizeaza prin butonul „Sterge log-uri mai vechi de X luni”, unde valoarea lui X va fi setata din cadrul fisierului de configurare Web.Config prin cheia UserTrackingLogNumberOfMonths. Fiind o cheie la nivelul fisierului de configuratie, aceasta va putea fi schimbata oricand de pe server-ul in care e hostata aplicatia iar daca in viitor se va dori ca data limita pentru care sa se stearga log-uri sa fie diferita, acesta schimbare nu va afecta deloc codul si nu va fi costisitoare.

Serviciul de criptare al datelor

Deoarece se lucreaza cu date medicale ale pacientilor ce sunt stocate in baza de date a sistemului, in primul rand serverul si aplicatia trebuie sa fie foarte securizate la nivel de retea dar in al doilea rand anumite date trebuie criptate pentru ca in cazul in care baza de date este furata sau sunt extrase partial date de catre un atacator cibernetic, datele acelea sa nu valoreze nimic pentru acea persoana. Un alt avantaj pe care il constituie implementarea acestui serviciu de criptare este acela ca dezvoltatorii software ce vor lucra la schimbari in baza de date sau la nivel de aplicatie web sa nu aiba acces nici ei la randul lor la identitatea pacientului decat daca primesc aprobare.

Serviciul de criptografie este situat la nivelul de acces al datelor (Figura 5.1) si este reprezentat prin clasa CryptoService. Metodele din cadrul acestuia sunt apelate din nivelul de prezentare al aplicatiei, si au rolul de a cripta si decripta anumite campuri. Campurile vizate de acest serviciu care sunt criptate la nivelul bazei de date sunt:

FirstName din tabela Patient – reprezinta prenumele pacientului

LastName din tabela Patient – reprezinta numele de familie al pacientului

CNP din tabela Patient – reprezinta codul numeric personal al pacientului

PassedData din tabela UserTrackerLog – reprezinta datele ce se afla in continutul mesajului HTTP

Numele si prenumele pacientului, cat si codul numeric personal al acestuia formeaza identitatea pacientului iar avand aceste date criptate la nivelul bazei de date se asigura pastrarea confidentialitatii pentru pacientii aflati in sistemul informatic de fata iar in cazul unui furt ale acestor date, ele nu vor avea nicio valoare. Este criptata si proprietatea PassedData din tabelul UserTrackerLog deoarece si acest camp poate contine date de identificarea a pacientilor pentru actiunile care interactioneaza cu entitatea pacient in mod direct (de exemplu actiunea de creare a unui pacient).

Criptarea si decriptarea acestor date se fac astfel la nivel de aplicatie, direct din codul C#. Algoritmul folosit in cadrul serviciului de criptografie este Advanced Encryption Standard (AES) sau cunoscut sub numele de Rijnadael. Acest algoritm a fost stabilit de catre U.S. National Institute of Standards and Technology in anul 2001 si este un algoritm de criptare ce foloseste chei simetrice. Mai multe detalii despre algoritmul AES se gasesc in capitolul 4 al acestei lucrari.

Deoarece doar aplicatia encripteaza datele si tot ea le decripteaza, transmiterea cheii nu este necesara si astfel se poate folosi aceeasi cheie publica pentru criptare cat si pentru decriptare. Algoritmii asincroni de criptare ce folosesc cate o cheie separata, una publica pentru criptare iar una privata pentru decriptare au dezavantajul ca sunt destul de costisitori din punct de vedere al resurselor iar astfel scad performanta si timpul de executie al acestui procedeu poate sa devina mare. S-a optat pentru folosirea unui algoritm sincron din acest motiv, iar in contextul de fata algoritmul ales asigura securitatea in intregime. Pentru o mai buna securitate se foloseste algoritmul AES256, ceea ce inseamna ca dimensiunea cheii este de 256 de biti iar pana la ora actuala si probabil mult timp de-acum incolo acesta nu a fost compromis.

In cadrul clasei CryptoService se afla cele doua metode responsabile pentru encriptare respectiv decriptare:

public static string EncryptStringAES(string decrypted) {..}

public static string DecryptStringAES(string encrypted) {..}

Pentru ambelele metode se folosesc librariile de la Microsoft incluse in namespace-ul System.Security.Cryptography.

Cheia folosita pentru criptarea si decriptarea datelor

In orice algoritmi de criptare, cheia are un rol extrem de important intrucat fara o cheie valida nu se pot cripta sau decripta datele. In cadrul serviciului de criptografie implementat, deoarece se foloseste algoritmul AES care este un algoritm de criptare de tip simetric, cheia de criptare este folosita si la decriptare. Ambele parti, in cazul in care criptarea si decriptarea se fac pe masini diferite trebuie sa cunoasca aceasta cheie. In cazul de fata insa, atat criptarea cat si decriptarea se fac in cadrul aplicatiei, ceea ce inseamna ca doar din cadrul aplicatiei este suficient sa fie accesata si folosita.

Cheia folosita in cadrul acestui serviciu este tinuta in Registrul Windows, care reprezinta o baza de date al carei continut consta in configurari si optiuni ale sistemului de operare Microsoft Windows. Aceasta contine astfel setari pentru componentele sistemului de operare, dar poate sa contina si setari pentru aplicatiile care ruleaza pe aceasta platforma si care au decis sa foloseasca acest registru.

Cel mai uzual loc in care se metin configurari pentru aplicatiile .NET sunt in fisiere XML din cadrul proiectului. Dar in cazul stocarii cheii simetrice pentru criptare, a mentine cheia in fisierul Web.config de exemplu al aplicatiei web nu era tocmai potrivit, deoarece aceasta putea fi din greseala stearsa sau modificata, iar in cazul unui release gresit al aplicatiei intr-un mediu public, cel putin pentru o perioada scurta de timp pana cand acesta va fi finalizat cu success, ar putea sa rezulte in permiterea oricui sa navigheze printre fisierele aplicatiei in momentul in care acceseaza aplicatia cunoscandu-i adresa URL si astfel sa extraga date din acel fisier de configuratie.

Cheia folosita are o lungime de 256 de biti, echivalentul a 32 de bytes si se introduce in Registrul Windows prin accesarea acestuia la nivelul sistemului de operare.(Figura 5.11) Cheia se afla in HKEY_CURRENT_USER in subcheia Encryptor si are numele CryptoSymmetricKey. Este foarte important ca locul in care se pastreaza cheia sa nu se modifice, deoarece asta ar influenta o modificare si asupra codului. Avantajul pe care il ofera aceasta baza de date de configurari este acela ca se pot seta permisiuni direct din Registry Editor (Figura 5.11) iar astfel asignarea rolurilor care sa aibe acces asupra acestei chei se realizeaza foarte usor.

Figure 5.11 Registrul Windows

Deoarece este o aplicatie web .NET Framework hostata in cadrul Internet Information Services (IIS), asupra subcheii Encryptor si implicit asupra cheii CryptoSymmetricKey se seteaza ca doar utilizatorii sistemului de operare cu dreptul de administratori si userul folosit de catre IIS sa aibă acces la citirea acestora. Prin urmare aceasta cheie nu va putea fi extrasa de catre un atacator decat daca acesta obtine drepturi depline asupra server-ului de pe care este hostata aplicatia.

Vectorul de initializare

Conform modului de criptare folosit: Cipher Block Chaining (CBC) descris mai in detaliu in capitolul 4 al acestei lucrari, este nevoie si de un vector de initializare pe langa cheie pentru a realiza criptarea, respectiv decrpitarea. Pentru acest mod de criptare folosind algoritmul AES, criptarea fiecarui bloc este calculate din cheie, blocul text si textul cifrat blocului anterior. Pentru primul bloc, vectorul de initializare denumit si IV (Initialization Vector) este utilizat in locul textului cifrat pentru blocul inexistent anterior.

Vectorul de initializare trebuie sa fie intotdeauna diferit, pentru fiecare pereche de criptare-decriptare a unui text, deoarece in acest fel nu se vor creea niciodata blocuri text criptate care sa semene intre ele si care sa permita atacatorului sa gaseasca un model(pattern) intre acestea, lucru care ar putea duce la compromiterea datelor. Pentru a obtine mereu un vector de initializare generat aleator, se foloseste un generator criptografic aleator implementat in cadrul clasei AesCryptoServiceProvider astfel:

AesCryptoServiceProvider aesCryptoService = new AesCryptoServiceProvider {..};

aesCryptoService.GenerateIV();

In urma apelarii acestei metode, aesCryptoService.IV va contine un vector de biti alesi aleatori. Pentru ca acelasi vector de initializare trebuie folosit si la decriptarea informatiei pe langa cheia de decriptare, acest vector de initializare prefixeaza textul codat rezultat in urma criptarii (cypher text) iar astfel fiecare informatie codata va contine in cadrul primelor caractere vectorul de initializare.

Criptarea datelor

Metoda de encriptare a datelor (Figura 5.10) primeste sirul de caractere ce trebuie encriptat prin parametrul decrypted iar pentru ca algoritmul de criptare are nevoie ca datele de intrare sa fie un vector de biti, se face conversia acestuia prin prima linie de cod a acestei metode.

Figura 5.10 Metoda responsabila cu encriptarea datelor

Obiectul de baza folosit pentru a encripta date cu ajutorul algoritmului AES este AesCryptoServiceProvider iar in cadrul acesteia se foloseste clasa SymmetricAlgorithm ce are nevoie sa fie specificate urmatoarele proprietati:

BlockSize – dimensiunea in biti a block ciphers

KeySize – dimensiunea in bitit a cheii simtetrice folosite

Key – valoarea cheii simetrice folosite

Padding – determina modul in care se face padding-ul

Mode – determina modul de functionare a block cipher (algoritmul folosit)

Se obtine cheia din Registrul Windows, iar in cazul in care aceasta nu este gasita se arunca o exceptie ce se logheaza in sistemul de erori iar aplicatia afiseaza o pagina de eroare. Daca exista cheia, aceasta se converteste din ASCII in vector de biti si se asigneaza lui aesCryptoService.Key. Dimensiunea cheii este de 32 bytes, dimensiunea blocului codat (cipher text) este de 128 biti, iar dimensiunea vectorului de initializare este de 16 bytes. Modul de functionare a block cipher-ului este Cipher Block Chaining (CBC) iar modul de padding este PKCS7. Acestea sunt descrise in capitolul 4.

Pentru a initializa criptarea datelor, se creaza un obiect de criptare simetrica folosind cheia specificata si vectorul de initializare generat aleatoriu: ICryptoTransform. Cruptarea se realizeaza prin apelarea metodei TransformFinalBlock ce asteapta ca parametrii:

inputBuffer – sirul de biti de intrare pentru care se realizeaza criptarea

inputOffset – decalajul din vectorul de biti de la care sa inceapa utilizarea datelor

inputCount – numarul de octeti din vectorul de octeti utilizat ca date

Va rezulta textul criptat care va fi prefixat de vectorul de initializare conform explicatiilor din subcapitolul anterior 5.3.2.2. In final metoda EncryptStringAES va return sirul de caractere ce reprezinta vectorul de initalizare si textul criptat ce urmeaza sa fie salvat in baza de date.

Decriptarea datelor

Pentru decriptarea datelor se foloseste metoda DecryptStringAES din clasa CryptoService si are ca parametru de intrare textul criptat. Modul de functionare al acestei metode este foarte asemanator cu cel de criptare, cu cateva mici diferente.

Cheia de decriptare va fi aceeasi cu cheia de criptare, deci se va obtine tot din aceeasi subcheie a Registrului Windows iar vectorul de initializare va fi extras din cadrul parametrului de intrare astfel:

var iv = encBytes.Take(aesCryptoService.BlockSize / 8).ToArray();

aesCryptoService.IV = iv;

Pentru a decripta textul, va fi necesara stergerea vectorului de initializare de la inceputul secventei de biti a textului de intrare. Se foloseste un obiect de decriptare simetrica folosit, iar modul prin care textul se decripteaza se face prin aceeasi metoda apelata ca la criptare, si anume TransformFinalBlock. In final textul decriptat se converteste in ASCII urmand sa fie folosit in cadrul aplicatiei acolo de unde aceasta metoda este apelata.

Un alt modul adus in plus acestui nivel de acces la date este cel de logare al erorilor. Acesta implica introducerea unei noi tabele in baza de date in care se inregistreaza pe rand data si ora in care s-a produs eroare, numarul thread-ului in care a avut loc, mesajul si exceptia erorii. S-a introdus o noua dependinta de pachetul „log4net”, iar metodele statice folosite in cadrul acestui serviciu nou permite logarea de erori din orice loc al solutiei.

Testare și Validare

Aproximativ 5% din total.

Manual de Instalare si Utilizare

În secțiunea de Instalare trebuie să detaliați resursele software și hardware necesare pentru instalarea și rularea aplicației, precum și o descriere pas cu pas a procesului de instalare. Instalarea aplicației trebuie să fie posibilă pe baza a ceea ce se scrie aici.

În acest capitol, trebuie să descrieți cum se utilizează aplicația din punct de vedere al utilizatorului, fără a menționa aspecte tehnice interne. Folosiți capturi ale ecranului și explicații pas cu pas ale interacțiunii. Folosind acest manual, o persoană ar trebui să poată utiliza produsul vostru.

Concluzii

Cca. 5% din total.

Capitolul ar trebui sa conțină (nu se rezumă neapărat la):

un rezumat al contribuțiilor voastre

analiză critică a rezultatelor obținute

descriere a posibilelor dezvoltări și îmbunătățiri ulterioare

Bibliografie

[61] A. Bak, S. Bouchafa, and D. Aubert, "Detection of independently moving objects through stereo vision and ego-motion extraction," in IEEE Intelligent Vehicles Symposium (IV), San Diego, USA, 2010, pp. 863-870.

[21] A. Chambolle and T. Pock, "A First-Order Primal-Dual Algorithm for Convex Problems with Applications to Imaging," Journal of Mathematical Imaging and Vision, vol. 40, pp. 120-145, 2011.

[31] R. C. Gonzalez and R. E. Woods, Digital Image Processing. Second Edition.: Addison-Wesley Longman Publishing Co., Inc., 2001.

[41] Ajax Tutorial, http://www.tutorialspoint.com/ajax/.

Anexa 1 (dacă este necesar)

…

Secțiuni relevante din cod

…

Alte informații relevante (demonstrații etc.)

…

Lucrări publicate (dacă există)

etc.