Ministerul Educatiei al RM

Universitatea Tehnica din Moldova

Facultatea CIM

Proiect de curs
Disciplina:Analiza și Modelarea Sistemelor Informationale.

Tema:

Executat de st.grupei:

Verificat de:

Chisinau 2012

1
 Cuprins:
Introducere ............................................................................................................................................ 3
1. Analiza si modelarea SI ........................................................................................................................ 5
1.1 Analiza si conceperea sistemelor informaționale......................................................................... ...................5
1.2 Limbajul UML............................................................................................................ ................................... ..6
1.3 Structura generală a limbajului UML............................................................................................................ ..7

2. Descrierea sistemului si Reprezentarea in limbajul UML ................................................................ 8

2.1.Descrierea temei .................................................................................................................................... 8
2.2 Reprezentarea diagramelor in UML................................................................................................... 9
2.2.1 Diagrama caz-utilizare .............................................................................................................. 10
Descriere generala ......................................................................................................................................... 10
Diagramele cazurilor de utilizare .................................................................................................................. 11
2.2.2 Diagrama de secvență ................................................................................................................ 14
Descriere generala ......................................................................................................................................... 14
Diagramele de secvență................................................................................................................................. 15
2.2.3 Diagrama de colaborare ............................................................................................................ 19
Descriere generala ......................................................................................................................................... 19
Diagramele de colaborare ............................................................................................................................. 20
2.2.4 Diagrama claselor ...................................................................................................................... 22
Descriere generala ......................................................................................................................................... 22
Diagramele claselor ....................................................................................................................................... 23
2.2.5 Diagrama de stări ...................................................................................................................... 25
Descriere generala ......................................................................................................................................... 25
Diagramele de stări ....................................................................................................................................... 26
2.2.6 Diagrama de activități ............................................................................................................... 29
Descriere generala ......................................................................................................................................... 29
Diagrama de activități ................................................................................................................................... 30
2.2.7 Diagrama de componente.......................................................................................................... 33
Descriere generala ......................................................................................................................................... 33
Diagramele de componente ........................................................................................................................... 34
2.2.8 Diagrama de plasare .................................................................................................................. 36
Descriere generala ......................................................................................................................................... 36
Diagramele de plasare ................................................................................................................................... 36
Concluzie .................................................................................................................................................... 37
Bibliografie................................................................................................................................................. 38

2
 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

3
 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.

4
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.

5
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.

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.

6
1.3 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.

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)

7
2.1 Descrierea sistemului modelat
Aplicatie Android - „calendar/agenda” .

Aplicatia Calendar pentru telefoanele cu sistem de operare Android iti permite sa

gestionezi timpul, in asa fel incat sa stii mereu ce si cand ai de facut. Calendarul poate fi
vizualizat pe zile, saptamani, luni ori in functie de evenimentele inscrise. Poate fi considerat si ca
Business Calendar ce iti permite sa inscrii un eveniment, sa cauti un anume eveniment, sa
adaugi tipul evenimentului independenta si sa schimbi cu usurinta modul de vizualizare, sa
adaugi evenimente care se repeta la anumite intervale de timp .

Exista posibilitatea de a crea mai multe calendare (în funcție de domeniul de activitate:
serviciu, hobby, vacanță)cărora să le asociezi o culoare specifică. Poți alege între mai multe
moduri de afișare a calendarului (activități zilnice, săptămânale, lunare). Există o funcție de
căutare a activităților și poți crea o listă cu sarcini/treburi de făcut.

Adaugarea de evenimente:
- Este o metoda simpla si rapida de a adauga evenimente noi
- detaliile legate de eveniment la fel mot fi usor modificate

La fel este si optiunea de setare a alarmei. Atit alarma simpla / zilnica cit si optiunea de
reamintire a unor evenimente alese de catre utilizator.

Lista vasta de evenimente te ajuta sa-ti gasesti mai usor programarile

- Apasa pe un eveniment pentru a vedea si edita detalii despre acesta;

- Foloseste optiunea de cautare pentru a gasi instant un eveniment specific;

- Vizualizeaza si gestioneaza-ti evenimentele de pe calculator.

Sistemul este rapid, prietenos si flexibil - Are aceleasi functionalitati ca cele oferite de aplicatiile
de tip calendar propriu-zise (ex. iCloud, Google Calendar)

- este conceput pentru limbile engleza, romana, rusa.

8
2.2 Reprezentarea diagramelor in UML

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.

9
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;
 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”

10
 Diagramele cazurilor de utilizare

Diagrama cazurilor de utilizare p-u exemplu de inregistare si creare account.

uc inregistrare/ creare account

introdu email

introdu parola

«include»
adauga nume

«include»
«include»
inregistrare/creare introdu date adauga
account «include» personale prenume
«include»

utilizator «include»
adauga
data/luna/anul
«extend» «extend» nasterii
«include»

adauga oras adauga tara

acceptare reguli

In diagrama urmatoare este reprezentat procesul de insemnare (inscriere) a unui eveniment,

introducind caractersticile lui : denumirea, data si ora, de asemene descrierea si optiunea de
reamentire.

uc insemnarea ev eniment

alege ora

«extend» alege
data/luna/an
alegerea «extend»
caracteristicilor

«include» culege
denumirea

«include»
adauga zi de
nastere
insemnarea unui Descriere
ev eniment «include»

adauga interv iu
utilizator

adauga sedinta
«include»
aduga alt gen

Reamintire

«extend» «extend»

alege image alege sound

11
Diagrama cazurilor de utilizare, de stergere si modificare a unui eveniment: sunt reprezentate
ambele procese: stergerea nu este complicata se alege doar eveniemntu si se confirma stergerea
lui, la modificare putem efectua schimabarea unor anumitor date sau a intregului eveniment.
uc stergerea unui ev eniment

confirma
stergerea

alege «include»
ev enimentu alege
stergerea unui «include» data/luna/an
ev eniment

«extend» alege ora

«extend»
modificarea
caracteristicilor alege
«extend» denumirea
Utilizator modificarea «extend»
unui ev eniment alege
«include» ev enimentu

«extend»
modificarea alege zi de
descrierii nastere

«extend»

alege interv iu

alege alt gen

modificarea de ev eniment alege sedinta
modului de
reamentire

alege sound alege image

Diagrama urmatoare reperezinta procesul de organizare/planificare a unui evenimet(sarbatori,antilniri,etc)

uc organizarea unui ev eniment

adauga data adauga ora

«extend» «extend»

alegerea
adauga denumire
caracteristicilor «include»
«include»
organizarea unui
1..* ev eniment

utilizator alegerea adauga oras

«include» locului «extend»

«extend»
«include» adauga strada
«extend» «extend»

adauga adauga harta

inscriere lista denumire local
participanti

12
Diagarama data reprezinta diagr.c_u pentru setarea alarmei. se alege una dintre 2: alarma
zilnica sau alarma simpla/ dupa care urmeaza selectarea optiunilo

uc setare alarma

alege pereodicitatea

alege luni

«include»
alege marti
alege ton alarma
include
alege ora
repetare
«extend»
alege miercuri
«extend»
«include»
«include» «extend»
«extend»
alege ziua
alege j oi
«extend»
selectare alarma «include»
zilnica
«extend»

«extend» alege v ineri

«extend»
setare alarma
alege sambata

utilizator
selectare alarma alege duminica
simpla

«include»
alege data
«include»
«extend»
«include»
alege ora

include
repetare alege ton
alarma

«include»

alege
pereodicitatea

13
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;
 "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.

14
 Diagramele de secvență

sd inregistrare

:mobile :ecran::mob

:user

1.pornire aplicatie()

2.rulare aplicatie()
3. initializare aplicatie()

«send»
4.Alegeti optinea INREGISTRARE()
«call»
5.Select IREGISTRARE()

6.pregatire p-u creare account()

:acount
7. crearea acountului ()
«create»
8. Accountul a fost creat()

9. Introduceti Email ()
«call»
10.Introducerea email-ului()

11. Salvarea emai-ului introdus()

12.verificare()

13. OK ()
«call»
14. Introduceti parola ()
«call»
15. Introducerea parolei()

16. Salavare parola()

17.verificare()

18. OK ()

19. Introduceti datele personale()

«call»
20. Introducerea datelor()

21. Salvarea datelor ()

22.verificare()

23.OK ()

24. Acceptati regulile propuse? ()

«call»
25. Select acceptare()

26. Finisarea inregistrarii()

27.finish ()
«return»

15
sd Diagrama de secv . insemnarea unui ev eniment

:Mobile :ecran::mobil

:user

1. Pornire aplicatie()

2. rularea aplicatiei()
3. initializarea aplicatiei ()
«send»
4.Alegeti optiunea dorita ()
«call»
5. Select insemnare eveniment()

6.Preg p-u crearea eveniment()

:Eveniment
7. creare ev ()
«create»

8. Evenimentul a fost creat()

9. Alegeti caracteristicile ()
«call»
10. introduce data()

11. Salvare()

12. verificare()

13. OK ()
«call»
14.Adaugati descriere ()
«call»
15.Select zi de nastere ()

16.Save()

17.Verificare si salvare()

18.OK ()

19.Doriti sa adaugati reamintire? ()

«call»
20. Select DA ()

21.Alegeti melodie sau imagine()

«call»
22. Select melodie ()

23. Save()

24. Verificare / salvare()

25. OK ()

26. Doriti sa salvati evenimentu ()

«call»
27. Select DA.()

28.Save()

29.salvare
eveniment()
30. Evenimet salavat()

31. insemnarea evenimetului a avut loc cu succes()

32.Select EXIT()

33. inchiderea aplicatiei()

34.iesire din aplicatie ()

«return»

16
sd Setare alarma

:Mobile :ecran::mobil

:user

1.Pornire aplicatie()

2.rularea aplicatiei()
3.initializare aplicatie ()
«send»
4.alegeti optiunea dorita ()
«call»
5.Select Setare alarma()

6.Alegeti tipul alarmei /zilnica , simpla/()

«call»
7.Select alarma simpla()

8. pregatit p-u crearea alarmei()

:alarma
9.creare alarma ()

«create»
10. Alarma creata()

11. Alege data

() «create»
12.Select data ()

13.Save ()

14.verificarea()
15.Salvat ()
«call»
16.Alege ora ()
«call»
17.Select ora alarmei()

18.Save()

19.Verificare()

20.Salavat ()

21.Alege ton alarma ()

«call»
22.Selectare ton ()

23.Save()

24.Verificare()

25. Salvat "call"()

26.Doriti sa includeti repetare alarmei cu o anumita pereodicitate? ()

«call»
27. Select NU ()

28.Save()

29.Verificare()

30.Salvat ()

31.Salveaza alarma setata?()

32.Select DA()

33.Salveaza alarma ()

34.Verificare ()

35.Salvat()

36.Alarma a fost setata cu succes ()

«call»
37.EXIT ()

38.Inchiderea aplicatie()

39.Iesirea din aplicatie ()

«return»

17
sd excluderea unui ev eniment

:mobile :ecran::mobil

:user

1. Pornire aplicatie()

2.rulare aplicatie()

3.initializare aplicatie ()
«send»
4.Alegeti optiunea dorita()
«call»
5.Select Excluderea unui eveniment()

6.Alegeti evenimentu din lista()

7.Alegerea eveniment()

8.D-voastra intr-adevar doriti excluderea acestui ev din lista?()

«call»
9.confirmarea excluderii()

10 . excluderea evenimentului()

11. finisarea operatiunii ()

«return»

1) Diagrama reprezinta procesul de inregistrare. Este clar specificat pas cu pas etapele
procedurii de inregistrare. Putem vedea clar toate legaturile dintre obiecte si schimbul de
mesaje care are loc.
2) Diagrama. In cea de a 2-a diagrama este ilustart procesul de insemnare a unui eveniment
in agenda, incluzind toate specificatiile ce tine cont de adaugarea descrierii, reamintire, si
a altor caracteristici ce tin de descrierea completa a unui evenimet.
3) In diagrama data este reprezentat procesul de setare a alarmei simple nu zilnice, care
include alegerea orei, melodiei si a altor optiuni oferite.
4) Diagrama reprezinta excluderea unui eveniment din agenda.

18
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.
 "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.
19
Diagramele de colaborare

In diagrama data este reprezenatata procedura de setare a alarmei, sunt reprezentate principalele
obiecte si colaborarile intre ele, schimbul de mesaje, consecutivitatea evenimentelor poate fi
urmarita prin interactiunile numerotate.

sd setare alarma

2: ruleaza aplicatia()
«self»

:Mobile
1: pornire aplicatie ()
6: creare alarma ()
25: Verificare()
20:
30: Iesirea din aplicatie () 15: verificare ()
10: verificare()
3: initializarea aplicatiei() 29: Inchiderea aplicatiei ()

:alarma
5: Select setarea alarma zilnica()
26: Salvat()
8: select zilele dorite()
21:
:user 13: Select ora() 24: SAVE ()
16: Salvat()
18: Select ton ()
11: Salvat ()
23: Select DA() 19:
4: Alegeti optiunea dorita() 14: Save()
28: EXIT()
9: Save()
7: alege zilele()
:Ecran::Mobil
12: Alege ora()

17: alege ton alarma ()

22: Doriti sa salvati alarma setata?()

27: Alarma a fost setata cu succes()

Planificarea unui eveniment - in diagrama sunt incluse obiectele de baza ce colaboreaza

intre ele la efectuarea procesului de planificare a unui eveniment. Toate operatiunile efectuate
pas cu pas sunt indicate in diagrama data.

sd Panificarea unui ev ement

2: rularea aplicatie()

:Mobile

6: crearea evenimetului()
1: Pornire alpicatie () 22: Verificare()
15: verificare ()
3: initializare aplicatie()
26: Inchiderea aplicatiei() 10: verificare ()
27: Iesirea din aplicatie()

:ev eniment
5: Select Planificarea unui eveniemt()
:user 8: Select caracteristici()
13: Select locul() 23: Salvat ()

4: Alegeti optiunea() 18: Inscriere lista()

16: salvat()
20: Select DA() 21: Save evenim planificat()
7: introduceti caracteristicile ev /data, ora, denumirea/() 11: Salvat()
25: EXIT() 14: Save()
12: Alege locul petrecerii ev()
9: Salveaza caract.p-u eveniementu creat()
17: Adauga lista participantilor() :ecran::mobil
19: doriti sa salvati evenimetu planificat?()

24: Planul ev a fost creat.()

20
 Diagrama urmatoare reprezinta procesul de modificare a unui eveniment din agenda.

sd mdificarea ev

2: rularea aplicatiei()
«self»

:Mobile

1: Pornire aplicatie()

17: inchiderea aplicatiei()

3: initializarea plicatiei()

5: Select modificare evenient()

:useer 16: Iesirea din aplicatie()
7: Select evenimet()
4: Alegeti optiunea dorita () 9: Select modifica data/luna/an ev()
11: Select new date ()
6: Alegeti evenimentul ce doriti sa-l schimbati() 13: Select DA()
8: Alegeti modificarea care doriti sa o efectuati() 15: EXIT()
10: Introdu new data/luna/an()
12: SAVE?() :ecran::mobil
14: Modificarile au fost salvate ()

obj ect niv de specificare

insemnarea unui
Utilizator Mobile
ev eniment

Utilizator_aplicatie Insemnare unei zile Mobile - Androind

de nastere

21
2.2.4 Diagrama claselor

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.

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

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

· <<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)

class diagram 1

User

- Login: char
- Password: char
+ create account() : void
+ modify account() : void
+ notes an event() : void
+ change an event() : void
+ alarm setting() : void
«interface» Database
application interface
+ realize the log and pass check() : void
- choice menu: char
+ store account() : void
- help: char
-modify
1

-save modify account

- email: char
- Name, surname: char
- birthday: char
- pass & login : char
- tel: int
- adress: char

+ cancel () : void
+ modify() : void

In diagrama data sunt ilustrate relatiile intre urmatoarele clase: user, Database, si Modify
account. Clasele sunt create inpreuna cu atributele si metodele sale. Deasemena este inclusa
interfata aplicatiei.

23
 class diagram3

birthaday

- Tittle: char
- Date & Time: float
- Place: char
- description: char

+ create () : void
+ save () : void
+ delete() : void

User
notes an ev ent
- Login: char
- Title: char
- Password: char
-create -save - description: char meeting
+ create account() : void - Type : char
1..* - Title: char
+ modify account() : void
+ Save() : void - Date & time : float
+ notes an event() : void
+ Create () : void - Place : char
+ change an event() : void
+ Delete() : void - Description: int
+ alarm setting() : void
+ create () : void
+ Save() : void
+ Create () : void
+ save() : void
+ Delete() : void
+ delete() : void

other

- Title: char
- Date&time: float
- Place: char

+ create () : void
+ save() : void
+ delete() : void

In aceasta diagrama sunt reprezentate relatiile intre user, insemnarea unui eveniment si tipurile
de evenimente ce pot fi create.

class diagram 2

User

- Login: char
- Password: char «interface»
application interface
+ create account() : void - choice menu: char
+ modify account() : void - help: char
+ notes an event() : void
+ change an event() : void
-set
+ alarm setting() : void

1..* alarm

-save

setting the alarm

- daily alarm: char

- simple alarm: char
- Title: char
- Date & Time: float
- Sound: file

+ reset() : void
+ set() : void

Diagrama data reprezinta relatiile intre user, interfata si cazul de utilizarea care il
realizeaza /setarea alarmei /.

24
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.

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ă.
25
Diagramele de stări

stm diagram 1

Initial

activ ation

authentification [login and password is corect] authentification [login and pass incorrect]

Log in try again [yes]

Log in is failed

initialization
exit [No]

choose an option

notes an event is chosen

[click notes an event]
notes an ev ent

choose the type

[click select ]

selecting the tyoe

type meeting is selected

meeting

select the date & time of

meeting [click select]
select Date & time

choose the place [click select ]

select Place
the ev ent is sav ed exit [click log out ]
save [click save ]
save the alarm [click yes ] log out
Sav ed

[click No] exit

the ev ent is not sav ed

Final

In diagrama data sunt reprezentate starile, ce crespund procesului de inregistrare a

unui eveniment in cadrul aplicatiei.procesul incepe cu logare, dupa care continuaalegerea
optiunii dorite, inclusiv cu toatea operatiile adaugatoare.

26
 stm diagram 2

Initial

activ ation

authentification [login and password is corect] authentification [login and pass incorrect]

Log in try again [yes]

Log in is failed

initialization exit [No]

choose an option

delete an event is chosen [click select ]

delete an ev ent

select the event [click select]

th ev ent is chosen

delete [click No]

delete [click Yes]

deletion is done cancel

exit [click log out]
save [click yes]
exit [click log out]
sav ed log out

Final

In aceasta diagrama sunt reprezentate starile, ce crespund procesului de excludere a unui

eveniment din bd salvat anterior. La fel procesul incepe cu logare, dupa care continua cu
alegerea optiunii dorite, dupa care urmeaza efectuarea tuturor operatiilor.

27
 stm diagram 3

Initial

activ ation

authentification [login and password is corect] authentification [login and pass incorrect]

Log in try again [yes]

Log in is failed

initialization
exit [click No]

choose an option

alarm setting is chosen

[click select]
alarm setting
daily alarm selected
simple alarm [click [click select daily]
select simple]
simple alarm daily alarm
Log out

set the time set the time exit [click log Final
[click save ] [click save] out]
sav ed

exit [click log out ]

select the sound

song is chosen tha alarm is sav ed

[click save] save the alam [click yes]

sav ing the alarm is not sav ed

[click no ]

Aceasta diagrama de stari, corespunde procesului de setare a alarmei. La fel

procesul incepe cu logare, dupa care continua cu alegerea optiunii dorite, dupa care
urmeaza efectuarea tuturor operatiilor.

28
2.2.6 Diagrama de activități

Descriere generală

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.

29
Diagramele de activitate

act diagram 1

ActivityInitial

activ area aplicatiei

introdu login & pass

[click YES]
[pass invalid]
autentificare incorecta /
reautentificare
incercati din nou

[pass valid]
[click No]

autentificare cu succes
exit

afisare menu

alegerea otpiunii dorite

ActivityFinal

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.

30
 act diagram2

ActivityInitial

alegerea optiunii

[Nu a fost aliasa nici-o optiune]

[optiune aleasa]

adaugare ev eniment

selectam tipul introducem data si alegem titlu selectam locul

ora ev enimentuli

salv are ev enimet

[NO]
anulare
[YES]

ev enimentul este salv at

exit

ActivityFinal

In aceasta diagrama este modelat procesul de executare a unei operatiuni in cadrul aplicatiei,
optiunea aleasa este insemnarea unui eveniment in agenda. 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.

31
 act diagram 3

User Menu Database

ActivityInitial

introducerea login & pass

autentificare

Logg in

alege optiune

alege modificarea account

introducere email

introd. loggin nou

introd passw ord nou

introd date personale

select "Sav e"

modificarile au fost
salv ate

afisarea mesaj ului

"Sav ed"

operatiune
indeplinita

ActivityInitial

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.

32
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.

33
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.

Diagramele de componente

cmp diagram 1

libraries

«library»
functions.lib

«file» «executable»
w eb.xml application.exe

«library» «database»
user.lib user db

«library»
plugin.dll

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.xml/ si baza de date a utilizatorilor.

34
 cmp diagram 2

mobile phone «executable»

application.exe
«file»
script

«library»
user's serv ice.j av a «file»
help.hlp

«table» «library»
user db tools.j av a

In aceasta diagrama le fel sunt reprezentate componentele de baza a sistemului, inclusiv si

componenta – telefonul mobil, la care deasemnea se mai adauga anumite componente cu stabilerea
lagaturilor intre ele. componentele adaugatore sunt file-urile help, script si libraria user’s service.java.

cmp diagram 3

«file»
w eb.xml

PC «executable» «file»
application.exe settings

«file»
online application

«library» «library» «file»

w eb tools.lib user's serv ices.lib user's db

In Diagrama data deja componentele de baza a sistemului ramin aceleasi insa se schimba
componenta – telefonul mobil cu cea PC , la care se adauga componentele de gruapare si anume librarii si
file-uri cu extensia .xml, .bd desemena cu stabilerea lagaturilor intre ele.

35
2.2.8 Diagrama de plasare

Descriere generală

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.
deployment deployment

«device»
Work Station::Mobile Phone

Android v 4.0.4
application serv er Database

application
application.exe
database
«device»
w ork station:: PC

Window s 7

36
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

aplecî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ă.
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.

37
Bibliografie:

1. Conspect la disciplina AMSI.

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

38