Sunteți pe pagina 1din 50

MODELAREA SISTEMELOR INFORMATICE

Modelele construite pe parcursul dezvoltarii unui sistem sunt reprezentari abstracte ale sistemului. Fiecare model
reflecta o anumita vedere asupra sistemului si corespunde unui nivel de detaliu.
In etapa de analiza se construiesc modele care exprima cerintele impuse sistemului. Modelele de analiza 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.
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.
Fiecare vedere asupra unui sistem poate avea aspecte structurale si aspecte comportamentale. In functie de
natura sistemului, unele modele pot fi mai importante decat altele. De exemplu, pentru unele sisteme sunt mai
importante aspectele structurale si functionale, pentru altele aspectele temporale.
Construirea modelelor este ghidata de metode. O metod definete o abordare reproductibil care permite
obinerea de rezultate fiabile n mod repetat. Toate domeniile cunoaterii utilizeaz metode mai mult sau mai
puin sofisticate i mai mult sau mai puin formalizate. De exemplu, buctarii utilizeaz re ete de buc tarie,
arhitecii construiesc planuri, muzicienii urmeaz reguli de compoziie.
Modelele sunt alcatuite din elemente de modelare care constituie concepte fundamentale pentru
reprezentarea sistemelor sau a fenomenelor. Elementele de modelare sunt adesea notatii grafice. Ele constituie
limbajul de modelare.
In plus fa de limbajul de modelare, o metod definete reguli de aplicare care descriu coordonarea
diferitelor puncte de vedere, nlanuirea aciunilor, ordonarea sarcinilor si repartizarea responsabilitilor.
Principalele scopuri ale modelarii sistemelor informatice 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.


2.1. Metode de analiza si de proiectare
Proiectarea unui sistem are loc pe baza unei specificatii a cerintelor, deci este o continuare a procesului de

analiza. Metodele de proiectare sunt strans legate de cele folosite in analiza, modelele de proiectare fiind adesea
construite plecand de modelele de analiza. De aceea, multe dintre metodele de dezvoltare a programelor furnizeaza
atat elemente de modelare utile in analiza cerintelor cat si elemente de modelare specifice fazei de proiectare.
Exista doua strategii de structurare a unui sistem informatic, pe baza carora metodele de analiza si
proiectare sunt clasificate in metode funcionale i metode orientate obiect.
2.1.1. Metodele funcionale
Aceste metode i au originile n dezvoltarea limbajelor procedurale. Mai orientate c tre prelucr ri
dect spre date, ele propun o abordare ierarhic descendent, bazat pe descompunerea prelucrrilor care trebuie
sa fie efectuate de un sistem. Principalul instrument de analiz este diagrama de flux de date. Metodele de analiz
structurat Structured Analysis) i de proiectare structurat Structured Design) sunt reprezentative pentru
aceast categorie de metode. Ele cuprind un ansamblu de notaii pentru specificarea programului. Astfel, n
timpul fazei de analiz se folosesc diagrame de flux de date, diagrame de st ri/tranzi ii i diagrame

entitate/legatur. In faza de proiectare sunt adugate detalii modelelor de analiz i plec nd de la diagramele de
flux de date sunt construite diagramele de structur.
Diagramele de flux de date
Se folosesc pentru a modela transformrile datelor pe masur ce acestea tranziteaz sistemul. O diagram de flux
de date este alctuit din blocuri de prelucrare i blocuri " rezervoare de date". Fluxul datelor este reprezentat prin
sgei. Fig. 2.1 ilustreaz tratarea propunerilor fcute unei ntreprinderi de ctre societi de servicii[ ].
Prelucrrile sunt reprezentate prin elipse iar rezervoarele prin dreptunghiuri.

Fig. 2.1. Diagrama de flux de date


Plecnd de la diagrama de cel mai nalt nivel, prelucrrile complexe sunt descompuse recursiv n
subdiagrame pn la prelucrri simple, uor de implementat. Prelucrrile simple sunt specificate n pseudocod,
folosind tabele de decizie, sau alte tehnici.
Diagramele de flux de date sunt simple si intuitive. Ele pot fi folosite ca mijloc de comunicare cu
potentialii utilizatori ai sistemului care participa la validarea cerintelor. Totodata, la nivelul proiectarii
arhitecturale, ele pot reflecta schimbul de date intre sub-sisteme. Nu sunt adecvate pentru modelarea subsistemelor cu interfete complexe. Este necesara o diagrama pentru fiecare intrare particulara.
Diagramele de stri-tranziii
Se folosesc pentru a modela comportamentul dependent de timp al sistemului. Ele sunt similare celor din
notaia UML prezentate n paragraful 2.3.).
Diagramele entitate/legatur ER)
Reflecta relaiile dintre rezervoarele de date. Fiecare "entitate" corespunde unui rezervor de date dintr-o
diagram de flux de date. Relaiile dintre entiti sunt numite "asocieri". Entitile i asocierile pot fi
caracterizate prin atribute. Figura 2.2 pune n eviden trei entiti: proiect, propunere i societate servicii,
reprezentate prin dreptunghiuri, fiecreia fiindu-i asociate atribute. De exemplu, entitii proiect i se asociaz un
cod proiect care identific ntr-o maniera unic proiectul, un nume de proiect, un nume de responsabil i o dat
limit.

Fig. 2.2. Diagrama entitate/legatur.


Proiectarea structurat urmeaz analizei structurate i stabilete modalitile concrete de realizare a
sistemului. De exemplu, prelucrrile din diagramele de flux de date sunt grupate n task-uri i alocate proceselor
sistemului de operare.
Diagramele de structur
Modeleaza arhitectura unui sistem ca o ierarhie de module funcii) i o prezint sub forma unei structuri
arborescente figura 2.3). Modulele sunt reprezentate prin noduri iar conexiunile intre module prin arce. Un arc
conecteaza un modul, situat pe nivelul n, de modulul care-l apeleaza, situat pe nivelul n-1). Parametrii de intrare
i de ieire sunt indicai de-a lungul conexiunilor, prin texte si sageti.
Pot fi construite mai multe diagrame de structura pornind de la o diagrama de flux. Proiectantul trebuie sa
aleaga solutia care conduce la componente slab cuplate si cu o coeziune interna puternica.

Fig 2.3. Diagrama de structur.


Identificarea modulelor program pornind de la o diagrama de flux este simplificata daca se aloca fiecarui modul
una dintre urmatoarele functii, derivate din fluxul datelor figura 2.4):

Figura 2.4. Tipuri de module program


Un modul de intrare accepta date de intrare ale sistemului sau date de la un modul situat pe un nivel mai
coborat al diagramei si le transfera unui modul situat pe un nivel superior, intr-o forma transformata. Un modul de
transformare accepta date de la un modul de nivel superior, le transforma si le transfera inapoi modulului.
Mai intai se identifica modulele de intrare-iesire la cel mai inalt nivel de 21121n1315v abstractizare. Procesul
se repeta pentru fiecare dintre blocurile definite pe primul nivel, etc. Intr-un proiect bine structurat fiecare nod al
diagramei de structura trebuie sa aiba 2-7 descendenti.
Dicionarul de date
Conine detalii care nu sunt cuprinse n diagramele prin care se modeleaza sistemul. El descrie fluxuri de
date, rezervoare de date, entitati, module i semnificaia numelor atribuite.
Dictionarul de date este un mijloc de management al numelor. El nu este specific unei metode de
dezvoltare. Un sistem mare este modelat de un numar mare de persoane, fiecare adaugand diverse nume pentru
entitati si relatii. Pot sa apara inconsistente si conflicte de denumiri. Dictionarul de date permite verificarea
unicitatii numelor. Crearea, actualizarea si interogarea dictionarului de date sunt necesare pe intreaga durata de
viata a unui sistem. Aceste operatii trebuie sa fie efectuate cu ajutorul unui program al mediului de dezvoltare.
2.1. 2. Metode orientate obiect
Aceste metode se bazeaz pe conceptele de clas, obiect, abstracie, specializare i comunicare prin
mesaje.
Analiza orientat obiect permite examinarea unei probleme punndu-se n eviden clasele sub form de
componente independente i obiectele care interacioneaz dup modaliti bine definite. Rezultatele unei
asemenea analize pot s serveasc de baz pentru o proiectare orientat obiect.
In majoritatea metodelor orientate obiect, studiul unei probleme este realizat urmrind trei aspecte:
aspectul static sau descriptiv, care red obiectele i legturile dintre ele;
aspectul dinamic, care precizeaz comportamentul obiectelor, diferitele stri prin care ele trec i evenimentele
care declaneaz trecerea dintr-o stare n alta.
aspectul funcional, care precizeaz funciile realizate de obiecte prin intermediul metodelor.
Metoda Grady Booch

Metoda propus de Booch este o metod de proiectare definit iniial pentru programare n ADA, apoi
generalizat pentru alte limbaje. Ea propune patru etape:
- identificarea obiectelor i a claselor la un nivel de abstracie dat;
- precizarea semanticii claselor precum i a interfeei fiecrei clase;
- identificarea relaiilor dintre clase, distingnd pe de o parte aspectele statice iar pe de alt parte aspectele
dinamice;
- implementarea claselor i a comunicaiei dintre obiecte.
Abordarea nu este nici ascendent, nici descendent. Este mai degrab o metod de proiectare
incremental i iterativ.
Metoda Jackson Jackson Structured Development )
Metoda JSD este, n particular, celebr n Europa. JSD nu face distincie ntre analiz i proiectare,
cele dou faze find grupate ca activitate de specificare. JSD divizeaz dezvoltarea sistemelor n dou etape:
specificarea i apoi implementarea. Metoda este conceput n special pentru aplicaii n care este important
elementul timp. Ea utilizeaz modele grafice ca cele din SA/SD, OMT i alte tehnici.
Un model JSD descrie lumea real n termeni de entiti, de aciuni i de ordonare a ac iunilor.
Dezvoltarea unui program const din ase etape secveniale: etapa aciune a entittilor, etapa de structurare a
entitilor, etapa de modelare iniial, etapa funcie, etapa de analiz a aspectelor temporale ale sistemului i
etapa de implementare.
In timpul etapei de aciune a entitilor, sunt identificate entitile i aciunile din lumea real domeniul
problemei). Alegerea este ghidat de scopul realizrii sistemului. Etapa folosete ca intrare defini ia cerintelor; ea
produce o list de entiti i de aciuni. Aciunile se petrec n lumea real. Ele au loc la momente de timp date,
sunt atomice i nedecompozabile. Etapa de structurare a entitilor ordoneaz parial aciunile fiecrei entiti
n timp. Etapa de modelare iniial face legtura ntre lumea real i modelul abstract. Etapa funcie utilizeaz
pseudocod pentru descrierea aciunilor. La sfrsitul acestei etape, se dispune de o specifica ie complet a
sistemului cerut.
Etapa de analiz a aspectelor temporale ale sistemului examineaz modul n care modelul se poate
decupla de lumea real. Rezultatul acestei etape este un ansamblu de note informale asupra constr ngerilor de
performan. Etapa de implementare se concentreaz pe problema proceselor i a aloc rii lor la procesoare.
Numrul de procese poate fi diferit de numrul de procesoare. Dup cele ase etape se scriu programele i se
concepe baza de date.
OMT Object Modeling Technique)
OMT propune modelarea unui sistem pe baza a trei puncte de vedere corelate dar distincte, fiecare
evideniind aspecte importante ale sistemului:
- aspectele statice, care sunt reprezentate n modelul obiect;
- aspectele temporale, comportamentale i de "control" ale sistemului,
redate n modelul dinamic;
- aspectele funcionale i de transformare de date, reprezentate n
modelul funcional.

Cele trei modele decupeaz sistemul n vederi ortogonale care pot fi reprezentate cu o nota ie uniform.
Interconexiunile ntre modele sunt limitate i explicite.
Modelul obiect descrie structura obiectelor, identitatea lor, relaiile dintre obiecte, atributele lor i
operaiile asociate obiectelor. Modelul obiect este reprezentat grafic prin diagrame de clase i diagrame de
obiecte. Clasele sunt conectate prin diferite tipuri de asocieri i organizate n ierarhii de clase cu o structur i un
comportament comun. Modelul obiect obinut din analiz descrie obiectele domeniului aplicaiei obiectele lumii
reale). Modelul obiect rafinat n etapa de proiectare descrie modul concret de realizare a sistemului; el poate s
conin obiecte construcii) informatice.
Modelul dinamic descrie sistemul n relaie cu timpul i secvenierea operaiilor: evenimentele care
marcheaz schimbrile, secvenele de evenimente, strile care definesc contextul evenimentelor i organizarea
strilor i evenimentelor. Modelul dinamic este reprezentat grafic prin diagrame de stare. Fiecare diagram de
stare descrie comportamentul dinamic al obiectelor unei clase. Activitile i aciunile ataate strilor sunt
descrise n modelul funcional. Evenimentele corespund mesajelor apeluri ale opera iilor), schimbate ntre
obiectele modelului.
Modelul funcional prezint prelucrrile dintr-un sistem, independent de momentul la care sunt executate.
El conine funcii operaii ataate claselor), constrngeri i dependene funcionale. Modelul funcional este
reprezentat prin diagrame de flux de date.
2.2.Comparaie ntre metodele funcionale i metodele
orientate obiect
Metodele funcionale de exemplu SA/SD) i metodele orientate obiect de exemplu OMT) au multe n
comun. Ele utilizeaz construcii de modelare similare i suport cele trei vederi ortogonale ale unui sistem.
Diferena este de stil i de punct de vedere. In abordarea funcional, modelul funcional domin, urmeaz apoi
ca importan modelul dinamic, iar modelul obiect este cel mai puin important. Metodele obiect consider
modelul obiect ca cel mai important, apoi modelul dinamic i la sfrit modelul funcional.
Metodele funcionale organizeaz un sistem n jurul procedurilor. Invers, o tehnic de modelare obiect
cum ar fi OMT) organizeaz un sistem n jurul obiectelor lumii reale sau al obiectelor conceptuale care exist
n viziunea utilizatorului din lumea real. Cea mai mare parte a modificrilor cerinelor sunt modific ri de
funcii; n general, obiectele din domeniul aplicaiei nu se schimb. Astfel, modificarile funcionale pot
presupune un efort mare de adaptare a programului n cazul unei proiectri bazate pe proceduri. Aceste
modificari pot fi efectuate cu uurin n cazul unei proiectri orientate pe obiectele din domeniul aplica iei,
adugnd sau modificnd operaii, structura de baz a obiectelor rmnnd neschimbat. Metode cum ar fi
SA/SD, sunt utile pentru dezvoltarea de programe n care prelucrrile sunt mai importante i mai complexe
dect datele.
O concepie obiect este mai extensibil dect o concepie funcionala. Se adaug pur i simplu obiecte i
relaii care nu existau anterior.
Analogia direct dintre obiectele unei concepii obiect i obiectele domeniului face ca sistemele s fie mai
uor de neles, corespondena dintre specificaie i cod fiind simplificat.

In SA/SD, descompunerea unei prelucrri n subprelucrri este oarecum arbitrar. Persoane diferite pot
produce descompuneri diferite. In concepia obiect, descompunerea este bazat pe obiectele domeniului
problemei.
2.3. UML - Unified Modelling Language
In prima jumtate a anilor '90 au aprut diverse metode obiect. Aceast proliferare a nsemnat o
recunoatere a avantajelor orientrii obiect, dar totodat a evideniat multitudinea de interpretri a ceea ce
nseamn "obiect". Majoritatea metodelor se bazeaz ns pe unele elemente comune, cum sunt no iunile de
clas, de asociere introdusa de James Rumbough), de partiionare n subsisteme Grady Booch), de exprimare a
cerinelor plecnd de la studiul interaciunii utilizator - sistem "use cases" introduse de Ivan Jacobson.)
Experiena n utilizarea acestor metode a fcut posibil unificarea lor. In 1996, a fost creat un consor iu
de parteneri pentru definirea unui limbaj de modelare orientat obiect, care s integreze conceptele cele mai
valoroase din metodele existente i totodat s unifice notaiile; printre firmele care au contribuit la definirea
limbajului UML sunt: DEC, HP, IBM, I-Logix, Intellicorp, ICON Computing, MCI Systemhouse, Microsoft,
Oracle, Rational Software, TI si Unisys. UML versiunea 1.0, a fost supus analizei n vederea standardizarii, n
ianuarie 1997 . Au urmat apoi versiunile 1.1 noiembrie 1997), 1.2 iunie 1998) si ultima versiune, 1.3 1999).
UML The Unified Modeling Language for Object-Oriented Development) este un limbaj de modelare
obiect i nu o metod obiect. UML este independent de procesul de dezvoltare folosit, dar in mod optim ar trebui
sa fie folosit intr-un proces de dezvoltare iterativ si incremental, dirijat de cazuri de utilizare si centrat pe
arhitectura. Un astfel de proces, numit Rational Unified Process, este descris in cartea celor trei principali autori ai
limbajului Jacobson, Booch si Rumbaugh, 1999).
UML este un limbaj pentru:

Vizualizare

Specificare

Construire

Documentare

UML este un limbaj grafic. Modelele UML uureaz comunicarea intre diversele categorii de persoane implicate
in procesul de dezvoltare a unui sistem informatic. Comunicarea este ne-ambigua deoarece notaiile grafice au
asociata o semantica bine definita.
UML permite specificarea sistemelor prin modele precise, ne-ambigue si complete la toate nivelele de detaliu:
analiza, proiectare si implementare.
Modelele UML pot fi transpuse direct in limbaje de programare ca Java, C++, Visual Basic sau in tabele ale unei
baze de date relaionale. UML este de asemenea adecvat pentru "Inginerie inversa", adica generarea de modele
pornind de la codul sursa.
Modelele UML pot fi folosite in documentele de analiza a cerintelor, de proiectare arhitecturala si de detaliu.
UML permite modelarea sistemelor din mai multe puncte de vedere si la diferite nivele de detaliu. Astfel,
elementele de modelare definite in UML pot fi impartite in 3 categorii:
1) Modelare comportamentala
-Cazuri de utilizare
-Diagrame de cazuri de utilizare

-Diagrame de interactiune
-Diagrame de stari
-Diagrame de activitati
2) Modelare structurala
-Clase
-Diagrame de clase
-Diagrame de obiecte
-Interfete
-Pachete
3) Modelare arhitecturala
-Componente
-Diagrame de componente
-Diagrame de distributie
2.3.1. Cazuri de utilizare
Unul dintre aspectele importante in intelegerea si definirea cerintelor unui sistem este acela al
interactiunii dintre sistem si utilizatori sau alte componente externe. Scenarii de interactiune tipica a unui
sistem au fost folosite deseori in analiza cerintelor dar de regula in mod neformal si rareori
documentate.
In UML modelel cazurilor de utilizare "Use cases") a fost introdus de Jacobson in 1992. El a fost
adoptat intr-o masura remarcabila, devenind un instrument folosit in mod frecvent in specificarea
sistemelor informatice.
Modelul cazurilor de utilizare include actorii, sistemul, cazurile de utilizare si diagramele de
cazuri de utilizare.
Un actor este un rol pe care o entitate externa il joaca in raport cu un sistem. Actorii se
determina observand utilizatorii directi ai sistemului, cei care sunt responsabili de exploatarea sau de
interogarea sa. Aceeasi persoana fizica poate juca rolul mai multor actori de exemplu vanzator si
client). Mai multe persoane pot sa joace acelasi rol, si deci sa actioneze ca acelasi actor. Un actor poate
fi de asemenea un echipament extern sistemului sau un alt sistem.
Actorii se reprezinta sub forma unor mici personaje care declanseaza cazuri de utilizare. De exemplu:

Caz de utilizare
Determinarea actorilor permite precizarea limitelor sistemului ntr-o manier progresiv: vagi la
nceput, ele se precizeaz pe masura elaborrii diferitelor cazuri de utilizare. Aceasta activitate de
delimitare este extrem de importanta. Ea permite stabilirea a ceea ce trebuie sa realizeze viitorul
sistem, ceea ce face parte din sistemul de dezvoltat i ceea ce nu face parte din el.
Cazurile de utilizare sunt abstracii ale dialogului ntre actori i sistem. Ele descriu interaciuni
poteniale fr a intra n detalii ale fiecrui scenariu.

Un scenariu este o secventa de pasi care descrie o posibila interactiune dintre un sistem si un
actor.
Sa consideram un sistem de gestiune electronica a cartilor din mai multe biblioteci, de exemplu
din intreaga tara. Sistemul urmeaza sa fie utilizat de doua categorii de utilizatori: bibliotecarii si abonatii.
Bibliotecarii acceseaza sistemul pentru a inregistra abonati si carti noi sau pentru a elimina carti din
evidenta. Abonatii pot cere informatii despre diferite carti si pot cere imprumutarea unei carti. Sistemul
trebuie sa pastreze evidenta abonatilor, a cartilor imprumutate de fiecare abonat si alte informatii.
Deoarece sistemul realizeaza o gestiune centralizata, pentru accesul sau se propune o interfata Web.
In acest exemplu, actorii sunt: abonatul si bibliotecarul. Cazurile de utilizare ar putea fi:

si altele.
Un posibil scenariu al cazului de utilizare "Imprumut" este urmatorul:
"Un utilizator isi introduce identitatea, apoi completeaza fisa electronica de imprumut pentru o carte si
actioneaza butonul "Imprumut" din pagina Web. Sistemul cauta cartea si afiseaza utilizatorului datele
necesare in legatura cu imprumutul".
Acesta este un scenariu posibil. Alte scenarii ale cazului de utilizare "Imprumut" pot fi acelea in
care sistemul nu autorizeaza accesul utilizatorului sau refuza imprumutul pentru ca utilizatorul are deja
imprumutate carti in numarul maxim admis, sau cartea nu a fost gasita.
Un caz de utilizare descrie un set de scenarii corelate, de exemplu, toate scenariile de acces la sistem
in scopul imprumutului unei carti. Formatul descrierii consta dintr-o secventa tipica de pasi si
alternativele, ca variante ale secventei tipice. Exemplu:
Cazul de utilizare :"Imprumut"
1. Un utilizator completeaza rubricile afectate numelui si prenumelui sau apoi apasa butonul "Submit".
2. Sistemul preia datele si verifica daca utilizatorul este inregistrat ca abonat.
3. Sistemul afiseaza urmatoarea pagina, continand formularul de imprumut.
4. Abonatul completeaza formularul de imprumut, cu titlul cartii, numele si prenumele autorului si codul
ISBN al cartii apoi apasa butonul "Submit".
5. Sistemul preia datele si cauta cartea.

6.

Sistemul inregistreaza imprumutul.

7. Sistemul afiseaza datele necesare imprumutului.


Alternativa "Acces ne-autorizat":
La pasul 2: Utilizatorul nu este inregistrat ca abonat si atunci sesiunea este incheiata de sistem cu un
mesaj in care utilizatorul este invitat sa se inregistreze.
Alternativa "Imprumutul nu este posibil"
La pasul 5:
5a) Cartea nu este gasita. Sistemul afiseaza un mesaj si sesiunea este incheiata.
5b) Cartea este gasita dar abonatul a imprumutat deja numarul admis de carti. Sistemul afiseaza un
mesaj si incheie sesiunea.
UML admite variatii in privinta descrierii cazurilor de utilizare. De exemplu, o descriere mai exacta
a cazului de utilizare anterior este:

Imprumut
Actori:
Scop:
Descriere generala:

Abonat
Imprumutul unei carti
Un abonat acceseaza pagina Web a
sistemului de gestiune electronica a
cartilor din bibliotecile existente in tara.
El isi introduce identitatea si datele de
identificare ale cartii pe care doreste sa o
imprumute. Sistemul valideaza identitatea
abonatului si cauta cartea. Daca cartea
exista si abonatul are dreptul sa obtina un
nou imprumut atunci sistemul autorizeaza
imprumutul.
Pre-conditie:
Daca este necesar, abonatul tebuie sa
execute mai intai procedura de acces la
sistem log-in).
Post-conditie:
In baza de date a sistemului exista o
inregistrare a imprumutului catre abonat
Cazuri de utilizare referite:
Inregistrarea unui nou abonat
1. Un utilizator completeaza rubricile afectate numelui si prenumelui sau apoi apasa butonul
"Submit".
2. Sistemul preia datele si verifica daca utilizatorul este inregistrat ca abonat.
3. Sistemul afiseaza urmatoarea pagina, continand formularul de imprumut.
4. Abonatul completeaza formularul de imprumut, cu titlul cartii, numele si prenumele autorului si
codul ISBN al cartii apoi apasa butonul "Submit".
5. Sistemul cauta cartea.
5a) Daca sistemul nu gaseste cartea, se executa alternativa "Cartea nu exista".
5b) Daca autorul are deja imprumutat numarul maxim de carti admis, se executa alternativa
"Restrictia numarului de carti imprumutate".
6. Sistemul inregistreaza imprumutul.
7. Sistemul afiseaza utilizatorului datele necesare imprumutului.
Alternativa "Acces ne-autorizat"

1.

Sistemul afiseaza un mesaj prin care invita utilizatorul sa se inregistreze ca abonat apoi incheie
sesiunea.

Alternativa "Cartea nu exista"


1. Sistemul afiseaza mesajul "Cartea solicitata nu ese inregistrata in bibliotecile noastre", apoi incheie
sesiunea.
Analog pentru alternativa 5b.
Pre-conditia este un predicat in cazul de fata exprimat ne-formal) care exprima conditia care
trebuie sa fie satisfacuta inainte de inceperea cazului de utilizare. Post-conditia exprima conditia care
este satisfacuta dupa executia cazului de utilizare conform descrierii secventei tipice!).
Un caz de utilizare este imaginea unei funcionaliti a sistemului, declanat ca rspuns la stimularea
unui actor.
Descrierea unui caz de utilizare trebuie sa precizeze:

- cum si cand incepe si se termina cazul de utilizare evenimente care marcheaza inceputul si sfarsitul cazului;
-

cand au loc interactiunile cu actorii si informatiile schimbate comunicate intre actori - sistem) in
timpul fiecarei interaciuni;

fluxul de baza comportamentul de baza) si alternativele fiecarei interactiuni;

repetarile de comportament, care pot fi descrise prin formulari de tipul:


ciclu
----------sfarsit ciclu
sau
cat timp
sfarsit cat timp
Cand se foloseste modelul cazurilor de utilizare?
Cazurile de utilizare definesc comportarea unui sistem fara a da informatii despre modul de

realizare a comportarii. Se folosesc ca mijloc de vizualizare, specificare si documentare a unui sistem,


subsistem parte sau element.
In fazele initiale ale dezvoltarii, cazurile de utilizare se folosesc ca mijloc de comunicare intre
analist si client precum si experti ai domeniului, pentru determinarea contextului sistemului si pentru
desprinderea cerintelor.
Pe parcursul dezvoltarii se folosesc pentru validarea arhitecturii sistemului. Se folosesc, de
asemenea, in procesul de testare a sistemului executabil.
Modelul cazurilor de utilizare include un set de cazuri de utilizare si un set de diagrame de cazuri
de utilizare.

Diagramele de cazuri de utilizare se foloses pentru a reprezenta


relatiile intre cazurile de utilizare ce descriu un sistem. Exista
trei tipuri de relatii intre cazurile de utilizare figura 2.5):

Figura 2.5. Relatii intre cazuri de utilizare


Relatia de generalizare
Are acelasi rol ca si relatia de generalizare intre clase. Un caz de utilizare copil mosteneste
comportarea si intelesul cazului de utilizare parinte: copilul poate adauga noi aspecte ale comportarii
sau poate redefini partial comportarea parintelui.
Relatia de includere
Un caz de utilizare poate incorpora comportarea reprezentata printr-un alt caz de utilizare, intr-un punct
specificat al sau. Cazurile de utilizare "incluse" nu pot fi folosite independent, ci doar ca parti ale
cazurilor de utilizare care le includ.
Relatia de includere se foloseste pentru a evita descrierea de mai multe ori a aceluiasi flux de
evenimente. Un astfel de flux, care apare in mai multe cazuri de utilizare, se defineste ca un caz de
utilizare separat, care factorizeaza o comportare comuna.
Relatia de extindere
Un caz de utilizare poate extinde, in anumite conditii, comportarea reprezentata printr-un alt caz. Cazul
extins poate fi folosit si singur. El este extins numai in anumite puncte. Relatia de extindere se foloseste:
-

pentru a modela parti ale cazurilor de utilizare pe care utilizatorii le pot vedea ca optiuni ale
comportarii sistemului; in acest caz se separa comportamentul principal de cele optionale.

pentru a modela sub-fluxuri de evenimente, care sunt executate numai in anumite conditii.

Relatiile de includere si extindere favorizeaza structurarea cazurilor de utilizare prin factorizarea


comportamentului comun si separarea variantelor.
O diagrama de cazuri de utilizare reda un set de cazuri de utilizare, actori si relatii. In diagramele de
cazuri de utilizare, actorii se reprezint sub forma unor mici personaje care declanseaz cazuri de
utilizare.
Diagramele de cazuri de utilizare pot fi utile pentru a reprezenta contextul sau cerintele unui
sistem. Contextul unui sistem cuprinde tot ceea ce este exterior sistemului si interactioneaza cu
sistemul. El defineste mediul sistemului. O diagrama de caz de utilizare care modeleaza contextul
evidentiaza actorii care interactioneaza cu sistemul. Un astfel de exemplu este redat in figura 2.6:

Figure 2.6. Diagrama de caz de utilizare


Cazurile de utilizare si diagramele de cazuri de utilizare pot reda comportamentul uni sistem la
diferite nivele de abstractizare. Astfel, cazul de utilizare anterior poate fi detaliat pentru a reda
participarea diferitelor componente ale sistemului in cazul de utilizare. O astfel de detaliere apare
necesara in etapele de proiectare ale sistemului. In aceste modele actori pot fi: baze de date, programe,
componente, etc.
2.3.2. Diagrame de interactiune
Cazurile de utilizare constituie o descriere funcional a cerinelor, structurat n raport cu unul
sau mai muli actori. Trecerea ctre o structurare obiect se realizeaz asociind o "colaborare" fiecrui
scenariu. Colaborarea evideniaz obiectele domeniului, conexiunile dintre aceste obiecte i mesajele
schimbate de ctre obiecte n cadrul scenariului. Scenariile, care au fost ntocmite la nceputul etapei
de analiz, sunt reprezentate n continuare prin diagrame de interaciune: diagrame de colaborare i
diagrame de secven. Diagramele de colaborare redau relatiile structurale dintre obiecte si mesajele
prin care ele comunica. Diagramele de secventa evidentiaza ordonarea in timp a mesajelor.
Diagramele de interactiune includ actori, obiecte sau componente implicate intr-o interactiune si redau
mesajele schimbate in cursul interactiunii.
Obiecte
Un obiect este un concept, o abstracie sau un lucru avnd limite foarte clare i un sens precis
n contextul problemei studiate. Fiecare obiect are o identitate i poate fi distins de celelalte.
In UML, un obiect se reprezint sub forma unui dreptunghi coninnd numele obiectului si clasa
din care face parte sau numai numele obiectului, subliniate). De exemplu:

Mihai : Persoana

Mihai

IBM:

Calculator
Notaia permite de asemenea desemnarea de obiecte anonime, specificand numai numele clasei din
care face parte. De exemplu:

:Student
:Profesor
Comportamentul unui obiect, ca urmare a unei stimul ri externe, este reprezentat prin opera ii.
Operaiile unui obiect sunt declanate prin mesaje trimise de alte obiecte.
Diagramele de secventa
Diagramele de secven ilustreaz interaciunile dintre obiecte sau actori si obiecte din punct de
vedere temporal. Un obiect este reprezentat printr-un dreptunghi i o bar vertical numit linia de via
a obiectului. Mesajele sunt reprezentate prin sgei orizontale orientate de la emitorul mesajului ctre
destinatar. Ordinea de trimitere este dat de poziia pe axa vertical. Timpul se scurge de sus n jos.
Axa vertical poate fi gradat n scopul exprimrii mai exacte a constrngerilor temporale n cazul
modelrii unui sistem de timp real.
Diagramele de secven se construiesc plecand de la cazurile de utilizare. Ele se pot folosi n dou
scopuri, care corespund la doua nivele diferite ale procesului de dezvoltare:
1) Ca mijloc de documentare a cazurilor de utilizare; interaciunea este descris n termeni
apropiai utilizatorului i fr a intra n detalii de sincronizare. Sgeile corespund evenimentelor
care survin n domeniul aplicaiei. De exemplu, diagrama din figura 2.7. reprezint nceputul
unei comunicaii telefonice.
2)

:Apelant

:Linie telefonica

:Apelat

Deschide telefonul
Ton
Formeaz numar
Indicator de sonerie

Sun

Deschide telefonul
Alo
Figura 2.7. Diagram de secven
2) Ca mijloc de reprezentare exact a mesajelor schimbate ntre obiecte. Perioada de activitate a unui
obiect este reprezentat cu ajutorul unei benzi rectangulare suprapuse pe linia de via a obiectului.
In exemplul din figura 2.8, obiectul 1 apeleaza o operatie a obiectului 2. Obiectul 2 creaza obiectul 3
care exista pana cand este distrus tot de obiectul 2. Obiectul 3 apeleaza o operatie proprie.

:Obiect2
:Obiect1

:Obiect3

apel operatie Obiect2


<<creaza>>

return dupa exec. operatie


Figura 2.8.Apeluri de operatii, crearea si distrugerea obiectelor.
Sagetile folosite in figura 2.8 se folosesc pentru a reprezenta mesaje care corespund unui apel de
proceda intr-un flux de executie cu un singur fir de executie. UML permite si reprezentarea de mesaje
intre obiecte care sunt active in fire de executie diferite. Intre astfel de obiecte pot fi trimise mesaje
sincrone sau asincrone.
Atunci cand un obiect trimite un mesaj sincron fig. 2.9.b), el ramane in asteptare pana cand
destinatarul trateaza mesajul. De aceea, revenirea dupa tratarea unui mesaj sincron nu este necesar sa
fie reprezentata.
Un apel de procedura este un apel sincron. De aceea nici revenirea dupa executia unei proceduri nu
este reprezentata intotdeauna.
Trimiterea asincrona fig. 2.9.a) a unui mesaj nu ntrerupe execuia expeditorului. Expeditorul
trimite mesajul fr s tie cnd, nici chiar dac mesajul va fi tratat de ctre destinatar. In figura 2.9.a
este redata si confirmarea destinatarului dupa tratarea mesajului.

:Ob1

:Ob2

Figura 2.9.a. Apel asincron.


Figura 2.9.b. Apel sincron si apel cu timeout.
Trimitere mesaj cu timeout = trimitere sincrona cu blocarea expeditorului pe un timp limitat care poate
fi specificat). Expeditorul asteapta ca destinatarul sa primeasca mesajul un timp limitat. Comunicatia nu
are loc daca in intervalul de timp dat destinatarul nu ia in considerare mesajul.
Scopul unui mesaj asincron poate fi:
- Crearea unui obiect nou
- Crearea unui fir de executie
- Comunicarea cu un fir de executie existent
Alegerea formei de sincronizare are loc de regul n etapa de proiectare, pentru a realiza de
exemplu o excludere mutual n utilizarea unei resurse critice. Forma de sincronizare poate fi
important de asemenea n etapa de analiza. De exemplu, comunicaia prin pot corespunde unei
trimiteri asincrone.

Mihai
Monica
Scrisoare prin pot
Diagramele de secventa redau modul de transfer al controlului intre obiecte figurile 2.10 si 2.11.)

Figura 2.10. Control centralizat

A
B

C
D

Figura 2.11. Control descentralizat


Pentru a indica bucle i salturi se pot aduga notaii de tip pseudocod pe partea stng a diagramei
figuriel 2.12 si 2.13):

while [X] loop

end loop

Figura 2.12. Iteraie.

if X

mesaj 1

else

mesaj 2

end if
sau

[X]

[not X]
Figura 2.13. Decizie.
Exemple de diagrame de secventa

Diagrame de colaborare
Diagramele de colaborare sunt n particular indicate pentru faza exploratorie, care corespunde cutrii
obiectelor. Ele ilustreaz n acelai timp interaciuni ntre obiecte i relaiile structurale care permit aceste
interaciuni.
Relatiile structurale sunt reprezentate prin "legaturi" - linii care conecteaza obiectele. Mesajele schimbate
ntre obiecte sunt reprezentate de-a lungul legturilor. Ordinea de trimitere a diferitelor mesaje este indicat
printr-un numr amplasat in fata mesajului, ca n figura 2.14.
Obiectele i legturile create sau distruse n cursul unei interaciuni pot purta constr ngerile , respectiv .
Obiectele care sunt create i distruse n cursul aceleiai interaciuni sunt identificate prin constrngerea .
1:X

A
B
3:Z

C
2:Y
Figura 2.14
"Scenariul incepe cu un obiect A care trimite un mesaj X unui obiect B. Acesta trimite un mesaj Y obiectului C
care-si trimite un mesaj Z."

B
A

C
D
Figura 2.15
Pentru a indica trimiterea unui mesaj ctre toate obiectele unei clase, existente la un moment dat, se folosete
notaia *:mesaj, ca n exemplul de mai jos:

:X

*: mesaj

:Y
Figura 2.16.
In diagramele de colaborare pot fi introdui actori, pentru a reprezenta declanarea interaciunilor de ctre un
element extern sistemului. Datorit acestui artificiu, interaciunea poate fi descris ntr-o manier mai abstract,
fr a se intra n detaliile obiectelor de interfa utilizator. Primul mesaj de interaciune este trimis de actor. Un
exemplu este prezentat in figura 2.17.

:Ascensor
1: Apel la al doilea etaj

:Cabina
2: Adaug destinaia al doilea etaj
Figura 2.17.
In figura 2.18 este reprezentata o posibila diagrama de colaborare, corespunzatoare unui scenariu al cazului de
utilizare descris in paragraful 2.3.1. Scenariul corespunde secventei tipice de evenimente a cazului de utilizare,
adica: utilizatorul este inregistrat ca abonat, el nu a imprumutat numarul maxim admis de carti, cartea este gasita si
imprumutul inregistrat. Obiectele redate in diagrama sunt: "Fereastra-Abonati", in care utilizatorul completeaza
datele necesare imprumutului, "Sistem"-reprezentand modulul central al sistemului, "Fisierul de abonati", "Fisele
abonatilor", "Fisierul de carti", "Fisele cartilor" si "Fereastra-mesaj" in care sistemul afiseaza datele necesare
imprumutului.

Figura 2.18
Echivalenta diagrame de interactiune - diagrame de colaborare
Ambele categorii de diagrame reprezinta vederi diferite asupra aceleiasi informatii. In cazul diagramelor de
secventa accentul este pus pe secventialitatea mesajelor. In cazul diagramelor de colaborare accentul cade pe
colaborarile dintre obiecte. Formele grafice utilizate in cadrul fiecarei categorii de diagrame accentueaza aceste
aspecte.
Numeroase editoare UML permit conversia automata de la o diagrama de secventa la cea de colaborare
corespunzatoare sau invers.

2.3.3. DIAGRAMELE DE CLASE


Clase
O clas de obiecte reprezint un grup de obiecte care au proprieti similare atribute), un comportament
comun operaii), relaii comune cu alte obiecte i o aceeai semantic. De exemplu, "Persoana", "Societate",
"proces" sunt clase de obiecte. Semantica asociat unei clase corespunde unui punct de vedere. Obiectele din
lumea real pot fi abstractizate n mod diferit. De exemplu, un cal poate fi ncadrat n clasa mijloacelor de
transport terestre sau n clasa animalelor.
In UML, o clas este reprezentat printr-un dreptunghi alcatuit din trei compartimente care con in: numele
clasei, atributele, operaiile. Compartimentul atributelor i cel al operaiilor pot fi omise.

Nume clasa
Atribute

Operaii

Relaiile dintre clase sunt abstracii ale relaiilor existente ntre obiecte. Fiecrei familii de legturi ntre obiecte i
corespunde o relaie ntre clasele obiectelor. Asa cum obiectele sunt instane ale claselor, legturile ntre obiecte
sunt instane ale relaiilor dintre clase.
Diagramele de clase redau structura statica a unui sistem. Exista doua tipuri principale de relatii intre clase:
asociere si generalizare.

Alin:Persoana

IBM:Firma

legturi

Maria:Persoana

Persoana
Lucreaz pentru >

Universitate

< Studiaza n

A&C:Firma

Societate
asocieri

Student

Figura 2.19. Legturi i asocieri.


Asocierile
Asocierea este o conexiune semantic bidirecional ntre clase. De exemplu, asocierea "Lucreaz pentru"
dintre clasele Persoana i Societate reprezint toate legturile posibile dintre obiecte ale clasei Persoana i obiecte
ale clasei Societate:
Sgeata ataat numelui asocierii nu este obligatorie. Ea indic sensul citirii numelui asocierii.
Extremitatea unei asocieri este numita rol. Rolul exprim felul n care o clas "vede" o alt clas n cadrul
unei asocieri. De exemplu, n asocierea dintre clasele Societate i Persoana, orice obiect al clasei Persoana este un
"Angajat" al unei Societai, care este reprezentat printr-un "Patron" . Numele de rol sunt amplasate la cele dou
extremiti ale asocierii:
Societate

Patron

Persoana
Angajat
Figura 2.20. Nume de rol.
Dac ntre dou clase exist o singur asociere, numele asocierii este suficient pentru a preciza relaia. Numele de
rol se folosesc de regul atunci cnd ntre dou clase exist mai multe asocieri.
Aritatea asocierilor
Cea mai mare parte a asocierilor sunt binare - ele unesc dou clase. Asocierile de aritate superioar se
reprezint cu ajutorul unui romb, ca n figura de mai jos. De exemplu, asocierea ilustrat n figura 3.15. exprim
faptul ca "Proiectele sunt implementate prin Programe scrise n Limbaje de programare".

Proiect

Limbaj

Program
Figura 2.21. Asociere ternar.

Multiplicitatea asocierilor
Fiecare rol al unei asocieri poate purta o indicaie de multiplicitate care arat c te obiecte ale unei clase
pot fi legate unui obiect al celeilalte clase. De exemplu, o societate poate avea zero sau mai mul i angaja i.
Multiplicitatea poate fi "unu", "mai multe "*) sau un subansamblu de ntregi pozitivi: 1, 0..1, M..N, * sau 0..*
de la zero la mai muli), 1..*.

Persoana
Societate
Patron

0..*
1

Angajat

Fig. 2.22. Multiplicitatea asocierilor.


Multiplicitatea unei asocieri exprim o constrngere valabil pe toat durata de existen a obiectelor
claselor asociate. Multiplicitile nu trebuie s fie considerate n timpul regimurilor tranzitorii, de creare sau de
distrugere a obiectelor.
Asocierile pot fi caracterizate prin atribute. In figura 2.23, "Nota" este un atribut al asocierii existente ntre
clasa

"Student"

clasa

"Tema".

Asocierea dintre clasa Student i clasa Tema este de tip N la N. Fiecare student realizeaz individual o tema dat
iar nota obinut nu poate fi reprezentat nici ca atribut al studentului cci un student efectueaz mai multe
teme), nici ca atribut al temei cci fiecare student primete o not pentru aceeai tema). Nota este un atribut al
relaiei dintre clasa studenilor i clasa temelor.
Student

Tema

0..* Realizeaza> 0..*

Nota

Figura 2.23. Asocieri cu atribute.


O asociere care conine atribute este numit asociere atributat. O asociere poate fi reprezentat printr-o
clas cu atribute i operaii proprii. O asemenea clas, numit uneori clas-associere, este ataat asocierii printro linie punctat figura 2.24).

Figura 2.24. Clas-asociere.


Asocierile pot fi constrnse. Constrngerile sunt scrise ntre acolade. De exemplu, instanele clasei B asociate
unei instane a clasei A trebuie s fie ordonate:
0..*
A

B
Figura 2.25. Asociere constrns.
O asociere poate lega o clas de ea nsi. O asemenea asociere este numit asociere reflexiv. Un
exemplu de asociere reflexiv este cel ilustrat n figura 2.26. Fiecare persoan are zero, unu sau doi p rin i i
zero sau mai muli copii. Numirea rolurilor este n acest caz esenial pentru claritatea diagramei.
Prini

Persoana
Figura 2.26. Asociere reflexiv
* Copii
Asocierile 1 la mai muli i mai muli la mai muli pot fi calificate. Calificarea este specificat printr-o
cheie ataat rolului clasei de plecare.
0..2

B
Fig. 2.27. Calificarea asocierilor
Fiecare instan a clasei A mpreun cu valoarea cheii identific un sub-ansamblu al instanelor clasei B, care
particip la asociere. Exemplu:

Director

Fiier
Nume de fiier

Fig. 2.28. Identificarea unui fiier.


In contextul unui director, un nume de fiier identific un fiier. Un director mpreun cu un nume de fiier
desemneaz un fiier.
Agregarea
Agregarea este o form particular de asociere care exprim un cuplaj mai strns ntre clase. Una dintre clase
joac un rol mai important dect cealalt n relaie. Agregarea permite reprezentarea relaiilor de tip "masterslave", "client-server" i "compus - componeni". Agregarea este desemnat printr-un un mic romb amplasat
alturi de clasa agregat figura 2.29):

Fig. 2.29. Clase agregat.


Un document are mai multe paragrafe i fiecare paragraf este alctuit din mai multe fraze. In cazul n care
multiplicitatea agragatului are valoarea 1, distrugerea agregatului antreneaz distrugerea componentelor.

Maina
Motor
1

Fiecare main poseda un motor care nu poate fi partajat cu alte maini. Distrugerea ma inii antreneaz
distrugerea motorului.
O agregare nereflexiv a crei valoare de multiplicitate este 0 sau 1 de partea agregatului se poate realiza prin
coninere fizic.

Agregat
Componente
0..1
Figura 2.30. Agregare prin coninere fizic.
Coninerea fizic este un caz particular de agregare, numit compunere. Relaia de compunere este
semantic echivalent cu considerarea componenilor ca atribute ale clasei agregat:

este echivalent cu:

Main
Motor

Figura 3.25.

O asociere este de tip agregat atunci cnd:


- obiectele unei clase fac parte din obiectele unei alte clase;
- atributele unei clase se propag n atributele unei alte clase;
- o aciune asupra obiectelor unei clase implic o aciune asupra obiectelor unei alte clase;
- obiectele unei clase sunt subordonate obiectelor unei alte clase.
Ierarhii de clase: generalizare i specializare
Ierarhiile de clase sunt bazate pe noiunile de clasificare, generalizare i specializare. Generalizarea
const n factorizarea elementelor comune atribute, operaii i constrngeri) ale unui ansamblu de clase ntro clas mai general, numit superclas. Clasele sunt ordonate ntr-o ierarhie. Sgeata care simbolizeaz
generalizarea ntre dou clase puncteaz ctre clasa mai general.
Elicopter

Vehicul
Vehicul aerian
Vehicul terestru

Avion
Camion

Main

Fig. 3.26. O ierarhie de clase.


In ierarhia din figura de mai sus, fiecare clasa exceptnd clasa radacina) are o singura super-clasa. Reprezentarea
grafica corespunde unui arbore, numit si arborele de mostenire. Clasele pot avea mai multe super-clase. In acest
caz, generalizarea este numit multipl iar ierarhia de clase se reprezinta printr-un graf , numit si graful de
mostenire.
Specializarea permite capturarea particularitilor unui ansamblu de obiecte, nereprezentate prin clasele
existente. Noile caracteristici sunt definite ntr-o clas nou, sub-clas a uneia sau mai multor clase existente.
Specializarea este o tehnic foarte eficient de extensie coerent a unui ansamblu de clase existente . Noile cerine
sunt ncapsulate n sub-clase care extind funciile existente . De exemplu, dac ntr-o aplicaie apare necesar s
se reprezinte "bicicleta" ca vehicul de transport, n plus fa de cele reprezentate n ierarhia de mai sus, atunci
se va defini o clas nou, sub-clas a clasei "Vehicul terestru", n care vor fi definite particularit ile bicicletei ca
vehicul terestru. Fiecare sub-clasa a unei ierarhii mosteneste atributele si operatiile definite n clasele aflate pe

calea de la clasa radacina la subclasa respectiva, fiind cu att mai specializata cu ct se afla mai departe de
radacina.
Motenirea este o tehnic oferit de limbajele de programare pentru a construi o clas plecnd de la una
sau mai multe clase, partajnd atribute, operaii i uneori constrangeri n interiorul unei ierarhii de clase. Clasele
copil motenesc caracteristicile claselor printe. Atributele i operaiile declarate n clasele printe sunt accesibile
n clasele copil, ca i cum ar fi declarate local. Motenirea este o modalitate de a realiza clasificarea. Relaia de
generalizare definit n UML este mai abstract dect relaia de motenire care exist n limbajele de programare
obiect, cum ar fi C++. Ea este mai adecvat etapei de analiz. Decizia asupra modalitii de a realiza
generalizarea se ia mai trziu, n etapa de proiectare.
Prin clasificare si generalizare, universul problemei este divizat in pari independente care grupeaza
obiectele prin afinitate. Modificarea unei pari antreneaza un minimum de modificari ale celorlalte, fapt pus
n evidena de arborele de motenire: fiecare subarbore grupeaza obiectele care mpart caracteristicile
radacinii sale. De exemplu, adaugarea de noi caracteristici la clasa Articol-de-lux figura )nu afecteaza clasa
mbracaminte i nici subclasele acesteia, dar extinde automat caracteristicile subclaselor clasei Articol-de-lux.

Figura 3.27.
Uneori, anumite clase sunt create doar ca surse de motenire pentru alte clase; ele sunt clase abstracte. De
exemplu, clasa Articol este o clasa abstracta daca nu caracterizeaza complet
nici un obiect din universul problemei. Clasa Articole-electrice a fost introdusa pentru a factoriza proprietatile
electrice de exemplu, tensiunea de alimentare, consumul si altele), comune calculatorului si articolelor
electrocasnice.

Figura 3.28.
Operatiile unei clase:
-

la nivel de specificatie: metodele publice

- la nivel de implementare: operatiile private si protected


Folosirea diagramelor de clase:
1) In modelarea conceptuala
- Clasele corsepund conceptelor din domeniul aplicatiei
- Nu exista neaparat o legatura directa cu clasele de obiecte utilizate pentru implementare
2) Pentru specificarea software
- Se pune accent pe interfata si nu pe implementare
- adesea se foloseste cuvantul "tip" in legatura cu interfata unei clase: un tip poate fi implementat de mai multe
clase si o clasa poate implementa mai multe tipuri
3) In implementare
- sunt clase de obiecte intr-un anumit limbaj de programare

DIAGRAMELE DE OBIECTE
O diagrama de obiecte reda un set de obiecte si relatiile dintre ele la un moment dat de timp.

O diagrama de obiecte este o instanta a unei diagrame de clase sau partea statica a unei diagrame de
interactiune.
O diagrama de interactiune adauga la o diagrama de obiecte mesajele care sunt schimbate intre obiecte.

3.1.4. Diagramele de stri-tranziii


O diagram de stri-tranziii descrie comportamentul obiectelor unei clase prin stri i evenimente.
Obiectele care nu au un comportament reactiv foarte marcat pot fi considerate ca obiecte care rmn
ntotdeauna n aceeai stare. O diagram stri-tranziii corespunde unui automat cu stri finite.

Articol-de -lux
Un eveniment corespunde apariiei unei situaii date n domeniul aplicaiei. El nu are durat. De exemplu,
"utilizatorul apas pe butonul stnga" sau "o persoan iese din birou". Dou evenimente pot fi legate printr-o
legtur de cauzalitate. De exemplu, "zborul 100 trebuie s plece de la Bucureti nainte s soseasc la Paris".
Dou evenimente fr legtur de cauzalitate se numesc concurente. De exemplu, "zborul 200 poate s plece
nainte sau dup zborul 450 care pleac de la Roma". Un eveniment este o cale de transmisie de informaii cu
sens unic de la un obiect ctre un altul.
Specificarea complet a unui eveniment n UML conine: numele evenimentului, lista parametrilor, obiectul
expeditor, obiectul destinatar, descrierea semnificaiei evenimentului.
Fiecare obiect este la un moment dat ntr-o stare particular. Starea este definit de valorile atributelor
sale i de legturile sale. De exemplu, starea curent a unei persoane poate fi: n activitate, n omaj sau la
pensie. Este determinat de vrsta persoanei i de prezena unei legturi ctre o societate:

Emil
Vrsta:75
ans
Ana
Vrsta:40
Figura 3.29.
Mihai este n omaj, Ana este n activitate i Emil este la pensie.
Diagramele stri-tranziii sunt grafuri orientate. Strile sunt legate prin conexiuni bidirecionale numite tranziii.
Trecerea dintr-o stare n alta se efectueaz n cazul n care o tranziie este declan at de c tre un eveniment.
Trecerea dintr-o stare n alta este instantanee, deoarece sistemul trebuie s fie ntotdeauna ntr-o stare
cunoscut. Un eveniment poate determina o tranziie n aceeai stare. Strile se reprezint prin dreptunghiuri
rotunjite. Fiecrei stri i este asociat un nume care o identific. Exemplu:

Figura 3.30. Diagram de stri-tranziii.


In unele cazuri, diagramele de stri tranziii pot deveni foarte complicate. Problema poate fi rezolvat recurgnd
la abstractizare. Astfel, mai multe stri pot fi abstractizate ntr-o singur stare, care corespunde unei reprezentri
de nivel ierarhic mai nalt, dup cum o stare poate fi descompus n sub-stri disjuncte. De exemplu, strile A i
B din diagrama ilustrat n figura 3.29, pot fi abstractizate ntr-o stare mai general deoarece din ambele exist
o tranziie n starea C:

Figura 3.31.
Automatele acceptate de UML sunt deterministe. Pentru fiecare nivel de abstractizare exist o singur stare
iniial. Este posibil s existe mai multe stri finale, fiecare corespunznd unei condiii de sf r it diferite. De
asemenea, este posibil s nu existe nici o stare final. Este cazul unui sistem care nu se opre te niciodat .
Reprezentrile strilor initial i final sunt ilustrate astfel:
Stare

intermediar
Stare iniial

Stare final
Figura 3.31.
Tranziiile pot fi controlate prin grzi. O gard este o condiie boolean care valideaz declanarea unei
tranziii n cazul apariiei unui eveniment.
Starea X
Starea Y

Eveniment [gard]

Figura 3.32. Tranziie condiionat.


In cazul n care mai multe tranziii pot fi declanate de acelai eveniment i evenimentul are loc, g rzile, care
trebuie s fie mutual exclusive, sunt evaluate, i apoi o singur tranziie este validat i declanat.
Aciuni i activiti
Operaiile definite n specificaia unei clase apar n diagramele stri-tranziii ca aciuni i activit i. O
aciune este considerat ca instantanee, adic are un timp de execuie neglijabil n raport cu dinamica sistemului.
In diagramele de stri-tranziii, aciunile sunt ataate evenimentelor:
X

Eveniment/Aciune

Figura 3.33.
Aciunea corespunde unei operaii declarate n clasa obiectului destinatar al evenimentului. Ea este executat
atunci cnd evenimentul este recepionat i determin trecerea obiectului din starea X n starea Y.
O activitate este o operaie care necesit un anumit timp de execuie. Ea este asociat unei st ri. Anumite
activiti sunt ciclice, ca afiarea unei imagini pe un ecran de televizor sau ca soneria telefonului care persist
pn cnd un eveniment o ntrerupe declannd o tranziie. Alte activiti sunt secveniale, ca de exemplu
execuia unui calcul. Activitile sunt indicate prin cuvantul cheie "do":

Starea A
Activitate reprezentat prin operatia P,
do: operatia P
a crei execuie are loc n starea A.
Figura 3.34.
O activitate poate fi ntrerupt n orice moment, imediat ce este declan at o tranzi ie de ie ire din starea
corespunztoare activitii.
Anumite aciuni se execut nainte sau dup o activitate. Aciunile de intrare/ieire sunt specificate n interiorul
strii ce conine activitatea. Ele sunt indicate de cuvintele cheie "entry" i "exit". Pot exista de asemenea ac iuni
interne. O asemenea aciune este executat la ntlnirea unui eveniment care nu schimb starea curent figura
3.33). In cazul n care o activitate secvenial se termin, starea poate fi parasit automat. O asemenea tranzi ie,
care nu este marcat printr-un eveniment, este numit tranziie automat. Tranziia la sfritul unei activiti
secveniale poate fi de asemenea controlat prin grzi fig. 3.34.).

Starea A
entry: aciune 1

do : operaie O
exit : aciune 2
on Eveniment E: aciune E
Fig 3.35. Aciuni de intrare/ieire i aciuni interne.

X
do: activitate secvenial

X
[C]

do: activitate secvenial

[not C]

Fig. 3.36. Tranziii automate la sfritul unei activiti secveniale.


Fiecare diagram de stri-tranziii descrie comportamentul unui grup de obiecte cel mai adesea o clas ).
Notaia UML permite reprezentarea trimiterii de mesaje ntre dou obiecte ca trimiteri de evenimente ntre
automatele de stri ale claselor obiectelor. O trimitere de eveniment ctre o clas este reprezentat sub forma:
^clasa-int.evenimentargumente)
De exemplu, evenimentul "buton apsat", adresat obiectului "telecomand", are ca efect trimiterea evenimentului
"comutat" ctre un obiect "televizor", ceea ce se reprezint n diagrama stri-tranziii a clasei "telecomand "
astfel:
Buton apsat: ^Televizor.comutat

Ateptare

Figura 3.37.
Crearea unui obiect se reprezint prin trimiterea unui eveniment de creare clasei obiectului. Parametrii
acestui eveniment permit iniializarea noului obiect care si ncepe existen a plec nd din starea ini ial

descris n automatul clasei. Distrugerea unui obiect este efectiv atunci cnd fluxul de control al automatului
ajunge ntr-o stare final.

Distrugere

Creare
parametri)
Fig.3.38. Evenimente de creare i de distrugere de obiecte.
Exemplu de diagrama de stari:

3.1.5. DIAGRAMELE DE ACTIVITI


Fiecare operaie a unei clase, care reprezint o activitate, poate fi descris n scopul analizei printr-o
diagram numit diagram de activitate. Activitatea este descompus n mai multe etape, fiecare etap put nd fi
tratat la rndul su ca o activitate. Fiecare operaie-activitate este deci descris ca o nlan uire de activit i.
Atunci cnd o activitate se termin, activitatea urmtoare demareaz automat. Activitile nu posed nici tranziii
interne, nici tranziii declanate de ctre evenimente. De exemplu, o operaie de transformare a unui obiect
tridimensional poate fi descris de diagrama:

Transformare
geometric

Proiecie

Transformare
fereastr-poart
Fig. 3.39. Diagram de activitate.
Tranziiile ntre activiti pot fi controlate prin condiii booleene mutual exclusive. Sincronizarea ntre
fluxurile controlului este reprezentat prin barele de sincronizare, ca n figura 3.38. O bar de sincronizare
permite deschiderea sau nchiderea ramurilor paralele ale fluxului de execuie n cadrul unei metode sau al
unui caz de utilizare.

Figura 3.40.
Concluzie
Modelul de analiz corespunde unui punct de vedere logic asupra sistemului. Acest model reflect
cerinele utilizatorilor dar, n acelai timp, permite identificarea diferitelor pri ale sistemului. Vederea logic
cuprinde ca elemente de modelare: obiectele, clasele, colaborrile i interaciunile.
3.2. Studiu de caz
Sistem de gestiune a unei biblioteci.
Descrierea neformal a cerinelor
Sistemul trebuie sa in evidena crilor care aparin unei biblioteci i a abonailor. Bibliotecarul va
putea cere sistemului:
s nregistreze o nou carte;
s tearg o carte nregistrat;
s nregistreze un nou abonat;
s tearg un abonat din fiierul de abonai.
Fia unei cri va conine:
titlul crii;
numele autorului;
un cod de identificare al crii.
Fia unui abonat va conine numele i prenumele abonatului.
O persoan abonat la bibliotec va putea cere sistemului:
s mprumute o carte;
sa returneze o carte.

Fiecare abonat va trebui s se identifice prin numele i prenumele su. Numrul c r ilor mprumutate simultan
unui abonat va fi limitat.
Cazurile de utilizare
Sistemul va fi utilizat de dou categorii de utilizatori: bibliotecarii i abona ii. Cerin ele func ionale pot fi
deci partajate n dou categorii: cerinele bibliotecarior i cerinele abonailor. Numrul cerinelor fiecrei
categorii fiind redus, putem considera numai dou cazuri de utilizare:

Figura 3.41.
Descrierea cazurilor de utilizare
Gestiunea
Cazul de utilizare este declanat de bibliotecar, atunci cnd cere sistemului s actualizeze fiierul cr ilor
sau fiierul abonailor. Bibliotecarul se adreseaz sistemului selecionnd un articol specific al meniului
aplicaiei.
Inregistrarea unei cri noi
Bibliotecarul introduce titlul crii, numele autorului i un cod de identificare al c r ii. Sistemul verific
dac codul nu este deja alocat unei alte cri i dac cartea nu este deja nregistrat.
Cazul de utilizare se termin prin afiarea unui mesaj care indic bibliotecarului fie c a furnizat un cod
care este deja asignat unei alte cri fie c a specificat o carte care este deja nregistrat , fie c opera ia s-a
sfrit cu succes cartea a fost nregistrat n urma dialogului curent). Cazul de utilizare este ilustrat prin
scenariile 1 i 2.
Stergerea unei cri
Bibliotecarul introduce codul crii. Sistemul caut cartea utiliznd codul. Dac gsete cartea, atunci o
terge din fiierul de cri. Cazul de utilizare se termin cnd sistemul afieaz un mesaj indicnd sau codul este
eronat nu este nici o carte nregistrat avnd codul introdus) sau cartea a fost ters . Cazul de utilizare este
ilustrat prin scenariul 3.
Inregistrarea unui nou abonat
Bibliotecarul introduce numele i prenumele unei persoane. Sistemul caut persoana n fi ierul de
abonai. Dac persoana nu este gsit, atunci sistemul adaug persoana n fiierul de abona i. Cazul de utilizare

se termin prin afiarea unui mesaj indicnd fie c persoana este deja nregistrat fie c sistemul a nregistrat
noua persoan.
1.

Figura 3.30.
2.

Figura 3.42.

3.

Figura 3.32.
4.

Figura 3.43.
Stergerea unui abonat
Bibliotecarul introduce numele i prenumele unui abonat care trebuie s fie eliminat din lista de abona i.
Sistemul caut abonatul n fiierul de abonai. Dac-l gasete, atunci l terge din fiier. Cazul de utilizare se
termin cnd sistemul afieaz un mesaj indicnd sau ca persoana al crei nume i prenume au fost introduse nu
este nregistrat n fiierul de abonai sau c abonatul a fost eliminat din fiier.
5.

Figura 3.44.
B. Exploatare
Cazul de utilizare este declanat de o persoan cand ea se adreseaza sistemului pentru a imprumuta sau
pentru a inapoia o carte. Persoana se adreseaza sistemuluis selectionand un articol specific al meniului aplicatiei.
Cererea de imprumut
Persona selectioneaza articolul "Imprumuta" al meniului aplicatiei. Sistemul invita persoana sa-si introduca
numele si prenumele. Sitemul verifica daca persoana este un abonat al bibliotecii. Daca persoana nu este un
abonat, atunci sitemul afiseaza un mesaj explicativ si cazul de utilizare se termina. Daca persoana este un abonat,
atunci sistemul verifica daca numarul cartilor deja imprumutate de abonat este mai mic ca numarul maxim admis.
Daca nu, sistemul afiseaza un mesaj explicativ si cazul de utilizare se termina. Daca imprumutul este posibil atunci
sistemul invita persoana sa introduca titlul cartii si numele autorului.
6.

Figura 3.45.
7.

Figura 3.46.

8.

Figura 3.47.
Restituirea unei carti
Persoana alege articolul "restituire" al meniului aplicatie. Sistemul il invita sa-si introduca numele si
prenumele. Sistemul cauta persoana in fisierul de abonati. Daca persoana nu este abonata, sistemul afiseaza un
mesaj si cazul de utilizare se termina. Daca persoana este abonata, atunci sistemul invita persoana sa introduca
titlul cartii si autorul.

9.

Figura 3.48.
Login bibliotecara
Sistemul trebuie sa fie protejat fata de utilizatorii care nu sunt bibliotecari, dar care utilizeaza functiile de
gestiune ale bibliotecii. O modalitate de asigurae a acestei protectii este de a permite accesul la functiile de
gestiune numai intr-o stare speciala a sistemului.
Starea initiala a sistemului va permite numai functii de exploatare si de asemenea trecerea intr-o stare de
login bibliotecarea. Tranzitia din aceasta stare in starea de gestiune va avea loc cand utilizatorul intropduce o
parola cunoscuta sistemului. Comportamentul global al sistemului va corespunde deci diagramei de stari tranzitii
urmatoare:

Figura 3.49.
10.

Figura 3.40.

Diagramele de colaborare
1.

Figura 3.41.
2.

Figura 3.42.

4.

Figura 3.43.
8.

Figura 3.44.

9.

Figura 3.45.
Diagrama de clase

Figura 3.46.

Clasele rezultate din analiza


class Sistem
;
class FisierCarti
;
class FisierAbonati
;
class FisaCarte
;
class FisaAbonat
;
class AnsambluDeCarti
;
3.3. Proiectarea arhitectural.
In cursul analizei se determin "ceea ce trebuie fcut", independent de modul de realizare. In etapa de
proiectare trebuie s se decid asupra modului de rezolvare a problemei, mai nti la un nivel general, apoi la
nivele de detaliu din ce n ce mai fine.
Se ncepe cu proiectarea de sistem, n cursul creia se decide arhitectura sistemului, adic organizarea
sistemului n componente numite sub-sisteme. Principalele decizii care trebuie s se ia n etapa de proiectare de
sistem sunt:
- descompunerea n sub-sisteme;
-identificarea concurenelor;
-distribuirea sub-sistemelor pe procesoare i taskuri;
-alegerea unei abordri de gestiune a rezervoarelor de date;
-partajarea accesului la resursele globale.
Un sub-sistem este n general definit prin serviciile pe care le ofer. Un "serviciu" este un grup de func ii
corelate, care au acelai scop: de exemplu, sub-sistemul de fiiere al unui sistem de operare, sub-sistemul care
realizeaz interfaa cu utilizatorul a unui sistem, etc.
Fiecare sub-sistem trebuie s aib o interfa bine definit cu restul sistemului. Interfaa specific
interaciunile i fluxul de informaii ntre sub-sisteme i restul sistemului. Fiecare sub-sistem trebuie s fie
conceput astfel nct majoritatea interaciunilor dintre componente s fie n interiorul sub-sistemelor i nu
ntre sub-sisteme. In acest fel, fiecare sub-sistem poate fi realizat independent de celelalte. El poate fi descompus
la rndul su n pri mai simple, numite module.
Fiecare sub-sistem se reprezint printr-un pachet. Un pachet se reprezint ca n figura de mai jos:

Figura 3.47.
Un pachet poate conine alte pachete. Arhitectura sistemului este definit prin ierarhia de pachete i prin
relaiile dintre pachete. Importurile ntre pachete se reprezint n diagramele de clase i n diagramele de
componente.

Client
pachetului

<< Import >>


Figura 3.48.
Anumite pachete sunt utilizate de toate celelalte pachete. Astfel sunt pachetele care grupeaz clasele de
baz: lista, mulimea, fiierul i altele. Pentru simplificarea reprezentrii grafice, astfel de pachete se declar ca
pachete globale. Nu este necesar s se reprezinte grafic dependenele dintre aceste pachete i utilizatorii lor.
Repartiia sub-sistemelor pe echipamente este reprezentat n diagramele de realizare. Ele ilustreaz
configuraia de echipamente a sistemului i repartiia programelor executabile pe aceste echipamente. Nodurile
diagramei sunt conectate prin linii care simbolizeaz un suport de comunicare bidirecional. Exemplu:

Consola
Imprimanta

TX

<<TCP/IP>>

Server 1)

SGBD

1
*

<<RNISS>>

PC
Pilot
Figura 3.49.
Sistemul ilustrat n figura 3.49. cuprinde: un server, 3 terminale X, mai multe PC-sta ii pilot i o
imprimant.
Un sistem poate fi descompus ntr-o secven de straturi orizontale sau n partiii verticale. Fiecare strat
reprezint un nivel de abstracie. Este implementat folosind serviciile stratului de dedesubt i furnizeaz servicii
folosite de nivelul de deasupra. Sunt dou tipuri de arhitecturi n straturi: deschise i nchise. Intr-o arhitectur
nchis fiecare strat folosete numai serviciile oferite de stratul de sub el. Aceasta limiteaz dependen ele ntre
straturi i faciliteaz modificrile. Intr-o arhitectur deschis, un strat poate utiliza funciile realizate de oricare
dintre straturile precedente inferioare). Aceasta limiteaz necesitile de redefinire a operaiilor la fiecare nivel i
conduce astfel la un cod mai eficient. Un aspect negativ al arhitecturii deschise este c nu respect principiul
mascrii ascunderii) datelor. Orice schimbare a unui nivel poate afecta toate straturile superioare, deci o
arhitectur deschis este mai puin robust dect una nchis.
In descrierea unei probleme sunt menionate n general numai primul i ultimul strat; primul cel mai
nalt) reprezint sistemul iar ultimul resursele disponibile echipamente, sistemul de operare, biblioteci

existente). In practic se introduce un strat care abstractizeaz primul nivel, adic echipamentele i serviciile
oferite de sistemul de operare. Prin aceasta se asigur portabilitatea sistemului pe alte platforme hardwaresoftware.
Partiiile verticale divizeaz un sistem n mai multe sub-sisteme independente sau puin legate, fiecare
furniznd un pachet de servicii proprii. De exemplu, partiiile unui sistem de operare pot con ine: sistemul de
fiiere, gestiunea procesorului, gestiunea memoriei, gestiunea echipamentelor periferice.
Cele dou tipuri de descompuneri pot fi combinate, adic, un strat poate fi divizat n partiii verticale.
3.4. Proiectarea obiectelor.
Obiectele identificate n analiz servesc de schelet pentru viitorul sistem. Proiectantul trebuie s aleag
ntre diferite variante de a le implementa innd cont de criterii de performan i alte criterii ca: reutilizarea,
motenirea, tratarea erorilor, gestiunea memoriei dinamice. In plus, operaiile identificate n analiz trebuie s
fie exprimate prin algoritmi, operaiile complexe descompuse n operaii interne mai simple, atributele i
asocierile implementate prin structuri de date.
Principalele activiti efectuate n timpul proiectrii obiectelor sunt urmtoarele:
-determinarea operaiilor asociate claselor;
-determinarea reprezentrii obiectelor;
-concepera algoritmilor de implementare a operaiilor;
-ajustarea arhitecturii n scopul motenirii;
In proiectarea obiectelor se pleac de la modelul structural static) rezultat din analiz, care este
reprezentat prin diagramele de clase. Proiectantul trebuie s converteasc aciunile i activitile specificate n
diagramele de comportament diagramele de colaborare, de secven, de stri-tranziii i de activiti) n
operaii asociate claselor. In acest fel se ncepe procesul de reprezentare a modelului de analiz ntr-o structur
fizic de program.
Fiecare operaie trebuie s fie exprimat printr-un algoritm. In alegerea algoritmilor proiectantul trebuie s
in cont de criterii ca: complexitatea calculelor, uurina implementrii i a nelegerii, uurina modificrilor
ulterioare.
Pe parcursul dezvoltrii algoritmilor pot s apar necesare noi clase. Acestea sunt clase de nivel cobor t,
pe baza crora sunt implementate clasele aplicaiei. Ele pot fi clase existente sau clase concepute n aceast
etap. Astfel de clase pot fi clase utilitare. Ele grupeaz funcii de exemplu, ale unei biblioteci matematice) dar
nu reprezint obiecte. In diagramele UML clasele utilitare sunt desemnate prin stereotipul <<Utilitar>>. Se poate
utiliza de asemenea, reprezentarea grafic echivalent - un dreptunghi cu o bordur grizat:

Figura 3.50.
Mascarea ascunderea) informaiilor
Una dintre sarcinile importante ale proiectrii este de a defini cu grij interfaa fiecrei clase. Interfaa
constituie partea public a clasei; numai informaiile cuprinse n aceast parte pot fi folosite n implementarea
altor clase. Detaliile de implementare sunt amplasate n partea privat a clasei. Ele nu sunt accesibile altor clase.
Partea privat conine n general datele prin care sunt reprezentate obiectele i legturile dintre ele. Ascunderea
informaiei interne ofer mai multe avantaje:
- permite localizarea erorilor la nivelul metodelor;
- asigur protejarea datelor mpotriva acceselor nedorite;
- contribuie la obinerea unui program cu o bun adaptabilitate, deoarece orice modificare a structurii obiectelor
sau a implementrii metodelor nu afecteaz comunicaia obiectelor din alte clase cu obiectele clasei.
Regulile de vizibilitate permit completarea sau particularizarea mascrii. Cele trei nivele de mascare definite n
UML corespund celor existente n limbajul C++: privat, protejat i public. Nivelul de vizibilitate al fiecarui atribut
sau operaie poate fi precizat n reprezentarile grafice ale claselor cu ajutorul caracterelor +, #, - .

+ Atribut public
# Atribut protejat
- Atribut privat
+ Operatie publica )
# Operatie protejata )
- Operatie privata )
In timpul fazei de analiz i de proiectare de sistem elementele de modelare au fost repartizate n module
i pachete. Este posibil ca aceast organizare iniial s nu fie optim. Clasele adugate n timpul proiectrii fie
c se adaug la pachetele i straturile existente fie c se organizeaz n pachete i straturi separate.
Un pachet nu este numai o grupare logic de elemente ci i o ncapsulare a lor. Fiecare element con inut
ntr-un pachet posed un parametru care indic dac elementul este vizibil sau nu din exteriorul pachetului.
Valorile parametrului sunt: "public" sau "implementare". Numai clasele indicate ca publice pot fi referite de clasele
membre ale pachetelor client. Pachetele trebuie s aib interfee minimale i bine documentate. Interfaa dintre
dou pachete este compus din asocierile care leag clasele unui pachet de clasele celuilalt pachet i din operaiile
utilizate n schimbul de mesaje ntre obiecte aparinnd claselor din pachetele respective.
Diagramele de componente
Aceste diagrame descriu elementele fizice i relaiile lor n mediul de realizare. No iunea de modul, n
UML, este foarte geneal. Modulele pot fi fiiere, biblioteci i altele.
Fiecare clasa este realizat prin dou componente: specificaia i corpul implementarea). Specificaia
poate fi generic. In C++ specificaia corespunde unui fiier .h iar corpul unui fiier .cpp. Scopul principal al
acestor diagrame este de a reprezenta relaiile stabilite ntre diferite componente. O s geat indic faptul ca o
component utilizeaz serviciile oferite de o alt component. Sgeata indic furnizorul.

Instaniere

Fig. 3.29.
Intr-o diagram de componente, relaiile de dependen reprezint n general dependene de compilare.
Alte notaii:
Componenta care conine punctul de intrare

Funcie sau procedur care nu aparine unei clase