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 informaionale......................................................................... ...................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 stri.....................................................................................................................25

Descriere generala..........................................................................................................................................25
Diagramele de stri.........................................................................................................................................26

2.2.6 Diagrama de activiti..............................................................................................................29

Descriere generala..........................................................................................................................................29
Diagrama de activiti.....................................................................................................................................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

INTODUCERE
2

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 informaional cuprinde ansamblul informaiilor interne i externe utilizate n
cadrul lui precum i datele care au stat la baza obinerii lor, procedurile i tehnicile de obinere a
informaiilor (plecnd de la datele primare) i de difuzare a informaiilor, 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

In etapa de proiectare se construiesc modele care redau arhitectura sistemului, alocarea

cerintelor pe subsisteme, distributia proceselor in sistem, sincronizarea lor, starile si tranzitiile
3

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 ateniei de la prezentarea a ceea ce

exist si ce se intenioneaz la desdescrierea a ceea ce va nsemna noul sistem i cum va
functiona. Prezentarea nouui sistem const in prezentarea tuturor intrrilo sistemului, a iesirilor,
precum si a interfetelor si dialogurilor.
Proiectarea fizic este cunoscut i sub numele de proiectare de detaliu. In timpul
proiectrii 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 informaiile de natur s sintetizeze cerinele utilizatorilor noului sistem, operatiune
prestat de analistii de sistem, iar in timpul proiectrii fizice se prezint punctele de vedere ale
specialitilor, cum ar fi cei din domeniul programrii, securitii sistemelor, reelelor, etc.

1.1.

Analiza si conceperea sistemelor informationale

4

n viata noastra de zi cu zi, calculatoarele sunt ceva obisnuit, ba chiar indinspensabil n

unele cazuri. Se poate spune, pe drept cuvnt ca traim ntr-o societate informatizata . Peste tot
sunt calculatoare, legate eventual ntre ele si formnd 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 ntlnim, 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.

1.2.

Limbajul UML

Unified Modeling Language (prescurtat UML) este un limbaj standard pentru descrierea
de modele i specificaii pentru software. Limbajul a fost creat de ctre consoriul Object
Management Group (OMG) care a mai produs printre altele i limbajul de programare CORBA.
UML a fost la baz dezvoltat pentru reprezentarea complexitii programelor orientate pe obiect,
al cror fundament este structurarea programelor pe clase, i instanele acestora (numite i
obiecte). Cu toate acestea, datorit eficienei i claritii n reprezentarea unor elemente abstracte,
UML este utilizat dincolo de domeniul IT. Aa se face c exist aplicaii ale UML-ului pentru
management de proiecte, pentru business Process Design etc.
Istoria dezvoltrii limbajului UML ncepe n luna octombrie a anului 1994, cnd Grady Booch i
James Rumbaugh din Rational Software Corporation au nceput s lucreze mpreun asupra
unificrii 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
unificrii celor mai avantajoase trsturi ale lor. Proiectul acestei aa zise metode unificate
(Unified Method) versiunea 0.8 a fost pregtit i publicat n luna octombrie anului 1995. n
toamna aceluiai an a aderat la ei i Iv. Jacobson, tehnologul principal al companiei Objectory
AV (Suedia), cu scopul integrrii metodei sale OOSE cu celelalte dou precedente.
Componente de baza ale limbajului UML
Limbajul UML reprezint limbajul de destinaie general al modelrii 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 destinaie. Acest limbaj conine cele mai bune caliti
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 numr de noiuni principale care pot fi studiate i
aplicate de ctre majoritatea programitilor i elaboratorilor cunoscui cu metodele de analiza i
proiectarea obiect orientate. Totodat noiunile de baz pot fi combinate i extinse n asa fel c
specialitii modelrii orientate pe obiecte pot elabora de sinestttor modele ale sistemelor
complexe n diferite domenii de aplicare.
Utilizarea constructiv a limbajului UML este bazat pe inelegerea principiilor comune de
modelare a sistemelor complexe i a particularitilor procesului de analiza i proiectarea obiect
orientate. Alegerea mijloacelor expresive pentru construcia modelelor ale sistemelor complexe
stabilete din vreme problemele care pot fi rezolvate cu ajutorul utilizrii 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 legtura cu executarea de ctre sistem a funciilor sale sau
cu destinaia lui de baza. Totodat toate detalii de importana secundar sunt omise pentru ca
procesul de analiza i cercetare a modelului primit s nu fie foarte complicat.

1.3 Structura general a limbajului UML

UML const din dou pari interdependente:

Semantica limbajului UML reprezint un careva metamodel, care definete sintaxa

abstracta i semantica noiunilor modelrii orientate pe obiecte n limbajul UML.

Notaia limbajului UML reprezint o notaie grafica pentru reprezentarea vizual a

semanticii limbajului UML.

Sintaxa abstract i semantica limbajului UML sunt descrise cu ajutorul unei anumite submulimi
de notaii ale UML. n completare la aceasta, notatia UML descrie corespunderea sau
reprezentarea notaiei grafice n semantica noiunilor de baza. n aa fel din punct de vedere
funcional aceste dou pri completeaz una pe alt. Totodat semantica limbajului UML este
descris pe baza unui metamodel care are trei reprezentri aparte: sintaxa abstract, reguli de
construcia corect a expresiilor i semantica. Cercetarea semanticii limbajului UML presupune
un careva stil semiformal de redare, care unifica limbaje naturale i formale pentru reprezentarea
noiunilor de baza i regulilor de extindere a lor.
Semantica se definete pentru dou tipuri de modele de obiecte: de structura i de comportare.
Modelele de structur, cunoscute ca modele statice, descriu structura entitilor sau a
componentelor unui sistem inclusiv clase, interfee, atribute i relaii. Modelele de comportare,
numite uneori dinamice, descriu comportarea sau funcionarea obiectelor unui sistem, inclusiv
metodele lor, colaborarea ntre ele, i procesul de schimbare a strilor unor componente aparte i
al sistemului ntreg.
Dicionarul limbajului nclude trei tipuri de construcii de baz:

entiti abstracii ce sunt elemente de baz a modelului;

relaii legturi ntre entiti;

diagrame ce grupeaz interesele entitilor i relaiilor.

Diagrame UML
n cadrul limbajului UML toate reprezentrile modelului unui sistem complex sunt fixate n
calitate de construcii speciale grafice care deseori sunt reprezentate sub form de graf conex cu
noduri entiti i muchii relaii. 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)

7

o Diagrame de stri (statechart diagram)

o Diagrame de activiti (activity diagram)
o Diagrame de interaciune (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)

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 funcie de domeniul de activitate:
serviciu, hobby, vacan)crora s le asociezi o culoare specific. Poi alege ntre mai multe
moduri de afiare a calendarului (activiti zilnice, sptmnale, lunare). Exist o funcie de
cutare a activitilor i poi crea o list cu sarcini/treburi de fcut.
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.

2.2

Reprezentarea diagramelor in UML

Model al unui sistem complex n notaia UML.

Fiecare din aceste diagrame detalizeaz i concretizeaz diferite reprezentri 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 iniial
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 varieti ale unui model logic care reflect
aspectele dinamice ale procesului de funcionare a unui sistem complex. Diagramele de realizare
sunt destinate reprezentrii 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 urmrete scopurile urmtoare:

determinarea limitelor comune i a contextului domeniului de modelare la etapele iniiale

de proiectare a unui sistem;

formularea cerinelor comune ctre comportare funcional a sistemului proiectat;

elaborarea modelului iniial conceptual al unui sistem pentru detalierea de mai trziu n
forma modelelor logice i fizice;

pregtirea documentrei iniiale pentru interaciunea elaboratorilor unui sitem cu clienii

i utilizatorii.

Esena acestei diagrame const n faptul c: sistemul proiectat se reprezint ca o colecie de

entiti i actori care colaboreaz cu sistemul cu ajutorul aa 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.

10

Scopul cazului de utilizare const n determinarea aspectului terminal sau fragmentului de

comportare a unei entiti fr desfurarea structurii interne a acestei intiti. n calitate de aa
entitate poate fi un sistem iniial 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 posibilitile lui funcionale pentru atingerea anumitor scopuri i pentru rezolvarea
problemelor particulare.

Interfaa (interface) specific parametrii modelului care sunt vizibili din afar fr indicarea
structurii lor interne. n limbajul UML interfaa este clasificatorul care caracterizez numai o
parte limitat a comportrii unei entiti 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

Diagramele cazurilor de utilizare

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

11

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.

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.

12

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

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

13

2.2.2 Diagrama de secven

Descriere general
14

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 stnga la dreapta.
n diagrama de secven se reprezint numai obiectele care acioneaz i nu se reflect
asocierile statice cu alte obiecte. Pentru diagrama de secven momentul principal este dinamica
colaborrii ntre obiecte n timp. Grafic fiecare obiect se reprezint printr-un dreptunghi i se
plaseaz n partea de sus a ciclului su de via (fig. 1). n nteriorul dreptunghiului se indic
numele obiectului i numele clasei desprite prin dou puncte. Totodat toat nregistrare se
subliniaz, ce indic c obiectul este exemplarul unei clase. n caz dac numele obiectului
lipsete, 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 definete intervalul de timp
n care obiectul exist i interacioneaz cu sistemul dat.
Pentru a evidenia obiectele active n limbajul UML se utilizeaz notaia special focus control
(focus of control).
Fiecare legtura se descrie cu o totalitate de mesaje transferate cu care obiectele-participante se
schimb. n acest sens mesajul (messaje) reprezint un fragment de informaie care este
transferat de ctre un obiect altuia.

Stereotipuri:
call" invoc o operaie sau procedur a obiectului-destinatar;
"return" returneaz valoarea operaiei executate obiectului apelant;
"create" creaz alt obiect pentru executarea anumitor aciuni;
"destroy" distruge un obiect. Se transmite n caz dac este necesar a termina aciunile
din partea obiectului existent sau dac obiectul trebuie s elibereze resursele alocate;
"send" trimite un semnal unui obiect care se iniializeaz asincron de ctre un obiect i
este acceptat de altul. Diferena ntre un semnal i un mesaj const n fapt c semnalul
trebuie s fie descris n clasa obiectul creia iniializeaz transmiterea lui.

15

Diagramele de secven

16

17

18

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.

19

2.2.3 Diagrama de colaborare

Descriere general
Particularitatea principal a diagramei de colaborare const n posibilitatea de a
reprezenta grafic nu numai consecutivitatea colaborrii dar i toate relaii structurale ntre
obiecte. n primul rnd n diagrama de colaborare sub form de dreptunghiuri se reprezint
obiectele care conin 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 executrii a unui
program. El poate avea un nume propriu i valorile atributelor. Referitor la obiecte formatul
liniei ce conine clasificatorul se completeaz cu numele obiectului:
<Numele obiectului>'/' <Numele rolului al clasificatorului> ':' <Numele clasificatorului>
Multiobiect (multiobject) reprezint o mulime de obiecte n una din terminaiile asocierei
Obiectul activ (active object) are un fir (thread) de control propriu i poate iniializa activitatea
de control. Totodat sub noiune de fir se subnelege 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
arogant

c:
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 parile sale prin relaii de agregare sau compoziie. Relaii
analogice leag obiectele respective.

Tipul de legtura se nscrie lnga terminaia ei i indic posibilitatea realizrii acestei legturi. 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.

20

"local" variabila local a metodei.

"global" variabila global. Domeniul ei de vizibilitate este toat diagrama de colaborare.

"self" legtura reflexiv a obiectului care presupune transferul mesajelor ctre sine. n diagrama
de colaborare legtura reflexiv se reprezint n form de bucl n partea de sus al dreptunghiului
obiectului.

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.

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.

21

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

22

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 programrii OO. Diagrama de clase poate reflecta
diferite legturiintre entitile domeniului de obiecte (obiecte i subsisteme) i descrie structura
lor intern itipurile de relaii.
Diagrama de clase reprezint un graf cu noduri elemente de tip clasificatori care
sunt legateprin diferite tipuri de relaii de structur. Trebuie de menionat c diagrama de clase
poate conine interfee, pachete, relaii i chiar exemplare, aa ca obiecte i legturi.
Clasa (class) in limbajul UML definete totalitatea de obiecte care au aceeai structur,
comportament i relaii cu obiectele din alte clase.
Numele clasei trebuie s fie unic in cadrul pachetului, care este descris de ctre o totalitate de
diagrame de clase. Numele se indic in prima seciune de sus a dreptunghiului.
In a doua secie a dreptunghiului de clas se inscriu atributele lui sau prorietile. Fiecrui atribut
de clasii corespunde rindul textului, care este format din specificatorul de vizibilitate a
atributului, numeluilui, tipul sensului i, posibil sensul final:
23

<<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 protecie (protected).
In sfirit, simbolul atributul cu regiunea de vizibilitate tipului privat. (private).
In a treia secie a dreptunghiului de clas se inscriu operaii sau metodele clasei. Operaia
(operation) prezint un anumit serviciu, care prezint fiecare exemplar al clasei dup anumit
cerin. Totalitatea de operaii caracterizeaz un aspect funcional in comportamentul clasei.

Relaiile de baz i legturile sunt:

Relaia

de dependena (dependency relationship) // stereotipurile:

<<access>> servete ca indicator de accesibilitate unor atribute i operaii clasei surs
pentru claseclienii;
<<bind>> clasaclient pote utiliza careva ablon pentru urmtoarea parametrizare;
<<derive>> atributul clasei client poate fi calculat dup atributele clasei surs;
<<import>> atribute deschise i operaii publice clasei surs devine o parte a clasei client
<<refine>> indic c clasa client servete ca precizie a clasei
Relaia

de asociere (association relationship)

Relaia de generalizare(generalization relationship) // {complete},{incomplete},{disjoint},
{overlapping}.
- Relaia de realizare(realization relationship)

24

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.

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

25

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

2.2.5 Diagrama de stri

Descriere general
Diagrama de stari descrie procesul de modificare a starilor pentru o anumita clasa.
Aceast diagram este folosit pentru descrierea consecutivitilor de stri posibile i trecerilor,
care in ansamblu caracterizeaz comportamentul elementelor modelului in timpul ciclului de
via. Diagrama de stri reprezint comportamentul dinamic a entitilor in baza specificaiei
reaciei lor la perceperea cror-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 strii reprezint aliniat de text, care dezvluie sensul strii date. Numele este
intodeauna
26

scris cu litera majuscul.

Pseudo stari : initiala si finala .

Fiecare tranziie poate fi marcat cu aliniat de text, care are urmtorul format general:
<signatura evenimentului>'['<condiia de paz>']' <exprimarea aciunii>.
Termenul eveniment (event) trebuie explicat aparte, deoarece el este un element independent al
limbajului UML. Opional evenimentul reprezint specificaia anumitui fapt, care are ataat o
locaie in timp i in spaiu.
Condiia gard (guard condition), dac exist, atunci intodeauna este scris in paranteze
dreptungiulare dup evenimentul triger i reprezint expresie bulean.
Expresia aciunii (action expression) se execut atunci i numai atunci cind se execut tranziia.
Reprezint operaia atomic, care se execut dup efectuarea tranziiei respective inainte de
oricare
aciune in starea obiectiv.

Diagramele de stri

27

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.

28

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.

29

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.

2.2.6 Diagrama de activiti

30

Descriere general
In contextul limbajului UML activitatea (activity) reprezint o totalitate de calcule executate de
ctre automat. Totodat calculele elementare pot duce la un anumit rezultat sau careva aciune
(action). In diagrama de activiti se reflect logica sau consecutivitatea tranziiilor de la o
aciune la alta, totodat se evideniaz rezultatul activitii. Rezultatul, la rindul su poate duce la
schimbarea strii sistemului dat sau la returnarea unei valori.
Starea activitii este un caz particular a strii. Starea activitii nu poate avea tranziii interne
fiindc ea nu este elementar. Starea activitii se utilizeaz pentru modelarea unui pas de
executarea a algoritmului (procedurii) sau a unui flux de control.
Grafic starea activitii se reprezint printr-o figur asemanatoare cu dreptunghiul, laturile
laterale ale cruia sunt substituite cu arcuri convexe (printr-un dreptunghi cu coluri rotunjite).

Tranziia . Laconstruirea diagramei de activiti se utilizeaz careva tranziii netrigere care

acioneaz deodat dup perfectarea activitii sau dup executarea aciunii corespunzatoare.
Aceast tranziie transmiteactivitatea in urmtoarea stare imediat dup ce se termin aciunea din
starea precedent. In diagram aceast tranziie se reprezint printr-o linie continu cu o sgeat.
Diagramele de stri 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 particulariti in limbajul UML se folosete construcia special, care
aredenumire de partiii (swimlanes), care sunt divizate unul cu altul cu linii verticale. Dou linii
vecine formeaz o partiie, iar un grup de stri intre aceste linii sunt executate de subdiviziunea
separat (secie, filial, diviziuni) a companiei.
In cazul general aciunile in diagrama de activitate sunt efectuate cu obiecte. Aceste obiecte sau
iniializeaz executarea aciunelor sau definesc un anumit rezultat a acestor aciuni. In urma
cruia
aciunile specific apelurile, care trec de la un obiect a grafului de activitate la altul.
In diagrama de activitate cu partiii deplasarea obiectelor poate avea un sens adugtor. i
anume,
dac obiectul este amplasat la hotarul ambilor partiii, aceast lucru inseamn c trecerea la starea
de aciune urmtoare in partiia vecin este asociat cu un document finit (obiectul in care-va
stare). Dar dac obiectul este amplasat inuntrul partiiei, atunci starea acestui obiect este definit
de aciunile partiiei date.

Diagramele de activitate
31

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.

32

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.

33

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.

34

2.2.7 Diagrama de componente

Descriere general
Diagrama de componente permite determinarea arhitecturii sistemului elaborat prin stabilirea
dependenei ntre componentele de program n calitate de care poate fi codul iniial, binar i
executabil. n mai multe domenii de elaborare modul i componenta corespund fiierului.
Sgeile punctate care leag modulele arat relaiile de dependena analogice celor ce au loc la
compilarea codurilor sursei iniiale. Elementul grafic de baz al diagramei de componente sunt
componentele, interfeele i dependenele 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 utilizrii 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

organizaia n cadrul unui pachet fizic cu care el este asociat cu ajutorul elementelor unui model.
n calitate de clasificator componentul poate s aib aa proprieti ca atribute i operaii.

Fig.1. Componenta.
n limbajul UML sunt specificate trei feluri de componente:

n primul rnd componente de regrupare, care specific executarea de ctre sistem a funciilor
sale. Aa fel de componente pot fi librrii conectate dinamic cu extensia .dll
(fig. 69, a), Web pagini n limbajul de trasare hipertextului cu extensia .html (fig. 69, b) i
fiierele de adeverin cu extensia .hip (fig. 69, c).

n al doilea rnd, componente produse de lucru. Ca regul acestea sunt fiierele cu texte iniiale
a programului, de exemplu, cu extensia .h sau .cpp pentru limbajul C++ (fig. 69, d).

n al treilea rnd, componentele de executare, ce reprezint modulele fiierele cu extensia .exe.

Ei se indic obinuit.

35

Un alt mod de specificare a diferitor feluri componentelor este indicarea steriotipului

componentului naintea numelui lui. n limbajul UML pentru componente sunt specificate
urmtori steriotipuri:

Librrie (library) definete prima specie a componentuluui, care reprezent librrie

dinamic sau static.

Tabel (table) definete prima specie a componentului, care reprezent un tabel de baze
de date.

Fiier (file) definete a doua specie a componentului, care reprezint un fiier cu texte
iniiale a programului.

Document (document) definete a doua specie a componentului, care reprezint un

document.

Executare (executable) definete a treia specie componentului, care poate fi executat n

nod.

Diagramele de componente

36

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.

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 users service.java.

37

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.

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 executrii lui (runtime). n urma cruia sunt prezentate
numaicomponente exemplare a programului, care sunt fiiere de executare sau librriile
dinamice. Acele componente, care nu sunt utilizate la etapa executrii, 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 mpri simbolul grafic n dou
secii cu linie orizontal. n seciunea cea de sus este scris numele nodului, iar n cea de joscomponente 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.

38

Concluzie:
Pe parcusul acestui proiect de curs am capatat cunotine 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, relaii si diagrame.
UML este un instrument standard pentru crearea carcaselor de documentare
(desenelor) ale produsului soft. UML este un limbaj de vizualizare, specificare,
construcie i documentare artefactelor sistemelor de program.
Am inteles cele mai importante principii de modelare a unui sistem si anume
aplecndu-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 activiti, de component si de plasare.
Istrumentul de modelare folosit este Enterprise Architect (EA). Platforma dat
suporta: proiectarea i construcia 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:
39

- software i ingeneria sistemelor;

- afacere si sisteme IT;
- Integrarea dezvoltrii in timp real.

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

ajuta echipele, construind sisteme puternice i ntreinute. Utiliznd calitatea nalt,
intergrarea reportrii si documentrii poate oferi o viziune clar si precis.
Integrnd capacitile de gestionare a cerinelor, Enterprise Architect ajut la
urmrirea specificaiilor la nivel nalt pentru analiza, proiectarea, implementarea,
testarea i ntreinerea modelelor folosind UML.

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

40