Partea II – Proiectarea Sistemului Informatic

1. Proiectarea Logică

Precum majoritatea aplicațiilor existente, acest sistem apelează la modelarea logică a datelor,
ceea ce presupune următorii pași: intrarea de date, prelucrarea de date și ieșirea de date. Pentru a
evidenția modul în care datele suferă schimbări voi utiliza diagrama de flux de date. Aceasta va
evidenția modul în care circulă datele, structura acestora și cerințele funcționale ale sistemului.
Aceste diagrame se regăsesc și sub denumirea de modele ale proceselor de prelucrare.

Figura 1 Diagrama Flux de Date

 După cum se poate observa în diagrama prezentată mai sus, prin care se reprezintă grafic
circuitul datelor în acest sistem informatic și modul în care acestea sunt procesate, operațiile sunt
strâns legate de tipul de utilizator. În această diagramă, utilizatorul final este reprezentat generic,
iar operațiile sunt prezentate în fincție de rolul acestuia, conform culorilor specifice, explicate în
cadrul legendei . În general, fiecare proces primește o serie de date, pe care fie le prelucreză și le
trimite mai departe, fie le stochează în baza de date, sau ambele. Această diagramă este o
diagramă de flow specifică nivelului întâi.

Fiecare utilizator trebuie să fie autentificat în cadrul aplicației pentru a reuși să realizeze
aumite acțiuni, iar pentru acest proces este necesară introducera unor date de logare, mai specific
intrducerea email-ului și a parolei, urmând ca acestea să fie verificate. Datele de intrate sunt
comparate cu cele existente în tabelul Utilizatori din baza de date, iar dacă acestea corespund
unei înregistrări din tabel sunt considerate valide, sunt trimise mai departe și se afișează meniul
principal. În caz contrar, se reafișează pagina de autentificare, aici formându-se o buclă. Până în
acest moment circuitul este același pentru fiecare tip de utilizator, dar meniul principal diferă.

În diagrama de mai sus am folosit culoarea mov pentru acțiunile pacienților, flow-ul acesta
fiind specific doar pacienților. Din meniul principal se trimite mai departe opțiunea aleasă, care
va declanșa diferite procese. Primul proces specific pacienților este realizarea programării, care
trimite mai departe datele introduse de către pacient, urmând ca acestea să fie stocate în tabelul
Programări. Pentru afișarea istoricului medical sunt trimise datele utilizatorului curent către baza
de date, și anime email-ul, care este unic, iar datele medicale sunt trimise către utilizator.

În cazul administratorilor am ales să reprezint două dintre funcționalitățile existente, și

anume: modificarea serviciilor și adăugarea utilizatorilor. Modificarea serviciilor trimite și
stochează în tabelul Servicii datele introduse de catre administrator. Se observă că relația are
două sensuri, ceea ce înseamnă că datele noi sunt returnate înapoi procesului. Adăugarea
utilizatorilor este un proces similar, care creează o nouă instanță în baza de date, în tabelul
utilizatori, folosindu-se de datele introduse de către administrator. Precum în cazul anterior, și
această relație are două sensuri.

În cazul doctorilor, dacă aceștia doresc să vizualizeze programările existente, vor introduce o
dată pentru care se dorește afișarea, iar utilizatorul, în cazul de față doctorul, va primi datele
programării și ale pacienților programați. Pentru a introduce un tratament în istoricul medical al
pacientului, dorctorul introduce datele medicale, și anume: CNP pacient, diagnostic,
medicamentație, observații medicale, dacă este cazul, data începerii tratamentului și data
finalizării tratamentului. Aceste date medicale sunt trimise tabelului Istoric Medical, unde sunt
stocate.

Observație: în această diagramă nu sunt reprezentate toate procesele și funcționalitățile pe

care acest sistem le oferă, alegându-le pe cele mai reprezentative.
 În paragrefele de mai sus am descris modul în care datele sunt prelucrate de către principalele
procese ale acestei aplicații, urmând ca în cele ce urmează să descriu structura acesteia și baza
informațională pe care am folosit-o.

1.1 Arhitectura sistemului

Acest sistem este dezvoltat pe baza arhitecturii client-server. Această arghitectură, după cum
și numele său sugerează, implică doua entități diferite, și anume: clientul, care e responsabil de
trimiterea cererilor, și serverul, care este responsabil cu trimiterea răspunsurilor. În cazul acestei
aplicații, serverul referă baza de date, iar clientul este reprezentat de către utilizatorii finali ai
aplicației, și anume: pacienții, doctorii și administratorii. Cererile trimise de către un client spre
server pot să fie multiple, iar serverele pot să răspundă mai multor clienți. Ambele componente
ale acestei arhitecturi colaborează astfel încât sarcinile să fie îndelplinite cu succes.

Figura 2 Arhitectura client-server

În figura de mai sus este reprezentat modul în care funcționează această arhitectură, prin
evidențierea componentelor sale.

Pentru a avea o viziune mai complexă asupra sistemului am realizat diagrama de

componente. Înțelegerea comportamentului exact al serviciilor pe care sistemul le oferă
reprezintă un importan pas în proiectarea tehnică a acestuia. Diagramele de componente pot
descrie sistemele software care sunt implementate în orice limbaj de programare.

În cazul acestei aplicații, prin figura 13 am ilustrat diagrama care îi corespunde.

Observăm că în cadrul acestui sistem există trei mari componente, prin care se gestionează
serviciile în funcție de utilizator. O componentă reprezintă o entitate necesară pentru a executa o
funcție stereotip. O componentă furnizează și consumă comportament prin interfețe, precum și
prin alte componente. Componenta Pacient poate să introducă programări și să vizualizeze
serviciile pe care clinica le oferă și tratamentele care îi sunt specifice. Observăm de asemenea că
între programări și servicii există o legătură, aceasta este o relație de dependință.

Componenta Doctor poate vizualiza programările existente și pacienții și poate să introducă

tratamente. Observă că programările au o relație de dependință față de componenta doctor.
Compoanenta Administrator poate edita servicii, pacienți și doctori. Baza de date este
reprezentată sub forma unei componente, pentru care trebuie să se asigure persistența datelor.

Figura 3 Diagrama de componente

 În ceea ce privește structirarea codului, am folosit ca model pattern-ul MVVM(Model-
View-View Model). Cu ajutorul acesti model, am reușit să îmi stratific aplicația în trei
componente: modelul(model), interfața(view) și modelul interfeței(view-model), fiecare
ocupându-se de partea pe care o decriu.

Figura 4 Modelul arhitectural Model-View-ViewModel

MVVM ne ghidează cum să distribuim responsabilitățile între clase într-o aplicație GUI
(sau între niveluri), cu scopul de a avea un număr mic de clase, păstrând în același timp numărul
de responsabilități pe clasă mic și bine definit. MVVM „corect” presupune cel puțin o aplicație
care să aibă un nivel de complexitate cel puțin moderat, iar aceata să se ocupe de datele pe care
le obține de la o anumită sursă. Această sursă poate fi reprezentată de către o bază de date, un
fișier, un serviciu web sau dintr-o multitudine de alte surse.

În cele ce urmeză voi trata fiecare componentă a acestei arhitecturi, specificând de

asemenea modul în care aceata este introdusă în acest sistem.

Modelul reprezintă datele sau informațiile cu care se lucrează. Cea mai importantă
caracteristică a modelelor este fapul că acestea nu realizează comportamente sau servicii de
manipulare a informației, ci doar o rețin. Aceste modele sunt clase. Logica sistemului este de
obicei ținută separat față de model și încapsulată în alte clase care acționează asupra modelului.
Acest lucru nu este întotdeauna adevărat: de exemplu, unele modele pot conține validare.

În cazul acestei aplicații, modelele au fost generate automat de către framework-ul

EntityFramework(vezi Entity Framework-tehnologii folosite), folosind tehnica DatabaseFirst.
Astfel, acest framework a generat, conform bazei de date existente, următoarele modele, care
sunt defapt clase:
 În figura reprezentată mai sus se poate observa că fiecare model este o clasă, care are ca
și proprietăți atributele tabelului pe care îl reprezintă, luate din baza de date. Spre exemplu, în
această figură modelul este clasa User.cs, care are proprietățile: idUser, nameUser, CNP, ș.a.m.d.
Acest subiect va fi dezvoltat și în partea de „Tehnologii specifice”, în care voi descrie modul în
care funcționează EntityFramework.

Interfața este modul prin care utilizatorul final interacționează cu sistemul informatic, și
este responsabilă de prezentarea datelor. Este important ca interfața să fie una prietenoasă, ușor
de înțeles, deoarece aceata influențează considerabil experiența utilizatorilor. Interfața
gestionează intrarea datelor de la utilizator, date precum: apăsări de taste, mișcări ale mouse-ului,
gesturi tactile și așa mai departe, care în final manipulează proprietățile modelului. În acest
pattern interfața este una activă, ceea ce presupune că aceasta are cunoștințe despre modele,
conține comportamente și legaturi de date, numite data-binding, necesitând astfel cunoașterea
modelului și a view-modelului. Proprietățile, comenzile și apelarea metodelor reprezintă metode
prin care se pot mapa aceste comportamente.

În mod normal, în aplicațiile de tip WPF care nu sunt structurate conform modelului
MVVM în clasa de code-behind sunt scrise evenimentele asociate controalelor. Pentru separarea
codului, în acest pattern se folosesc în special data-binding-ul și comenzile, pentru a înlocui
evenimentele. Pentru a putea folosi data-binding-ul avem nevoie de un context pentru această
interfață, context care este setat în constructorul interfeței și care este chiar view-modelul
specific acesteia. Mai jos este evidențiată interfața pentru autentificare din doua perspecive: ceea
ce vede utilizatorul final și modul în care aceasta este construită.

View-model-ul este o piesă cheie a triadei, deoarece este nucleul prin care se introduce
separarea modelului de interfață. În loc să conștientizeze modelul cu privire la vizualizarea unei
date, astfel încât acesta să transforme data în formatul de afișare, modelul pur și simplu conține
datele, interfața păstrează data formatată, iar viewmodel-ul acționează ca legătura dintre cei doi.

Viewmodel-ul primește datele de la interfață, le procesează și le trimite mai departe

modelului, sau ia modelul și îl trimite spre interfață. Observăm că relația are două sensuri, în
funcție de necesitate. Acesta componentă expune, de asemenea, metode, comenzi și alte puncte
care ajută la menținerea interfeței, la manipularea modelului ca rezultat al acțiunilor din interfață
și la declanșarea evenimentelor.Cea mai importantă caracteristică a acestei componente este că
ea realizează toate funcționalitățile aplicației și, precum am menționat mai sus, deservește ca
DataContext pentru interfață.
 Pentru a ilustra cât mai bine modul în care aceste trei componente coexistă în acest
sistem, vom lua ca exemplu fereastra de autentificare, împreună cu modelele folosite pentru
aceasta și view-modelul care îi deservește ca și DataContext. Voi evidenția modul în care fiecare
componentă respectă caracteristicile menționate anterior și voi arăta cum funcționează întreg
procesul.

În prima figură este fereastra de autentificare pe care o vede utilizatorul atunci când
deschide aplicația. În cea de-a doua figură este ilustrat modul în care se construiește această
fereastră. Observăm că în constructor este setat DataContextul de unde se vor prelua datele, și
anume viewModel-ului care îi este specific. Utilizatorul trebuie să introducă date pentru a se
autentifica, și anume email-ul și parola. După cum putem observa există două butoane, cel de
autentificare și cel pentru înregistrare. Utilizatorul introduce datele și apasă pe butonul de logare.
Aici se declanșează comandă, care, cu ajutorul proprietăților, preia datele de la utilizator, și prin
intermediul modelului verifică dacă acestea corespund cu cele din baza de date. În cazul de față
modelul utilizat este de tip User.

Din exemplu de mai sus se poate observa că obiectivul principal, aceala de a oferi o
separare clară între logică și prezentare este îndeplinit, iar problemele cauzate de plasarea logicii
aplicației în cod-behind sau XAML sunt evitate.

Bineînțeles, ca oricare altă abordare arhitecturală, acest model are avantaje și

dezavantaje, și nu este folositor pentru toate tipurile de aplicații. În cazul acestei aplicații, prin
acest model se realizază o structurare a codului, care are o serie de avantaje. Fiind un sistem de
dimensiune medie, implementarea acestui pattern m-a ajutat să-l dezvolt astfel încât să fie ușor
mentanabil, testabil și exting. O separare corectă a diferitelor tipuri de cod ar trebui să faciliteze
accesul la una sau mai multe dintre părțile mai granulare și să facă posibilă implementarea unor
schimbări fără a-mi face griji sumplimentare. Deși rezolvă multe dintre probleme, acest pattern
are și o serie de dezavantaje, care pot să constituie piedici în implementare. În cazul unor sistem
de complexitate foarte ridicată poate fi foarte dificil sa creezi un view-model care să satisfacă
toate nevoile. De asemene, tot în cazul aplicațiilor complexe, care necesită binding-uri complexe
de date, debugging-ul poate fie dificil, ceea ce constituie o problemă. Cu toate acestea, eu
consider că, în ceea ce privește acestui sistem, acest pattern este unul potivit, care satisface
nevoile arhitecturale.
4.2 Baza Informaţională
Una dintre principalele componente ale unui sistem informatic este reprezentată de către
baza informațională. Prin aceasta ne referim la datele care sunt supuse prelucrării, fluxurile
informaționale și sitemele și nomenclatoarele de coduri. Baza informațională cuprinde toate
datele necesare pentru ca sistemul să reușească să îndeplinească cu succes obiectivele care stau
la baza acestuia.

Având în vedere faptul că acest sistem este unul destinat unei clinici medicale, trebuie să
identificăm principalele date de care avem nevoie astfel încât să fie corespunzătoare și să
îndeplinească nevoile acestui tip de instituție. După cum am menționat în capitolul anterior(1.2.1
Fațeta Subiect), stakeholderii acestui sistem sunt reprezentați de cele trei entități de bază, cărora
li se adresează, și anume: doctori, pacienți și administrator. Fiecare dintre aceștia are propriile
interese în ceea ce 3privește aplicația, interese care trebuie considerate și transformate într-un
mod logic, astfel încât să poată fi transpuse în acest sistem. Interesele stakeholderilor au fost
transformate în cerințe de sistem(capitolul 2.3.1 Cerințe funcționale), acestea fiind principala
sursă de unde putem să aflăm datele de care avem nevoie.

Această aplicație se adresează mai multor tipuri de utilizatori, ceea ce înseamnă că este
necesar să avem date despre aceștia, în special pentru a fi posibilă autentificarea în cadrul
sistemului. Fiecare utilizator va trebui să introducă o adresă de email și o parolă, acestea fiind
datele necesare procesului de logare, iar mai apoi fiecare dintre aceștia vor introduce alte date cu
caracter personal pentru a face gestionarea sistemului mai ușoară. Observăm astfel că avem
nevoie de datele specifice utilizatorilor. Mai apoi, fiecare dintre aceștia trebuie să poată realiza
acțiunile care îi sunt specifice. Administratorul trebuie să aibă posibilitatea de a modifica lista cu
serivicii, deci, din această cerință reiese nevoia existenței datelor legate de servicii. Nu doar
administratorul are nevoie de aceste date, ci și pacientul, care trebuie să le poată vizualiza.
Pacientul trebuie să poată să aibă acces la istoricul său medical. Istoricul medical cuprinde mai
mullte date, care sunt cumulate pentru o afișare corespunzătoare. Aceste date sunt legate de:
medicamentație, observații medicale, perioada specifică tratamentului și numele doctorului care
a introdus acest tratament. Medicul trebuie să poată vizualiza programările, astel avem nevoie de
date specifice programarilor, acestea fiind furnizate de către paienți.

Considerând cele menționate anterior, putem concluziona faptul că atât datele, cât și
procesarea acestora reprezintă componente de bază în cadrul sistemului informatic, componente
fără de care acesta nu ar putea funcționa. Aceste date trebuie stocate coresunzător, astfel încât
cerințele funcționale să poată fi realizabile. Fiecare dintre datele necesare trebuie să fie
transormată în unitate logică, pentru a fi posibilă accesarea și procesarea sa în cadrul sistemului.
Pentru a reuși să realizez această procesare logică, am creat o bază de date, care să cuprindă toate
informațiile necesare unei funcționări corespunzătoare. Această bază de date va fi descrisă în
capitolul următor, fiind specificată fiecare entitate, nevoia existenței acesteia, relațiile acesteia și
modul în care este datele care îi sunt alăturate sunt prelucrate în cadrul aplicației.
5. Proiectarea Tehnică
5.1 Structura fizică a datelor
După cum am menționat în capitolul anterior, pentru stocarea datelor am creat o bază de
date relațională. Aceasta reprezintă o colecție organizată de date structurate astfel încât să fie
ușor accesibile, ușor de gestionat și de actualizat. Proiectarea acesteia s-a realizat ținând cont de
nevoile stakeholderilor și de datele care trebuie să fie introduse în sistem. După cum am
menționat în capitolul Fațeta Subiect, unde am vorbit despre principalele entități cărora li se
adresează acest sistem, acestea sunt în număr de trei, mai specific: pacienți, administrator și
doctori.

Proiectarea bazei de date a reprezentat un important pas în ceea ce privește dezvoltarea

sistemului, deoarece aceasta trebuie să respecte un set de principii pentru a putea fi considerată
corectă și ușor de dezvoltat în cazul în care aplicația va suferi modificări pe parcursul duratei sale
de viață. În ceea ce privește organizarea în cadrul bazei de date, informațiile sunt stocate in
tabele. Fiecare tabel conține un set de rânduri, care se numesc înregistrări, și un set de coloane,
care se numesc atribute.

Proiectarea corectă a bazei de date constă într-o serie de pași. Aceștia sunt:

 Scopul bazei de date să fie bine definit. În cazul acestui sistem scopul este de a
organiza datele din cadrul clinicii medicale astfel încât să fie ușor accesibile.
 Baza informațională trebuie să fie în concordanță cu scopul bazei de date. În cazul
de față, baza informațională, descrisă la capitolul anterior, reprezintă toate datele
care descriu nevoile stakeholderilor.
 Informațiile din baza informațională trebuie să fie organizate în tabele. Aici se
creează principalele entități, denumite și subiecte majore.
 Alegerea cheilor primare pentru fiecare dintre tabelele create, cu ajutorul cărora se
identifică în mod unic rândurile din fiecare tabel.
 Crearea de relații între tabele, prin corelarea datelor dintr-un tabel cu altele dintr-
un tabel diferit.
 Normalizarea bazei de date.

După ce am stabilit scopul bazei de date și baza informațională, am realizat tabelele. Acestea
reprezintă principalele entități care caracterizează sistemul. Baza de date specifică acestei
aplicații a fost creată folosind SQL Server, fiind o bază de date relațională. Legăturile dintre
tabele se realizează prin intermediul constrângerilor referențiale. Acestea sunt denumite și chei
străine. Pe lângă cheile străine, fiecare tabel include un câmp care identifică în mod unic fiecare
înregistrare. Mai jos este ilustrată diagrama bazei de date, prin care am reușit să transpun într-un
mod logic entitățile necesare pentru ca aplicația să îndeplinească obiectivele stabilite.
 În cele ce umează, voi descrie fiecare tabelă specificând rolul acesteia și relațiilepe care
aceasta le are în cadrul bazei de date.

1. Tabela Role

Aceasta reprezintă tipul de utilizator. În acest tabel există doar trei înregistrări și doar
două câmpuri. Fiecare user înregistrat în cadrul aplicației va avea un rol, acest lucru se creează
prin asocierea unei chei străine, astfel se creează o relație între tabelul User și tabelul Role.
Cardinalitatea acestei relații este de 1:N, adică unui rol îi corespund mai mulți utilizatori, iar unui
utilizator îi corespunde un singur rol.

2. Tabela User

În această tabelă se stochează datele caracteristice fiecărui utilizator, și anume: nume,

prenume, CNP, email, parolă telefon, rol și userID. Cheia primară, după cum îi spune și numele,
este userID, care se incrementează automat la adăugarea unui nou utilizator. Deoarece am decis
ca emailul să fie unul din câmpurile necesare procesului de autentificare, acesta are
constrângerea de a fi unic.

3. Tabela Doctor

Aceasta reprezintă utilizatorii care sunt doctori. Acest tabel este necesar deoarece
doctorul, spre deosebire de un utilizator obișnuit, are o specializare. Cheia primară a acestui tabel
este câmpul idDoctor, iar datele personale despre acesta vor fi stocate în tabela User pentru a
evita redundanța. Între tabela doctor și utilizator este o relație opțională de 1:1, adică unui
utilizator poate să îi corespundă un doctor. Observăm că unul din câmpurile specifice acestei
tabele este idSpecialization, o cheie străină prin care unui doctor i se atribuie o specializare.
 4. Tabela Specialization

Prin acest tabel sunt reprezentate specializările pe care un doctor poate să le aibă. În
cadrul acestui sistem un doctor poate să aibă o singură specializare. Aceasta are ca și cheie
primară câmpul idSpecialization, care se incrementează automat la adăugarea unei noi
înregistrări. Pentru fiecare specializare există un set de servicii care pot să fie prestate. Relația
are următorul sens: doctorul are o specializare în funcție de care poate să presteze mai multe
servicii. Fiecare serviciu are un nume și un cost un identidicator. Cheia străină idSpecialization
atribuie unui serviciu specializarea corespunzătoare.

5. Tabela Appoiments

Pacientul, una dintre entitățile principale specifice acestei aplicații, este reprezentat de
către tabela User. Acesta trebuie să poată realiza programări, astfel observăm că în baza de date a
acestui sistem există tabelul Appoiments. În acest tabel va fi stocată fiecare programare. O
programare este caracterizată de: un doctor, un pacient, o oră de start și un serviciu. Toate aceste
elemente reprezintă câmpuri în cadrul acestei tabele. Un pacient poate să aibă mai multe
programări, iar unui doctor pot să îi fie asociate mai multe programări. Aici există relații de tipul
1:N.

6. Tabela Week

Doctorul, o altă entitate reprezentativă, poate să aibă un program specific, care să difere
în funcție de zi. Pentru ca acest lucru să fie posibil, în această bază de date există tabela Week și
Schedule. Tabela week are un nume sugestiv, deoarece aceasta cuprinde zilele din timpul
săptămânii. A fost necesară pentru a evita redundanța datelor. Această tabelă cuprinde cele șapte
zile ale săptămânii, alături de un număr care deservește ca și cheie primară. Aceasta se
incrementează automat.

7. Tabela Schedule

Aceasta este reprezentarea logică a orarului unui anumit doctor.Un orar este împărțit pe
zile, iar în fiecare zi doctorul are o oră la care își începe activitatea și o oră la care își încheie
activitate. Cheia străină idDay face legatura cu tabela Week, fiind o relație 1:N, adică unei zile îi
corespunde mai multe orare. Câmpul idDoctor atribuie orarul unui doctor. De asemenea, această
relație este de tipul 1:N.

8. Tabela Diagnosi

Această tabelă este reprezentarea logică a diagnosticelor. Luând în considerare faptul că

mai multor pacienți pot să li se atribuie același diagnostic, sau un pacient poate să aibă același
diagnostic de mai multe ori, am creat această tabelă pentru a evita redundanța. Această tabelă are
în componență două atribute: idDiagnosis, acesta fiind cheia primară, și nameDiagnosis, care
reprezintă numele diagnosticului.

9. Tabela Medicine

Acest tabel reprezintă medocamentele pe care un doctor le introduce în cadrul unui tratament.
Realizarea acestei tabele are la bază același considerent precum tabela Disgnosi, având aceeași
structură: cheia primară și numele medicamentului prescris.

10. Tabela Treatment

În cadrul acestui sistem doctorii pot să adauge tratamente pentru pacienți. Implementarea
acestei funcționalități impune crearea mai multor tabele, întrucât este necesară maparea unei
relații de tipul M:M(many-to-many). Unui tratament îi corespunde un diagnostic, iar unui
tratament îi pot corespunde mai multe medicamente. Observăm cea din urmă este o relație M:M,
de aceea este necesare crearea unui tabel intermediar, prin care această relație să poată fi
gestionată corespunzător. Acest concept se numește joining table sau bridging table. Scopul
tabelului intermediar este săstocheze o înregistrare pentru fiecare dintre combinațiile celorlalte
două tabele. În cazul de față, tabela intermediară este tabela Prescription, unde stocăm pentru
fiecare tratament în parte medicamentația corespunzătoare.

5.2 Procese
În acest capitol voi prezenta principalele procese care se desfășoară în cadrul aplicației,
cui sunt destinate, ce interfețe utilizează, care sunt modelele necesare și care este clasa sau
clasele care se ocupă de implementarea logicii de business a fiecăruia dintre acestea. Cu alte
cuvinte voi explica modul în care s-au implementat funcționalitățile astfel încât să fie conforme
cu pricipiile arhitecturii MVVM.

P1 Autentificarea

După cum am mai menționat și în capitolele anterioare, fiecare utilizator trebuie să se

autentifice în cadrul acestui sistem. Pentru a fi posibil acest lucru, a fost necesară existența unei
interfețe prin care utilizatorul să introducă datele de logare. Aceste date de logare sunt email-ul,
care este un câmp cu valori unice din tabela User și parola. Datele introduse de utilizator sunt
preluate de proprietățile Email și Password din clasa AuthenticationViewModel, care deservește
ca și DataContext pentru interfața de autentificare. Prin comanda LoginCommand se iau datele
de la proprietățile publice Email și Password și se verifică dacă acestea corespund una dintre
înregistrările din baza de date. Dacă acestea nu corespund cu nicio înregistrare, se trimite un
mesaj de eroare și nu se schimbă interfața. În caz contrar, se verifică rolul urilizatorului, se
pornește un Thread pentru utilizatorul curent și se afișează interfața principală specifică tipului
de utilizator căruia îi corespunde.

Modelele utilizate sunt clasa User și clasa Role. Clasa Role este utilizată pentru acordarea
de drepturi și pentru a afișa interfețele corespunzătoare.

P2 Înregistrarea

Acest proces se adresează doar pacienților, și constă în crearea unui cont nou pentru un
pacient care nu are deja un cont. Prima interacțiune a utilizatorului cu aplicația este fereastra de
autentificare descrisă anterior. Dacă utilizatorul dorește să își creeze un cont, acesta va apăsa
butonul de register care, care va desclanșa comanda ShowRegisterViewCommand. Această
comandă va închide fereastra de autentificare și o va afișează pe cea de înregistrare.

P3 Gestionarea Serviciilor

*
 Fiecărui buton afișat în interfața de mai sus îi corespunde o comandă care gestionează
prelucrarea datelor. În ceea ce privește pacienții aceștia vor putea doar să vizualizeze lista cu
servicii, fără a avea posibiliateta de a o modifica. În interiorul interfeței se poate observa
prezența unui tabel, care este un controler, numit DataGrid. În mod normal acest controler ia date
dintr-un tabel și le afișează într-un mod organizat. În cazul de față, pentru a evita redundanța în
tabela Services avem doar id-ul specializării, nu și numele acesteia. Din aceată cauză am creat o
nouă clasă, numită DataGridViewModel prin care am creat o colecție observabilă în care să
existe și numele specializării. Această clasă are metoda FillDataGrid care creează o colecție
observabilă de tipul DataGridViewModel, unde vor fi stocate toate datele pe care dorim să le
afișăm, inclusiv numele specializării fiecărui serviciu. În clasa ServicesViewModel există
metoda FillServices prin care se returnează colecția observabilă de tipul DataGridViewModel
creată anterior. Aceată colecție reprezintă sursa de date pentru tabelul din interfața ilustrată mai
sus. Am decis să explic acest proces deoarece este implementat pentru mai multe funcționalități
din cadrul sistemului.

5.3 Tehnologii specifice

5.3.1 Visual Studio 2019

…………………..

5.3.2 WPF- Windows Presentation Foundation

……………………..

XAML și code-behind

5.3.2 Limbajul C#
……………………

5.3.3 Entity Framework

……………………………..