MINISTERUL EDUCAIEI AL REPUBLICII MOLDOVA

UNIVERSITATEA TEHNIC A MOLDOVEI

Facultatea ,,Calculatoare Informatica si Microelectronica

Catedra - Automatica i Tehnologii Informaionale

Teza de curs
Tema:
,,Analiza si modelarea unui Content Management System

A elaborat: Florea Andrei, gr. SI111

A verificat: Melnic Radu

Chiinu 2014

Cuprins:
Introducere..................................................................................................................... 3
1.

UML limbaj universal de modelare..............................................................................4

2.

Noiunile i blocurile costructive ale limbajului UML..........................................................5

3.

Elaborarea modelului................................................................................................ 13
3.1 Diagrama Use Case......................................................................................... 18
3.2 Diagrama de segventa si colaborare...............................................................21
3.4 Diagrama claselor........................................................................................... 31
3.5 Diagrama de stare........................................................................................... 33
3.6 Diagrama de activitate.................................................................................... 37
3.7 Diagrama de componente...............................................................................41
3.8 Diagrama de amplasare.................................................................................. 42

4.

Concluzii............................................................................................................... 43

5.

Bibliografie............................................................................................................ 44

Introducere

Un sistem informatic reprezint un model fizic de simulare a comportamentului

unei pri din lumea real sau conceptual. Acest model fizic este definit prin
intermediul unui limbaj de programare i el se concretizeaz ntr-o aplicaie (model
executabil) ce poate fi rulata pe un sistem de calcul.
Astzi pentru realizarea aplicaiilor de complexitate medie sau mare apare
necesitatea de a utiliza diferite metode de analiz i modelare (proiectare) a
sistemelor informatice. Prin metode de analiz i proiectare nelegem o mulime de
procedee, tehnici i recomandri utilizate n etapele timpurii ale ciclului de via al
unei aplicaii avnd ca scop final crearea unui model al aplicaiei care urmeaz a fi
construite. Specificarea acestui model se realizeaz prin intermediul unui limbaj sau
formalism vizual (notatie) compus dintr-un set de simboluri grafice i adnotri
textuale. Ciclul de via al unei aplicaii reprezint totalitatea etapelor care sunt
parcurse n procesul de dezvoltare a aplicaiei respective. Cele mai importante etape
sunt:
Culegerea de specificaii (analiza funcional) presupune definirea
problemei; specificarea detaliata a functionalitatilor ce trebuiesc sa fie suportate de
catre sistemul informatic;
Analiza n cadrul creia se realizeaz identificarea caracteristicilor
eseniale tuturor soluiilor corecte posibile;
Modelarea este necesar pentru nelegerea sistemului, cu alte cuvinte este
un proces de reprezentare a obiectului asociat printr-un model adecvat pentru
obinerea informaiei necesare despre acest model. Pentru aceasta este necesar
prelucrarea unei cantiti mari de modele interconectate;
Proiectarea care adaug modelelor de analiz noi elemente care definesc
o soluie particular, pe baza optimizrii anumitor criterii;
Implementarea n care se realizeaz un proiect executabil al soluiei
particulare modelat n faza de proiectare;
Testarea n care se verific echivalena implementrii cu modelul proiectat
i valideaz faptul c implementarea respect criteriile de corectitudine identificate n
etapa de analiz.
Metodele de analiz i proiectare orientate pe obiecte permit parcurgerea etapelor
ciclului de via a aplicaiilor ntr-o manier iterativ.
Odat cu evoluia metodelor de analiz i proiectare orientate-obiect s-au
dezvoltat o serie de instrumente care permit automatizarea procesului de realizare a
aplicaiilor avnd la baz aceste metode. Astfel de instrumente poart numele de
instrumente CASE (Computer Aided Software Engineering) i ele sunt formate dintr-o
3

colecie de componente care sprijin realizarea operaiilor ce trebuie efectuate n

cadrul uneia sau mai multor etape ale unei metode de analiz i proiectare.

1. UML limbaj universal de modelare

n anii 90 a aprut o serie de metode de dezvoltare a aplicaiilor, fiecare dintre
acestea introducnd notaii (grafice sau formale) particulare. Printre cele mai populare
metode se numrau:

OMT (Object Modeling Technique) James Rumbaugh

OOD (Object Oriented Design) Greedy Booch

OOSE (Object-Oriented Software Engineering) Ivar Jacobson

Limbajul UML (Unified Modeling Language) s-a nscut n 1997, din dorina de a
unifica cele mai importante concepte introduse de fiecare dintre aceste metode precum
i pentru a gsi o notaie standard de modelare a acestor concepte. UML s-a format
avnd la baz cele trei metode amintite mai sus, la care se adaug contribuii notabile
n diverse faze ale etapelor de analiz i proiectare: clasificare, hri de stri, ciclu de
via al obiectelor, abloane de proiectare .a.
UML este un limbaj de vizualizare, specificare, construire i documentare a
artefactelor sistemelor informaionale. El reprezint un standard de notaie introducnd
un numr de 9 diagrame de descriere a unui sistem informatic i semantic a acestor
diagrame propunndu-ne nu n ultimul rnd i un proces de utilizare a acestor
diagrame n construcia unei aplicaii. Permite construirea modelelor precise, baznduse pe specificarea tuturor soluiilor importante care se refer la analiza, proiectarea i
realizarea elaborrii i dezvoltrii produsului soft.
Astfel, stabilirea ierarhiei claselor poate fi neleas studiind atent codul
fiecruiadintre ele, dar nelegerea ntregei structuri fiind imposibil. n al treilea rnd,
dac autorul codului niciodat nu a concretizat ntr-o form real modelul gndit,
aceast informaie risc mult pentru a fi perdut pe totdeauna. n cel mai bun caz,
informaia ar putea fi parial reconstruit reieind din realizarea ei. Datorit faptului
c UML este un limbaj grafic, aceasta permite de a rezolva problemele sus
menionate, ntru-ct cu un limbaj textual de programare nu totdeauna ne permitem
acest lucru, plus la aceasta UML nu este doar un simplu sistem de simboluri grfice;
dup fiecare din ele st o semantic bine definit, astefl nct o idee conceput de un
careva elaborator poate fi interpretat doar ntr-un singur sens de ctre altul sau chiar
i de un program. Modelele elaborate n baza lui pot fi traduse automat n diverse
limbaje de programare, cum sunt C++, Java, Visual Basic, pentru construcia diferitor
aplicaii WEB i chiar n tabele relaionale ale bazelor de date. Noiunele pe care
dorim s le reprezentm grafic sunt reprezentate n UML, cele textuale prin
intermediul codului, asfel are loc realizarea proiwctrii directe, adic generarea
codului surs n orice limaj de programare concret. Poate avea loc i proiectarea
4

invers, adic trecerea de la codul surs la reconstruirea modelului. Dac nu codificm

informaia atunci aceast informaie risc de a fi pierdut la trecerea direct de la
model la cod, deacea pentru proiectarea inves sunt necesare att mijloace
instrumentale, ct i intervenia programatorului.
Limbajul UML este destinat n primul rnd elaborrii sistemelor informaionale,
ns sfera de aplicare a lui nu se limiteaz doar la modelarea produselor soft.
Expresivitatea lui permite modelarea documentelor n sistemele juridice, modelarea
structurii i funcionrii sistemelor de deservire a pacieniolor n spitale, aplicndu-se
n mare msur n urmtoarele domenii: sisteme informaionale de proporiile unei
ntreprenderi, servicii bancare i financiare, telecomunicaii, transport, n diferite
ramuri ale industriei, economie, electronica medicinal, tiin, distribuirea sistemelor
WEB, etc.

2. Noiunile i blocurile costructive ale limbajului UML

Pentru nceput vom face cunotin cu noiunea de obiect.
Obiect este o reprezentare a unei entiti din lumea real sau conceptual. Un
obiect este un concept, o abstracie sau un lucru ce are un neles i limite bine definite
n cadrul unei aplicaii.
ntr-un sistem informatic, obiectele au trei caracteristici:

Stare

Comportament

identitate
Starea unui obiect este una dintre condiiile posibile n care un obiect poate
exista. Starea obiectului se modific n timp, i este definit de valorile luate de o
submultime a mulimii de proprieti (atribute) i de relaiile pe care obiectul le are cu
alte obiecte din sistem.
De exemplu: un obiect calculator se poate afla n starea conectat dac se afl n
realie cu obiectul reea electric i n starea deconectat dac nu se afl n relaie cu
acest obiect.
Comportamentul determin modul n care un obiect reactioneaz la cererile altor
obiecte din sistem. Comportamentul este implementat prin intermediul unei mulimi
de operaii.
Indentitatea reprezint faptul c fiecare obiect este unic (chiar i atunci cnd
starea unui obiect este identic cu starea altui obiect).
n UML obiectele sunt reprezentate printr-un dreptunghi, avnd numele
obiectului subliniat i centrat n cadrul dreptunghiului.
Calculator
5

n limbajul UML sunt incluse trei blocuri de costruire:

Esenele sunt abstracii ale principalelor elemente de model
Relaiile reprezint legturile dintre esne
Diagramele efectueaz gruparea pe interese a ansamblurilor de interese.
n UML sunt patru tipuri de esene:
1. Esenele structurate sunt numite substantive n model care de obicei reprezint
prile statice, care corespund elementelor conceptuale sau fizice ale modelelor. Sunt
prevzute apte tipuri de esene structurate:
Clasa (Class) descrierea mulimei obiectelor cu acelea atribute, operaii,
relaii i semantic. Clasa poate reprezenta una sau mai multe interfee. Grafic se
reprezint cu ajutorul unui dreptunghi mprit n trei seciuni unde se indic respectiv
numele clasei, atributele i operaiile.
Numele clasei
Atributele clasei
Operaiile clasei
De expemplu clasa calculator poate avea urmtoarle caracteristici:

Atribute: perfoman, informaie, rapiditate, gabarit

Operaii: prelucarea infomaiei, afiarea informaiei, rularea programelor

Poate avea relaii cu urmtoarele obiecte ale claselor: reea, printer, scaner
Fiecare clas trebuie s aib un nume ce o deosebete de restul claselor. Acest
nume poate fi simplu i compus. Vom avea un nume compus atunci cnd pe lng
numele simplu al clasei se va indica i pachetul cruia i aparine clasa dat. Sintaxa
utilizat n acest caz este:
<numele pachetului>::<numele clasei>
Atributele sunt nume ale proprietilor clasei ce include i mulimea valorilor pe
care le pot primi exemplarele acestora. O clas poate s aib mai multe attribute sau
nici unul. Sintaxa utilizat pentru atribute este:
<specificator de acces>< numele atributului> : type=<tipul atributului>

Specificatorul de acces poate lua una din urmtoarele trei valori, care se reprezint cu ajutorul
simbolurilor speciale:

Simbolul + indic faptul c avem un atribut de tip public. Atributul este

accesibil sau vizibil din oricare alt clas a pachetului, n care este determinat
diagrama

Simbolul #indic faptul c avem un atribut de tip protected. Atributul dat

nu este vizibil i nu poate fi accesat de toate clasele cu excepia subclaselor clasei
date.
7

Simbolul - indic faptul c avem un atribut de tip private. Atributul dat nu

este vizibil sau accesibil nici unei alte clase (fr excepii).
Dac specificatorul de acces lipsete este vorba de faptul c vizibilitatea
atributului nu este indicat.
Operaiile sunt nite abstracii ce ne indic aciunele ce le putem efectua asupra
obiectelor clasei date. O clas poate avea mai multe operaii sau nici una. Sintaxa
utilizat pentru declararea operaiilor este:
<specificator de acces><numele oper.>(lista de parametri):<tipul rezltatului>
Interfaa (Interface) reprezint un asamblu de operaii care determin setul de
servicii, care poate s le asigure respectiv o clas sau component.. n aa mod
interfaa descrie compoentul vzut din exterior. Ea determin numai specificarea
operaiei semantice, dar niciodat exeutarea ei. Interfaa este reprezentat grafic printrun cercule; n form desfurat l putem reprezenta ca o clas stereotip pentru
dezvluirea operaiilor i a altor atribute.

Interaciune (Collaboration) reprezint un asamblu de roluri i alte elemente

care furnizeaz mpreun, producnd un oarecare efect de colaborare. Astfel
interaciunea areaspect att structural ct i de comportament exprimat nschimbul
mesajelor ntre o mulime de obiecte ntr-un context oarecare, n rezultat fiind atins
un scop anumit. Un mesaj este specificarea schimbului de date ntre obiecte, n timpul
cruia este transmis o informaie oarecare contnd pe faptul c drept rspuns va
rezulta o aciune concret. Una i acea clas poate s participe n mai multe
interaciuni, n aa mod ea realizeaz imaginea de comprotament care la rndul su
furnizeaz sistema. Grafic interaciunea se reprezint n felul urmtor:
Nume

Precedente (Use Case) - reprezint o descrire, o succesiune de aciuni pe care o

efectueaz sistemul i produce rezultatul urmrit de un oarecare actor. Se folosete
pentru structurizarea esenelor comportamentale i se rea lizez prin intermediul
comparrii. Grafic precedentele se noteaz astfel:
Nume

Clase active (Active class) sunt clasele obiecte care sunt atrase n mai multe
proceduri i deacea ele pot s iniializeze aciuni de comenzi. Clasa activa se
deosebete de cea obinuit prin aceea c obiectele ei reprezint elemente care
acioneaz paralel cu alte obiecte. Se noteaz asementor cu clasa obinuit, numai c
liniile de contur sunt mai evideniate:
Nume
Atibute
Operaii
Componenta - reprezint prile fizice ale sistemului care corespunde unui
sistem de interfee. Componenta reprezint prin sine o cutie fizic, care conine
elemente logice. n sistem se pot ntlni aa componente cum sunt: codurile surs,
fiiere executabile, fiiere binare. O componenta este un modul soft (cod sursa, cod
binar, dll, executabil etc) cu o interfata bine definita. Un tip de component reprezint
o parte distinct, realocabil, a implementrii unui sistem. Instana unei componente
este o unitate de implementare n execuie i poate fi utilizat pentru reprezentarea
unitilor de implementare care au o identitate n momentul execuiei. Reprezentarea
grafic a componentelor n UML este dat mai jos. Un tip de component are asociat
un nume, iar o instan a unei componente are asociate (opional) un nume i un tip. In
general numele unei componente este numele fisierului reprezentat de componenta.
Obiectele implementate de o instan de component se reprezint grafic n interiorul
simbolului instanei de component. n mod analog se reprezint grafic clasele
implementate n componente.
Componenta

Nodul (Node) este un element fizic care exist n timpul funcionrii complexului
de programe reprezentnd o resurs de calcul care de obiciei e dotat cu cel puin
un volum de memorie, iar de cele mai multe ori cu un procesor. Grafic se
reprezint sub forma unui cub care conine numere.
Elementele descise pn aici sunt esenele principale care sunt incluse n limbajul
UML, ele ns pot fi modificate n alte elemente cum sunt: actori, documente, fiiere,
biblioteci, pagini i tabele.
1.

Esene de comportament: - sunt componente dinamice ale limbajului

UML i sunt verbe, care descriu componentul modelrii n timp i spaiu.
Interraciune reprezint comportamentul , esena crora const n schimbul de
mesaje dintre obiecte n cadrul unui cotext cocret. Cu ajutorul interaciunii se poate
descrie att operaia aparte, ct i comportamentul unui asamblu de obiecte. Ea
propune un nalt set de obiecte cum sunt: comunicarea, consicutivitatea factorilor i
legturilor. Grafic se reprezint astfel:
Nume
Automatul (State machine) este descrierea succesiunii strilor prin care trece
obiectul pe parcursul ciclului su de vai, reacionnd la evenimente (inclusiv i
descrirea reaciei la aceste elemente). Grafic se reprezint printr-un dreptunghi n
cadrul cruia este descris aciunea
Aciune

Starea (State) este o situaie din viaa obiectului, pe parcursul creia el satisface o
condiie oarecare, realizeaz o activitate sau se afl n ateptarea unei condiii.
Grafic starea reprezint un dreptunghi cu colurile rotungite n cadrul creia este
descris activitatea:
Activitate

2.

Esenele de grup - sunt prile organizatorice ale limbajului UML.

Acestea sunt blocurile pe care se poate baza modelul. Exist numai o esen de grup
pachetul.
Pachetul (Packejes) este principala funcie de organizare a elementelor
modelelor n limbajul UML. Numele pachetului trebuie s conin un cuvunt chee
10

care este determunat de UML i preluat de stereotipe. n numele lui se poate conine
informaie despre proprieti i elemente. Pachetul poate s mai conin i subpachete
i nuntrul fiecrui pachet se scrie numele sau coninutul.
Pachet
Coninut

Stereotipul (Stereotype) este extinderea dicionarului UML care permite crearea

noilor tipuri de blocuri constructive, analogice cu cele existente dar specifice
pentru problema dat. El este reprezentat sub form de nume luat n ghilimele i
amplasat deasupra numelui altui element.

Relaiile
n limbajul UML sunt definite patru tipuri de relaii:
de dependen
de asociere
de generalizare
de realizare
Aceste realai sunt unice i ndeplinesc funcia de interconexiune a blocurilor de
construci ale libajului UML la crearea modelelor concrete.
Dependen (depenecy) reprezint o releie temetic dintre dou esne, prima
din ele fiind independent, iar a doua dependent de prima, adic modificarea primii
esene va provoca modificarea celei de-a doua. Grafic se reprezint astfel:

Asociere (association) reprezint o relaie structurat care descrie un asamblu

de legturi dintre obiecte.

Exist mai multe tipuri de asocieri:

agregare modeleaz o relatie de tip parte/intreg n care obiectul parte
poate face parte din mai muli intregi (n momente de timp diferite). n
reprezentarea grafic se adauga un romb gol la capatul corespunzator prii
ntreg.
compunere modeleaza o relatie de tip parte/intreg in care obiectul parte
compune un singur intreg pe toat perioada ciclului de viata i se distruge n
11

momentul distrugerii ntregului. n reprezentarea grafic se adauga un romb

plin la capatul corespunzator partei intreg

legtur (clas asociere) reprezinta o colecie de atribute care

caracterizeaz o asociere. Clasele asociere apar atunci cand nu exista un mod
logic de a plasa aceste atribute la nivelul unei clase aflate in sistem.
asociere reflexiv asociere intre obiecte ale aceleasi clase.

Generalizare reprezint un raport dintre generalizare i specializare, adic cnd

un obiect al unui element specializat poate nlocui un alt element specializat, cu alte
cuvinte modeleaz motenirea proprietailor, operaiilor si relaiilor ntre dou clase.
Clasa general poarta numele de superclas, iar clasa specializat se numete
subclas. Generalizarea apare atunci cnd orice exemplu de obiect al unei clase este
un exemplu valid de obiect al altei clase.
Genealizare reprezint un raport dintre clasificatoare, unde un clasificator
determin contactul, iar altul asigur ndeplinirea lui. Cel mai des realizarea se
ndeplinete ntre interfee i componentele ce se realizeaz, i ntre precedente i
cmponente.
Diagramele
Diagramele n UML sunt reprezentri grafice ale unui set de elemente. O diagram
n UML este analogic unui graf, vrfurile cruia sunt esenele, iar ramurile
realaiile. Unul i acela element poate fi reprezentat ntr-un numr mai mare de
combinaii, de aici rezult mai multe tipuri de diagrame.
Limbajul grafic UML permite elaborarea a nou tipuri de diagrame:
1. diagrama claselor
2. diagrama obiectelor
3. diagrama precedentelor
4. digrama succesiunelor
5. diagrama interaciunii
6. diagrama de stare
7. diagrama de aciune
8. diagrama componentelor
9. diagrama de desfasurare
Diagrama cazurilor de utilizare (Use case diagram)

12

Diagramele de cazuri de utilizare au rolul de a reprezenta ntr-o form grafic

funcionalitile pe care trebuie s le ndeplineasc sistemul informatic n faza sa
final.
Diagrama claselor (Class diagram)
Diagramele de clase fac parte din categoria diagramelor statice. Ele descriu
structura intern a sistemului informatic prin identificarea claselor, a atributelor i
operaiilor acestora i a relaiilor dintre clase.
Diagrama de secven i colaborare (Sequence diagram and Colaboration
diagram)
Un scenariu reprezint o cale (un drum) prin fluxul de evenimente al unui caz de
utilizare. Scenariile descriu o secven de aciuni concrete care pot avea loc la un
moment dat n sistem. Scenariile se descriu prin intermediul aa-numitelor diagrame
de interaciune. n UML avem dou tipuri de diagrame de interaciune: diagramele de
secven i de colaborare. Fiecare dintre aceste diagrame reprezint o vedere grafic
diferit a unui scenariu.
Diagramele de secven prezint interaciunile care au loc ntre diverse obiecte
ale unui sistem, ordonate cronologic. Ele determin obiectele i clasele implicate ntrun scenariu i secvenele de mesaje transmise ntre obiecte necesare ndeplinirii
funcionalitii scenariului. Diagramele de secven sunt asociate unui caz de
utilizare.
Deoarece diagramele de secven ofer o imagine temporal a scenariului ele
sunt utile n fazele timpurii ale analizei pentru identificarea obiectelor si claselor, pe
cnd diagramele de colaborare surprind legturile dintre obiecte, acestea sunt utile la
faza de proiectare, atunci cnd se modeleaz implementarea relaiilor.
Diagrame de tranziie a strilor (State machine diagram)
UML furnizeaz diagramele de tranziie a strilor i diagramele de activiti
pentru modelarea comportamentului obiectelor n interiorul lor. Una din aceste
diagrame este diagrama de tranziie a strilor.
Diagrame de componente (Component diagram)
O diagram de componente prezint dependenele existente ntre diverse
componente software (cod surs, cod binar, executabile, librarii cu legare dinamica
etc) ce compun un sistem informatic. Aceste dependene sunt statice (au loc in etapele
de compilare sau link-editare) sau dinamice (au loc in timpul execuiei).

13

Diagrame de exploatare (Deployment diagram)

Diagramele de exploatare prezint configuraia elementelor de procesare din
timpul execuiei i componentele, procesele i obiectele care le conin. Instanele
componentelor soft reprezint manifestri a unor uniti de cod n cadrul execuiei.
Instrumentul Rational Rose conine un editor de diagrame de exploatare particulare.

3.

Elaborarea modelului

n lucrarea dat avem ca sarcin: Analiza principiilor implimentarii modelelor de

desenare a curbelor shi suprafetelor, astfel vom ncerca s facem un prototip al unui
program de desemare MS Paint, elaborat de compania Microsoft Software. Pornind de
la aceasta, vom elabora i explica toate diagramele necesare acestui proiect pornind cu
diagrama cazurilor de utilizare.
Diagramele variantelor de utilizare
Reprezint interaciunea dintre variantele de utilizare, care sunt funciile
sistemului i persoanele n acest sistem. Adic prezint persoane sau sisteme, care
primesc sau transmit informaia n sistema dat. Pe diagram sunt prezente aciunile
reciproce dintre variantele posibile de utilizare i persoane. Ea reflect cerinele ctre
sistem din punct de vedere al utilizatorului. n aa mod variantele de utilizare este o
funcie efectuat de sistem, iar persoanele sunt persoane cointeresate de sistemul
elaborat. Diagrama arat care persoane iniiaz diagrama variantelor de utilizare. La
fel din ea se vede cnd persoanele cointeresate primesc datele de la variantele de
utilizare. Din diagramele variantelor de utilizare se poate de aflat mult informaie
referitor la sistem. Acest tip de diagram descrie funcionarea sistemei la general.
Utilizatorii, managerii proiectrii, analiticii, specialitii n domeniu i toi cei care sunt
cointeresai n sistemul dat pot s neleag ce poate face sistemul n cauz.
Diagramele variantelor de utilizare conin, firesc, variante de utilizare, actori i
legturi ntre ei.
Diagramele variantelor de utilizare conin, firesc, variante de utilizare, actori i
legturi ntre ei. Varianta de utilizare (Use Case) este prezentarea cea mai general a
funciilor sistemului. Actorul (Actor) tot ceea ce interacioneaz cu sistemul dat.
Variantele utilizrii i actorii definesc cadrul de folosin pentru care este creat
aplicaia. Variantele utilizrii definesc tot ceea ce se petrece n interiorul sistemului,
iar actorii ceea ce e n afara lui.
Cum am mai menionat mai sus, variantele de utilizare i actorii rspund la
ntrebarea Ce va face sistemul?, ns nu i la ntrebarea Cum o va face sistemul?.
Unul din avantajele folosirii diagramei variantelor este acela c ea ne permite s
nelegem ce din punct de vedere funcional va face sistemul elaborat i cu cine/ce va
interaciona. nct informaia este prezentat grafic i este uor inteligibil, clienii
14

care au comandat elaborarea sistemului nu trebuie s aib nici un fel de cunotine

tehnice sau de un alt fel.
Este larg practicat elaborarea a ctorva diagrame a variantelor pentru un sistem.
Unele descriu grupele principale variantelor de utilizare, altele legturile ntre ele i
actori; numrul lor depinde de cel care le elaboreaz. De notat, ns, c ele trebuie s
conin un volum mare de informaii utile nct astfel de diagrame sunt greu de
neles.
Scopul principal al diagramelor variantelor de utilizare este documentarea tuturor
variantelor de utilizare (funciile sistemului), actorilor (ceea ce e n afara sistemului cu
care el interacioneaz) i a legturilor ntre ei.
E bine de urmat urmtorii pai n timpul elaborrii diagramelor variantelor:
Nu modelai legturi ntre actori. Din definiie actori sunt n afara
sistemului, ce nseamn c legturile ntre ei nu sunt regulate de sistem
Nu conectai dou diagrame variantelor(cu excepia a ctorva exemple )
Fiecare varianta de utilizare este iniializat de un actor, de aceea orice
sgeat ncepe la un actor i se termin la o variant de utilizare(exist
excepii)
Gndii la baza de date ca la un strat de sub diagram. Prontr-o variant de
utilizare datele sunt introduse n baza de date, iar scoase printr-o alt.
Varianta de utilizare este o prezentare general a funcionalitii sistemului, cu
alte cuvite ele arat cum sistemul poate fi folosit.

Avantajul principal a variantelor de utilizare este c folosindu-le separm

implementarea sistemului de descrierea funciilor sale. Acest fapt ajut concentrarea
ateniei pe aa ntrebri ca satisfacerea cerinelor ctre sistem fr a avea nevoie de a
defini cum sistemul va fi implementat. Diagramele variantelor ne arat ce sistemul va
face i cum poate fi utilizat nc la nceputul proiectului.
Metoda diagramelor variantelor de utilizare nu este cea standard i difer de ea
foarte mult. Separnd proiectul n diagramele variantelor noi atragem atenia mai mult
procesului de percepere a sistemului, nu i felului de implementare a lui.
Decompoziia funcional are ca scop devizarea poiectului n subprobleme cu care se
va confrunta sistemul, apoi diagramele variantelor atrag atenia asupra aspiraiilor
utilizatorului ctre sistem.

15

La nceputul oricrui proiect apare ntrebarea: Care sunt variantele de utilizare

pentru proiectul dat?. Este preferabil de citit atent documentaia clientului, luai n
vedere opinia oricrui utilizator care va folosi acest sistem. Este bine s obinei
rspunsuri la urmtoarele ntrebri de la fiecare din viitorii utilizatori a sistemului:
Ce vrea s fac cu sistemul?
Va lucra cu informaie(introducere, tregere, etc)?
Va fi nevoie de a informa sistemul despre careva evnimente din afar?
Va fi nevoie ca sistemul s informeze utilizatorul despre careva
evenimente?
Setul de variante de utilizare creat ajut familiarizarea utilizatorilor cu funciile
sistemului la nivelul cel mai general, de aceea dac numrul lor este foarte mare
elasticitatea i uurina de percepere se pierde; de obicei un proiect are 20-50 de
variante de utilizare. Pentru a organiza schema mai bine variantele de utilizare pot fi
strnse n pachete.
Variantele de utilizare atrag atenia asupra cererilor utilizatorilor ctre sistem.
Fiecare variant de utilizare prezint o tranzacie terminat ntre utilizator i sistem.
Denumirile variantelor de utilizare trebuie s fie alese din sfera de utilizare a
sistemului, nu i din cea tehnic, prin aceasta se ajunge la o mai bun nelegere a
sistemului de ctre utilizatori. De obicei variantele de utilizare sunt numite folosind
verbe care descriu rezultatul tranzaciei respective. Utilizator nu este curios s tie
cum se va face una sau alta varianta de utilizare, pe el l interiseaz doar rezultatul
final al tranzaciei.
Pentru a fi sigur c orice variant de utilizare este prezent n modelul respectiv
este necesar de a:
1. controla c orice cerin funcional este prezent cel puin ntr-o variant de
utilizare.
2. lua n consideraie cum va interaciona cu sistemul oricare din utilizatori
finali
3. ce fel de informaie va introduce/scoate din sistem utilizatori
4. cine va porni/opri sistemul dat
5. toate sistemele din afar cu care va interaciona sistemul dat i ce fel de
informaie va fi trimis ntre ele.
Actorii sunt tot ceea ce interacioneaz cu sistemul elaborat. n timp ce variante
de utilizare descriu evenimente din interiorul sistemului, actorii descriu ceea ce este n
afara lui. n limbajul UML actorii se reprezint prin urmtoare figur

16

Exist trei tipuri de actori: utilizatori, alte sisteme ce interacioneaz cu sistemul

dat i timpul.
n primul tip intr persoane fizice, ele sunt prezente n majoritatea sistemelor.
Denumind actori folosii nume-rol i nu profesia sau postul lor, nct un om concret
la diferite momente de timp poate reprezenta diferii actori. Dimineaa el poate fi
lucrator din banca, iar la amiaz client care vrea s scoat bani din contul su.
Folosind nume-rol nu va trebui s schimbai modelul de fiecare dat cnd apar noi
posturi sau cnd drepturile i obligaiile unui post sunt schimbate.
Tipul doi sunt alte sisteme, fie banca are o sistem credit care prelucreaz
conturile de credit ale clienilor. nct sistemul elaborat trebuie s interacioneze cu
sistema credit, ultima devine un actor.
Timpul devine un actor n cazuri cnd de el depind careva procese din sistem, de
exemplu la o or stabilit se ncep procese de serviciu, nct noi nu putem controla
timpul el devine un actor.
Limbajul UML presupune un numr de legturi ntre actori i variante de
utilizare. Aceste legturi sunt de comunicaie(communication), de utilizare(uses), de
extindere(extends) i de generalizare(actor generalization). Legturile de
comunicaie descriu legturile ntre actori i variante de utilizare. Cele de utilizare i
de extindere numai ntre variante de utilizare, iar cele de generalizare ntre actori.
Legturi de comunicaie
Este legtura ntre un actor i o variant de utilizare. n limbajul UML este
prezentat n forma unei sgei:

Direcia sgeii indic pe cel care a iniializat comunicaia.

Legturi de utilizare
O legtur de utilizare (Uses relationship) ofer posibilitatea ca o variant de
utilizare s folosesc funcionalitatea altei variante de utilizare. Cu ajutorul acestei
legturi se modeleaz comportamentul care se ntlnete n mai multe variante de
utilizare.
Legtura de utilizare n limbajul UML este prezentat cu ajutorul unei sgei i
cuvntului <<uses>>
Legturi de extindere
Legturi de extindere(Extends relations) sunt asemntoare celor de utilizare,
ns varianta concret de utilizare poate i s nu foloseasc funcionalitatea varinatei
de utilizare abstracte cu care este legat prin legtura de extindere. n limbajul UML
astfel de relaii se reprezint printr-o sgeat cu cuvntul <<extends>>

17

Cu ajutorul relaiei de generalizare noi accentm atenia asupra faptului c mai

muli actori au caliti comune. De exemplu clienii pot fi de dou tipuri: persoane
fizice i persoane juridice.
De obicei acest fel de relaii este util cnd comportamentul unui tip de actori
difer de cel a altui tip ntr-aa fel nct cauzeaz aciunile sistemei. De exemplu dac
un tip de actori poate iniializa un fel de variant de utilizare, iar al doilea nu poate,
atunci este bine s introducem ambele tipuri ca fiind generalizri a unui tip comun.
ns dac tip A i tip B iniializeaz aceleai variante de utilizare cu mici diferene este
mai preferabil s nu crem 2 tipuri de actori generalizate, ci s implementm
prelucrarea n fluxul de evenimente a variantei de utilizare.
Notie
n timpul lucrului asupra proiectului este binevenit ataarea unor notie scurte
elementelor de pe diagram. Mai trziu va fi uor de a percepe destinaia sau alte
caracteristici ale elementului.
Pachete
n limbajul UML elementele de tipul variantelor de utilizare, actori, clase i
componente pot fi grupate n pachete (packages) i se reprezint n felul urmtor:
Numrul pachetelor care pot fi create este nelimitat, este chiar posibil de a plasa un
pachet n altul.

18

3.1 Diagrama Use Case

Fig.3.1 Diagrama caz de utilizare User

In diagrama data sunt aratate cazurile de utilizare pentru un utilizator, ce nu este
inregistrat in sistem. Un astfel de utilizator nu poate face nici un fel de modificare
in system, el poate vizualiza doar continul paginilor site-ului vizitat. De asemeni el
se poate inregistra pentru a primi anumite drepturi in sistem.

Fig .3.2 Diagrama caz de utilizare Author

19

In aceasta diagrama sunt prezentate cazurile de utilizare pentru un utilizator cu

drepturile de autor. Acest utilizator poate vizualiza continutul paginilor site-ului, la
fel ca si orice alt utilizator. Autorul mai are si alte drepturi: adaugarea unui content
nou, editarea unui content existent sau stergerea unui content. Aceste actiuni pot fi
efectuate doar dupa autentificarea in sistem.

Fig. 3.3 Diagrama caz de utilizare Moderator

Diagrama data arata cazurile de utilizare pentru utilizatorul cu drepturi de
moderator. Acest utilizator de asemeni poate vizualiza continutul paginilor siteului, la fel ca utilizator simpli sau autorii. Pe linga astea moderatorul mai are
dreptul de aprobarea a contentului adaugat de autori. El verifica daca autorii au
respectat regilile la adaugarea contentului, si doar dupa aprobare, contentului va fi
vizibil pentru alti utilizatori.

20

Fig.3.4 Diagrama caz de utilizare AddContent

Cazul de utilizare AddContent include citeva cazuri de utilizare. Pentru a adauga
un content nou, trebuie de specificat titlul contentului, de introdus textul
(continutul), imagini (la dorinta), si de formatat textul(font, color, font-size etc.).

Fig.3.5 Diagrama caz de utilizare EditContent

Editarea contentului include mai multe actiuni: schimbarea titlului, modificarea
continutului, reformatarea textului, adaugarea unor imagini noi sau stergerea celor
existente.
21

3.2 Diagrama de segventa si colaborare

Fig. 3.6 Diagrama de Secventa Authentication

Fig.3.7 Diagrama de Colaborare Authentication

Cind un autor incearca sa adauge sau sa editeze un content, serverul ii cere sa se
autentifice. El trebuie sa introduca login si password, si daca in baza de date se
gaseste un utilizator cu asa credentiale, se face logarea in sistem.
22

Fig 3.8 Diagrama de Secventa ContentVisualization

Fig.3.9 Diagrama de Colaborare Generate ContentVisualization

Cind un utilizator acceseaza o pagina, serverul prelucreaza cererea, cautind
pagina ceruta, in caz ca exista o asa pagina, se extrage din baza de data contentul
pentru pagina data, si cu ajutorul Content Delivery Application se genereaza fisierul
.html, care este trimis ca raspuns browser-ului si afisat utilizatorului
23

Fig 3.10 Diagrama de Secventa AddContent

24

Fig.3.11 Diagrama de Colaborare AddContent

Pentru ca un autor sa poata adauga un content pe site, el trebuie mai intii sa fie
autentificat. Accesind pagina de adaugarea a contentului, autorului i se ofera o forma
pentru completare, in care el trebuie sa introduca titlul contentului si continul lui.
Dupa ce forma este trimis catre server, acesta o prelucreaza si o salveaza in baza de
date.

25

Fig 3.12 Diagrama de Secventa EditContent

26

Fig.3.13 Diagrama de Colaborare EditContent

Pentru a edita un content, autorul trebuie sa acceseze pagina cu lista contenturilor existente si sa aleaga contentul ce doreste sa-l modifice. Lui i se ofera, ca si in
cazul adaugarii, o forma, insa deja completata cu datele contentului ales. Dupa
executarea modificarilor dorite, forma este trasmisa serverului, iar el salveaza
contentul modificat in baza de date.

27

Fig 3.14 Diagrama de Secventa DeleteContent

28

Fig.3.15 Diagrama de Colaborare DeleteContent

Ca si pentru orice alta operatie, este necesara autentificarea in sistem. Ca si in
cazul editarii, utilizatorul acceseaza pagina cu lista content-urilor. Dupa alegerea
contentul ce urmeaza sa fie sters, se transmite serverului o cerere de stergere,
serverul cauta contentul in baza de date, si in cazul gasirii, in sterge. Utilizatorului i
se afiseaza lista cu content-uri, deja fara contentul sters.

29

Fig 3.16 Diagrama de Secventa AproveContent

30

Fig.3.17 Diagrama de Colaborare AproveContent

Dupa adaugarea sau editarea unui content, el trebuie sa fie verificat daca
corespunde tutror regulilor. Un moderator acceseaza o pagina cu lista contenturilor neaprobare, alege un content, verifica daca acesta corespunde regulitor. Daca
contentul corespunde regulilor, serverului este trimis o cerere, acesta modifica
statutul de aprobare a content-ului, dupa care contentul va putea fi vizualizat de alti
utilizatori.

31

3.4 Diagrama claselor

Fig.3.18 Diagrama de Clasa Users

Aceasta diagrama arata tipurile de utilizatori din sistem, si modul de interactiune a
lor cu sistemul. Avem 3 tipuri de utilizatori: User, Moderator si Author. Ultimii 2
tot pot fi tratati ca useri, deoare au si ei aceleasi drepturi ca userii. Toate tipurile de
utilizatori interactioneaza cu sistemul prin intermediul unui browser.

Fig. 3.19 Diagrama de Clasa CMS

32

Diagrama precedenta, arata structura sistemului CMS, care este format dintr-un
server, functia lui fiiind de primire, prelucrare si transmitere a cererilor; o baza de
date, in care se pastreaza toata informatia; si o aplicatie care folosind informatia din
baza de date, genereaza fisierele html, care ulterior vor fi transmise de catre server
browser-ului utilizatorului.

Fig. 3.20 Diagrama de Clasa UserCMS

Aceasta diagrama arata legatura dintre utilizator si CMS. Utilizatorii prin
intermediul browser-erelor, fac legatura cu serverul. Dupa multitudinea relatiilor, se
observa ca server, este doar unul, insa la el se pot adresa mai multi utilizatori.
33

3.5 Diagrama de stare

Fig. 3.21 Diagrama de Stare Authentication

La autentificare sistemul trece prin citeva stari. Dupa deschiderea paginii de
autentificare, sistemul asteapta ca utilizatorul sa introduca credentialele sale, dupa
introducerea lor, sistemul se afla in stare de verificare a corectitudiinii lor. Daca ele
nu sunt corecte, se trece in starea retry, si utilizatorul este nevoit sa le introduca din
nou. In cazul in care credentialele sunt corecte, are loc logarea, si sitemul trece in
starea user logged.

34

Fig. 3.22 Diagrama de Stare AddContent

La adaugarea unui content sistemul trebuie sa treaca mai intii prin starea user
authentificated. Dupa deschiderea paginii de adaugare, si inainte de transmiterea
datelor, trebuie sa fie parcurse 3 stari: titlul introdus, textul introdus si imaginile ales.
Salvarea contetului in baza de date se face dupa trimiterea formei de adaugare, dupa
trecerea de starea content saved, se afiseza pagina cu contentul adaugat.

35

Fig. 3.23 Diagrama de Stare EditContent

36

La modificarea unui content, trebuie mai intii sa fie afisata lista content-urilor
existent si sa fie ales contentul ce va fi editat. Dupa asta sistemul poate trece prin 3
stari paralele, insa ca nu sunt obligatorii, si anume: textul modificat, titlul modificat si
imaginile modificate. Dupa trecerea prin una din ele, sau prin toate, are loc
transmiterea datelor catre server, si dupa ce au fost salvate modificarile, are loc
afisarea pagina cu content-ul editat.

Fig. 3.24 Diagrama de Stare DeleteContent

Pentru stergerea unui content, trebuie afisata pagina cu content-urile existente, se
alege contentul dorit, si se sterge. Dupa ce contentul a fost sters, se afiseaza iarasi lista
de content-uri existente, si se poate repeta lantul de actiuni pentru un alt content, sau
se poate parasi pagina.

37

3.6 Diagrama de activitate

Fig. 3.25 Diagrama de Activitate Authentication

Pentru a se autentifica utilizatorul trebuia sa faca unele actiuni, si anume: sa
deschida pagina de logare, sa introduca credentialele sale si sa transmita serverului
cererea de logare. Serverul, primind cererea, va cauta in baza de date utilizatorul cu
credentialele primite. Daca exista un astfel de utilizator, se deschide pagina principala

38

dupa logare, in caz ca nu exista asa ucredentiale, utilizatorul este nevoit sa le

introduca din nou.

Fig. 3.26 Diagrama de Activitate ContentVisualization

La vizualizarea unui pagini, serverul verifica daca exista pagina ceruta. Daca
pagina nu exista, se va afisa un mesaj de eroare. Insa daca exista pagina data, se va
extrage din baza de date contentul pentru pagina respectiva, se va genera fisierul html
cu contentul scos din baza de date, si sa va afisa utilizatorului.
Diagrama urmatoare reprezinta activitatile pentru adaugarea unui content pe site.
Pentru aceasta trebuie sa se execute autentificarea si sa se deschida pagina de
adaugarea a contentului. Dupa care se va introduce titlul contentului, textul
continutului sau si imagine din el. La finisrea introducerii datelor respective, ele
39

trebuie trimiste catre server. Ultimul le va salva in baza de date si va afisa pagina cu
contentul adaugat utilizatorului.

Fig. 3.27 Diagrama de Activitate AddContent

Urmatoarea diagrama reprezinta activitatile pentru editarea unui content, care se
aseamna cu cele din diagrama precedenta. Insa la editare, trebuie deschisa pagina cu
40

lista content-urilor existente si de ales contentul ce dorim sa-l modificam. Restul

actiunilor sunt ca si la adaugarea contentului.

41

Fig. 3.28 Diagrama de Activitate EditContent

42

3.7 Diagrama de componente

Fig. 3.29 Diagrama de Componente Visualization

Vizualizarea contentului unei pagini se face, evident, prin intermediul unui
browser. Acesta depinde de fisierul html, ce il primeste de la server. Serverul
depinde de aplicatia ce generea documentele html. Ultima depinde de baza de date,
deoarece genereaza documentele in baza informatiilor extrase de acolo.

Fig. 3.30 Diagrama de Componente Content

Fiecare pagina contine un content, cu alte cuvinte, un articol. Acesta trebuie sa aiba
un titlu si un continut. Continul la rindul sau este compus din text si imagini.

43

Fig. 3.31 Diagrama de Componente Page

Fiserele html sunt generate de catre Content Delivery Application, in baza unui
Layout si unui Content (informatii extrase din baza de date).

3.8 Diagrama de amplasare

Fig.3.32 Diagrama de amplasare

Diagrama de aplasare arata toate elemente ce sunt folosite in sistem, si legaturile
dintre ele. Utilizatorul cu ajutorul calculatorului sau prin intermediul internetului
face legatura cu serverul. Serverul se leaga cu baza de date, care se poate afla chiar
pe server, sau poate aplasata si pe un alt server.

44

4.

Concluzii

Lucarea dat modeleaz i analizeaz un produs soft n cazul dat acesta fiind un
CMS (Content Management System). La elaborarea modelului m-am bazat pe
principiile limbajului UML, folosind ca instrument de lucru mediul Enterprise
Architect. n procesul elaborrii proiectului am cptat deprinderi de abordare
sistemic a problemelor de proiectare i de programare a sistemelor complexe ,
prezentnd posibilitile de modelare ale sistemelor pe exemplul CMS-ului, cu
ajutorul mediului de programare Enterprise Architect.
Limbajul UML uureaz elaborarea, vizualizarea i documentarea modelelor, ceea
ce permite o proiectare rapid a sistemelor, prin accentuarea ateniei aspra aspectelor
necesare proiectrii. Analiznd sistemul dat n baza metodologiei APOO i trecnd
prin etapele planificrii, sincronizrii i analizei am dezvoltat modelul dat n
diagramele de interaciune i diagrama claselor n care am descris fiecare caz de
utilizare prin interaciunea dintre obiecte.
Datorit diagramelor utilizate modelul poate fi ilustrat din mai multe puncte de
vedere. Diagrama cazurilor de utilizare descrie aplicaiile principale ale CMS-ului.
Diagrama claselor descrie structura unui sistemului n viziunea mea, adic arat toate
seciunele lui i destinaia fiecreia. Diagramele interaciunelor i colaborrilor
descriu cum se desfoar funciile unui astfel de sistem.

45

5.

Bibliografie

1.

Ovidiu Gheorghies,Ingineria programarii (UML),7octombrie 2002

2.

Prieto-Diaz, R. and Arango, G. 1991. Domain Analysis and Software

Systems Modeling. Las Alamitos, California: Computer Society Press of the
IEEE.

3.

Knoepfel, Andreas; Bernhard Groene, Peter Tabeling (2005). Fundamental

Modeling Concepts - Effective Communication of IT Systems.
4.

Melnic Radu, AMSI conspectul, UTM (2010).

46