Proiectarea Sistemelor Informaționale

Ministerul Educației al Republicii Moldova

Universitatea Tehnica a Moldovei
Facultatea CIM
Catedra TI

Proiect de curs
Disciplina:”Proiectarea Sistemelor Informaționale”
Tema:“Analiza și Modelarea unei aplicații – “ Bază de Date”

A efectuat: student gr. TI-111 fr Vasilachi Denis

A verificat: lector superior Melnic Radu

Chișinău 2014

Cuprins
INTODUCERE .............................................................................................................................................................. 1

0
Proiectarea Sistemelor Informaționale

1.1.Analiza si conceperea sistemelor informationale ................................................................................................ 4

1.2.Limbajul UML ....................................................................................................................................................... 4
1.3.Componente de baza ale limbajului UML ............................................................................................................ 4
1.4. Structura generală a limbajului UML .............................................................................................................. 5
1.5.Diagrame UML ................................................................................................................................................. 5
2.1. Descrierea sistemului modelat .......................................................................................................................... 6
2.2.1 Diagrama caz-utilizare....................................................................................................................................... 6
2.2.2 Diagrama de secvență ..................................................................................................................................... 11
2.2.3 Diagrama de colaborare.................................................................................................................................. 15
2.2.4 Diagrama claselor............................................................................................................................................ 17
2.2.5 Diagrama de stări ............................................................................................................................................ 20
2.2.6 Diagrama de activități ..................................................................................................................................... 23
2.2.8 Diagrama de plasare ....................................................................................................................................... 27
Concluzie: ................................................................................................................................................................. 27
Bibliografie: .............................................................................................................................................................. 28
_Toc356571790

1
Proiectarea Sistemelor Informaționale

INTODUCERE

Analiza si modelarea sistemelor informationale comporta o varietate mare de activitati si

manipularea unor mari volume de informatii. Scopul final este realizarea sistemului informational bazat
pe un sistem de prelucrare automata a datelor, integrat.

Sistemul informational trebuie sa se realizeze pe baza unei analize amanuntite a sistemului condus si a
sistemlui de conducere.

Sistemul informaţional cuprinde ansamblul informaţiilor interne şi externe utilizate în cadrul lui
precum şi datele care au stat la baza obţinerii lor, procedurile şi tehnicile de obţinere a informaţiilor
(plecând de la datele primare) şi de difuzare a informaţiilor, precum şi personalul implicat în culegerea,
transmiterea, stocarea şi prelucrarea datelor.

Modelarea parte esentiala in orice proiect software, in special in proiectele mari.

Modelele sunt : - reprezentari abstracte ale sistemului

- create in etapele care preced codificarea:

Analiza si specificarea cerintelor,

Proiectarea arhitecturala

Proiectarea de detaliu

- utilizate: inainte de codificare: pentru a verifica daca toate cerintele utilizatorilor sunt
acoperite, daca functiile prevazute sunt complete si corect modelate, daca arhitectura este
robusta si extensibila.

- dupa codificare, pentru verificarea si validarea sistemului.

Modelele de definitie si analiza a cerintelor:

• exprima cerintele impuse sistemului

• corespund unei vederi externe asupra sistemului

• se folosesc de catre client, viitorii utilizatori ai sistemului, experti ai domeniului

aplicatiei, analisti, echipa de verificare si validare a sistemului.

Modelele de proiectare:

• redau arhitectura sistemului, alocarea cerintelor pe subsisteme, distributia proceselor in sistem,

sincronizarea lor

• realizarea fizica a sistemului, echipamentele din componenta sa si repartitia

componentelor program pe diferite componente hardware

2
Proiectarea Sistemelor Informaționale

In etapa de proiectare se construiesc modele care redau arhitectura sistemului, alocarea cerintelor
pe subsisteme, distributia proceselor in sistem, sincronizarea lor, starile si tranzitiile intre stari. Alte
modele descriu realizarea fizica a sistemului, echipamentele din componenta sa si repartitia
componentelor program.

Principalele scopuri ale modelarii sistemelor informatiionale sunt:

- vizualizarea, ca mijloc de usurare a comunicarii si intelegerii;

- specificarea, prin construirea de modele precise, neambigue si complete;
- documentarea cerintelor, a solutiilor de proiectare si a modului de realizare.

În faza de proiectare logică se efectuează deplasarea atenției de la prezentarea a ceea ce există si ce

se intenționează la desdescrierea a ceea ce va însemna noul sistem și cum va functiona. Prezentarea
nouui sistem constă in prezentarea tuturor intrărilo sistemului, a iesirilor, precum si a interfetelor si
dialogurilor.

Proiectarea fizică este cunoscută și sub numele de proiectare de detaliu. In timpul proiectării
logice se prezintă o imagine generală a sistemului, in timp ce proiectarea fizică inseamnă o abordare
detaliată a sistemului. Cu alte cuvinte, in etapa de proiectare logică se acumulează informațiile de natură
să sintetizeze cerințele utilizatorilor noului sistem, operatiune prestatî de analistii de sistem, iar in timpul
proiectării fizice se prezintă punctele de vedere ale specialiștilor, cum ar fi cei din domeniul
programării, securității sistemelor, rețelelor, etc.

3
Proiectarea Sistemelor Informaționale

1.1. Analiza si conceperea sistemelor informationale

În viata noastra de zi cu zi, calculatoarele sunt ceva obisnuit, ba chiar indinspensabil în unele
cazuri. Se poate spune, pe drept cuvânt ca traim într-o societate informatizata . Peste tot sunt
calculatoare, legate eventual între ele si formând astfel retele de calculatoare. Toate acestea se datoreaza
faptului ca ne dam seama din ce în ce mai mult ca PC-ul ne usureaza munca. Dar trebuie de subliniat
faptul ca un calculator este de fapt o "masinarie" care prelucreaza o serie de informatii pe care i le
dam.
Informatia, este elementul esential din acest întreg lant. De fapt, în practica întâlnim, printre altele, doua
concepte legate de aceasta si anume sistemul informational si sistemul informatic.

Sistemul informational este ansamblul de elemente implicate în procesul de colectare, transmisie,

prelucrare, etc. de informatii.

Rolul sistemului informational este de a transmite informatia între diferite elemente . De exemplu, în
cadrul unei unitati economice, roulul sistemului informational este de a asigura persoanele din
conducere cu informatii necesare pentru luarea diferitelor decizii economice sau de alta natura..

În cadrul sistemului informational se regasesc : informatia vehiculata, documentele purtatoare de

informatii, personalul, mijloace de comunicare, sisteme de prelucrare a informatiei, etc.

Printre posibile activitati desfasurate în cadrul acestui sistem, pot fi enumerate :achizitionarea de
informatii din sistemul de baza, completarea documentelor si transferul acestora între diferite
compartimente, centralizarea datelor, etc.

În cadrul sistemului informational, majoritatea activitatilor se pot desfasura cu ajutorul tehnicii de

calcul. Se pot prelucra datele primare si apoi, rezultatul poate fi transferat mai departe, catre alt
compartiment spre prelucrare.Transferul se poate face si el pe cale electronica, prin intermediul unei
retele de calculatoare sau cuajutorul modemului.

Ansamblul de elemente implicate în tot acest proces de prelucrare si transmitere a datelor pe cale
electronica alcatuiesc un sistem informatic.

Într-un sistem informatic pot intra : calculatoare, sisteme de transmisie a datelor, alte
componente hardware, softwer-ul, datele prelucrate, personalul ce exploateaza tehnica de calcul , teoriile
ce stau la baza algoritmilor de prelucrare, etc.

4
Proiectarea Sistemelor Informaționale

1.2. Limbajul UML

Unified Modeling Language (prescurtat UML) este un limbaj standard pentru descrierea
de modele și specificații pentru software. Limbajul a fost creat de către consorțiul Object Management
Group (OMG) care a mai produs printre altele și limbajul de programare CORBA. UML a fost la bază
dezvoltat pentru reprezentarea complexității programelor orientate pe obiect, al căror fundament este
structurarea programelor pe clase, și instanțele acestora (numite și obiecte). Cu toate acestea, datorită
eficienței și clarității în reprezentarea unor elemente abstracte, UML este utilizat dincolo de domeniul
IT. Așa se face că există aplicații ale UML-ului pentru management de proiecte, pentru business
Process Design etc.

Istoria dezvoltării limbajului UML începe în luna octombrie a anului 1994, cînd Grady Booch şi James
Rumbaugh din Rational Software Corporation au început să lucreze împreună asupra unificării
metodelor Booch şi OMT. Cu toate că aceste metode fiecare în parte erau destul de cunoscute, lucrul în
comun era organizat pentru cercetarea tuturor metodelor OO cu scopul unificării celor mai avantajoase
trăsături ale lor. Proiectul acestei aşa zise metode unificate (Unified Method) versiunea 0.8 a fost
pregătit şi publicat în luna octombrie anului 1995. În toamna aceluiaşi an a aderat la ei şi Iv. Jacobson,
tehnologul principal al companiei Objectory AV (Suedia), cu scopul integrării metodei sale OOSE cu
celelalte două precedente.

1.3. Componente de baza ale limbajului UML

Limbajul UML reprezintă limbajul de destinaţie generală al modelării vizuale, care este elaborat
pentru specificarea, vizualizarea, construirea şi documentarea componentelor produsului soft, business-
proceselor şi altor sisteme. Totodată limbajul UML este un mijloc de modelare simplu şi puternic care
poate fi utilizat efectiv pentru construirea modelelor conceptuale, logice şi grafice ale sistemelor
complexe de diferită destinaţie. Acest limbaj conţine cele mai bune calităţi ale metodelor ingineriei de
program care au fost utilizate cu succes pe parcursul ultimilor ani la modelarea sistemelor complexe.

Limbajul UML este bazat pe un anumit număr de noţiuni principale care pot fi studiate şi aplicate de
către majoritatea programiştilor şi elaboratorilor cunoscuţi cu metodele de analiza şi proiectarea obiect
orientate. Totodată noţiunile de bază pot fi combinate şi extinse în asa fel că specialiştii modelării
orientate pe obiecte pot elabora de sinestătător modele ale sistemelor complexe în diferite domenii de
aplicare.

Utilizarea constructivă a limbajului UML este bazată pe inţelegerea principiilor comune de

modelare a sistemelor complexe şi a particularităţilor procesului de analiza şi proiectarea obiect
orientate. Alegerea mijloacelor expresive pentru construcţia modelelor ale sistemelor complexe
stabileşte din vreme problemele care pot fi rezolvate cu ajutorul utilizării acestor modele. Totodată unul
din principiile de bază pentru construirea modelelor ale sistemelor complexe este principiul de
abstractizare care presupune includerea în model numai a acelor aspecte ale sistemului proiectat, care au
nemijlocit legătura cu executarea de către sistem a funcţiilor sale sau cu destinaţia lui de baza. Totodată
toate detalii de importanţa secundară sunt omise pentru ca procesul de analiza şi cercetare a modelului
primit să nu fie foarte complicat.

5
Proiectarea Sistemelor Informaționale

1.4. Structura generală a limbajului UML

UML constă din două parţi interdependente:

 Semantica limbajului UML reprezintă un careva metamodel, care defineşte sintaxa abstracta şi
semantica noţiunilor modelării orientate pe obiecte în limbajul UML.

 Notaţia limbajului UML reprezintă o notaţie grafica pentru reprezentarea vizuală a semanticii
limbajului UML.

Sintaxa abstractă şi semantica limbajului UML sunt descrise cu ajutorul unei anumite submulţimi de
notaţii ale UML. În completare la aceasta, notatia UML descrie corespunderea sau reprezentarea notaţiei
grafice în semantica noţiunilor de baza. În aşa fel din punct de vedere funcţional aceste două părţi
completează una pe altă. Totodată semantica limbajului UML este descrisă pe baza unui metamodel care
are trei reprezentări aparte: sintaxa abstractă, reguli de construcţia corectă a expresiilor şi semantica.
Cercetarea semanticii limbajului UML presupune un careva stil semiformal de redare, care unifica
limbaje naturale şi formale pentru reprezentarea noţiunilor de baza şi regulilor de extindere a lor.

Semantica se defineşte pentru două tipuri de modele de obiecte: de structura şi de comportare. Modelele
de structură, cunoscute ca modele statice, descriu structura entităţilor sau a componentelor unui sistem
inclusiv clase, interfeţe, atribute şi relaţii. Modelele de comportare, numite uneori dinamice, descriu
comportarea sau funcţionarea obiectelor unui sistem, inclusiv metodele lor, colaborarea între ele, şi
procesul de schimbare a stărilor unor componente aparte şi al sistemului întreg.

Dicţionarul limbajului înclude trei tipuri de construcţii de bază:

 entităţi – abstracţii ce sunt elemente de bază a modelului;

 relaţii – legături între entităţi;
 diagrame ce grupează interesele entităţilor şi relaţiilor.

1.5. Diagrame UML

În cadrul limbajului UML toate reprezentările modelului unui sistem complex sunt fixate în calitate de
construcţii speciale grafice care deseori sunt reprezentate sub formă de graf conex cu noduri – entităţi şi
muchii – relaţii. În UML sunt definite nouă tipuri de diagrame:

 Diagrame cazurilor de utilizare (use case diagram)

 Diagrame de clase (class diagram)
 Diagrame de comportament (behavior diagrams)
o Diagrame de stări (statechart diagram)
o Diagrame de activităţi (activity diagram)
o Diagrame de interacţiune (interaction diagrams)
 Diagrame de secvenţă (sequence diagram)
 Diagrame de colaborare (collaboration diagram)
 Diagrame de realizare (implementation diagrams)
o Diagrame de componente (component diagram)
o Diagrame de plasare (deployment diagram)
6
Proiectarea Sistemelor Informaționale

2.1. Descrierea sistemului modelat

Model al unui sistem complex în notaţia UML.

Fiecare din aceste diagrame detalizează şi concretizează diferite reprezentări despre modelul
unui sistem complex în termenii limbajului UML. Totodată diagrama cazurilor de utilizare reprezintă cel
mai general model conceptual al unui sistem complex care este iniţial pentru construirea tuturor
celorlalte diagrame. Diagrama de clase este un model logic care reflectă aspectele statice ale procesului
de construire structurală a unui sistem complex.

Diagramele de comportament la fel sunt varietăţi ale unui model logic care reflectă aspectele
dinamice ale procesului de funcţionare a unui sistem complex. Diagramele de realizare sunt destinate
reprezentării fizice a componentelor sistemului complex şi de aceea sunt atribuite modelului fizic.

2.2.1 Diagrama caz-utilizare

Descriere generala.

Proiectarea a unei diagrame a cazurilor de utilizare urmăreşte scopurile următoare:

 determinarea limitelor comune şi a contextului domeniului de modelare la etapele iniţiale de

proiectare a unui sistem;

 formularea cerinţelor comune către comportare funcţională a sistemului proiectat;

7
Proiectarea Sistemelor Informaționale

 elaborarea modelului iniţial conceptual al unui sistem pentru detalierea de mai tîrziu în forma
modelelor logice şi fizice;

 pregătirea documentărei iniţiale pentru interacţiunea elaboratorilor unui sitem cu clienţii şi

utilizatorii.

Esenţa acestei diagrame constă în faptul că: sistemul proiectat se reprezintă ca o colecţie de entităţi şi
actori care colaborează cu sistemul cu ajutorul aşa numitor cazuri de utilizare.

Cazul de utilizare deteremina o succesiune de actiuni care trebuie sa fie executate de catre sistemul
proiectat la colaborarea lui cu un anuimt actor.

Scopul cazului de utilizare constă în determinarea aspectului terminal sau fragmentului de comportare a
unei entităţi fără desfăşurarea structurii interne a acestei intităţi. În calitate de aşa entitate poate fi un
sistem iniţial sau un element al modelului care dispune de comportament propriu, precum este
subsitemul sau clasa în modelul unui sistem.

Actorul reprezintă orice entitate externă sistemului modelat, care colaborează cu sistemul şi utilizează
posibilităţile lui funcţionale pentru atingerea anumitor scopuri şi pentru rezolvarea problemelor
particulare.

Interfaţa (interface) specifică parametrii modelului care sunt vizibili din afară fără indicarea structurii lor
interne. În limbajul UML interfaţa este clasificatorul care caracterizeză numai o parte limitată a
comportării unei entităţi modelate.

Intre interfata si c-u putem folosi 2 relatii: - asocierea

- dependenta.
Relatiile diagramei caz-utilizare:
1) actor-actor: - dependenta, - genaralizare.
2) Actor-C_u: - asocierea.
3) C_u – C_u: - dependenta /stereotipuri/:”include”, ”extend”, ”depends”

8
Proiectarea Sistemelor Informaționale

Diagrama caz de utilizare 1:

Diagrama cazurilor de utilizare pentru funcționalitatea bazei de date.

Această diagramă caz de utilizare explică funcționalitatea bazei de date. Software-ul oferă următoarele
opțiuni: Creare conturi, atribuire drepturi utilizatorilor. Relația de tipul "include" înseamnă că
completă și mai necesită niște cazuri de utilizare.

Clasificatoarele rămase: Modifică cont, Căutare date, de acces la date și ghidul sunt de tip "extended"
prin urmare, reprezintă opțiuni suplimentare (acțiuni) pentru utilizatori.

9
 Proiectarea Sistemelor Informaționale

Diagrama caz de utilizare 2:

Cerințele externe și funcționalitățile oferite de aceasta pentru utilizatorul final

Aceasta diagrama a cazurilor de utilizare descrie cerințele externe pentru aceast subiect și
funcționalitățile oferite de acesta la utilizator . Relația dintre administrator și utilizator, precum și între
utilizator și user oferă o înțelegere clară, că tipurile de actori administrator și de user moștenesc
proprietățile și comportamentul în cazul utilizării părinte utilizator și poate trece peste comportamentul
părintelui. O relație de asociere între un actor și unul sau mai multe cazuri de utilizare indică faptul că
actorul și cazul de utilizare comunica unul cu celălalt.

10
Proiectarea Sistemelor Informaționale

Diagrama caz de utilizare 3:

Descrierea detailata a functionalitatii clasificatorului de modificare a contului.

Această diagramă reprezintă gama detaliat funcționarea modulului modificarea contului. Acesta
include următoarele acțiuni: Pornire calculator, autentificare, accesați contul și salvați modificările. Se
extinde următoarele acțiuni: a anula acțiunea, ghid de utilizare. Acțiuni autentifica și accesa contul
depinde de următoarele acțiuni: Verificarea autentificarii și verificarea drepturilor utilizatorilor.

11
Proiectarea Sistemelor Informaționale

Diagrama caz de utilizare 4:

Digrama de mai jos descrie procedura de introducere a unui pacient nou.

Aceasta diagrama descrie toate actiunile pe care le indeplineste un utilizator (actor) pentru a
vizualiza date . Ea include: nume, prennume, patronimic, data nasterii, legatura cu institutia. Extinde
date Public si Private.

12
Proiectarea Sistemelor Informaționale

Diagrama caz de utilizare 5:

Diagrama de mai jos descrie meniul principal al utilizatorului.

Diagrama cazului de utilizare a meniului descrie submeniul programare, registre care la fel mai
contine submeniuri.

13
Proiectarea Sistemelor Informaționale

2.2.2 Diagrama de secvență

Descriere generală

Diagrama de secvență – colaborarea dintre obiecte poate fi studiată în timp și deci putem vedea
schimbul de mesaje din sus în jos și de la stînga la dreapta.

În diagrama de secvenţă se reprezintă numai obiectele care acţionează şi nu se reflectă asocierile

statice cu alte obiecte. Pentru diagrama de secvenţă momentul principal este dinamica colaborării între
obiecte în timp. Grafic fiecare obiect se reprezintă printr-un dreptunghi şi se plasează în partea de sus a
ciclului său de viaţă (fig. 1). În înteriorul dreptunghiului se indică numele obiectului şi numele clasei
despărţite prin două puncte. Totodată toată înregistrare se subliniază, ce indică că obiectul este
exemplarul unei clase. În caz dacă numele obiectului lipseşte, atunci se indică numai numele clasei şi
obiectul se consideră anonim.

Fig. 1. Primitivele grafice ale diagramei de secvenţă.

Linia de viaţă a obiectului (object lifeline) se reprezintă printr-o linie verticală punctată asociată
cu un singur obiect în diagrama de secvenţă. Linia de viaţă defineşte intervalul de timp în care obiectul
există şi interacţionează cu sistemul dat.

Pentru a evidenţia obiectele active în limbajul UML se utilizează notaţia specială – focus control (focus
of control).

Fiecare legătura se descrie cu o totalitate de mesaje transferate cu care obiectele-participante se schimbă.

În acest sens mesajul (messaje) reprezintă un fragment de informaţie care este transferat de către un
obiect altuia.

Stereotipuri:
 call" – invocă o operaţie sau procedură a obiectului-destinatar;
 "return" – returnează valoarea operaţiei executate obiectului apelant;
 "create" – crează alt obiect pentru executarea anumitor acţiuni;
 "destroy" – distruge un obiect. Se transmite în caz dacă este necesar a termina acţiunile din
partea obiectului existent sau dacă obiectul trebuie să elibereze resursele alocate;
14
Proiectarea Sistemelor Informaționale

 "send" – trimite un semnal unui obiect care se iniţializează asincron de către un obiect şi este
acceptat de altul. Diferenţa între un semnal şi un mesaj constă în fapt că semnalul trebuie să fie
descris în clasa obiectul căreia iniţializează transmiterea lui.

Diagramele de secvență 1:

Diagrama de secventa de mai jos reprezinta interactiunea intre administrator si baza de date. Putem vedea
clar toate legaturile dintre obiecte si schimbul de mesaje care are loc.

15
Proiectarea Sistemelor Informaționale

16
Proiectarea Sistemelor Informaționale

17
Proiectarea Sistemelor Informaționale

Diagramele de secvență 2:

In cea de-a doua diagrama este descrisa pas cu pas cautarea informatiei in baza de date de catre
administrator.

18
Proiectarea Sistemelor Informaționale

19
Proiectarea Sistemelor Informaționale

Diagramele de secvență 3:

Diagrama descrie pas cu pas cautarea informatiei in baza de date de catre

utilizator.

Diagramele de secvență 4:

20
Proiectarea Sistemelor Informaționale

Diagrama descrie pas cu pas introducerea unei informatii baza de date de catre utilizator.

21
Proiectarea Sistemelor Informaționale

22
Proiectarea Sistemelor Informaționale

2.2.3 Diagrama de colaborare

Descriere generală

Particularitatea principală a diagramei de colaborare constă în posibilitatea de a reprezenta grafic

nu numai consecutivitatea colaborării dar şi toate relaţii structurale între obiecte. În primul rînd în
diagrama de colaborare sub formă de dreptunghiuri se reprezintă obiectele care conţin numele
obiectului, clasei, valorile atributului. Mai departe, ca şi în diagrama de clase se indică asocierile între
obiecte sub forma de linii de conectare. Totodată pot fi indicate numele asocierilor şi al rolurilor
obiectelor pentru asocierea dată.

Obiectul (object) este un exemplar aparte al clasei care este creat la etapa executării a unui program. El
poate avea un nume propriu şi valorile atributelor. Referitor la obiecte formatul liniei ce conţine
clasificatorul se completează cu numele obiectului:

<Numele obiectului>'/' <Numele rolului al clasificatorului> ':' <Numele clasificatorului>

Multiobiect (multiobject) reprezintă o mulţime de obiecte în una din terminaţiile asocierei

Obiectul activ (active object) are un fir (thread) de control propriu şi poate iniţializa activitatea de
control. Totodată sub noţiune de fir se subînţelege un anumit flux de control care poate fi executat în
paralel cu alte fire de calcul sau cu fire de control în cadrul unui proces de calcul sau control.

1: create
a : Abonatul c:
arogant Conectare

Obiectul compus (composite object) sau obiectul-container este destinat pentru reprezentarea obiectului
care are structura proprie şi fire interne de control. Obiectul compus este exemplarul clasei compuse
care este legat cu parţile sale prin relaţii de agregare sau compoziţie. Relaţii analogice leagă obiectele
respective.

Tipul de legătura se înscrie lînga terminaţia ei şi indică posibilitatea realizării acestei legături. În
limbajul UML pentru acest scop se utilizează:

 "association" – asociere (se presupune implicit, de aceea acest tip poate să nu fie indicat).
 "parameter" – parametrul metodei.
 "local" – variabila locală a metodei.
 "global" – variabila globală. Domeniul ei de vizibilitate este toată diagrama de colaborare.
23
Proiectarea Sistemelor Informaționale

 "self" – legătura reflexivă a obiectului care presupune transferul mesajelor către sine. În diagrama de
colaborare legătura reflexivă se reprezintă în formă de buclă în partea de sus al dreptunghiului obiectului.

Diagrama de colaborare 1:

Diagrama de colaborare 1 reprezinta interactiune intre administrator si baza de date in timpul cind
el creaza un cont nou.

Diagrama de colaborare 2:

24
Proiectarea Sistemelor Informaționale

Diagrama de colaborare de mai jos reprezinta interactiune intre utilizator si baza de date in timpul
cind el cauta informatie.

Diagrama de colaborare 3:

25
Proiectarea Sistemelor Informaționale

Diagrama de colaborare 3 reprezinta interactiune intre utilizator si baza de date in timpul cind el
creaza cartela pentru un pacient nou.

2.2.4 Diagrama claselor

26
Proiectarea Sistemelor Informaționale

Descriere generală

Diagrama de clase (class diagram) se utilizează pentru reprezentarea structurii statice a unui
modelde sistem in terminologia claselor programării OO. Diagrama de clase poate reflecta diferite
legăturiintre entităţile domeniului de obiecte (obiecte şi subsisteme) şi descrie structura lor internă
şitipurile de relaţii.

Diagrama de clase reprezintă un graf cu noduri – elemente de tip ≪clasificatori≫ care sunt
legateprin diferite tipuri de relaţii de structură. Trebuie de menţionat că diagrama de clase poate conţine
interfeţe, pachete, relaţii şi chiar exemplare, aşa ca obiecte şi legături.

Clasa (class) in limbajul UML defineşte totalitatea de obiecte care au aceeaşi structură,
comportament şi relaţii cu obiectele din alte clase.

Numele clasei trebuie să fie unic in cadrul pachetului, care este descris de către o totalitate de
diagrame de clase. Numele se indică in prima secţiune de sus a dreptunghiului.

In a doua secţie a dreptunghiului de clasă se inscriu atributele lui sau prorietăţile. Fiecărui atribut de
clasăii corespunde rindul textului, care este format din specificatorul de vizibilitate a atributului,
numeluilui, tipul sensului şi, posibil sensul final:

<<specificatorul de vizibilitate>> <<numele atributului>> [multiplicitate]:

<<tipul atributului>>=<<sensul final>> {aliniat-proprietate}

Specificatorul de vizibilitate poate primi unul dintre cele trei sensuri şi concomitent reflectă cu
ajutorul simbolurilor speciale:
· Simbolul + inseamnă atributul cu regiunea de vizibilitate de tip public (public).
· Simbolul #. inseamnă atributul cu regiunea de vizibilitate de tip protecţie (protected).
· In sfirşit, simbolul – atributul cu regiunea de vizibilitate tipului privat. (private).

In a treia secţie a dreptunghiului de clasă se inscriu operaţii sau metodele clasei. Operaţia
(operation) prezintă un anumit serviciu, care prezintă fiecare exemplar al clasei după anumită cerinţă.
Totalitatea de operaţii caracterizează un aspect funcţional in comportamentul clasei.

Relaţiile de bază şi legăturile sunt:

· Relaţia de dependenţa (dependency relationship) // stereotipurile:

27
Proiectarea Sistemelor Informaționale

· <<access>> – serveşte ca indicator de accesibilitate unor atribute şi operaţii clasei – sursă

pentru clase–clienţii;
· <<bind>> – clasa–client pote utiliza careva şablon pentru următoarea parametrizare;
· <<derive>> – atributul clasei – client poate fi calculat după atributele clasei – sursă;
· <<import>> – atribute deschise şi operaţii publice clasei – sursă devine o parte a clasei – client
· <<refine>> – indică că clasa – client serveşte ca precizie a clasei

· Relaţia de asociere (association relationship)

· Relaţia de generalizare(generalization relationship) //
{complete},{incomplete},{disjoint},{overlapping}.
- Relaţia de realizare(realization relationship)

Diagrama de clase 1:

In diagrama data sunt ilustrate relatiile intre urmatoarele clase: utilizator, baza de date, si
modificare cont. Clasele sunt create inpreuna cu atributele si metodele sale. Deasemena este inclusa
interfata aplicatiei.

Diagrama de clase 2:

28
Proiectarea Sistemelor Informaționale

In diagrama data sunt ilustrate relatiile intre urmatoarele clase: utilizator, creare cont. Clasele sunt
create inpreuna cu atributele si metodele sale. Deasemena este inclusa interfata aplicatiei.

Diagrama de clase 3:
29
Proiectarea Sistemelor Informaționale

In diagrama 3 sunt ilustrate relatiile intre urmatoarele clase: utilizator, pacient, cauta pacient si pacient
nou. Clasele sunt create inpreuna cu atributele si metodele sale.

2.2.5 Diagrama de stări

Descriere generală

Diagrama de stari descrie procesul de modificare a starilor pentru o anumita clasa.

Această diagramă este folosită pentru descrierea consecutivităţilor de stări posibile şi trecerilor, care in
ansamblu caracterizează comportamentul elementelor modelului in timpul ciclului de viaţă. Diagrama
de stări reprezintă comportamentul dinamic a entităţilor in baza specificaţiei reacţiei lor la perceperea
căror-va evenimente concrete.

Un automat – reprezinta o diagram de stari .

Elementele de baza : - starile si – tranzitiile.

Starea (state) poate fi in formă de valori concrete a atributului clasei sau obiectului, in acest caz
modificarea anumitelor valorilor va respinge modificarea clasei modelate sau obiectului.

fig1. Representarea starilor.

30
Proiectarea Sistemelor Informaționale

Numele stării reprezintă aliniat de text, care dezvăluie sensul stării date. Numele este intodeauna
scris cu litera majusculă.

Pseudo stari : initiala si finala .

Fiecare tranziţie poate fi marcată cu aliniat de text, care are următorul format general:
<signatura evenimentului>'['<condiţia de pază>']' <exprimarea acţiunii>.

Termenul eveniment (event) trebuie explicat aparte, deoarece el este un element independent al
limbajului UML. Opţional evenimentul reprezintă specificaţia anumitui fapt, care are ataşată o locaţie in
timp şi in spaţiu.

Condiţia gardă (guard condition), dacă există, atunci intodeauna este scrisă in paranteze dreptungiulare
după evenimentul – triger şi reprezintă expresie buleană.

Expresia acţiunii (action expression) se execută atunci şi numai atunci cind se execută tranziţia.
Reprezintă operaţia atomică, care se execută după efectuarea tranziţiei respective inainte de oricare
acţiune in starea obiectivă.

Diagrama de stare 1:
In diagrama data sunt reprezentate starile, ce reprezinta baza de date pentru un utilizator de
tip administrator. Acesta descrie tranzițiile între toate stările posibile, și descrie condițiile în
care acestea apar.

31
Proiectarea Sistemelor Informaționale

Diagrama de stare 2:
Această diagramă de stare reprezintă starile cind aplicatia bazei de date cind este logat un
utilizator. Acesta descrie tranzițiile între toate stările posibile, și descrie condițiile în care
acestea apar.

32
Proiectarea Sistemelor Informaționale

Diagrama de stare 3:
Această diagramă de stare reprezintă starile cind in aplicatia bazei de date cind este logat
un utilizator cu rol de administrator pentru a sterge un utilizator. Acesta descrie tranzițiile între
toate stările posibile, și descrie condițiile în care acestea apar.
33
Proiectarea Sistemelor Informaționale

2.2.6 Diagrama de activități

Descriere generală

34
Proiectarea Sistemelor Informaționale

In contextul limbajului UML activitatea (activity) reprezintă o totalitate de calcule executate de către
automat. Totodată calculele elementare pot duce la un anumit rezultat sau careva acţiune (action). In
diagrama de activităţi se reflectă logica sau consecutivitatea tranziţiilor de la o acţiune la alta, totodată
se evidenţiază rezultatul activităţii. Rezultatul, la rindul său poate duce la schimbarea stării sistemului
dat sau la returnarea unei valori.

Starea activităţii este un caz particular a stării. Starea activităţii nu poate avea tranziţii interne
fiindcă ea nu este elementară. Starea activităţii se utilizează pentru modelarea unui pas de
executarea a algoritmului (procedurii) sau a unui flux de control.
Grafic starea activităţii se reprezintă printr-o figură asemanatoare cu dreptunghiul, laturile laterale ale
căruia sunt substituite cu arcuri convexe (printr-un dreptunghi cu colţuri rotunjite).

Tranziţia . Laconstruirea diagramei de activităţi se utilizează careva tranziţii netrigere care acţionează
deodată după perfectarea activităţii sau după executarea acţiunii corespunzatoare. Această tranziţie
transmiteactivitatea in următoarea stare imediat după ce se termină acţiunea din starea precedentă. In
diagramă această tranziţie se reprezintă printr-o linie continuă cu o săgeată.

Diagramele de stări pot fi utilizate nu numai pentru specificarea algoritmelor de calculare sau
fluxurilor de control in sistemele de programare. Un domeniu de utilizare este legat cu modelarea
busimes-proceselor.

Pentru modelarea acestor particularităţi in limbajul UML se foloseşte construcţia specială, care
aredenumire de partiţii (swimlanes), care sunt divizate unul cu altul cu linii verticale. Două linii vecine
formează o partiţie, iar un grup de stări intre aceste linii sunt executate de subdiviziunea separată (secţie,
filial, diviziuni) a companiei.

In cazul general acţiunile in diagrama de activitate sunt efectuate cu obiecte. Aceste obiecte sau
iniţializează executarea acţiunelor sau definesc un anumit rezultat a acestor acţiuni. In urma căruia
acţiunile specifică apelurile, care trec de la un obiect a grafului de activitate la altul.

In diagrama de activitate cu partiţii deplasarea obiectelor poate avea un sens adăugător. Şi anume,
dacă obiectul este amplasat la hotarul ambilor partiţii, aceast lucru inseamnă că trecerea la starea de
acţiune următoare in partiţia vecină este asociată cu un document finit (obiectul in care-va stare). Dar
dacă obiectul este amplasat inăuntrul partiţiei, atunci starea acestui obiect este definită de acţiunile
partiţiei date.

35
Proiectarea Sistemelor Informaționale

Diagrama de activitate 1:

In Diagrama data sunt reprezentate toate starile si trazactiile ce se petrec in timpul procesului de
logare si intrare in aplicatie, incepind cu starea initiala si terminind cu cea finala.

36
Proiectarea Sistemelor Informaționale

Diagrama de activitate 2:

Diagrama data reprezinta un business proces, partitiile/subdiviunile/ fiind user-ul, menu-ul aplicatiei si baza
de date. Aici este aratata procedura de schimbare a accountului, ce include in ea alegerea unui nou login,parole,
dupa care urmeaza salvarea tuturor shimbarilor introduse.

37
Proiectarea Sistemelor Informaționale

Diagrama de activitate 3:

In aceasta diagrama este modelat procesul de executare a unei operatiuni in cadrul aplicatiei, optiunea aleasa
este crearea unui cont nou. Cu ajutorul tranzactiilor este aratat schimbul de stari, de la o operatie la alta,
deasemenea sunt incluse si ramificatiile, simbolurile fork si join – care exclud problema reprezentarii ramurior
paralele ale unor calcule.

38
Proiectarea Sistemelor Informaționale

2.2.7 Diagrama de componente

Descriere generală

Diagrama de componente permite determinarea arhitecturii sistemului elaborat prin stabilirea

dependenţei între componentele de program în calitate de care poate fi codul iniţial, binar şi executabil.
În mai multe domenii de elaborare modul şi componenta corespund fişierului. Săgeţile punctate care
leagă modulele arată relaţiile de dependenţa analogice celor ce au loc la compilarea codurilor sursei
iniţiale. Elementul grafic de bază al diagramei de componente sunt componentele, interfeţele şi
dependenţele între ele.

Diagrama de componente se elaborează pentru urmatoarele scopuri:

 Vizualizarea structurii comune a codului sursă a unui sistem de program.

 Specificarea variantei executabile a unui sistem de program.
 Asigurarea utilizării repetate a unor fragmente ale codului sursă.
 Reprezentarea conceptuală şi fizică a schemelor bazei de date.

În metamodelul limbajului UML componentul este descendentul clasificatorului. El reprezintă

organizaţia în cadrul unui pachet fizic cu care el este asociat cu ajutorul elementelor unui model. În
calitate de clasificator componentul poate să aibă aşa proprietăţi ca atribute şi operaţii.

Fig.1. Componenta.

În limbajul UML sunt specificate trei feluri de componente:

 În primul rând componente de regrupare, care specifică executarea de către sistem a funcţiilor sale. Aşa
fel de componente pot fi librării conectate dinamic cu extensia .dll
(fig. 69, a), Web – pagini în limbajul de trasare hipertextului cu extensia .html (fig. 69, b) şi fişierele de
adeverinţă cu extensia .hip (fig. 69, c).
 În al doilea rînd, componente – produse de lucru. Ca regulă acestea sunt fişierele cu texte iniţiale a
programului, de exemplu, cu extensia .h sau .cpp pentru limbajul C++ (fig. 69, d).
 În al treilea rînd, componentele de executare, ce reprezintă modulele – fişierele cu extensia .exe. Ei se
indică obişnuit.

39
Proiectarea Sistemelor Informaționale

Un alt mod de specificare a diferitor feluri componentelor este indicarea steriotipului componentului
înaintea numelui lui. În limbajul UML pentru componente sunt specificate următori steriotipuri:

 Librărie (library) – defineşte prima specie a componentuluui, care reprezentă librărie dinamică
sau statică.
 Tabel (table) – defineşte prima specie a componentului, care reprezentă un tabel de baze de date.
 Fişier (file) – defineşte a doua specie a componentului, care reprezintă un fişier cu texte iniţiale a
programului.
 Document (document) – defineşte a doua specie a componentului, care reprezintă un document.
 Executare (executable) – defineşte a treia specie componentului, care poate fi executat în nod.

Diagrama de componente 1:

Diagrama data descrie arhitectura sistemului, prin stabilirea legaturilor de dependenta intre
componente, si anume componenta de executare /application.exe/, componentele de regrupare
/functions.lib, file- web.aspx/ si baza de date a utilizatorilor.

Diagrama de componente 2:

In aceasta diagrama le fel sunt reprezentate componentele de baza a sistemului, inclusiv si componenta –
PC, la care deasemnea se mai adauga anumite componente cu stabilerea lagaturilor intre ele. componentele
adaugatore sunt file-urile help si libraria user’s service C#.

40
Proiectarea Sistemelor Informaționale

Diagrama de componente 3:

In Diagrama data deja componentele de baza a sistemului ramin aceleasi, la care se adauga
componentele de gruapare si anume librarii si file-uri cu extensia .aspx, .bd desemena cu stabilerea legaturilor
intre ele.

2.2.8 Diagrama de plasare

Descriere generală
41
Proiectarea Sistemelor Informaționale

Diagrama de plasare este specifică pentru vizualizarea elementelor şi componentelor a programului, ce

există numai la etapa executării lui (runtime). În urma căruia sunt prezentate numaicomponente –
exemplare a programului, care sunt fişiere de executare sau librăriile dinamice. Acele componente, care
nu sunt utilizate la etapa executării, în diagrama de plasare nu sunt indicate.

Nodul (node) reprezintă un anumit element fizic a sitemului, care are o anumită resursă de calculare. Ca
resursă de calculare a nodului poate fi o valoarea electronică sau magnitioptică a memoriei sau
procesorului.

Fig. 2. Reprezentarea grafică a nodului în diagrama de plasare.

Dacă este necesar de indicat componentele, care sunt deplasate în nodul separat, atunci pentru această
există două moduri. Primul din ei dă posibilitate de a împărţi simbolul grafic în două secţii cu linie
orizontală. În secţiunea cea de sus este scris numele nodului, iar în cea de jos- componente deplasate la
nodul dat .Al doilea mod permite deplasarea în diagrama de plasare nodurile cu componentele depuse.
Ca componente depuse pot fi numai componentele executante.

Diagrama de plasare descrie reprezentarea generala a configurarii topologiei sistemului. In aceasta

diagrama saunt utilizate relatiile de asociere intre nodurile urmatoare: - device – ce prezinta tipul
statiunii de lucru aceasta poate fi sau telefonul mobil sau calculatorul, applcatia – ce este componenta de
executare si baza de date.

42
Proiectarea Sistemelor Informaționale

43
Proiectarea Sistemelor Informaționale

Concluzie:

Pe parcusul acestui proiect de curs am capatat cunoștințe noi in modelarea vizuala

in limbajul UML. M-am familiarizat cu componentele de baza al limbajului, structura lui
generala, la fel am aflat de notiune de entități in limbajul UML, relații si diagrame.

UML este un instrument standard pentru crearea carcaselor de documentare

(«desenelor») ale produsului soft. UML este un limbaj de vizualizare, specificare,
construcţie şi documentare artefactelor sistemelor de program.

Am inteles cele mai importante principii de modelare a unui sistem si anume

aplicîndu-le în practica prin intermediul diagramelor. Diagramele elaborate sunt:
diagramele caz de utilizare, diagrame de secvență, diagrame de colaborare, diagrama
claselor, diagrame de stare, de activități, de component si de plasare.

Istrumentul de modelare folosit este Enterprise Architect (EA). Platforma dată suporta:
proiectarea și construcția sistemelor de software, procese de afaceri de modelare, precum
și industria de modelare bazate pe domenii.

Enterprise Architect prevede modelarea completă a ciclului de viață pentru:

- software și ingeneria sistemelor;

- afacere si sisteme IT;

- Integrarea dezvoltării in timp real.

Enterprise Architect este un multi-utilizator, instrument grafic, proiectat pentru a ajuta

echipele, construind sisteme puternice și întreținute. Utilizînd calitatea înaltă, intergrarea
reportării si documentării poate oferi o viziune clară si precisă.

44
Proiectarea Sistemelor Informaționale

Integrînd capacitățile de gestionare a cerințelor, Enterprise Architect ajută la urmărirea

specificațiilor la nivel înalt pentru analiza, proiectarea, implementarea, testarea și
întreținerea modelelor folosind UML.

45
Proiectarea Sistemelor Informaționale

Bibliografie:

1. Conspect la disciplina PSI.

2. http://www.sparxsystems.com/

3. http://uml.org/

4. http://it.toolbox.com/blogs/enterprise-solutions/

5. http://en.wikipedia.org/wiki/Unified_Modeling_Language

6. http://www.youtube.com/results?search_query=use+case+diagram+enterprise
&oq=use+case+diagram+enter&gs_l=youtube.3.0.33i21.17615.19276.0.21414.
5.5.0.0.0.0.80.346.5.5.0...0.0...1ac.1.11.youtube.8nGEbVav2Gs

7. http://www.youtube.com/results?search_query=sequence+diagram+enterpris
e+architect+&oq=+diagram+enterprise&gs_l=youtube.1.0.0i5l3.147342.14734
2.0.149447.1.1.0.0.0.0.100.100.0j1.1.0...0.0...1ac.1.11.youtube.nqQG3SuaIXQ

8. http://www.youtube.com/results?search_query=enterprise+architect+tutorial
&oq=enterprise+architect+tu&gs_l=youtube.3.0.0j0i5.95693.151454.0.154012.
4.4.0.0.0.0.105.344.3j1.4.0...0.0...1ac.1.11.youtube.cYrv5Dm8udI

46