Sef lucr. Ing. Muji Marius Meruțiu Vlad -Ionuț [621835]

UNIVERSITATEA “PETRU MAIOR” DIN TÂRGU -MUREȘ
FACULTATEA DE INGINERIE
SPECIALIZAREA: CALCULATOARE

LUCRARE DE DIPLOMĂ

SISTEM INFORMATIC PENTRU GESTIUNEA UNUI DEPOZIT
DE PRODUSE FARMACEUTICE

Coordonator: Student: [anonimizat]

2014

UNIVERSITATEA "PETRU MAIOR" TG . MUREȘ LUCRARE DE LICENȚĂ
FACULTATEA DE INGINERIE Viza facultății
Specializarea: CALCULATOARE

SISTEM INFORMATIC PENTRU G ESTIUNEA UNUI DEPOZIT
DE PRODUSE FARMACEUTICE

Conducătorul temei : Șef. Lucr. Dr. Ing. Marius Muji Candidat: [anonimizat]: 2014

a)Tema lucrării de licență:

Sistem Informatic Pentru Gestiunea Unui Depozit De Produse Farmaceutice

b)Problemele principale tratate:

– Sistemele informatice
– Analiza sistemului in formatic
– Proiectarea sistemului informatic
– Proiectarea bazei de date
– Implementarea sistemului informatic

c)Bibliografie recomandată:

– Ileana Ștefan – Analiza ș i proiec tarea sistemelor informatice, Tîrgu -Mureș ,2007
– Dorin Lixandroiu, Radu Lixandroiu – Baze de date relaționale, Braș ov 2009
– Stanciu V. – Proiectarea sistemelor informatice de gestiune, Ed. Ci son, Bucureș ti 2000
– C.J. Date, Baze de Date, Ed. Plus, Bucureș ti, 2002

Termene obligatorii de consultații: săptămânal

Locul pract icii: laboratoarele din cadrul facultății
Primit tema la data de: 01.04.2013
Termen de predare: 20.06.2014
Semnătura șefului de departament Semnătura conducă torului

Semnă tura candidat: [anonimizat] 1
1.1. Motivația și importanța lucrării ………………………….. ………………………….. ……………….. 1
1.2. Structura Lucrării ………………………….. ………………………….. ………………………….. ……… 4
1.3. Sistem informatic. Sistem informațional . Noțiuni generale ………………………….. ……… 5
1.3.1. Conceptul de sistem ………………………………………………………………………………… 6
1.3.2. Componentele sistemelor informatice ……………………………………………………… 10
CAPITOLUL II. Cerințele și analiza sistemului informațional ………………………….. …….. 11
2.1. Specificarea cerințelor ………………………….. ………………………….. ………………………….. …. 11
2.2. Analiza sistemului informatic ………………………….. ………………………….. …………………… 12
2.2.1. Analiza bazei de date relaționale. Modelul entitate -relație ………………………….. ….. 13
2.2.2. Analiza aplica ției software. Diagrama Procesului de Afaceri ………………………….. . 18
CAPITOLUL III. Proiectarea sistemului informatic ………………………….. ……………………. 23
3.1 Proiectarea bazei de date relaționale ………………………….. ………………………….. …………… 24
3.2 Proiectarea aplicației software a sistemului informatic ………………………….. ………………. 27
CAPITOLUL IV. Implementarea sistemului informatic ………………………….. ……………….. 44
4.1. Implementarea bazei de date ………………………….. ………………………….. …………………….. 44
4.2. Implementarea aplicației software a sistemului informatic ………………………….. ………… 47
4.3. Concluzii ………………………….. ………………………….. ………………………….. …………………… 51
BIBLIOGRAFIE ………………………….. ………………………….. ………………………….. ………………… 52

1 CAPITOLUL I. INTRODUCERE

1.1. Motivația și importanța lucrării
Prezenta lucrare de diplomă, tratează și descrie un sistem informatic pentru
gestiunea unui depozit de produse farmaceutice, de nouă generație, depozit care va stoca
și distribui mai departe prod usele preluate în principal de la furnizorul
,,FARMAEXPERT DCI SRL”, dar și de la alte firme naționale sau internaționale, de
exemplu ,,BAYER HEALTH CARE GERMANIA ”.
Am ales această temă pentru lucrarea de diplomă, deoarece în ultimii ani, am
observat o ev oluție și o dezvoltare tot mai mare a domeniului farmaceutic. Având în
atenție statisticile economice legate de profitul obținut din producție și vânzări, domeniul
farmaceutic, este unul dintre puținele domenii care a reușit să înregistreze un trend
ascend ent, chiar și pe fond de criză economică și să mențină o creștere constantă.
,,FARMAEXPERT” , este unul din cei mai importanți distribuitori de produse
farmaceutice și parafarmaceutice din România, oferind o gamă complexă de produse și
servicii, lucrând în parteneriat cu 170 producători și peste 4.400 de farmacii, spitale,
instituții și medici.
Cu o acoperire la nivel național, prin intermediul a 6 sucursale din marile orașe
ale țării (Iași, Brașov, Ploiești, Cluj, Timișoara, București -Sud), ,,Farmexpert”, oferă
clienților săi, un portofoliu de aproximativ 7.000 de produse de import și indigene,
permanente și sezoniere.
Distribuția la clientul final, se realizează la nivel național (~ 10 milioane km
parcurși anual pe întreaga rețea de drumuri) prin intermedi ul propriului parc auto ( ~ 170
de autovehicule ), special configurat astfel încat să păstreze calitatea medicamentelor,
produselor parafarmaceutice și dispozitivelor medicale pe tot parcursul lanțului de
distribuție până la consumatorul final.

2 Crearea dep ozitului în zona apropiată a municipiului Targu -Mureș, permite
accesul tuturor farmaciilor din județ, clinicilor private, Spitalului Clinic Județean,
instituțiilor publice sau private și medicilor, la produse de înaltă calitate, medicamente de
ultimă gene rație, aparaturi și instrumente de diagnostic, vaccinuri, proteze etc. Beneficiul
este enorm, deoarece reduce semnificativ costul de transport de la furnizor la client.
Mai jos, atașez o imagine [1] cu evoluția pieței farmaceutice, conform datelor
Compani ei de analiză și studii de piață ,,CEGEDIM România”, preluată de la Ziarul
Financiar.

Fig [1] Evoluția pieței farmaceutice
Pentru a rezista unei economii în continu ă schimbare, cu fluctua ții rapide și care
să ofere o palet ă largă de produse care s ă satisfac ă diferite nevoi, pl ăceri și dorin țe,
vechile strategii de marketing nu mai reu șesc s ă îndeplineasc ă eficient cerin țele pieței .
Exist ă tot mai mu lți clien ți, tot mai multe nevoi și tot mai multe cereri. Totul se

3 întâmplă cu rapiditate, informa ția es te din ce în ce mai mult ă și greu de gestionat
utiliz ând vechile metode.
Ca urmare a dezvolt ării tehnologice din ultimii ani , care reprezintă un pas foarte
important în toate domeniile vie ții, implicit și în pia ța de v ânzări care are rol important
pentru desfășurarea activit ății oricărei companii, se realizeaz ă o migrare spre
informati zarea activit ății intreprinse, utiliz ându-se sisteme informati ce din ce în ce mai
complexe , care simplific ă munca angajaților din acest domeniu .
“Astfel, s-a reu șit rezolvare a multor probleme de natur ă: economic ă,
administrativ ă, social ă, utilizând procesul tehnologic de gestionare în cadrul
organizațiilor, care a evoluat în complexitate cu cât a devenit mai important. La început,
marele scop era să se gestioneze tehnologic un sistem după metodă: pune în funcțiune,
menține în rulare și încearcă să reduci costul afacerii. Dar mai tarziu, direcția principală a
fost de a gestiona resursele informaționale ale organizației, în special , pentru a sprijini
managementul de luare a deciz iilor prin furnizarea de informații, atunci când a fost
nevoie. Astăzi, modificările necesare pentru a sprijini noile tehnologii și structuri
organizatorice, care sunt în prezent în curs de dezvoltare , necesită o cantitate
semnificativă de afaceri bine coo rdona te și conducerea executivă IT. ” [2]
Prin urmare , e nevoie de o bun ă cunoa ștere și înțelegere a sistemelor informati ce
de către managerii de companii, pentru a rezista și prospera pe pia ța de consum, acum
virtualizat ă și informati zată. Toat ă informa ția trebuie colectat ă, înregistrat ă, stocat ă și
procesat ă, cu scopul de a realiza obiectivele organiza ționale propuse, de a calcula
statistici și predic ții, pentru a îmbun ătăți și dezvolta strategii func ționale de v ânzare.
De aceea, gestiunea informațiilor, reprezintă o prioritate și o responsabilitate
importantă, iar dezvoltarea unui sistem informatic care să permită gestiunea corectă a
informației este absolut necesară.
Ca urmare a acestor argumente, consider o provocare interesant ă să îmi dezvolt
lucrarea de diplom ă pe baza unei aplica ții care utilizeaz ă un sistem informatic de gestiune
al unui depozit de produse farmaceutice de ultim ă genera ție.

4 În proiectarea sistemului și pentru optimizarea activit ăților, m -am bazat pe modul
de func ționare al unui depozi t logistic de m ărfuri farmaceutice, util în controlul
aprovizion ării, stocului de marf ă și distribu ției c ătre clien ți, care să cuprindă o arie
teritorială mai mare din Romania.
Sistemul informatic , are o interfa ță de logare , ce permite accesul utilizatoril or în
funcție de pozi ția ierarhic ă ocupat ă în cadrul companiei . Acest lucru este necesar pentru
atribuirea de diferite responsabilit ăți care trebuie îndeplinite de c ătre angaja ți.
Aplica ția a fost realizat ă, utiliz ând cuno ștințele și informa țiile acumulate în
perioada studiilor universitare, în special cele care se refer ă la programare orientat ă pe
obiecte și baze de date. Am utilizat Microsoft SQL Server , pentru a crea baza de date a
sistemului informatic, cu ajutorul limbajului universal SQL și limbajul d e programare C#
pentru aplicatia propriu -zisă.
Pentru o mai bun ă înțelegere , am inclus î n acest document : cerin țele, tehnicile de
analiz ă, proiectare și implementare a aplica ției, precum ș i niște diagrame care descriu
detaliat procesele tehnologice și interpretarea datelor.

1.2. Structura Lucrării
Pentru o mai bună parcurgere și întelegere, conform ,, Ghidului pentru
întocmirea lucrării de diplomă ”, am structurat c onținutul lucr ării în 4 capitole, fiecare
capitol fiind împărțit în subcapitole.
Astfel, am denumit primul capitol, „ Introducere ”, pe care l -am dedicat descrierii
motivației și importanței lucrării, descrierii succinte a structurii lucrării, precum și
prezentării unor noțiuni generale necesare familiarizării cu un sistem informatic și
informațion al.
In cadrul celui de al doilea capitol, intitulat „ Analiza și Cerințele Sistemului
Informațional ”, am specificat cerințele pe care trebuie să le respecte sistemul și am
prezentat analiza sistemului informatic, unde am inclus diagramele necesare dezvoltăr ii
acestuia: Diagrama Entitate -Relație (ERD) și Diagrama Procesului de Afacere (BPMN) .
Cel de al treilea capitol, intitulat „ Proiectarea Sistemului Informatic ” cuprinde
pașii de proiectare a sistemului informațional: proiectarea bazei de date relaționale și

5 proiectarea aplicației software. De asemenea, sunt prezentate diagramele folosite pentru
dezvoltarea acestuia.
Al patrulea capitol , intitulat „ Implementarea Sistemului Informatic ” cuprinde
implementarea bazei de date , implemen tarea aplicației software și formularea
concluziilor.
In finalul documentului, se află Bibliografia , care face trimitere la cărțile și
materialele cu conținut informativ din care m -am inspirat.

1.3. Sistem Informatic. Sistem Informațional. Noțiuni Generale

Este important s ă facem distinc ție între no țiunea de Sistem Informatic și cea de
Sistem Informa țional. Deoarece un Sistem Informa țional are drept componente principale
date și informa ții, e important de asemenea s ă înțelegem ce sunt acestea.
,,Datele privesc evenimente primare, colectate pentru informare sau rezolvarea
unor probleme sau situații.” [3] Ele pot lua forma unor inșiruiri de caractere numerice sau
alfanumerice, care pot avea o anumită semnificație. De exemplu, datele economice
descriu: acțiuni, fenomene, fapte, proces e care fac referire la procesele unei companii.
Informațiile sunt mesaje obținute prin prelucrarea datelor, calcule, sortări,
clasificări care capătă un sens și îndeplinesc un scop. Este necesar un proces care este
utilizat să producă informații și care p resupune colectarea de date, trecerea lor prin niște
transformări cu scopul de a obține informații corecte și coerente. Deși informația este o
resursă importantă necesară indivizilor și organizațiilor, nu toată informația poate fi
considerată utilă.[4]
Diferențele principale dintre date și informații , sunt:
 datele, reprezintă acele atribute primare colectate din locuri diverse,
neorganizate sau nedefinite sub o formă, pe baza careia să se ia u deciziile;
 informațiile , sunt acele mesaje: concise, complet e, actuale și clare, ce se obțin
după ce se prelucreaz ă datel e, în așa manieră încât să răspundă cerințelor
informaționale în scopul cărora au fost prelucrate datele.
Mai jos, se află o diagramă ce descrie fluxul prelucrării datelor.

6

Figura 1.2. Fluxul prelucr ării datelor

1.3.1 . Conceptul de sistem

Este considerat sistem, un grup de componente și elemente interconectate între
ele, care cooperează printr -o interacțiune dinamică cu scopul de a atinge un obiectiv
comun, susținerea unui organism economic, de exemplu.
Conceptul de sistem, se referă la tehnologiile de management a informației
necesare desfășurării unui business, cu rol în asigurarea calitătii, valorii și bunei
funcționări a acestuia. De asemenea, se referă și la utilizarea computerelor din o rice
domeniu dependent de economie, precum și la rețelele de calculatoare considerate
elemente componente ale unui sistem de prelucrare informații.

Sistem Informațional
Orice domeniu de activitate economică sau socială, se bazează pe un flux
informaționa l. Orice organizație, fie ea o instituție, o companie, o societate comercială,
un minister al unei țări, este imparțită și ierarhizată, respectând trei componente prin care
circulă acel flux:
 Sistemul de decizie, management sau conducere;
 Sistemul informat ic;
 Sistemul operational.

7

Figura 1.3. Structura Sistemului Informațional

Un sistem informațional, reprezintă un ansamblu de componente, proceduri,
tehnici de obținere și difuzare, care au rol în colectarea, transmisia și prelucrarea datelor
obținute d in mediul intern sau extern, cu ajutorul calculatorului, pe baza cărora se obține
un flux de informație cu rol central și prioritar, folosit în cadrul organizației, pe baza
căruia se iau decizii și se optimizează procesul economic. De asemenea, se iau în
considerare și resursele umane implicate în culegerea, transmiterea, stocarea și
prelucrarea datelor, deși odată cu evoluția tehnologică, rolul lor începe să se rezume din
ce în ce mai mult, doar la mentenanța aparatelor, controlul calitătii, optimizare și
îmbunătățirea tehnologiei, securității și funcționării.

Sistem Informatic

Prin urmare, sistemul informațional este un sistem care integrează în
componentele sale, sistemul informatic.

8
Sistemul informatic, este un subsistem tip user – calculator al si stemului
informațional, care utilizează computerul și aplicatiile sofware, proceduri manuale, o
bază de date și modele matematice cu scopul îndeplinirii unor activități de la nivel
operațional și decizional.

Pentru obținerea rezultatelor și îndeplinirea unui scop de către sistemul
informatic, se folosesc două strategii:
 modul ascendent, bazat pe spargerea problemei pe bucăți și în detaliu,
preluarea fiecărui detaliu și rezolvarea acestuia, apoi reconstituirea soluțiilor
până la punctul final în care se ob ține soluția globală. Acest mod este util,
doar când se cunoaște în detaliu arhitectura domeniului în care avem nevoie
de o soluție;
 modul descendent, opus celui de sus, are ca prioritate studierea problemei în
mod global, top -view, din exterior și descomp unerea treptată în bucăți mai
mici, care se rezolvă până la punctul în care se ajunge la rezolvare totală.
Fie că se folosește o metodă ascendentă sau descendentă de rezolvare, vom obține
un arbore al sistemului informatic global, care va conține diferite subsisteme, diferite
aplicații, programe, etc.

Figura 1. 4. Structura unui Sistem Informatic

9
Cu cât o organizație economică este mai complexă, cu atât mai complicat și mai
stufos este sistemul informatic. In schimb, dacă organiza ția are complexitate redusă,
sistemul informatic poate să fie constituit dintr -o singură aplicație informatică.
Componentele sistemului, cum sunt subsistemele și aplicațiile informatice sunt
numite produse software .
Baza de date, programele care o acceseaz ă, documentația necesară utilizării și
întreținerii programelor, constituie un produs informatic și ele se realizează pe baza unor
reguli și etape ce trebuie parcurse, care încep cu specificarea cerințelor și se finalizează
cu implementarea, exploatarea și întreținerea acestora.
Pentru a ne face o imagine despre cum arăta un sistem informatic de tip business
inteligence , atasez o imagine a unui sistem de acest tip. [5]

Figura 1.5. Componentele unui sistem BI (Business Inteligence)

10 1.3.2.Componentele siste melor informatice
In proiectarea unui sistem informatic, arhitectura acestuia trebuie să țină cont de o
serie de elemente, de la echipamente și componente de baz ă, până la produse software si
rețele de comunicare necesare în buna funcționare a sistemului.
Orice sistem informatic are următoarele componente de bază: [6]
 Hardaware -ul (Baza tehnica)
 Software -ul
 Comunicațiile
 Baza informa țional ă
 Baza științifică si metodologică
 Resursele umane
 Cadrul organizatoric

Figura 1.6. Componentele unui sistem i nformatic

11 Capitolul II . Analiza și cerințele unui sistem informatic

2.1. Specificarea cerințelor

O societate comercial ă de tip farmaceutic, dorește s ă informatizeze departamentul
care se ocup ă de stocarea produselor farmaceutice preluate de la furnizo ri, gestiunea
acestora și onorarea comenzilor venite din partea clien ților.
Prin urmare, sistemul informatic , trebuie s ă se ocupe de gestionarea e ficientă a
unei baze de date care con ține comenzile clienților, precum și datele referitoare la stocul
de prod use disponibile.
Scopul îl reprezint ă onorarea comenzilor în timp util precum și optimizarea
procesului, în așa fel încât să se creasc ă vânzările, adopt ând strategii noi pe baza
informa țiilor ob ținute anterior.

Obiectivele și cerin țele principale ale sis temului informatic de gestiune a produselor
farmaceutice :

 Inregistrarea comenzilor noi primite de la clien ți în baza de date, împreun ă
cu datele de identificare și contact ale acestora;
 Inregistrarea furnizorilor noi de produse farmaceutice în baza de dat e;
 Gestiunea în mod eficient a comenzilor înregistrate și a stocului de
produse farmaceutice;
 Efectuarea comenzilor noi pentru produse farmaceutice;
 Adăugarea de noi produse;
 Vizualizarea cata logului de produse farmaceutice.

Clien ții – sunt persoane fizic e și juridice, proprietari de farmacii, clinici private, manageri
de Spitale etc. Pentru ambele categorii , sistemul stochează doar anumite date esen țiale de
contact și identificare : id de client, nume, prenume, adresa și număr de telefon .

12 Produsele farm aceutice – sunt stocate într -un catalog de produse farmaceutice, ele fiind
identificate după un id de produs farmaceutic, un număr generat la introducerea în sistem,
numele produsului, un id de producător, date tehnice și specificații pentru fiecare produs .
Gestiunea comenzilor – se identific ă printr -un id unic. Fiecare comand ă poate s ă conțină
diferite produse farmaceutice. La fiecare comand ă, se înregistreaz ă datele clientului.
Deoarece aplicația este destinată utilizării în cadrul activității interne a u nei
companii, în care angațatii respectă o ierarhie în funcție de postul ocupat, distingem mai
multe tipuri de useri :
1. Userul tip Sef Depozit, cu ierarhia cea mai înaltă, poate să vizualizeze
stadiul comenzilor, să aprobe comenzile, să adauge furnizori, viz ualizează
stocul de produse farmaceutice și comand ă alte produse .
2. Userul tip angajat aprovizionare, se ocupă cu aprovizionarea și îi este
permis să vizualizeze stocul de produse, să adauge furnizori în baza de
date, să comande produse de la furnizori și să facă recepția comenzilor
furnizorilor.
3. Userul tip angajat vînzări, se ocupă de adăugarea comenzilor noi,
vizualizarea catalogului de medicamente, vizualizarea stocului si a
comenzilor finalizate sau nefinalizate.
4. Userul tip angajat, poate să modi fice starea comenzilor, iar datorită acestui
fapt se poate urmări stadiul realizării unei comenzi. Acestui tip de user i se
permite de asemenea să vizualizeze comenzile care trebuie realizate și
detaliile despre produsele farmeceutice și despre clienți.
2.2. Analiza sistemului informatic
Pe baza cerințelor și specifica țiilor formulate pentru s istemul informatic care se
dorește a fi implementat, se face analiza sistemului. Analiza se face pe două direcții:
 Analiza bazei de date relaționale ;
 Analiza aplicaț iei din punct de vedere al principalelor procese care se regăsesc
în ea.

13 Pentru a realiza a naliza si stemului informatic , trebuie identificate și analiza te
datele necesare pentru derularea activității cerute de către sistem.
2.2.1. Analiz a bazei de date relaț ionale. Modelul entitate -relație
Modelul entitate -relație este un model conceptual care define ște mul țimea de
entită ți și relațiile dintre ele. Principalele concepte folosite pentru construcția acestei
diagrame sunt : entitatea, rel ația, cardinalitat ea, atributul .
Entitatea [7]
Entitatea – modelează clase de obiecte concrete sau abstracte despre care se
colectează informații, are existență independentă și poate fi identificată în mod unic. O
entitate poate reprezenta atât obiecte fizice precum : persoane, locuri sau lucruri, dar
și obiecte abstracte precum : clien ți, dosare, documente etc. Reprezentare fig. 2.1.

Figura 2.1 . Reprezentare grafică pentru Entitate

Entitatea se reprez intă printr -un dreptunghi, în interiorul căruia se află numele. Nu
pot exista două entități cu același nume, prin urmare, fiecare entitate trebuie să fie
denumită în mod unic.
Reprezentarea entităților se face întotdeauna prin substantive reprezentative .
Astfel, nu orice substantiv sau obiect din des crierea sistemului , poate să reprezinte și
o entitate. De exemplu, avem nevoie de denumirea unui client, dar acestea nu sunt
suficien te pentru a crea o entitate . Denumirile clien ților prime va fi un atribut al
entității Client .

14 Relația reprez intă o asociere între entități. În schema conceptuală fiecare relație
are un nume unic, reprezentat prin verbe.
Atributele
Atributul este o proprietate care descrie un anumit aspect al unei entități.
Aributul este o caracteristic ă a unei entit ăți sau a u nei rela ții. Fiecare entitate
are un anumit num ăr de atribute despre care sunt înregistrate date. [8] Ex.: nume,
prenume, data . Fiecare atribut poate lua valori care furnizeaz ă informa ții despre entitatea
respectiv ă. Ex.: Viorel, Blandian, 10.10.10 .
Numel e unui atribut este unic în cadrul unei entități sau al unei relații. Atributele
sunt întotdeauna substantive, dar nu orice substantiv este atribut.
Pentru fiecare atribut este necesar ă o descriere, împreun ă cu domeniul de valori
(întreg, ș ir de caracter e, data calendaristică etc.).
Clienti
id_client
nume_client
adresa
telefon

Fig 2.2 Entitatea Clien ți cu atributele sale
Relațiile
Relația reprezintă o asociere între entită ți. O relație este o asociere nedirecționată .
Entitățile implicate într -o anumită relație su nt participanții acesteia. Numărul de
participanți dintr -o anumită relație formeaz ă gradul acesteia .
Medicament Tip Medicament
are

Fig 2.3 Reprezentare rela ție

15 Cardinalitatea

Cardinalitatea unei rela ții indic ă numărul minim, respectiv maxim de instan țe din
fiecare entitate care poate participa la rela ție. Cardinalitatea unei rela ții se poate afla prin
adresarea unor întreb ări simple bazate pe leg ătura dintre entit ăți.
Exemplu: Câte comenzi poate s ă lanseze un client? răspunsul fiind : n (un număr
nelimitat). În sens opus , se pune întrebarea : Câți clien ți poate avea o comandă ?
răspunsul fiind: 1.
Astfel, cardinalitatea unei relații poate fi de 3 feluri : 1 la 1, 1 la n și n la m . [9]
o Cardinalitate de tip 1 la 1 ( unu la unu ) : constă în faptul că u nei instanțe
din prima entitate din relație , îi corespunde o singură instanță din a două
entitate a relației.
o Cardinalitatea de tip 1 la n ( unu la mul ți ): constă în faptul că unei
instan țe din prima entitate din relație , îi corespund mai multe instanțe din a
două entitate a relației.

Medicament Tip Medicament
are1 n

Fig. 2.4 Cardinalitate 1 la n

o Cardinalitatea de tip n la m ( mul ți la mul ți ): constă în faptul că unei
instanțe din prima entitate din relație , îi corespund mai multe instanț e din a
doua entitate a relației și invers, adică unei instanțe din a două entitate îi
corespund mai multe instanțe din prima entitate .

16
Medicament UM_Medicament
aren m

Fig. 2.5 Cardinalitate n la m

Diagrama entitate -relație corespunzătoare bazei de date a sist emului informatic

Entitățile sistemului, reprezentate prin dreptunghiuri, împreună cu legăturile
dintre ele, reprezentate prin arce neorientate și specificându -se cardinalitatea acestora ,
constituie Diagrama Entitate – Legătură corespunzătoare bazei de date a sistemului
informatic .
Principalii pași pentru construirea diagramei Entitate – Legatură sunt:
 Identificarea entităților care fac parte din sistem ;
 Definirea legăturilor între entități și a cardinalității acestora ;
 Indentificarea atributelor s istemului și a cheilor primare ale entităților ;
 Trasarea diagramei entitate – relație.

17

Fig. 2.6 . Diagrama Entitate – Relație
În figura de mai sus, este reprezentată Diagrama Entitate -Relație, realizată
parcurgând toți acești pași prezentați și tin ând c ont de toate regulile și definițiile
principalelor componente ale unei astfel de diagrame.

18
2.2.2 . Analiza aplica ției software a sistemului informatic. Diagrama Procesului de
afaceri .
După ce am finalizat analiza bazei de date relaționale, trecem la ur mătorul pas ,
care constă în analizarea aplicației software pentru sistemul informatic descris în cerin țe.
Aplicația software trebuie să se folosească de baza de date, iar analiza lui în acest punct
constă în depistarea principalelor procese care au loc în cadrul sistemului și al factorilor
care determină și ajută la func ționarea corectă a acestor procese. Această analiză poate fi
realizată cu ajutorul diagramei procesului de afaceri (Business Process Model ).
Diagrama procesului de afaceri (Business Process Model)
Este diagrama care descrie în mare , vocabularul afacerii pentru care urmează să
fie implementat sistemul informatic. Reprezintă punctul de pornire în proiectarea acestui
tip de aplicație. Scopul acestei diagrame este de a contribui la o cât mai bună înțelegere a
procesului care stă în spatele afaceri , care se bazează pe sistemu l informatic care trebuie
creat .
Un proces de afacere ( business process ) este o colecție de activitați care sunt
menite să producă un anumit rezultat. Reprezintă o vedere puternică asupra cum este
realizată într-o companie, în contrast cu vederea pe care sistemul o oferă asupra
procesului pe care îl reprezintă . Prezint ă o ordine riguroasă asupra activităților în timp și
spațiu , cu un început, un final, cu date de int rare bine definite și un rezultat care este și el
bine definit. Toate acestea pot fi considerate ca o structură pe care aplica ția software
pentru sistemul informatic se bazeaz ă.
Principalele componente ale unei astfel de diagrame sunt:
 Actorii,
 Evenime ntul care declanșează procesul ,
 Procesul ,
 Scopul procesului,
 Informații auxiliare ,
 Resurse necesare procesului ,
 Rezultatul procesului.

19 Actorii

Un actor , este un stereotip al unei clase. Actorii sunt reprezentați de utilizatori
sau entități care po t interacționa cu sistemul. Ei nu fac parte din sistem și definesc
mulțimi de roluri în comunicarea cu acesta. Grafic ei sunt reprezenta ți sub forma unor
mici pe rsonaje având propriul său nume , fig.

Fig. 2.7 . Reprezentare grafică actor

Evenimentul care declanșeaz ă procesul
Este evenimentul care duce la startul procesului și este de cele mai multe ori, un
eveniment declanșat de că tre un actor. În cadrul diagramei este reprezentat ca un
eveniment public, care este descris printr -un verb.

Fig. 2.8 . Even iment declanșator

Procesul
Un proces, reprezintă o activitate care are un scop bine definit , în urma căruia se
obține un rezultat de la o condiție inițială. Pentru a -și realiza scopul, procesul se poate
folosi de mai multe resurse. Grafic este reprez entat sub forma unei s ăgeți îngroșate, iar
denumirea procesului este încapsulată în cadrul acestei reprezentări.

20

Fig. 2.9 . Reprezentare proces

Scopul Procesului
Scopul procesului reprezintă cauza pentru care sistemul funcționează și trebuie
să fie exprimat în cei mai potriviți termeni care arată modul în care acest proces aduce
beneficii. Scopul se află reprezentat în dreptunghiul de mai jos și este conectat de căsuța
de proces printr -o linie discontinuă.

Fig. 2.10 . Reprezentare scop

Informaț ii auxiliare
Pentru a -și îndeplini scopul, procesele folosesc informații care spre deosebire de
resurse, nu sunt consumate în cadrul acestuia. Informațiile pot rezulta din diferite surse ca
de exemplu, catalog produse este considerat ca fiind o informație auxiliară procesului de
gestiune a comenzilor. Informațiile auxiliare și procesul sunt reprezentate prin căsuțe care
sunt legate între ele cu ajutorul unor săgeți întrerupte cu textul ,,supply ”.

21 Fig. 2. 11. Reprezentare informație auxiliară

Resurse nec esare procesului
Resursele sunt date de intrare în proces care sunt modificate și consumate pe
parcursul întregului proces. Ele sunt reprezentate prin căsuțe care sunt conectate de
proces cu ajutorul unor săgeți întrerupte cu textul ,,input ”.

Fig. 2.12 . Reprezentare resurse necesare

Rezultatul procesului
Rezultatul procesului reprezintă informa țiile și acțiunile care rezultă în urma
terminării procesului. Grafic sunt reprezentate printr -un dreprunghi unde este scris un
titlu cât mai reprezentativ pentru obiectele care rezultă în urma desfășur ării procesului.

Fig. 2.13 . Reprezentare rezultat proces

Cu ajutorul tuturor elementelor descrise mai sus , putem reprezenta Diagrama
Procesului de afacere ( Business Workflows Diagram ).

Pentru sistemul inform atic descris la începutul capitolului Diagrama procesului de
afacere este reprezentată în fig. 2.14.

22

Fig. 2.14. Diagrama procesului de afacere

Toate elementele prezentate mai sus , reprezintă partea de analiză a cerințelor și
scopurilor Sistemului inf ormatic de gestiune a comenzilor clienților , analiză care este
necesară pentru realizarea proiectului sistemului și mai apoi pentru implementarea lui.

23 CAPITOLUL III. Proiectarea sistemului informatic

In cadrul acestui stadiu de dezvoltare, se realizeaz ă proiectarea sistemului
informatic, pe baza cerin țelor și a datelor rezultate în etapa de analiza a sistemului. In
aceasta etap ă, accentul cade pe arhitectur ă (intrări și ieșiri, procese, interfețe) și design -ul
sistemului.

Design -ul sistemului
Dacă procesul de analiz ă a sistemului informatic se preocup ă să descrie felul
sistemului care trebuie folosit pentru atingerea scopului, în aceasta etap ă, design -ul
sistemului specifică modul în care sistemul își atinge obiectivele . Acesta este format din
trei act ivități:
 design -ul interfeței cu utilizatorul ;
 datele utilizate ;
 procesul .

Design -ul interfeței – face referință la interacțiunea care va avea loc între utilizatorul
sistemului și aplicație. Este important să fie un design atractiv (user -friendly) și ușor de
folosit, pentru a putea fi utilizate și alte echipamente de introdus date.
Design -ul datelor – are în vedere structura bazei de date și a fișierelor care o să fie
utilizate de noul sistem informatic.
Design -ul procesului – este o activitate care are în vedere resursele software, adică
programele utilizate, precum și procedurile prin care acestea vor fi utilizate de sistem.

Proiectarea sistemului se desfasoară pe două direcții :
1. Proiectarea bazei de date rela ționale : pentru aceasta se urmărește des crierea
atributelor entită ților, precum și stabilirea legăturilor dintre acestea. Se preia și se
îmbun ătățește diagrama Entitate -Relație realizată în faza de analiză a sistemului
informatic.

24 2. Proiectarea aplica ției software a sistemului informatic: are în prim plan stabilirea
arhitecturii aplicației software a sistemului informatic. Se pune accent pe modul în care
sunt gestionate datele de către aplicație, modul în care aplicația se comportă la diferiți
stimuli și acțiuni venite din partea utilizatorilor aplica ției sau acțiunii altor componente
ale aplica ției. În acela și timp trebuie modelate principalele procese și stări ale aplicației.
În proiectarea bazei de date , una dintre cele mai bune strategii este o abordare
structurată , formată din trei etape:
 Proiectarea tip conceptuală ;
 Proiectarea tip logică ;
 Proiectarea tip fizică .

3.1.Proiectarea bazei de date relaționale
Una dintre cele mai importante utiliz ări ale calculatoarelor este stocarea și
gestionarea de informații. Modul în care sunt organizate inf ormațiile poate avea un
profund efect in usurin ța cu care se pot accesa și gestiona acestea. Poate că cea mai
simplă, dar și cea mai utilizata modalitate pentru a organiza informațiile este de a le stoca
în tabele. Modelul relațional este centrat pe aceast ă idee: de organizare a datelor în
colecții de tabele bidimensionale, numit "relații." Pe lângă aceste date stocate, baza de
date poate să conțină utilizatori, tipuri de date, proceduri si funcții.
O schemă conceptuală sau model de date conceptual , este o hartă de concepte și
relațiile lor utilizate pentru baze de date. Aceasta descrie semantica unei organizații și
reprezintă o serie de afirmații cu privire la natura sa. În mod specific, acesta descrie
lucrurile de importanță pentru o organizație (clase ent ității), utilizate pentru a colecta
informații și caracteristicile (atribute) dar și asocieri între perechi de acele lucruri
semnificative (relații).
Când o bază de date relațională trebuie să fie proiectată, o diagramă entitate –
relație este redactată într -un stadiu timpuriu și dezvoltată , pentru ca cerințele de date și
prelucrarea acestora să devină mai bine înțelese. Desenând o diagramă entitate -relație ne
ajută să înțelegem nevoile de date ale unei organizații și poate servi ca o diagramă tip
schem ă pentru baza de date a sistemului. O diagramă entitate -relație ar putea servi ca

25 bază pentru proiectarea fișierelor într -un sistem convențional bazat pe fișiere, precum și
pentru o diagram ă schemă într -un sistem de baze de date. [16]
Cheia unei entități [10]
Cheia unei entități , reprezintă un atribut sau set de atribute , care pot identifica în
mod unic o instanță a acelei entități.
Acestea pot fi de două feluri:
o Entități naturale ;
o Entităț i artificiale (nu au semnificație reală) .
Cheile relaț ionale sunt împățite în:
 Cheie străină care identifică o coloană sau mai multe coloane într -un tabel,
aceasta efectuând o referință la una sau mai multe coloane din alt tabel.
 Super cheia reprezintă o coloană sau mai multe coloane care permite
identificarea fiecărei înregistr ări dintr -un tabel. Trebuie selectate acele super
chei care au nevoie de un minimum de coloa ne pentru identificare unică .
 Cheia candidată este o super cheie care are numărul minim posibil de
coloane necesare pentru o identificare a înregistrărilor. Pot exi sta mai multe
chei candidate.
O cheie candidată trebuie să respecte următoarele condiții:
o Să se asigure că fiecare înregistrare este unică ;
o Cheia cadidată este ireductibilă, adică nu se mai asigură că înregistrările sunt
unice de nici un sub -set de coloane ale cheii candidate.

 Cheia primară este o cheie candidat, care are scopul de a identifica instanțele din
cadrul unei relații .
În continuare este prezentată Diagrama logică a bazei de date:

Figura 3.1. Diagrama logică a bazei de date

26
Categorie_Medicament
id_categorie
nume_categorie
Clienti
id_client
nume_client
adresa
telefon
Comanda
id_comanda
data_comanda
id_furnizor
id_medicament
cantitate
pret
is_DoneComandaClient
id_comanda
id_client
data_comanda
detalii_comanda
stadiu
data_updateDetaliiComanda
id_comanda
id_medicament
cantitate
pret
Furnizor
id_furnizor
nume_furnizor
is_ActiveFurnizor_Medicament
id_medicament
id_furnizor
pretMedicament
id_medicament
nume_medicament
id_producator
id_tip_medicament
id_UM
pret_um
is_ActiveMedicament_UM
id_medicament
id_UM
UM_cantitateMesaje
id_mesaj
id_destinatar
id_expeditor
titlu
mesaj
data
NIR
id_NIR
id_comanda
id_medicament
cantitate
pret
data_receptie
Producator
id_producator
nume_producator
adresa
telefon
fax
descriereStatus
id_status
status_comanda
Stoc
id_medicament
cantitate
cantitate_comandataTemperaturaDepozit
id_temp
temperatura
Tip_medicament
id_tip_medicament
nume_tip_medicament
descriere
id_categorieUM
id_UM
nume_UM
UrmarireComanda
id_comanda
id_status
data_actualizareUtilizatori
id_user
user_name
user_password

27 Tabelele asociat e diagramei sunt :
Medicament ( id_medicament , nume_ medicament , id_producator, id_tip_ medicament ,
id_UM, pret_um , is_Active )
Medicament _UM ( id_ medicament , id_UM, UM_cantitate )
UM ( id_UM, nume_UM)
Tip_ Medicament (id_tip_ medicament , nume_tip_ medicame nt, descriere, id_categorie)
Categorie _Medicament (id_categorie, nume_categorie)
Producator (id_producator, nume_producator, adresa, telefon, fax, descriere)
Stoc (id_ medicament , cantitate, cantitate_comandata)
NIR ( id_NIR, id_ comanda, id_ medicament, c antitate, pret, data_receptie )
Furnizor (id_furnizor, nume_furnizor , is_Active )
Furnizor_Medicament ( id_ medicament, id_furnizor, pret)
Comanda ( id_comanda, id_furnizor , id_ medicament , data_comanda, cantitate, pret,
is_Done )
Clienti (id_client, nume_c lient, adresa, telefon)
ComandaClient (id_comanda, id_client, data_comanda, detalii comanda, stadiu,
data_update)
Detalii Comanda ( id_comanda, id_ medicament , cantitate, pret)
UrmarireComanda(id_comanda, id_status, data_actualizare)
Status(id_status, stat us_comanda)
Mesaje(id_mesaj, id_destinatar, id_expeditor, titlu, mesaj, data)
TemperaturaDepozit(id_temp, temperatura)
Utilizatori(id_user, user_name, user_password)

3.2. Proiectarea aplicației software a sistemului informatic
Procesul de proiectare a apl icației sistemului informatic , este și el imparțit pe
etape , care treptat , ajută la anticiparea și pregatirea sistemului pentru a face față tuturor
situațiilor pe care acesta le va putea întâlni pe parcursul perioadei lui de funcționare.
Principalele etap e de proiectare sunt :

28  Determinarea fluxului de date din interiorul sistemului și construitea Diagramei
Fluxurilor de date ( Data Flow Diagram ) .
 Definirea și analiza cazurilor de utilizare a sistemului informatic, aceste aspecte
ale sistemului sunt cont urate în cadrul Diagramei Cazurilor de Utilizare (Use Case
Diagram ) .
 Proiectarea activității principalelor procese care au loc în cadrul sistemului, toate
acestea fiind proiectate în cadrul Diagramelor de Activitate ( Activity Diagram ) .
 Determinarea sec vențelor prin care trec procesele din cadrul sistemului informatic
pentru a -și indeplini funcțiile. Aceste elemente se stabilesc în cadrul Diagramelor
de secvențe ( Sequence Diagram ) .
 Determinarea stărilor prin care trece sistemul informatic în urma uno r evenimente
care interacționează cu acesta. Aceasta determinare se face în cadrul Diagramei de
Stare de Tranziție ( State Machine Diagram ) .

Pentru întocmirea unei diagrame a fluxurilor de date care să fie folositoare, există
câteva reguli și informați i ajutătoare , care sunt de folos în mare pentru a evita să
construim o diagram ă care este incorectă sau incompletă.
Principalele reguli de întocmire a diagramei sunt :
 Botezarea componentelor și a fluxurilor de date : trebuie alese nume cât mai
sugestive . Proceselor li se asociază la denumire verbe, principalelor entități care
interacționează cu sistemul informatic și obiectele lor pentru stocarea datelor sunt
asociate substantive, iar fluxurile de date sunt exprimate și ele prin substantive cât
mai semni ficative pentru a exprima datele, tranzitia datelor .
 Numerotarea proceselor : procesele sunt numerotate secvențial, pentru a putea fi
identificate mai ușor . Numere le asociate fiecărui proces nu semnific ă și ordinea
lor de execuție.
 Duplicarea entitațilo r externe : se face în mare pentru a evita intret ăierile, care pot
duce la confuzii în citirea diagramei.
 Plasamentul entităților și a stocurilor de date : entitățile sunt plasate pe c ât posibil
pe marginea diagramei, iar stocurile de date cât mai în cent ru.

29  Fluxurile de date : fluxurile de date către stocurile de date sunt întotdeauna
unidirecționale.

Fig.3.2. Diagrama fluxurilor de date

Diagrama cazurilor de utilizare

Diagrama cazurilor de utilizare ( Use Case Diagram ) are scopul de a descrie
comportamentul sistemului informatic, oferind o imagine generală asupra modului în care
va fi utilizat sistemul astfel furniz ând o privire de ansamblu a funcționalităților ce se
doresc a fi oferite de c ătre sistem. Un alt scop al diagramei cazurilor de utili zare este de a
arăta cum interacționează sistemul cu unul sau mai mulți utilizatori ( actori ). Toate
acestea sunt realizate pentru a certifica faptul că sistemul informatic va produce ceea ce s –
a dorit .

Principalele componente ale unei diagrame a cazur ilor de utilizare sunt :

30  Actorii;
 Cazurile de utilizare ;
 Relațiile între actori ;
 Relațiile între cazuri de utilizare ;
 Relațiile dintre actori și cazuri de utilizare .

Actorii
Actorii nu sunt componente ale sistemului, ei doar reprezintă elemente care
interactionează cu sistemul informatic . E l nu particip ă propriu -zis la prelucrarea datelor
din sistem, el fiind limitat doar la a primi date și introduce date sistemului, astfel acesta
poate fi considerat doar ca un generator de evenimente . Un actor rep rezintă o clas ă și nu
o instanță și are acela și rol ca și o entitate externă din diagramele de flux de date, adică de
a interacționa cu sistemul informatic .
Reprezentarea grafică în format UML a unui actor , este prezentat în figura 3. 3.

Fig. 3.3. Rep rezentare grafică actor

La identificarea actorilor, trebuie să se aibă în vedere să nu fie omiși niciunul , iar
alții să nu fie repetați. De exemplu, același actor poate fi observat la momente diferite în
timp, când interacțiunile lui cu sistemul diferă.

31 Cazurile de utilizare
Un caz de utilizare reprezintă o colecție de scenarii posibile, referitoare la
comunicarea între sistem și actorii externi, caracterizate de anumite scopuri. O
caracteristică importantă a cazurilor de utilizare , este că ele arat ă ce trebuie să facă
sistemul și nu cum trebuie să facă.
Reprezentarea grafică a unui caz de utilizare este :

Fig. 3.4. Reprezentare grafică caz de utilizare

Pentru a putea identifica cu ușurință cazurile de utilizare, în primul rând trebuie să
identi ficăm actorii, iar pentru fiecare actor sunt puse următoarele întrebări:

 Ce funcționalități ale sistemului va trebui să acceseze actorul?
 Poate actorul să lucreze mai eficient dacă folosește noi funcționalități?
 Sunt evenimente în sistem care trebuie să î i fie aduse la cunoștință actorului?

Relațiile între actori și cazurile de utilizare
Relațiile între actori și cazurile de utilizare sunt relații de comunicare. Ca și
caracateristici , ele sunt relațiile cele mai generale și sunt unidirecționale.

Fig. 3.5. Reprezentare grafică relația între actori

32 Relațiile între actori

Relațiile între actori pot fi relații de generalizare, asta înseamnă că dacă un actor
moștenește un alt actor atunci el poate să comunice ca și părinte cu aceleași cazuri de
utilizar e ale sistemului.

Relațiile între cazurile de utilizare

Relațiile înt re cazurile de utilizare pot fi: de generalizare, extindere sau includere.

Relațiile de generalizare sunt folosite pentru a arăta faptul că un caz de utilizare
moștenește comportamen tul altui caz și îl îmbunătățește pe acesta.

Relațiile de extindere sunt folosite pentru a arăta că un caz de utilizare este inserat
în alt caz.

Relațiile de includere sunt folosite atunci când un caz de utilizare include
comportamentul altui caz de util izare.

Fig. 3.6. Reprezentare grafică relația de includere

33 Prezentarea diagramei cazurilor de utilizare

Fig. 3.7. Diagrama cazurilor de utilizare a sistemului informatic:

 Angajat V ânzări este actorul care se ocupă de adăugarea de noi co menzi venite
de la clienți . El mai are posibilitatea de a vizualiza comenzile și stocul de
medicament .

34  Angajat Aprovizionare este actorul care se ocupă cu adăugarea de furnizori,
comandă materialele și are posibilitatea să vizualizeze detaliile despre mate riale.
Pe lângă acestea el se mai ocupă și de recepția comenzilor de la furnizori.
 Angajat Necalificat este actorul care se ocupă să modifice starea comenzilor și
mai are posibilitatea să vizualizeze detalii legate de clienți și detalii legate de
comenzi.
 Manager este actorul responsabil să adauge noi materiale, să aduge noi furnizori,
să comande materiale și are posibilitatea să vizualizeze stocul de materiale și
comenzile.
 Adaugă noi comenzi : este un caz de utilizare care presupune introducerea
datelor care corespund unei noi comenzi .
 Adaugă furnizori este un caz de utilizare care presupune adăugarea de noi
furnizori în baza de date.
 Adaugă medicament nou este un caz de utilizare care presupune adăugarea de
noi materiale în baza de date.
 Comandă medic ament este un caz de utilizare care presupune efectuarea unei
noi comenzi pentru medicament .

Diagrama de activitate
Diagrama de activitate cuprinde toate atributele unei diagrame de stare, însă are și
alte atribute noi. Prin această metodă se poate vedea ceea ce se întâmplă în cadrul unui
caz de utilizare, sau al unui process ce se de sfășoară în sistemul informatic . Această
diagramă este folosită pentru a modela dinamica unui proces sau a unei operații și
reprezintă fluxul de control de la o activitate la alta.
Componentele principale ale diagramei de activitate sunt:
 stări de acțiune și stări de activități ;
 tranziții ;
 obiecte ;
 bare de sincronizare ;
 ramificații .

35 Stările de acțiuni reprezintă execuția propriu – zisă a unei acțiuni și nu poate fi
descompusă. Ele sunt atomice, nu pot fi întrerupte indiferent dacă se produc sau nu
evenimente și au o durată foarte mică. În cadrul unei activități există o singură acțiune
inițială, una sau mai multe acțiuni simple și finale.
Stările de activități sunt procesări nea tomice adică pot fi întrerupte la apariția
unui eveniment, ele putând fi descompuse, iar activitatea lor se poate reprezenta prin alte
diagrame de activități.
O stare de activitate se reprezintă grafic:

Fig. 3.8. Reprezentare grafică a unei stări de ac tivitate

Punct ul inițial reprezintă locul de pornire în citirea secvenței de acțiuni care
formează diagrama. În cadrul unei diagrame poate să existe un singur punct de start și de
la el poate să plece o singură tranziție către o acțiune .
Un punct iniția l este reprezentat grafic:

Fig. 3.9. Reprezentare grafică punct inițial

Punct ul final reprezintă ultima acțiune dintr -o diagramă de activitate, iar în
modelarea UML [11] se reprezintă prin cercuri mici concentric e, din care cel interior este
plin. Spre deosebire de punctul inițial, o activitate poate avea mai multe puncte de final.
Un punct final este reprezentat grafic:

Fig. 3.10 . Reprezentare grafică punct final

36 Tranzițiile într-o diagramă de activitate arată întotdeauna ordinea de execuție a
acțiunilor . Ele sunt reprezentate sub forma unei săgeți care întotdeauna arată către
acțiunea care urmează să se execute.
Tranziția este reprezentată grafic în figura de mai jos:

Fig. 3.11. Reprezentare grafică tranziție

Obiecte
O acțiune este r ealizată de către un obiect, sau operează asupra unui obiect,
acesta putând interveni în diagramă în două moduri :
o operația unui obiect este considerată numele activității ;
o obiectul poate fi privit ca intrare sau ieșire a unei activități .
Bare de sincroni zare sunt de două tipuri și anume join (îmbinare) sau fork
(bifurcare). În timpul execuției mai multor activități, există posibilitatea ca acestea să se
execute în paralel, iar pentru sincronizarea acestor activități se folosesc aceste bare de
sincronizare .
Ramificațiile sau blocuri de decizie sunt folosite pentru modelarea
alternativelor, a căror alegere depinde de o expresie booleană. Acestea au o tranziție de
intrare și două sau mai multe tranziții de ieșire, fiecare tranziție de ieșire fiind etichetată
cu o condiție de gardă, condiție care trebuie să acopere toate posibilitățile de continuare a
execuției și să nu se suprapună.
Una dintre cele mai importante activități este Activitatea de introducere a
comenzilor furnizor . Introducerea propriu -zisă se fac e de că tre Operatorul de Marketing
pe baza cerinț elor exprimate de către client. Această activitate presupune executarea
acțiunilor de logare, introducera datelor clientului, vizualizarea catalogului de produse,

37 selectarea produselor, adăugarea numărului d e produse dorite și adăugarea comenzii în
baza de date.
Diagrama este reprezentată în figura de mai jos:

Fig. 3.12. Diagrama de activitate pentru Adăugarea unei comenzi

38 O altă diagramă importantă este Diagrama de activitate pentru adăugarea de
medicam ente. Această activitate este realizată de către Manager. Acțiunile derulate în
cadrul activității sunt acțiunile de logare, adăugare medicament , selectarea sau adăugarea
de câmpuri necesare și salvarea datelor. În diagramă avem două puncte de decizie, pr imul
punct este situate după acțiunea de logare, iar dacă logarea nu s -a efectuat cu succes se
realizeaza terminarea activității . Al doil ea punct de decizie este situat după acțiunea de
selectare/ adugare de câmpuri necesare.

Diagrama de activitate pentru adăugarea de medicament este reprezentată:

Fig. 3.13. Diagrama de a ctivitate pentru Adăugarea de Medicamente

39 Diagrama tranzițiilor de stare

Diagrama de stare a tranzițiilor reprezintă stările unei clase date, evenimentele ce
cauzează tr anzițiile de la o stare la alta și acțiunile care rezultă din schimbările stărilor.
Scopul acestor diagrame este de a descrie răspunsul și comportarea diferit elor
obiecte la mesaje externe , dar și de a reprezenta și secvențele de stări prin care trec acele
obiecte pe parcursul existenței lor .
Într-o stare, toate acțiunile care există trebuie să se afle în următoarele momente:
on entry, on exit, on an event, upon event.
Starea este reprezentată grafic printr -un dreptunghi, în interiorul căruia scriem
numele și un compartiment. Componentele principale ale unei diagrame de tranziții sunt:
stările, tranzițiile, punctele de decizie, punctele de intrare și ieșire.
O diagramă poate să prezinte mai multe stări, dintre care doar una poate fi stare de
intrare, restul fiin d stări imbricate și finale.
Tipuri de stări
Starea inițială reprezintă inițializarea mașinii cu stări, conectându -se mașinii de
stări printr -o tranziție neetichetată. Această stare este unică într -o diagramă de stare .
Stările imbricate au apărut atunci c ând într -o diagramă de stări, numărul de
conexiuni dintre stări devine ridicat.
Starea finală reprezintă starea terminală a unui sistem și este folosită în cadrul
diagramei de stare când se dorește explicitarea finalului mașinii de stare.
Tranziția este t recerea de la o stare la altă stare și poate fi folosită pentru a
prezenta acțiunile care se impun acestei treceri.
Grafic, tranzițiile între două stări se reprezintă prin intermediul unor arce de cerc
sau linii drepte, pe care pot fi trecute, opțional acț iunile care au loc pe parcursul
tranzițiilor.
Punctul de intrare și de ieșire al diagramei reprezintă punctele din care pleacă și se
termină tranziția stărilor prin care trece obiectul . Grafic, ele sunt reprezentate la fel ca în
diagramele de activitate.
Stările prin care trece sistemul informatic în momentul în care se execută procesul
de adă ugare a comenzi lor venite de la clienți încep cu verificarea existenței clientului în

40 baza de date, dacă clientul există în sistem atunci se înregistrează datele refe ritoare la
comandă, se continuă cu starea în care sunt selectate materialele iar apoi urmează un
punct de decizie.
Din punctul de decizie se poate reveni în starea în care înregistrează datele despre
comandă altfel se trece în starea în care comanda este finalizată, stare care este și starea
finață a sistemului.
În figura de mai jos , se poate observa această diagrama de stare a tranzițiilor
pentru sistemul informatic, în momentul introducerii unei noi comenzi venite de la
clienți.

Fig. 3.14. Diagrama de stare a tranzițiilor

41 Diagrama de secvențe

Diagrama de secvențe reprezintă grafic o interacțiune între obiecte insistând în
ordinea temporală a expedierii mesajelor. Perioada în care un obiect preia controlul sau
efectuează o acțiune, este reprezentată sub forma unui dreptunghi în dreptul linie i
punctate.
Scopul unei astfel de diagrame , este de a cre ea o idee asupra cum preiau obiectele
acțiunea în anumite situații ș i asupra modului în care acestea se comportă și
interacționează între ele, toate aceste lucruri fiind analizate având în vedere caracteristica
cronologică și a timpului în care acestea îsi desfășoară activitatea.
Într-o diagramă de secvență, elementele de bază sunt obiectele, liniile de viață și
mesajele.
Obiectele sunt principalele elemen te ale diagramei, sunt entitățile care în cadrul
diagramei intervin în preluarea datelor, prin transmisia și recepționarea de mesaje. Ele
sunt reprezentate grafic prin dreptunghiuri în cadrul cărora sunt scrise numele.
Liniile de viață reprezintă axa timp ului pentru diagrame, astfel cronologia
expedierii mesajelor fiind redată de apariția lor pe axe. Ele sunt reprezentate printr -o linie
verticală punctată, fiecare obiect având o astfel de linie.
Mesajele sunt elementele cu care obiectele comunică între el e. Ele sunt
reprezentate sub forma unor săgeți care unesc liniile de viață ale obiectelor.
După modul în care se face preluarea datelor, mesajele se clasifică în trei
categorii: mesaje sincrone, mesaje asincrone și mesaje simple.
Mesajele sincrone sunt m esajele după care se așteaptă terminarea completă a
preluării indicate de către acesta.
Mesajele asincrone sunt opusul mesajelor sincrone și arată că se poate începe și
realiza o nouă prelucrare chiar dacă nu s -a finalizat prelucrarea în curs.
Mesajele s imple sunt mesajele pentru care nu sunt este specificat faptul dacă sunt
sincrone sau asincrone.
În această parte a proiectării sistemului informatic se face identificarea mesajelor
care apar între diferite clase ale sistemului informatic, în același timp acest moment este
și momentul în care se stabilesc operațiile care au loc între clase.

42 În figura de mai jos (Fig.3.15 ) este prezentată diagrama de secvențe :

Fig. 3.15. Diagrama de secvențe

43 După cum se poate observa din cadrul diag ramei prezenta tă mai sus se poate
distinge faptul că fiecare obiect nou al clasei Comandă trece prin următoarele secvențe de
activitate :
1) Angajat Vânzări introduce o comandă nouă în sistem ,
2) Se preia comanda de către angajat ,
3) Angajatul necalificat verifică stocul de mater iale,
4) Dacă stocul este ok , se pregătesc materialele ,
5) După ce s -au pregătit materialele, se face livrarea comenzii.

44 CAPITOLUL IV. Implementarea sistemului informatic

În acest capitol, sunt prezentate informațiile referitoare la implementar ea
sistemului informatic, analizat si proiectat anterior. Pe baza cerințelor si a diagramelor
care descriu modul de funcționare, are loc dezvoltarea aplicației , car e presupune o
programare propriu -zisă.
Implementarea sistemului informatic proiectat , se realizează în două etape și
anume:
 Implementarea bazei de date ,
 Implementarea aplicației software .

4.1. Implementarea ba zei de date
Această etapă din realizarea sistemelor informatice constă în realizarea proiectării
fizice a bazei de date și presupune tr ansformarea designului logic al bazei de date, într -o
structură fizică eficientă, specifică pentru sistemul de gestiune al bazei de date folosit.
Pentru realiarea bazei de date, am utilizat limbajul SQL in cadrul aplicatiei
Microsoft SQL Server 2014.

Limb ajul SQL
În prezent limbajul SQL este un limbaj folosit pentru crearea, modificarea, găsirea
și manipularea datelor de către bazele de date relaționale . Implementarea limbajului SQL
se poate face prin 3 metode: apelarea directă care constă în introducerea instrucțiunilor
direct din linia de comanda , apelarea modulară care folosește proced uri stocate și apelate
de metodele aplicației și apelarea încapsulată care conține instrucțiuni încapsulate în
codul de program. [12]
Instrucțiunile limbajului SQL sunt gru pate în mai multe categorii și anume:
instrucțiuni de definire a datelor , instrucțiuni de manipulare a datelor , instrucțiuni de
selecție a datelor , instrucțiuni de control a datelor .[13]

45 Microsoft SQL Server
SQL Server a fost lansat în anul 1989 și a devenit unul dintre cele mai importante
sisteme de gestiune a bazelor de date prezente pe piață în zilele noastre.
Principalele caracteristici ale aplicați aplicației SQL Server sunt:
 Utilizarea este mai ușoară deoarece are un model de programare asem ănător celui
al Windows -ului.
 Instalarea se face cu ușurință deasemenea și utilizarea și dezoltarea de aplicații.
 Permite lucrul cu documentele XML
 Poate fi integrat cu alte produse software
 Procesul de interogare poate fi împărțit în mai multe păr ți, fiecare fiind executată
de către un alt procesor.

Elemente ale limbajului SQL în cadrul SQL Server
În SQL există trei categorii de comenzi și anume prima comandă este pentru
crearea structurii de bază de date, a doua comandă este cea pentru adăugare a și
manipularea a datelor în tabele după crearea structurii și a treia comandă este pentru
securizarea datelor.
Comenzile pentru crearea structurii bazei de date sunt: Create, Alter, Drop.
Comenzile pentru manipularea datelor sunt: Insert, Update, Dele te, Select.
Comenzile de control sunt: Grant, Revoke.
După implementarea sistemului informatic, au rezultat un număr de 16 tabele
principale si 3 secundare , fiecare tabel având atribute corespunzătoare pentru datele care
sunt stocate în acel tabel. Cele principale sunt strict legate de gestiunea bazei de date a
produselor medicamentoase, iar cele 3 au rol in stocarea utilizatorilor dar si informarea
acestora despre anumite evenimente: temperatura depozitului, mesaje primite.

46

Fig. 4.1. Exemplu r eprezenta re tabel

Pentru manipularea datelor din baza de date, am utilizat procedurile stocate in
baza de date, care pot sa fie vizualizate in folderul Programmability, al SQL Server 2014.
Cu ajutorul lor se pot executa operatii specifice de manipulare: Select, De lete, Update și
Insert.
În urma implementarii, am considerat necesare crearea a 47 de proceduri stocate.
Structura unei proceduri stocate conține numele acesteia, eventual parametrii transmiși și
operațiile care se execută în cadrul procedurii. Aceste p roceduri au rol in extragerea
tuturor informatiilor din tabel (GetAllMedicament), in extragerea in functie de un
parametru transmis(GetMedicamentById), in adaugarea unor valori in
tabel( AddMedicament ), in updatare tabel (UpdateMedicament _UM ). Aceste proced uri
sunt apelate in cadrul metodelor din clasele folderului DATA, apelate din cadrul claselor
de Form Design.
ALTER PROCEDURE [dbo].[GetMedicamentByID]
@id_medicament int
AS
BEGIN
Select * from Medicament
Where id_medicament=@id_medicament
END

Sau

ALTER PROCEDURE [dbo].[AddFurnizor]
@nume_furnizor nvarchar (50)
AS
BEGIN
INSERT INTO Furnizor
VALUES (@nume_furnizor ,'True')

47 END

Fig. 4.2. E xemple de proceduri stocate
4.2. Implementarea aplicației software a sistemului informatic
Pentru a implemen ta o aplicație software se disting 3 nivele de implementare:
 Nivelul Prezentare este reprezentat de către interfața utilizatorilor.
 Nivelul Logic este codul din spatele interfeței și care face ca programul să
funcționeze corect.
 Nivelul Acces la date are rolul de stocare a datelor utilizate de către program.

Limbajul C#
Limbajul C# este unul dintre cele mai utilizate limbaje de programare în
dezvoltarea sistemelor informatice fiind realizat de către cei de la Microsoft. Are ca
principii elementele fundam entale din programarea orientată pe obiecte și ca și principiu
de utilizarea moștenește sintaxa și principiile de programare din C++. [14]
Pentru a realiza o aplicație C# sunt folosite mai multe clase, fiecare clasă fiind
grupată în namespaces, acestea cu prinzând mai multe clase cu nume diferite având
funcționalități înrudite. Două clase pot avea același nume cu condiția ca ele să fie definite
în spații de nume diferite . O clasă este formată din date și metode, apelarea unei metode
în cadrul clasei în care a fost definită aceasta presupunând specificarea numelui metodei.

Prezentarea aplicației realizate cu limbajul C#
Aplicația software a sistemului informatic dezovoltat, este o aplicație care conține
mai multe nivele logice. Aceste nivele sunt: nivelul d e acces la date, nivelul de
manipulare a obiectelor și a operațiilor specifice sistemului informatic, nivelul de
prezentare.
Nivelul de acces la date reprezintă nivelul în care se face conexiunea la baza de
date. Acest nivel este reprezentat în sistemul informatic propriu -zis de către un
connection -string cu ajutorul căruia se face conectarea la baza de date.

48 Acest string l -am introdus într-o clas ă numit ă ConnectionClass , iar stringul de
conectare l -am ata șat unei variabile tip string intitulat ă connect ionString , cu acces public.
public static string connectionString = "Data Source=(local);Initial
Catalog=DBMedicamente;Integrated Security=True" ;

Nivelul de manipulare a obiectelor și a operațiilor specifice sistemului
informatic
Pentru o utiliza re mai simpla si mai usoara a datelor din baza de date, am realizat o
mapare a tutuor atributelor din tabele. Fiecare tabel a fost mapat in folderul INFO, din
cadrul aplicatiei, iar numele acelor clase de obiecte corespunzatoare tabelelor coincide cu
numel e tabelelor respective.
De exemplu, am facut o mapare a atributelor din tabelul medicament. [15]
Tabelul medicament are atributele:
Fig. 4.3. Entitatea Medicament
Maparea atributelor din tabelul Medicament
class Medicament
{
private int idMedicament;
public int id_medicament
{
get { return idMedicament; }
set { idMedicament = value; }
}
private string numeMedicament;
public string nume_medicament
{
get { return numeMedicament; }
set { numeMedicament = value; }

49 }
private int idProducator;
public int id_producator
{
get { return idProducator; }
set { idProducator = value; }
}
private int idTipMedicament;
public int id_tip_medicament
{
get { return idTipMedicament; }
set { idTipMedicament = value; }
}
private int idUM;
public int id_UM
{
get { return idUM; }
set { idUM = value; }
}
private float Pret;
public float pret_um
{
get { return Pret; }
set { Pret = value; }
}
}
Manipularea datelor obținute în urma interogă rilor în baza de date se face cu
ajutorul unor metode deasemenea specifice pentru fiecare tabel, metode care sunt apelate
în program ori de câte ori este nevoie de date din acel tabel. Toate aceste metode sunt
cuprinse in folderul intitulat DATA, iar numel e claselor e format din numele
tabelului+DATA. UtilizatoriDATA.cs de exemplu. In INFO gasim maparea tabelului
Utilizatori sub forma Utilizatori.cs . Mai jos se afla metoda GetTipMedicament_ByID.
public static List<Tip_medicament > GetTipMedicament_ByCatego rie(string nume_categorie)
{
List<Tip_medicament > lstMed = new List<Tip_medicament >();

SqlConnection con = new SqlConnection (ConnectionClass .stringConnection);
SqlCommand cmd = new SqlCommand ();
con.Open();
try
{
cmd.Connection = con;
cmd.CommandType = CommandType .StoredProcedure;
cmd.CommandText = "GetTipMedicament_ByCategorie" ;
cmd.Parameters.AddWithValue( "@nume_Categorie" , nume_categorie);

SqlDataReader reader = cmd.ExecuteReader();

while (reader.Read())
{
Tip_medicament ob = new Tip_medicament ();
ob.id_tip_medicament = Convert.ToInt32(reader[ "id_tip_medicament" ]);
ob.id_categorie = Convert.ToInt32(reader[ "id_categorie" ]);
ob.nume_tip_medicament = reader[ "nume_tip_medicament" ].ToString();
ob.descriere = reader[ "descriere"].ToString();

50 lstMed.Add(ob);
}
}
catch (Exception e)
{
// eroare
con.Close();
}
finally
{
con.Close();
}

return lstMed;
}
Fig. 4. 4. Funcția care returneaza tipul medicamentului după categorie medicament
Nivelul de prezentare reprezintă nivelul de interfață grafică al aceste aplicații, iar pentru
implementarea lui s-au folosit elemente specifice de interfață grafică din Visual C#, de
exemplu comboBox -uri, TextBox -uri, Form -uri, GroupBox, StripMenu, GridBox, Label,
Picture . Acestea sunt disponibile in cadrul WindowsFormApplication C#.

51 4.3 Concluzii

Aplicația Sistem Informatic de gestiune a unui D epozit de Produse F armaceutice
a fost proiectată pentru a gestiona și programa eficient comenzile unui depozit care se
ocupă cu vânzarea de produse farmaceutice .
Caracteristicile principale ale sistemului i nformatic sunt:
 Sistemul este proiectat să se ocupe doar de partea de programare pentru a gestiona
vânzarea de produse farmaceutice către clienți și de a gestiona stocul de produse
farmaceutice .
 Activitățile economice sau de gestiune a personalului sunt i gnorate în ace astă
aplicație.
 În funcție de poziția ocupată în sistem, fiecare utilizator are acces partajat la
informații. Fun cțiile sunt definite în diagrama cazurilor de utilizare.
 În această aplicație am pus accent pe funcționalitatea gestiunii bazei d e date .

Pentru securitatea la logare, am inclus în baza de date în câmpul parolă ,
valoarea hash -ului ob ținut în urma conversiei MD5Hash, care la logare este
comparat cu hash -ul ob ținut prin conversie, luat din textboxul de parol ă.
Aplica ția poate s ă fie îmbun ătățită. Eu am încercat s ă creez baza de
plecare. Se poate pune accent pe securizarea datelor și accesul diferit la date, se
poate crea o arhitectur ă a bazei de date bazat ă pe un model Client -Server sau
RPC, poate s ă fie conectată ba za de date la un m icrocontroler cu senzor de
temperatura, umiditate, fum etc. Pot s ă fie ad ăugate multe func ționalit ăți.
Este o ap licație interesant ă și util ă ce poate s ă fie extins ă în func ție de
dorin țele și nevoile clientului.

52 BIBLIOGRAFIE

[1] http://www.zf.ro/infografice/evolutia -pietei -farmaceutice -din-romania -in-perioada –
1999 -2015 -6103941/poze/
[2] Ralph H. Sprague, Barbara C. McNurlin, Infor mation Systems Management in
Practice, 4th edition, Prentice Hall, 1998, p.2, p.33, p.60
[3] Dr. ing. Ioan Străinescu, ,,Curs de Informatică și Tehnologia Informației”
(http://ebo oks.unibuc.ro/informatica/info/Capitolul 204.htm )
[4] Elizabeth Hardcastle, ,,Business Information Systems”, Editor Bookboon 1997
[5] Roșca I. – „Proiectarea sistemelor informatice financiar contabile ”, Ed.Didactică și
Pedagogică, București, 1993
[6] Chindea M. E. – “Proiectarea sistemelor informatice economice ”, București, 1999
[7] C. J. Date, „Baze de Date ”, Ed. Plus, București, 2002
[8] Dorin Lixandroiu , Radu Lixandroiu – “Baze de date relationale ” , Brasov 2009
[9] Mocian I. – „Baze de date -pentru uz ul studenților ”, Ed.Universității “Petru Maior”,
Târgu -Mureș, 2008
[10] Ileana S tefan –“ Analiza și proiectarea sistemelor informatice “, Tirgu mures, 2007
[11] Bocu. D., Bocu. R. – „Modelare orientată obiect cu UML ”, Ed. Albastră, Cluj –
Napoca, 2007
[12] James R. Groff and Paul N. Weinberg, „SQL: The Complete Reference”,
Osborne/McGraw -Hill © 1999
[13] Mark McIlroy “SQL Essentials” – Blue Sky Technology , 2009
[14] Sasu L. – Visual C#, 2005
[15] Udrică M. – “Modelarea orientată obiect ”, Ed. Cison, Bucureșt i, 2000
[16] Florescu V., P.Nastase, F.Berbec – Baze de date – fundamente teoretice si practice ,
Editura Infomega, Bucuresti, 2002;