Universitatea Transilvania din Braov

Facultatea de Matematic i Informatic

Sisteme integrate de proiectare
i programare

-Partea II-a-

-note de curs pentru studenii de la ID-







Dorin Bocu

2003/2004

























I IN NI I I IE ER RE E N N
M MO OD DE EL LA AR RE EA A O OB BI IE EC CT T O OR RI IE EN NT TA AT T A A S SI IS ST TE EM ME EL LO OR R S SO OF FT T
U UT TI IL LI IZ Z N ND D U UM ML L









Cuvnt nainte

n loc de scuz, pentru ntrzierea cu care am venit la intlnirea cu
UML.
De mai mult vreme dau trcoale universului UML. Mult timp l-am privit ca
pe o jucrie, care trebuia inut sub pern, n sperana c ntr-o zi m va ajuta s
visez ceva frumos. Acum, a venit momentul s privesc acest univers cu ali ochi.
Adic, s ncerc un rspuns ct mai accesibil la ntrebarea "Ce putem face,
efectiv, cu ajutorul UML-ului?" nc mai am bnuiala c nu este uor ceea ce
ncerc. Din fericire, aceasta bnuial a nceput s pleasc n comparaie cu
dorina de a aduce la ramp o lume care vine puternic din urm, pentru a nlocui o
alta mai veche, n folosul tuturor celor care privesc n viitor.

Cum ne poate fi de folos UML?
UML este un limbaj de modelare, folosit pentru a reprezenta soluiile
sistemelor soft, n vederea transpunerii lor sub form de cod executabil, pe un
calculator, real sau virtual. De-a lungul procesului de dezvoltare, UML nu este
doar un instrument de reprezentare ci i un instrument de comunicare ntre
partenerii de proiect, de diferite categorii. Prin urmare, are toate calitile unui
limbaj care pretinde c rezolv probleme de comunicare, pstrnd ceea ce este
esenial n utilizarea limbajelor naturale (abilitatea gndirii comune de a le folosi)
i adugnd ceea ce este o exigen necesar n cazul limbajelor artificiale
(nclinaia lor spre rigoarea enunurilor, cel puin la nivel sintactic). UML are o
sintax aleas cu grij, pentru a permite reprezentarea unor semantici dintre
cele mai complexe, satisfcnd exigene dintre cele mai variate ale
pragmaticii. n aceast carte nu m va preocupa organizarea obiectelor care
populeaz UML-ul ntr-un ansamblu, coerent din punct de vedere al specificrii,
ci prezentarea acestor obiecte astfel nct cititorul s neleag, pn la urm, cum
intr ele n scen n proceul de reprezentare / documentare a soluiei unei
probleme date.

Documentaia, de cpti pentru realizarea acestei lucrri, mi-a fost pus
la dispoziie de D-l Mihai Mircea, fapt pentru care i mulumesc din toat inima.
De mare folos mi-au fost i crile (xerocopiate) pe care mi le-au adus
absolventele Mara Drgan i Elena ibrea la ntoarcerea lor din stagiile pe care le-
au efectuat n Olanda. n sfrit, de mare folos este i faptul c predau studenilor,
de la specializarea informatic a Facultii de Matematic i Infomatic din cadrul
Universitii Transilvania din Braov (n principal), cursul de Ingineria
sistemelor soft.

Chiar dac a fost scris cu gndul la studenii de la secia de informatic,
lucrarea poate fi citit, glumind puin, i de un individ care a studiat teologia, dac
se ntrebuineaz.

Cititorilor care vor s-mi transmit observaiile lor, relativ la aceast carte,
le pun la dispoziie adresa mea e-mail: d.bocu@unitbv.ro. Sper s fie folosit cu
nelegerea cuvenit, din toate punctele de vedere.































Capitolul 1
Elemente introductive

...Ingineria softului a intrat n mileniul trei orientat pe obiecte. Este
de datoria cercettorilor s identifice punctele slabe ale obiect
orientrii i s propun alte viziuni asupra modului n care se
desfoar etapa cea mai important pentru realizarea unui sistem soft:
modelarea.


























1.1 Cteva cuvinte despre problematica realizrii sistemelor soft
Realizarea sistemelor soft este o activitate a crei complexitate reclam efort constant de
sistematizare i optimizare. Se poate produce soft ieftin, de calitate i n timp util, dac se
lucreaz pe principii asemntoare tehnologiilor din mediile industriale. n lumea softului, astfel
de tehnologii se numesc metodologii. Specificarea unei metodologii urmrete asigurarea de
elemente suport (n efortul de dezvoltare a unui sistem soft) pentru:

Abstractizarea (=conceptualizarea, specificarea, implementarea) soluiei unui sistem soft
(ciclul de abstractizare, limbajul de modelare);
Etapizarea (structurarea) efortului de dezvoltare (ciclul de via al sistemelor soft,
partea de proces a unei metodologii).
Reprezentarea soluiei unui sistem soft n toate fazele de dezvoltare (notaia), ntr-o
strns legtur cu limbajul de modelare.
Managementul proiectelor de realizare a sistemelor soft (gestiunea resurselor i a
riscurilor pe care le presupune derularea unui astfel de proiect).
UML este un limbaj (de modelare) care, promovnd modelarea obiect orientat,
provoac prin varietatea ofertei: rigoare sintactic, semantic bogat, suport pentru
modelarea vizual, etc. Aceast carte urmrete iniierea unui informatician (obinuit s realizeze
un sistem soft concentrnd ntregul efort n faza de implementare) n arta de a modela nainte de
a implementa. Procednd astfel, informaticianul devine specialist n ingineria softului, capabil s
nfrunte, dintr-o perspectiv raional, dificultile care caracterizeaz efortul de dezvoltare a unui
sistem soft. Aspecte referitoare la aceste dificulti se pot gsi n [5].

1.2 Modelarea obiect orientat. Concepte i principii
fundamentale
nainte de a fi UML, a fost OO (=obiect orientarea). Originile obiect orientrii pot fi
identificate de-a lungul ntregului efort depus de comunitatea specialitilor n ingineria softului
(IS), pentru raionalizarea activitilor aferente procesului de dezvoltare a unui sistem soft. Cu
riscul de a nemulumi pe unii teoreticieni ai IS, voi spune c istoria IS consemneaz trei tendine
majore n ceea ce privete specificarea limbajelor de modelare:
modularizarea dirijat de date;
modularizarea dirijat de prelucrri;
modularizarea dirijat de fluxul datelor.
Aceste trei direcii au dus la specificarea unei palete largi de metode de abstractizare a soluiei
unui sistem soft; o parte dintre ele le prezentm n Figura 1. Trebuie s subliniez faptul c, ntr-o
proporie covritoare, aceste metode sunt deja istorie. De actualitate au mai rmas doar acele
concepte i principii care i-au gsit locul i n noile paradigme de modelare.
Acestor trei direcii, care s-au manifestat efectiv i n practic, li se adaug o a patra,
prezentat n Figura 2, ale crei ecouri s-au pierdut n laboratoarele de cercetare, sau pot fi
regsite n unele paradigme de modelare actuale.
Cititorul poate gsi informaii despre reperele prezentate n Figurile 1 i 2, consultnd lucrarea
Ingineria programrii (Ilie Vduva .a.), Editura Academiei RSR, 1985.


















Figura 1. Metode clasice de abstractizare, avnd la baz principiul modularizrii

Modularizare dirijat de prelucrri
Proiectarea Top-Down
Metoda HIPO (IBM)
Metoda SADT (Structured Analysis and Design Technique)
Modularizare dirijat de date
LCP (Logical Construction of Programs)
LCS (Logical Construction of Systems)
Metoda Jackson
Modularizare dirijat de fluxul datelor
Proiectarea structurat (Yourdon & Constantine)
Proiectarea compus (G. Myers)






Figura 2. Paradigme de abstractizare, orientate pe abstracii

Indiferent de modelul de abstractizare folosit, marea problem n IS rmne aceeai: ce
proprieti are modul n care domeniul problemei (DP) se mapeaz pe domeniul soluiei
(DS), abstractiznd conform cerinelor unei metodologii date?.
Autorul acestei cri consider c toate elementele-suport ale unei metodologii concur la
realizarea unei mapri de calitate a DP pe DS.
Se poate constata, practic, faptul c o mapare defectuoas a DP pe DS afecteaz modul de
ndeplinire a altor obiective asumate, ntr-o form sau alta, de orice metodologie, anume:

reutilizarea intensiv a efortului de modelare;
atenuarea intensitii ocurilor pe care o soluie poate s le acuze n cazul n care se
modific cerinele fa de sistemul soft (cititorul avizat nelege, probabil, c este vorba
de cerine funcionale, cerine n ceea ce privete platforma hard i soft-suport pentru
execuie, etc.);
simplificarea efortului depus pentru extinderea funcionalitii
sistemului soft.

Cauza principal a defeciunilor metodologiilor clasice de dezvoltare a sistemelor soft se afl
n modul n care este rezolvat problema relaiei dintre date i prelucrri.
n metodologiile clasice se face, sistematic, o greeal cu efecte, uneori, devastatoare asupra
calitii sistemelor soft: modelarea datelor este, o problem a crei soluie crete, n
contextul unei relaii, adeseori dihotomice, cu organizarea prelucrrilor. Dihotomia poate s
nsemne:

evoluia paralel a proceselor de organizare a datelor i prelucrrilor;
postularea derivrii structurii de prelucrare a unui sistem soft din
analiza structurii datelor;
enunarea primatului prelucrrilor asupra datelor n procesul de
dezvoltare a sistemelor soft.

Toate aceste probleme, plus nc nenumrate altele, ateptau o rezolvare din partea unei
paradigme de modelare noi. Paradigma care a impus o abordare nou a relaiei dintre date i
prelucrri este modelarea obiect orientat.
Nenumrate sunt exemplele de sisteme informaionale a cror reprezentare natural, n
domeniul problemei, este sub forma unei colecii, cu structur specific, de obiecte, posednd att
atribute informaionale ct i atribute comportamentale.
n modelarea obiect orientat, sistemele informaionale sunt abstractizate ca i colecii de
obiecte, ntre care se stabilesc diferite tipuri de relaii, pe baza crora are loc evoluia n timp
a sistemelor informaionale, n vederea ndeplinirii obiectivelor asumate.
Am dat mai sus o definiie care, pentru cunosctori, amintete foarte bine de noiunea de
sistem, din teoria general a sistemelor.
Aproape c se subnelege faptul c, pentru a putea modela un sistem informaional, acesta
trebuie s fie identificat ca un sistem cu invarian structural, pe un interval de timp rezonabil.
ntr-un univers obiect orientat, specialistul n IS i modific radical atitudinea fa de
relaia dintre date i prelucrri.
Rezultatul efortului de abstractizare a soluiei unui sistem soft, n modelarea OO poate fi o
ierarhie sau o reea de clase ntre care putem defini relaii de asociere, agregare,compunere,
generalizare, etc.
Fiecare clas abstractizeaz, la un anumit nivel, o anumit realitate informional. Specificarea
sintactic i semantic a unei clase nseamn:

Identificarea atributelor informaionale, necesare i suficiente pentru a rspunde
cerinelor interne i externe ale obiectelor din clasa respectiv;
Identificarea atributelor comportamentale, necesare i suficiente pentru a rspunde
cerinelor interne i externe ale obiectelor din clasa respectiv;
Modularizarea orientat pe abstracii
Metoda lui Parnas
Metoda mainilor abstracte (Dijkstra)
Metoda mainilor cu stri (IBM)
Specificarea atributelor comportamentale, care fac parte din interfaa clasei.
Dogmatic vorbind, toate atributele informaionale ale unei clase trebuie s fie private.
Accesul clienilor unei clase la atributele informaionale ale instanelor acestei clase este
posibil doar prin intermediul interfeei. Se spune c obiectele, aflate n relaia client-
server, fac schimb de mesaje.
1.3 Ce este UML(fr a intra n detalii)?
Cititorul bnuiete, deja, c UML este rezultatul unor acumulri cu un istoric destul de
zbuciumat, n materie de modelare a soluiilor sistemelor soft.
Aadar, s remarcm faptul c UML este un limbaj de modelare, nu o metodologie. Ca
limbaj de modelare, UML ofer o notaie, n spatele creia se afl o semantic adecvat. Notaia
este n mare parte grafic, astfel c este ct se poate de nimerit s reproducem caracterizarea de
ansamblu a UML-ului, fcut n documentaia pus la dispoziie n site-ul www.rational.com:

UML este un limbaj pentru specificarea, vizualizarea, construirea i documentarea
componentelor (artifacts) unui sistem soft sau, la fel de bine, pentru modelarea
organizaional i a altor sisteme, nu neaprat din lumea IS.

Cele mai puternice i recente rdcini ale limbajului UML se afl n metodologiile, patronate
spiritual de Grady Booch, James Rumbaugh i Ivar Jacobson.
UML a unificat i standardizat oferta metodologiilor Booch, OMT i OOSE, precum i a altor
metodologii cu abordri remarcabile, n spatele crora se afl autori precum Odell, Shaeler-Mellor,
Meyer, Wirfs-Brock etc.
Prima versiune public a UML a fost lansat n octombrie 1995 sub forma versiunii 0.8.
Reacia marelui public a fost evaluat i inclus n versiunea 0.9, n iulie 1996 i n versiunea 0.91,
n octombrie 1996. Versiunea 1.0 a fost prezentat pentru standardizare membrilor OMG (Object
Management Group) n iulie 1997. O serie de mbuntiri aduse UML au fost incluse n versiunea
1.1, care a fost prezentat OMG n septembrie 1997. UML a fost adoptat ca standard, n
unanimitate, de ctre membrii OMG, n noiembrie 1997. OMG este actualmente implicat, cu
responsabiliti precise, n dezvoltarea viitoare a standardului UML. Versiunea 1.3 a fost fcut
public n 1999 i prin contribuia grupului RTF (Revision Task Force), etc.
S ncercm acum o explicaie a sintagmei unified din denumirea UML.
Aadar, pentru UML, atributul unified poate fi neles n raport cu urmtoarele topici IS.

Metodologiile i notaiile asociate lor privite din punct de vedere
istoric
UML combin conceptele, folosite intens i cu acelai neles, n mai multe metodologii obiect
orientate, impunnd definiii clare pentru fiecare concept i o notaie adecvat. Ca urmare, UML
este capabil s reprezinte cele mai multe dintre modelele existente, la fel de bine sau chiar mai
bine dect metodologiile originale.

Ciclul de via al dezvoltrii sistemelor soft
UML opereaz cu aceleai concepte i notaii n diferite etape ale procesului de abstractizare a
soluiei. Prin urmare, nu este necesar un efort de translatare semantic i sintactic a soluiei, de la
un nivel de abstractizare la altul. Aceast situaie este absolut convenabil din perspectiva
modelului iterativ i incremental de dezvoltare, cu care UML se potrivete cel mai bine.

Tipuri de aplicaii
UML este pregtit s ofere suport pentru modelarea unui numr mare de tipuri de aplicaii,
incluznd sisteme cu volum mare de date i prelucrri, sisteme de mare complexitate, sisteme de
timp real, sisteme distribuite, etc. Este posibil s existe tipuri de probleme n care un limbaj de
modelare specializat este mai folositor, dar UML este de ateptat s fie la fel de bun sau chiar mai
bun dect orice alt limbaj de interes general, n multe tipuri de aplicaii.

Limbaje i platforme de implementare
UML este gndit s fie util pentru sisteme soft implementate pe diferite platforme, incluznd
limbaje de programare, SGBD-uri, 4GLs, documente organizaionale, medii firmware, etc. Modul
de lucru este acelai sau prezint multe similariti n toate tipurile de aplicaii, rezultatul fiind
dependent de mediul n care se lucreaz.




Procesul de dezvoltare
Aa cum am mai spus, UML este un limbaj de modelare, nu o descriere a unui proces de
dezvoltare detaliat. UML este gndit s fie utilizat independent de proces, dar ofer suport complet
pentru procesele de dezvoltare iterative i incrementale (a se vedea. Rational Unified Process -
RUP).

Obervaie
Ideile prezentate n acest paragraf i au originea n crile care, populariznd UML-ul, nu se
pot abine de la ridicarea lui pe cele mai nalte culmi; aproape c miroase a monoteism n
materie de limbaje de modelare. Ori, pn una alta, n modelare i n cunoatere, n general,
pluralismul rmne singura soluie a progresului.
Sintetiznd cele spuse n paragraful 1.3, putem spune c efortul de unificare ntruchipat de
UML a fost i este un demers dificil deoarece este sub presiunea permanent a unor cerine,
uneori, contradictorii:

Ambiia de a prelua tot ce este bun din punct de vedere sintactic i semantic n
metodologii precum Booch, OMT, OOSE i altele.

Nevoia de a prezenta utilizatorului protocoale simple i riguroase de reprezentare a
diferitelor proprieti ale soluiei unui sistem soft.

Nevoia de a oferi specialitilor suport pentru pentru abordarea unor tipuri variate
de probleme.

Punerea la dispoziia specialitilor a unui formalism adecvat pentru a reprezenta
concepte precum: procese i fire de execuie, distribuie i concuren (ActiveX,
DCOM i CORBA), abloane (patterns), diagrame de activitate (n modelarea
fluxurilor), etc.

S precizm, n sfrit, faptul c UML a fost dezvoltat de Rational Software Corporation i
partenerii ei, precum: OMG, Digital Equipment Corporation, HP, i-Logix, IntelliCorp, IBM,
Microsoft, Oracle, etc.
Cititorului amator de elemente de referin referitoare la UML s-i mai spunem c, din
perspectiv formal, UML are o arhitectur structurat pe patru nivele de abstractizare: obiecte
utilizator, model, meta-model i meta-metamodel. Astfel c, specialitii obinuiesc s spun c
UML are o arhitectur de metamodelare pe 4 nivele, cum rezult i din Figura 3.

Nivel Descriere Exemple
Meta-metamodel Desemneaz infrastructura
conceptual, necesar pentru o
arhitectur de metamodelare.
Definete limbajul pentru
specificarea metamodelelor.
MetaClase,
MetaAtribute,
MetaOperaii
Metamodel Desemneaz o instan a unui
meta-metamodel.
Definete limbajul necesar
pentru specificarea unui model.
Clas, Atribut,
Operaie,
Component
Model Desemneaz o instan a unui
metamodel. Definete un limbaj
pentru descrierea domeniilor
informaionale.
CodProdus,
DenumireProdus,
Cantitate, etc.
Obiecte(dat)
utilizator
Desemneaz o instan a unui
model. Definete un domeniu
informaional concret.
<1111>, <eav
PVC>, 30

Figura 3. Arhitectura UML

Pe bun dreptate, cititorul se va intreba: La ce mi folosete s tiu attea despre
arhitectura UML?. Un rspuns moderat la aceast ntrebare, mai jos.
Aa cum se prezint la ora actual, UML ofer utilizatorilor o notaie i un meta-model.
Notaia desemneaz acele elemente de sintax (preponderent grafice) cu ajutorul crora se
specific soluia UML a unui sistem soft. De exemplu, pentru a reprezenta soluia UML a unei
probleme, n mod normal ne vom folosi de notaia aferent diagramelor de clase, n care se
opereaz cu concepte precum: clase, asocieri, generalizri, multiplicitate, etc. Utilizatorul grbit
prinde din zbor semantica unor astfel de concepte. Utilizatorul care are obsesia rigorii, vrea un
rspuns precis la ntrebri de genul: Ce este o clas?.
Productorii de tools-uri de dezvoltare pentru specialitii IS sunt chiar interesai, n mod
obiectiv, de clarificarea rspunsurilor la astfel de ntrebri. Ideea unor limbaje de specificare i
proiectare riguroase este bine reprezentat n lumea metodelor formale (n care singurele enunuri
acceptate sunt n spiritul calculului propoziional sau al calculului predicatelor).

Metodele formale reprezint cea mai bun arm cu care putem stvili insinuarea
ambiguitilor n enunurile noastre.

Din pcate, omul n genere , nu a fost proiectat spre a fi un adorator al limbajelor
formale.
Pentru a comunica, omul n genere folosete cel mai bine limbajul natural sau derivai
simplificai ai acestuia. La urma urmei, aceast nclinaie natural are o explicaie destul de
profund:

Capacitatea lilmbajelor naturale de a opera cu semnificaii noi este mult mai mare dect
a limbajelor formale.

Pentru a mpca pe toat lumea, UML ofer utilizatorilor un meta-model, cu ajutorul cruia
se dau rspunsuri riguroase la ntrebri de genul: Ce este o clas?. Aceast caracteristic face din
UML un limbaj interesant, deoarece resursele pentru specificarea conceptelor lui se gsesc n el
nsui (limbajele de programare, de exemplu, folosesc metalimbaje de tip notaie BNF sau
diagrame de sintax, pentru specificare).

1.4 RUP(The Rational Unified Process)
RUP este modelul de dezvoltare considerat cel mai adecvat pentru paradigma de modelare
UML. Prezentarea lui, n acest paragraf, devine cu att mai interesant cu ct firma Rational ofer
o palet ntreag de tools-uri cu ajutorul crora se poate face dezvoltare n spirit UML&RUP.
Scopul RUP, redus la esene, ar putea fi formulat astfel:

Asigurarea cadrului pentru realizarea unor sisteme soft de calitate deosebit, care
corespund n cel mai nalt grad cerinelor utilizatorilor, dispunnd de un buget i grafic
de execuie predictibile

RUP reunete o parte dintre cele mai bune idei ale metodologiilor curente de dzvoltare a
softului, ntr-o form care este potrivit pentrui o mare varietate de proiecte de dezvoltare a
softului, sau chiar proiecte de modelare organizaional.
n ceea ce privete elementele de management, RUP furnizeaz, potenial vorbind, o
abordare disciplinat a problemelor legate de gestiunea sarcinilor i responsabilitilor, n
interiorul unei firme care dezvolt soft.

Caracteristici ale RUP

RUP descrie un proces iterativ.
n cazul sistemelor simple, pare absolut rezonabil un scenariu de rezolvare unidirecional a
problemei. Exist, ns, n practica IS, nenumrate probleme a cror rezolvare nseamn
dezvoltarea unor sisteme de mare complexitate sau de-a dreptul sofisticate. Pentru astfel de
sisteme, abordarea secven unidirecional este total nerealist. Alternativa o reprezint
abordarea iterativ care sprijin nelegerea progresiv a problemei prin rafinri succesive i
creterea incremental a soluiei efective, pe baza unor cicluri multiple. Abordarea iterativ
ofer flexibilitate n acomodarea la cerine noi sau modificri tactice la nivelul obiectivelor
sistemului modelat. De asemenea, abordarea iterativ permite participanilor la proiect s
identifice i s rezolve riscurile nainte ca acestea s devin o povar n procesul de
dezvoltare a proiectului. Activitile RUP pun accent pe realizarea i ntreinerea unor
modele, spre deosebire de alte metodologii care fetiizeaz rolul documentelor care nsoesc
reprezentarea soluiei.
Modelele, ndeosebi cele realizate cu ajutorul UML-ului permit reprezentri cu semantic
bogat ale sistemelor soft n curs de dezvoltare. Aceste modele pot fi vizualizate n diferite moduri
iar informaia asociat lor poate fi manevrat electronic n regim on-line, utiliznd tools-uri
precum Rational Rose sau ObjectiF. Deplasarea accentului spre modele urmrete minimizarea
cheltuielilor necesare pentru generarea i ntreinerea documentelor i, totodat, maximizarea
informaiilor cu coninut relevant.

Dezvoltarea sistemelor soft conform RUP este centrat pe
arhitectur.
RUP este un model de dezvoltare care conine suport pentru fundamentarea i realizarea
timpurie a arhitecturii sistemului soft. Identificarea unei arhitecturi robuste faciliteaz lucrul
n paralel la proiect, minimizeaz efortul de reproiectare i mrete probabilitatea de a
reutiliza unele componente ale sistemului. De asemenea, o arhitectur robust este de dorit i din
punct de vedere al managementului dezvoltrii sistemului soft.

Activitile de dezvoltare sub RUP sunt dirijate de contextele de utilizare(use case-
driven).
RUP pune mare accent pe construirea sistemelor, lund n cosideraie modul n care sistemul,
odat livrat, va fi utilizat.

RUP suport tehnicile obiect-orientate.
Fiecare model n cadrul RUP este obiect-orientat, realizat conform notaiei furnizate de UML,
de preferat.



FAZE
Fluxuri de lucru
n interiorul
fazelor
Iniiere Elaborare Construcie Tranziie
Modelare afacere
Specificare cerine
Analiz i
proiectare

Implementare
Testare
Configurare hard
Fluxuri suport
Managementul
schimbrilor

Managementul
proiectului

Asigurarea
mediului de lucru

Iteraie Iteraie Iteraie

Iteraii
preliminare
#1 #2 #n #n+1 #m

#m+1

Figura 4 Ciclul de via RUP

RUP este un proces configurabil.
Cu toate c nici un proces nu este potrivit pentru toate firmele de dezvoltare a softului, RUP
este configurabil, astfel nct s corespund cerinelor unor organizaii, mergnd pe scara
complexitii de la echipe de dezvoltare mici pn la firmele mari i foarte mari.


RUP ncurajeaz preocuprile pentru controlul calitii i managementului riscului.
Evaluarea calitii este realizat pe tot parcursul dezvoltrii soluiei, cu implicarea progresiv
a tuturor participanilor, utiliznd metrici i criterii obiective. Managementul riscului este, de
asemenea, o constant a unui proces RUP, ceea ce permite identificarea n fa a riscurilor care
ar putea duna succesului unui proiect.

Faze i iteraii n RUP
O faz, n IS, este intervalul de timp cuprins ntre dou repere majore ale procesului, n
care sunt ndeplinite un set precis de obiective, se realizeaz o serie de piese ale sistemului soft
(artifacts, n literatura american) i se decide trecerea sau nu n faza urmtoare, dac este cazul.

Iniiere (Inception);

Elaborare (Elaboration);

Contruire (Construction);

Tranziie (Transition).

Se poate vedea viziunea Rational asupra procesului de dezvoltare a unui sistem soft, din
perspectiv semantic, urmrind ideile prezentate n Figura 4.
Cititorul atent poate s observe marele potenial ncapsulat n modelul RUP. Dac adugm i
precizarea c acest model este susinut integral de instrumentele CASE elaborate de firma
Rational Software, cititorul trebuie s fie de acord cu faptul c toat vlva care se face n jurul
UML i RUP are explicaii care au depit deja faza confruntrilor teoretice.
Pentru edificare, n continuare voi oferi cteva explicaii pe marginea coninutului celor patru
faze.

Iniiere
Este faza n care se face ceea ce, n limba romn, s-ar putea numi studiul de oportunitate
care trebuie s precizeze:
domeniul proiectului;
criteriile pentru aprecierea reuitei;
evaluarea riscurilor;
estimarea resurselor necesare;
un grafic de execuie preliminar, raportat la cele patru faze principale.
Cu tehnologiile de dezvoltare existente este ct se poate de uzual s se realizeze un prototip
executabil care ajut la ntrirea celor precizate mai sus.

Elaborare
n aceast faz este analizat domeniul problemei, se stabilete un fundament arhitectural
robust, se realizeaz planul proiectului i se elimin factorii de risc major ai proiectului. Deciziile
arhitecturale trebuie luate avnd o viziune bine conturat asupra ntregului sistem. Aceasta
nseamn c cea mai mare parte a cerinelor fa de sistem trebuie specificate corect.
Pentru validarea arhitecturii propuse se poate implementa un sistem orientat pe contextele de
utilizare (use case) semnificative.

Construcie
n aceast faz, procednd iterativ i incremental se poate implementa un produs complet,
capabil s porneasc spre comunitatea utilizatorilor lui. Aceasta implic descrierea cerinelor
omise n faza de elaborare, proiectarea pn la detaliu a sistemului i completarea implementrii i
testrii acestuia.

Tranziie
n timpul acestei faze softul este livrat utilizatorilor. Odat ajuns la utilizatori este posibil s
apar cerine de dezvoltare adiional, este posibil , de asemenea, s fie scoase la iveal bug-uri
scpate sau plantate cu iscusin. n practic, aceast faz debuteaz cu o versiune beta a
sistemului care este nlocuit, treptat, de versiunea consolidat a acestuia. Teoretic, la terminarea
acestei faze se decide dac obiectivele ciclului de via au fost ndeplinite i se evalueaz
posibilitatea de a ncepe un nou ciclu de dezvoltare.
Cititorul deduce, din Figura 4, faptul c fiecare faz a modelului RUP poate fi obiectul mai
multor iteraii, o iteraie fiind un ciclu de dezvoltare complet n cadrul unei versiuni a sistemului
soft executabil, avnd ca rezultat un subset al produsului final, care se va mbogi funcional de la
iteraie la iteraie, pn cnd se ajunge s ndeplineasc condiiile de livrare la utilizatori.
1.5 Date eseniale pentru nelegerea UML
Inspirndu-m din strategia adoptat de Grady Booch n [2], n acest paragraf voi trece n
revist coordonatele eseniale pentru nelegerea UML.

Aadar, UML este un limbaj pentru: vizualizarea, specificarea, construirea i
documentarea componentelor unui sistem soft.

UML limbaj pentru vizualizare
UML pune accent pe vizualizarea soluiei unui sistem soft pentru a elimina cea mai mare parte
a problemelor de comunicare care pot s apar ntre diferitele categorii de participani la
dezvoltarea unui sistem soft. Evident, fr a renuna n totalitate la text, UML propune o manier
preponderent grafic de reprezentare i documentare a unui sistem soft.

UML limbaj pentru specificare
n ingineria softului, specificarea nseamn elaborarea de modele precise, complete i fr
ambiguiti. O specificare vizual, cum este specificarea UML, este expus riscului de a genera
ambiguiti n procesul de comunicare, ntr-un grad mai mare dect n cazul specificrii formale.
i totui, o specificare vizual a soluiei n toate fazele de dezvoltare a unui sistem soft, este de
preferat, dat fiind importana unei comunicri ct mai ample ntre specialitii IS, utilizatori i
beneficiari, ca parteneri n cadrul aceluiai proiect.

UML limbaj pentru construire
Probabil, a fost neles faptul c UML nu este un limbaj de programare vizual, dar, ceea ce
trebuie reinut este faptul c modelele elaborate n UML pot fi uor translatate n numeroase
limbaje de programare. Aceast stare de fapt ne sugereaz posibilitatea maprii naturale a unui
model UML n limbaje precum Java, C++, Vizual Basic, Ada, etc.
Posibilitatea efectiv a acestei mapri st la baza generrii automate a codului asociat unui
model UML, n conformitate cu o anumit opiune de limbaj. Generarea automat a codului,
pornind de la modelul UML, sau invers, regsirea modelului UML asociat unei implementri date,
sunt posibile utiliznd instrumente CASE, precum Rational Rose, ObjectiF, etc.

UML limbaj pentru documentare
O firm de soft adevrat produce toate genurile de componente adiionale obinerii codului
executabil al unui sistem soft, precum:

Cerinele fa de sistemul soft;
Descrierea arhitecturii sistemului;
Specificaiile de proiectare;
Codul surs;
Planurile de dezvoltare, etc.

UML posed resurse adecvate pentru specificarea cerinelor fa de un sistem soft,
reprezentarea arhitecturii unui sistem i a tuturor detaliilor de proiectare, modelarea activitilor de
management al proiectului, etc.

Unde putem folosi UML?
nainte de orice, UML a fost gndit s fie utilizat n dezvoltarea de sisteme soft n domenii
precum:

- Sistemele informaionale ale ntreprinderilor;
- Servicii financiare i bancare;
- Telecomunicaii;
- Transporturi;
- Electronica medical;
- Servicii distribuite bazate pe WEB, etc.

S mai adugm faptul c UML este suficient de expresiv pentru a permite i modelarea
sistemelor de alt natur dect soft (fluxuri de lucru n sistemul justiiei i sntate, etc.).

Arhitectura sistemelor soft din perspectiv UML
n paragraful 1.3 am fcut scurte referiri la arhitectura UML ca limbaj de modelare. n acest
paragraf voi ncerca o prezentare a ideilor principale referitoare la arhitectura unui sistem
soft, din perspectiv UML.
Un specialist n IS cunoate bine faptul c, sistemele de mare complexitate, nu pot fi modelate
satisfctor dac paleta criteriilor de observare i analiz nu este adecvat structurat. nvnd din
greelile altor limbaje de modelare, UML propune o formul de arhitectur comprimat n
sintagma perspectiva arhitectural 4+1.
Aceast formul este binevenit, att pentru lucrul n echip la un proiect (deci n sprijinul
managementului) ct i pentru procesul de obinere a unei soluii de calitate i ct mai complete.
Perspectiva arhitectural 4+1 este reprezentat, n sintez grafic, n Figura 5, care ne sugereaz
faptul c identificarea arhitecturii unui sistem soft este o activitate pentadimensional, dac mi se
ngduie exprimarea. Fiecare perspectiv focalizeaz atenia echipei de dezvoltare asupra unui gen
de probleme, a cror rezolvare influeneaz n mod specific calitatea soluiei, n ansamblu. Atrag
atenia asupra rolului pe care l joac perspectiva context de utilizare n contextul celorlaltor 4
perspective.

Perspectiva logic sistem (Structural view)
Aceast perspectiv a arhitecturii uni sistem soft se refer la cerinele funcionale ale acestuia.
Altfel spus, ce servicii asigur sistemul soft pentru utilizatorii lui? Arhitectura logic este
ncapsulat n diagramele claselor, care conin clasele i relaiile dintre ele (socotite abstracii
fundamentale ale sistemului n curs de dezvoltare). Mare parte din notaia UML este dedicat
reprezentrii arhitecturii logice (clase, asocieri, generalizri, agregri, pachete, etc.).





























Figura 5 Perspectiva arhitecturii 4+1

Elementele care definesc arhitectura logic ncep s fie precizate nc de la nceputul fazei de
elaborare (a se vedea RUP), cnd se stabilesc clasele i pachetele socotite abstracii majore ale
domeniului problemei. n timp, alte i alte clase i pachete sunt adugate modelului UML al
soluiei pentru a reflecta deciziile luate privitor la mecanismele cheie ale sistemului soft.
Prin urmare, putem spune c arhitectura logic a unui sistem soft poart amprenta
abilitii echipei de dezvoltare, de a armoniza gestiunea abstraciilor majore ale sistemului
soft cu gestiunea mecanismelor cheie ale sistemului soft.
Aceast abilitate este transpunerea, ntr-un context particular, a relaiei dintre strategie
(=abstraciile majore) i tactic (=mecanismele cheie). Deciziile tactice greite, n timpul
Perspectiva
logic sistem
(structural)
Funcionalitate
Perspectiva
componenete sistem
(implementaional)
Managementul
softului
Reutilizare
Portabilitate
Perspectiva
topologie sistem
(desfurare n mediul
de execuie)
Performan
Utilitate
Toleran la erori
Livrare i instalare

Perspectiva
procese sistem
(comportamental)
Performan
Utilitate
Toleran la erori


Perspectiva
contexte de
utilizare
(utilizator)
Mod de
folosire
nelegere
sistem
proiectrii, pot compromite uor o arhitectur logic robust. Pentru a implementa, cu succes,
deciziile referitoare la mecanismele cheie ale unui sistem soft, n IS a aprut o ramur de cercetare
nou, cea care se refer la proiectarea i utilizarea soluiilor-ablon (patterns, n literatura anglo-
saxon).

Perspectiva componente sistem (Implementation view)
Aceast perspectiv asupra unui sistem soft trebuie s precizeze diferitele componente ale
unui sistem soft, mpreun, eventual, cu relaiile dintre acestea.
Prin component a unui sistem soft vom nelege, cel mai adesea, un modul fizic de cod.
O component poate coincide cu un pachet, dar cel mai adesea poate diferi. Ca un exemplu,
care subliniaz diferena ntre pachet i component putem observa faptul c n Java clasa String
este parte a pachetului java.lang.package, dar poate s fie utilizat n nenumrate componente ale
unei aplicaii Java.
S mai atragem atenia cititorului i asupra faptului c ntre componente pot exista
dependene (care, n terminologia UML, arat cum pot influena schimbrile de stare ale unei
componente starea alteia sau a mai multor componente). Este evident faptul c perspectiva
componente sistem a arhitecturii unui sistem soft este important pentru rezolvarea corect a
problemelor de reutilizare a codului, portabilitate a codului i de management eficient al pieselor
fizice ale unui sistem soft.
Evident, exist o anumit mapare a perspectivei structurale pe perspectiva implementaional
a unui sistem.

Perspectiva procese sistem (Behavioral view)
Aceast perspectiv are n vizor structura executabilelor sistemului soft (procese, fire de
execuie, mecanisme de concuren i sincronizare, etc.)
Specificarea acestui tip de arhitectur ia n calcul cerine precum: performana, fiabilitatea,
utilitatea, etc.
Perspectiva componente sistem i perspectiva procese sistem folosesc pentru reprezentare
diagrame de componente care indic componentele (procesele), interfeele acestora i
dependenele dintre acestea.
Diagramele de componente asociate perspectivei proces indic, de fapt, modul de mapare a
claselor pe bibliotecile run-time, gen applet-uri Java, DLL-uri, componente ActiveX.

Perspectiva topologie-hard (Enviromental view)
O astfel de perspectiv va trebui s precizeze nodurile care formeaz topologia hard care
asigur execuia sistemului soft. n aceste noduri se vor executa diferitele procese, indicate n
perspectiva procese sistem. Topologia hard este reprezentat cu ajutorul unor diagrame de noduri,
purtnd etichete care sugereaz repartizarea, pe tipuri de activiti i informaii despre procesele
executate n aceste noduri. Evident, o bun topologie hard trebuie s asigure viteze de execuie
rezonabile, resurse suficiente n noduri, fiabilitate, etc.

Perspectiva contexte de utilizare (User view)
Aceast perspectiv demonstreaz i valideaz oarecum celelalte patru perspective. De fapt,
perspectiva contexte de utilizare se bazeaz pe folosirea contextelor de utilizare (use case) pentru
a descrie comportamentul sistemului soft, aa cum este acesta vzut de diferite categorii de
utilizatori i, prin intermediul acestora, de diferii membri ai echipei de proiectare. Aspectele
statice ale acestui tip de perspectiv sunt reprezentate cu ajutorul diagramelor de contexte de
utilizare. Aspectele dinamice sunt ncapsulate n diagrame de interaciune, diagrame de stare,
diagrame de activitate.

Scurta trecere n revist a modelului 4+1 ne atenioneaz, nc o dat, asupra complexitii
abordrii propuse de UML, precum i asupra necesitii de a ncepe explorarea notaiei UML care
permite materializarea abordrii 4+1.
1.6 Scurt incursiune n universul conceptual al UML
Dup ce am fcut attea promisiuni relativ la utilitatea UML n diferite contexte, este cazul s
facem o prim ncercare de ridicare a vlului care mai acoper nc, n acest punct al demersului
nostru, universul conceptelor utilizate n modelarea UML. Procednd top-down (aa cum se
ntmpl de multe ori n IS) s precizm, pentru nceput, c vocabularul UML opereaz cu trei
tipuri de elemente constitutive:
Entiti;
Relaii;
Diagrame.
Observaie
Cititorul trebuie s dea dovad de ngduina necesar fa de elementul constitutiv entitate.
La origine, n literatura de specialitate se vorbete despre things, ca tip de element constructiv.
ncercarea de a traduce things prin obiecte, componente etc. sau mai tiu eu ce altceva, creeaz
confuzii n ansamblul discursului de prezentare a UML. Traducerea prin lucruri nu sun prea
inspirat, datorit semanticii cu care circul cuvntul lucruri n limba romn.

Entitile desemneaz o serie de abstracii care pot fi socotite ceteni de prim rang
ntr-un model UML.
Relaiile abstractizeaz diferitele tipuri de legturi care pot exista ntre entiti.
Diagramele sunt folosite pentru a grupa coleciile de entiti, cu scopul de a evidenia
mai bine diferitele nivele de abstractizare ale soluiei unui sistem soft.

Tipuri de entiti n UML
UML opereaz cu patru tipuri de entiti:
Entiti cu funcii structurale;
Entiti cu funcii comportamentale;
Entiti cu funcii de grupare;
Entiti cu funcii de documentare.

Aceste tipuri de entiti reprezint fundamentul oricrei soluii obiect orientate, n UML. Ele
sunt utilizate intens pentru a realiza modele corect specificate (corectitudinea specificrii, n UML,
acoper att aspectele de sintax ale modelelor, ct i cerina de a ncapsula semantica eficient n
aceste metode).

Entitile cu funcii structurale (EFS)
Foarte sintetic, EFS sunt substantivele modelelor UML. De cele mai multe ori, EFS
reprezint pri statice ale unui model, reprezentnd elemente care sunt de natur conceptual sau
fizic. n total, n UML exist apte genuri de EFS, pe care le voi prezenta, pe scurt, n continuare.

1. Clasa - este o abstractizare a unei mulimi de obiecte care partajeaz aceleai
atribute informaionale, acelai comportament, aceleai relaii i aceeai semantic.

O clas implementeaz una sau mai multe interfee. Formalismul de reprezentare a unei clase
(de esen grafic, deci vizual) presupune redarea acesteia ca un dreptunghi care, n mod uzual,
include: numele clasei, atributele i operaiile ei, ca n Figura 6.

2. interfaa - abstractizeaz o colecie de operaii care specific serviciile furnizate de o
clas sau component.












Figura 6. Reprezentarea unei clase n UML

Asupra semnificaiei noiunii de component am fcut deja ceva consideraii n paragraful 1.5
i vom mai reveni, n cele ce urmeaz. n general vorbind, o interfa poate s reprezinte
comportamentul complet al unei clase / componente sau doar o parte a acestui comportament. Este
important s subliniem faptul c o interfa se specific printr-o list de signaturi de operaii,
nicidecum prin lista implementrilor acestor operaii. Este o chestiune de nuan prin care n
modelarea softului se face distincia necesar ntre interfa i implementarea acesteia.
Ca i notaie vizual, o interfa este redat printr-un cerc cruia i se ataeaz numele interfeei
(Figura 7).
Atribute informaionale
Pacient

CNP
Nume_I_Prenume


creare()
eliberare()
adaugare()

Nume clas
Operaii






Figura 7. Reprezentarea unei interfee n UML

3. colaborare - abstractizeaz o familie de clase, interfee i alte elemente care, prin
cooperare, reuesc s asigure un comportament care nseamn mai mult dect
suma mecanic a comportamentelor prilor.

De remarcat faptul c, o colaborare are att dimensiune structural ct i dimensiune
comportamental. Dintr-o perspectiv ceva mai larg privind, o colaborare reprezint
implementarea unui ablon care abstractizeaz o anumit funcie a unui sistem soft. Notaia pentru
colaborare este o elips al crei contur este realizat cu o linie ntrerupt, n interiorul creia se trece
numele colaborrii.





Figura 8. Reprezentarea unei colaborri n UML

4. Un context de utilizare (use case, n limba englez) - abstractizeaz o colecie de
secvene de aciuni pe care trebuie s le execute un sistem pentru a produce un
rezultat care trebuie observat de un actor particular.

Contextele de utilizare sunt folosite pentru a structura entitile comportamentale ntr-un
model UML. S mai precizm cititorului faptul c un context de utilizare este realizat de ctre o
colaborare.
Semantica realizrii va fi discutat tot n acest paragraf. Notaia pentru context de utilizare
este o elips al crei contur este o linie continu, n interiorul creia se trece numele contextului de
utilizare.






Figura 9. Reprezentarea unui context de utilizare n UML

Urmtoarele trei tipuri de EFS (clasele active, componentele i nodurile) sunt, ntr-o oarecare
msur, asemntoare claselor, n sensul c sunt descrise ca mulimi de obiecte care partajeaz
aceleai atribute, operaii, relaii i semantici. i totui, exist suficiente elemente care deosebesc
aceste trei tipuri de EFS de tipul clas, i ntre ele nsele, motiv pentru care sunt tratate distinct de
ctre notaia UML.

5. clas activ - este o clas ale crei obiecte posed unul sau mai multe procese sau
fire de execuie, ceea ce nseamn c obiectele pot iniia activiti de control.

Aadar, o clas activ este ntocmai ca o clas obinuit, exceptnd faptul c obiectele sale
reprezint elemente al cror comportament este concurent cu comportamentul altor elemente.
Notaia UML pentru o clas activ se deosebete de notaia pentru clas prin linia ngroat a
conturului.

De observat, Figura 10.

Cititorul bnuiete, probabil, faptul c avem nevoie de clase active pentru a modela soluiile
problemelor n care se apeleaz la multitasking i, n consecin, apar probleme noi legate de
sincronizarea proceselor sau firelor de execuie.


IPacient
Programare
pacient
Planificare
pacient












Figura 10. Reprezentarea unei clase active n UML

6. component - este o parte a unui sistem soft, reprezentat de un anumit gen de cod
fizic, dedicat, n general, realizrii uneia sau mai multor interfee.
Exemple de componente: unit-uri Pascal, ierahii de clase C++ specializate n lucrul cu octeii
de iruri, DLL-uri din lumea Windows, pachetele din Java etc.
Notaia UML pentru o component este ilustrat n Figura 11.







Figura 11. Notaia UML pentru o component

7. Un nod - este un element fizic, care exist la un moment dat i reprezint o resurs
de calcul (cel puin memorie, i adesea capabiliti de prelucrare).
Una sau mai multe componente pot fi rezidente ntr-un nod sau pot migra de la un nod la altul.
Notaia UML, simplificat, pentru un nod este prezentat n Figura 12.







Figura 12. Notaia UML, minimal pentru un nod

Acestea au fost cele apte tipuri de entiti cu funcii structurale, care formeaz fundamentul
structural al oricrui model UML autentic. Prezentarea pe care am fcut-o a avut ca scop
introducerea notaiei pentru cele apte EFS, semantica complet a conceptelor prezentate i a
notaiilor asociate fiind o problem ce urmeaz a fi pus n discuie, ulterior, n aceast carte sau,
de ce nu, n alt carte, care prezint procesul de utilizare efectiv a notaiei UML pentru
rezolvarea unor probleme date.

Entitile cu funcii comportamentale (EFC)
EFC abstractizeaz aspectele dinamice ale unui sistem n cadrul modelelor UML. Prin urmare,
EFC sunt verbe ale modelelor UML (avnd i o reprezentare grafic sugestiv) care ncearc
reprezentarea comportamentului unui sistem, n timp i n spaiu. UML opereaz cu dou tipuri
fundamentale de EFC.

1. interaciune - abstractizeaz un comportament care cuprinde o mulime de mesaje
schimbate ntre obiectele unui sistem, ntr-un context particular, n vederea
ndeplinirii unui obiectiv specific.

Prin urmare, la un anumit nivel de abstractizare, comportamentul unei familii de obiecte sau al
unei operaii individuale poate fi specificat ca o interaciune. O interaciune implic o serie de alte
elemente, precum mesaje, secvene de actiuni (comportamentul invocat de mesaje) i legturi
ntre obiecte.
Notaia UML pentru mesaj este prezentat n Figura 13.
Supervizor pacient

CNP


Iniiere()
Suspendare()

Evid_Pacient.java

Server
nume component





Figura 13. Notaia UML pentru mesaj

Dup cum se vede din notaia prezentat n Figura 13, sgeata care indic un mesaj ntre dou
obiecte are asociat i numele operaiei invocate.

2. main de stare (n engleza american, state machine) abstractizeaz, de data
aceasta , comportamentul unui singur obiect sau al unei interaciuni dintre obiecte,
pe timpul vieii acestora, ca succesiune de aciuni-rspuns la anumite evenimente.

Aadar, comportamentul unei clase sau al unei colaborri ntre clase (cadrul natural de
reprezentare al interaciunilor) poate fi specificat cu ajutorul unei maini de stare. O main de
stare implic o serie de alte elemente, precum: stri, tranziii, evenimente (fapte ce pot declana o
tranziie) i activiti (rspunsuri la tranziii). Notaia UML pentru o stare este prezentat n Figura
14 (dreptunghi cu colurile rotunde, n interiorul cruia se afl numele strii i, eventual, substrile
asociate.



Figura 14. Notaia UML pentru stare

Interaciunile i mainile de stare sunt elemente comportamentale fundamentale, care pot fi
incluse ntr-un model UML. Semantic vorbind, aceste elemente sunt, n mod uzual, conectate cu
alte elemente structurale, ndeosebi clasele, colaborrile i obiectele.

Entiti cu funcii de grupare (EFG)
EFG reprezint elemente utile n organizarea modelelor UML, reprezentate ca nite casete n
care un anumit model poate fi descompus n ceea ce se consider a fi prile lui componente.
Specia fundamental de EFG este pachetul.
Un pachet este un mecanism de interes general al limbajului UML, utilizat pentru organizarea
elementelor n grupuri de elemente. La diferite nivele de abstractizare, ntr-un pachet pot fi grupate
EFS, EFC i chiar alte EFG, dac este nevoie.
Spre deosebire de componente (care se manifest, cumva, n timpul execuiei unui sistem
soft), EFG au o valoare de ntrebuinare pur conceptual (n timpul procesului de dezvoltare a
sistemului). Notaia UML pentru un pachet este ilustrat n Figura 15. Problematica EFG necesit
o discuie mai ampl pentru a nelege ntreaga semantic a subiectului. Vom relua prezentarea
acestei problematici n Capitolul 3.

Entiti cu funcie de documentare (EFD)
EFD reprezint prile explicative ale modelelor UML. De fapt, acestea sunt comentarii pe
care le putei folosi n descrierea modelelor UML pentru a lmuri anumite aspecte neclare ale
acestora sau pentru a aduga informaii suplimentare despre proprietile acestor modele. EFD sunt
reprezentate n UML ca note. Reprezentarea aferent notelor n UML este ilustrat n Figura 16.







Figura 15. Notaia UML pentru conceptul de pachet






Figura 16. Notaia UML pentru conceptul de not

afieaz()
Ateptare

Gestiune pacieni
Funcia calculeaz
vrsta pacientului

Relaii n UML
UML utilizeaz patru tipuri de relaii pentru a descrie aspectele de natur relaional ale
modelelor:
Dependenele;
Asocierile;
Generalizrile;
Realizrile.

Aceste tipuri de relaii reprezint nucleul conceptelor de baz propuse de UML pentru
descrierea relaiilor dintre diferitele tipuri de entiti ale modelelor UML.

1. dependena - abstractizeaz o relaie semantic ntre dou entiti, caracterizat
prin faptul c o schimbare n una dintre ele poate afecta semantic cealalt entitate.

ntr-o astfel de relaie, despre entitatea n care se poate produce schimbarea se spune c este
independent, iar despre entitatea afectat se spune c este dependent. n lumea IS, o astfel de
relaie se ntlnete foarte des, n diferite ipostaze. Notaia UML pentru relaia de dependen este
reprezentat n Figura 17.



Figura 17. Notaia UML pentru relaia de dependen

2. asocierea - abstractizeaz o relaie structural prin care se descriu legturile dintre
obiecte, de tipuri diferite sau de acelai tip.

Asocierea (i diferitele variaiuni pe tema asocierii) sunt eseniale pentru descrierea relaiilor
statice dintre obiectele unei aplicaii. Notaia UML pentru asociere nseamn, n mod necesar, o
linie continu (vezi Figura 18), un nume i, eventual, restricii de cardinalitate i nume de roluri,
direcionate sau nu.






Figura 18. Notaia UML pentru asociere

3. generalizarea - este abstractizarea unei relaii dintre dou concepte UML,
compatibile, a crei semantic este exprimat astfel:

Unul dintre concepte este concept tat, cellalt este concept fiu
Orice element din categoria conceptual tat poate fi substituit de un element din
categoria conceptual fiu. Acest lucru este posibil deoarece un element fiu
motenete structura i comportamentul elementului printe asociat.

Notaia UML pentru generalizare este prezentat n Figura 19.



Figura 19. Notaia UML pentru relaia de generalizare

4. realizarea - este abstractizarea unei relaii semantice ntre clasificatori, exprimat
astfel: un clasificator specific nite capabiliti pentru care alt clasificator
furnizeaz suportul necesar.

Ca un exemplu uzual, o interfa pentru a fi utilizat efectiv, trebuie s fie realizat de una sau
mai multe clase. Aadar, o anumit clas realizeaz o anumit interfa. Notaia UML pentru
realizare este prezentat n Figura 20.


Medic
* 0..1
Asist
Pacient



Figura 20. Notaia UML pentru realizare

Probabil, cititorul a neles c n discuia referitoare la relaii, am urmrit o introducerea
aspectelor eseniale, semantica dezvoltat a acestei teme urmnd a fi discutat n alt loc, n aceast
carte.

Diagrame n UML
n UML, diagramele sunt reprezentri grafice ale unor colecii de elemente (entiti i relaii).
Diagramele UML sunt grafuri ale cror noduri sunt entiti i ale cror arce sunt relaii. Permind
asamblarea diferitelor tipuri de entiti i relaii pentru a obine descrieri ale sistemelor modelate
din diferite perspective, diagramele UML sunt elemente suport puternice pentru abstractizarea i
vizualizarea soluiei unui sistem soft.
Dei n teorie se susine c o diagram poate conine orice combinaie de entiti i relaii, n
practic se recomand utilizarea unui set restrns de tipuri de diagrame, care ncearc s acopere
toate cerinele legate de acceptarea pentru sistemele soft a arhitecturii 4+1.
De aceea, cei care popularizeaz UML-ul recomand urmtoarele nou tipuri de diagrame:
Diagrame de clase;
Diagrame de obiecte;
Diagrame de contexte de utilizare;
Diagrame de secven;
Diagrame de colaborare;
Diagrame hri de stare;
Diagrame de activitate;
Diagrame de componente;
Diagrame de desfurare.
Descrierea i exemplificarea modului de utilizare a acestor diagrame, sarcin de care urmeaz
s ne ocupm n continuare, va lmuri problemele eseniale care apar ntr-un exerciiu de modelare
UML.

Reguli UML pentru elaborarea de modele UML corecte

Un model corect este semantic autoconsistent i n armonie cu
modelele cu care intr n relaie.

Regulile UML care susin elaborarea de modele corecte se refer la:
Numele entitilor cum putem denumi entitile, relaiile i diagramele;
Domeniul contextul care d neles specific unui nume;
Vizibilitatea cum poate un nume s fie vzut i folosit de alte nume;
Integritatea cum interacioneaz entitile complet i consistent cu alte entiti;
Execuie ce se nelege prin execuia sau simularea unui model dinamic.
Modelele elaborate pe timpul dezvoltrii unui sistem soft fiind n atenia mai multor categorii
de participani, apar situaii n care modelele sunt afectate de:
Omisiuni - anumite aspecte sunt ascunse pentru a simplifica procesul de nelegere al
modulului;
Incomplete - anumite elemente pot lipsi cu desvrire;
Inconsistente - nu este garantat integritatea unui model.

Obinem astfel modele care sunt, n mod deliberat, la nivele diferite de detaliere pe timpul
ciclului de via al sistemelor soft. Regulile UML ncurajeaz dar nu oblig abordarea celor
mai importante aspecte care in de analiz, design i implementare pentru a obine modele
perfectibile n timp.

Mecanisme comune n modelarea UML
O construcie, de orice natur, este realizat mai simplu i mai armonios dac sunt respectate
anumite abloane n ceea ce privete modelarea aa-ziselor nsuiri comune.
De exemplu, dac atunci cnd vrem s construim o cas, optm pentru un anumit stil
(bucovinean, maramureean etc.), putem spune c am rezolvat o problem important, n ceea ce
privete arhitectura casei.
Aceast situaie se ntlnete i n modelarea UML, care propune patru mecanisme comune
pentru utilizarea lui consistent:

Specificaiile;
Ornamentele;
Separrile comune;
Mecanismele de extindere.

Specificaiile
Probabil, a fost neles faptul c UML este mai mult dect o notaie vizual. n spatele fiecrui
tip de notaie vizual exist ntotdeauna o specificaie care furnizeaz, sub forma unui enun
textual, sintaxa i semantica blocului constructiv asociat notaiei.
n practic, elementele grafice ale notaiei UML sunt folosite pentru a vizualiza sistemul.
Specificaiile UML sunt folosite pentru a exprima detaliile sistemului.

Ornamentele
Cele mai multe entiti au, n UML, o notaie grafic direct i unic, care asigur o
reprezentare vizual a celor mai importante aspecte ale elementelor. De exemplu, notaia grafic
pentru o clas este, n mod deliberat, uor de realizat, dat fiind faptul c la temelia oricrei soluii
obiect-orientate se afl modelul claselor. Notaia UML pentru o clas ocazioneaz, de asemenea,
descrierea celor mai importante aspecte: numele clasei, atributele i operaiile ei. Specificarea unei
clase poate, ns, include i alte detalii, precum: caracterul abstract al clasei, vizibilitatea
atributelor i operaiilor, etc. Astfel c, fiecare element al notaiei UML ncepe cu un simbol de
baz, la care se pot aduga o serie de ornamente, specifice acelui simbol. Se va reveni asupra
problemei ornamentelor chiar n acest capitol.

Separrile comune
n modelarea sistemelor obiect-orientate este uzual mprirea (separarea) produselor
efortului de modelare n perechi de abordare.
Mai nti, este foarte important separarea de tipul clas obiect. Situaia caracterizat de
aceast separare este: n timp ce clasa este o abstractizare, un obiect este o manifestare
concret a acestei abstractizri. Astfel, n UML putem ntlni tandemul clase obiecte, ca n
Figura 21.













Figura 21. Clas i obiecte

n Figura 21 este prezentat clasa Student, mpreun cu trei obiecte avnd ca tip definitor
aceast clas: Ion, marcat explicit ca fiind obiect de tip Student, :Student, prin care se
desemneaz un student anonim i Maria, care n specificarea complet este indicat ca fiind un
obiect de tip Student, folosind dependena stereotip <<instance Of>>.
Aproape fiecare bloc constructiv UML suport genul de abordare prezentat pe relaia clas /
obiect. Astfel, putem vorbi de contexte de utilizare, componente i instane ale componentelor,
noduri i instane ale nodurilor etc.
n Figura 21 s-a putut observa i modul n care se obin numele obiectelor ntr-un model UML.
n al doilea rnd, este extrem de important separarea dintre interfa i implementare.
O interfa declar un contract de furnizare a unor servicii iar o implementare a unei
interfee reprezint o realizare concret a contractului asumat de interfa. Un exemplu de utilizare
a acestei separri, n Figura 22.



Student

matricol

Ion : Student
: Student
Maria
Maria Student
<<instance Of>>








Figura 22. Interfeele i implementarea lor

Aa cum, probabil c ai ghicit, n Figura 22 sunt prezentate dou interfee implementate de o
component DLL.
Multe dintre blocurile constructive UML suport genul de abordare prezentat pe relaia
interfa / implementare. De exemplu, colaborrile realizeaz contextele de utilizare, metodele
implementeaz operaiile.

Mecanismele de extindere UML
Un limbaj de modelare, nchis din punct de vedere al notaiei, poate ajunge uor n situaia de
a nu putea exprima, cu mijloace recunoscute de toi utilizatorii lui, o anumit semantic din
domeniul problemei sau din domeniul soluiei.
Pentru acest motiv, UML a fost gndit ca un limbaj de modelare deschis-nchis (open-closed),
prin specificarea unor mecanisme de extindere care includ:
Stereotipurile (stereotypes);
Valorile etichetate (tagged values);
Constrngerile (constraints).

Un stereotip extinde vocabularul UML, permind specialitilor s creeze noi genuri de
blocuri constructive, pornind de la unele existente deja.
O valoare etichetat extinde proprietile unui bloc constructiv UML, permind specialitilor
s adauge informaii noi n procesul de specificare a blocului constructiv.
O constrngere extinde semantica unui bloc constructiv UML, permind specialitilor s
adauge reguli noi sau s le modifice pe cele existente.













Figura 23. Mecanismele UML de extindere, pe un exemplu

n figura 23 este prezentat un exemplu de clas stereotip (Overflow), aflat n relaie de
dependen cu clasa EventQueue, creia i-au fost adugate informaii referitoare la versiune i
autor folosind sintaxa specific valorilor etichetate i care are o metod (add()), pentru care
obiectele cu care lucreaz (evenimentele) sunt supuse constrngerii {ordered}.
1.7 Un exemplu pretext de modelare UML
Din experiena programatorilor, se tie c, pentru a nva un nou limbaj de programare cea
mai bun metod este s scrii programe n respectivul limbaj. Tot experiena spune c este bine ca
primele programe scrise ntr-un limbaj nou s fie simple. Satisfacia de a vedea aceste programe
simple funcionnd este dublat de nelegerea, de ctre noul venit n limbaj, a infrastructurii
necesare pentru a scrie programe care funcioneaz efectiv. O astfel de abordare este convenabil
i n cazul iniierii n modelarea UML. Exemplul la care m opresc este, deja, fapt comun n
majoritatea crilor de iniiere n programare:



DatePersStud.dll ISecretar
IDecan
<<exception>>
Overflow
EventQueue
{ version=3.2
author=ma}


add()
remove()
flush()

{ordered}
S se scrie un applet Java care afieaz pe ecranul monitorului mesajul Salutare
tuturor !

Procednd ca n situaia n care am face ceea ce n IS se numete reinginerie (identificarea
elementelor de modelare pentru soluia unei probleme pornind de la codul surs al soluiei), s
ncepem prin a constata faptul c un browser WEB va afia pe ecranul calculatorului mesajul cerut
dac va avea de interpretat codul Java de mai jos.

import java.awt.Graphics;
class Salutare extends java.applet.Applet
{
public void paint (Graphics g)
{
g.drawString(Salutare tuturor !,10,10);
}
}

Pentru neavizai s menionm faptul c linia de cod import java.awt.Graphics face
posibil accesul la resursele clasei Graphics prin specificarea pachetului din care aceasta poate fi
importat (java.awt).
n continuare, linia de cod class Salutare extends java.applet.Applet
introduce o nou clas, numit Salutare, specificnd faptul c aceast clas este derivat din clasa
Applet, rezident n pachetul java.applet.
n sfrit liniile de cod:

public void paint (Graphics g)
{
g.drawString(Salutare tuturor !,10,10);
}

declar o operaie numit paint(), a crei implementare se vede c invoc alt operaie, numit
drawString(), care este direct rspunztoare de afiarea irului de caractere Salutare tuturor
!, la coordonatele specificate. Fanii Java cunosc foarte bine faptul c, n cazul unui applet, n
locul metodei main() sunt apelate metodele asociate apariiei anumitor evenimente, pe timpul
rulrii applet-ului.
Un exemplu de astfel de metod este paint(), care este apelat automat, ori de cte ori
fereastra applet-ului trebuie s fie afiat sau remprosptat.
Modelarea acestei aplicaii n UML poate fi considerat simpl. Aa cum se poate vedea n
Figura 24, putem reprezenta clasa Salutare conform formalismului UML. Operaia paint() a
acestei clase, care suprascrie metoda paint() a clasei strmo Applet, este reprezentat omind
parametri formali i cu implementarea indicat ntr-o not ataat operaiei.







Figura 24. Abstraciile eseniale ale aplicaiei Salutare

Figura 24 poate fi considerat ca surprinznd abstraciile eseniale ale aplicaiei Salutare.
Aceast esenializare a reprezentrii se obine lsnd la o parte, cu bun tiin, alte aspecte,
precum faptul c dou clase (Applet i Graphics) sunt implicate, n moduri diferite, n realizarea
acestei aplicaii. Mai exact, clasa Applet este folosit ca i clas strmo pentru clasa Salutare, iar
clasa Graphics este folosit n specificarea signaturii i implementrii operaiei paint(). Dac
aceste observaii sunt luate n consideraie obinem reprezentarea din Figura 25.

Salutare


paint()

g.drawString( Salutare tuturor ,10,10);












Figura 25. Clasele situate n imediata vecintate a clasei Salutare


n Figura 25, sgeata care leag clasa Salutare de clasa Applet reprezint o relaie de
generalizare, iar sgeata care leag clasa Salutare de clasa Graphics indic o relaie de
dependen. Atenie la diferena dintre cele dou tipuri de sgei. Relaia de dependen pomenit
mai sus abstractizeaz faptul c Salutare folosete resurse ale clasei Graphics.
Analiza modului n care este construit aplicaia Salutare poate fi continuat, descoperind c
att clasa Applet ct i clasa Graphics fac parte din ierarhii specifice de clase. Exemplificnd cu
ierarhia de clase extins implementat de clasa Applet, avem situaia din Figura 26.























Figura 26. Ierarhia motenit de clasa Salutare

Un element de noutate adus de reprezentarea din Figura 26 este relaia dintre clasa
Component i interfaa ImageObserver. n biblioteca Java ImageObserver este o interfa care
este implementat de clasa Component. Relaia dintre clasa Component i interfaa
ImageObserver (notat conform formalismului UML printr-un cerc) este relaia de realizare,
adic putem spune clasa Component realizeaz interfaa ImageObserver.
Aa cum am vzut deja, clasa Salutare colaboreaz direct doar cu dou clase (Applet i
Graphics), aceste dou clase reprezentnd o mic parte a unei biblioteci mari de clase Java,
predefinite. Pentru o mai bun administrare i utilizare a acestei biblioteci de clase, Java
organizeaz interfeele i clasele ntr-o serie de pachete diferite. Pachetul rdcin al mediului Java
este numit, evident, java. nuntrul acestui pachet se afl alte cteva pachete, care conin alte
pachete, interfee sau clase etc. Spre a exemplifica, clasa Object este rezident n pachetul lang,
deci specificatorul lui complet este java.lang.Object. Analog, clasele Panel, Container i
Component sunt rezidente n pachetul awt, etc.
Acest mod de organizare, prin intermediul pachetelor este reprezentat n UML, ca n Figura
27.

Object
Component
Container
Panel
Applet
Salutare
ImageObserve
r
Salutare


paint()
Applet
Graphics















Figura 27. Dependenele aplicaiei Salutare din perspectiva pachetelor

Dup cum se vede, n UML pachetele sunt reprezentate ca nite dosare cu agtoare.
Bnuiesc c sunt deja uzuale, n acest moment, relaiile de dependen dintre pachetele
reprezentate n Figura 27.
Am ncercat, prin imaginile prezentate n Figurile 24, 25, 26 i 27, s deschid apetitul
cititorului pentru notaia UML, important pentru identificarea abstraciilor majore ale soluiei
unei probleme. Evident, aceste abstracii majore fixeaz relaiile invariante dintre diferitele piese
care, articulate, reprezint soluia unei probleme.
Dac diagrama claselor i organizarea claselor n pachete sunt eseniale pentru obinerea unei
arhitecturi solide a aplicaiei, alt ntrebare important pe care i-o pune specialistul n IS este
urmtoarea: Cum putem obine modelul conceptual al cooperrii, n timp, dintre diferite
obiecte, pentru a asigura funcionalitatea unei aplicaii ?.
Referindu-ne, din nou, la aplicaia Salutare, cunoaterea amnunit a bibliotecii Java
reliefeaz faptul c operaia paint() a aplicaiei Salutare este motenit de la clasa Component.
Se pune, evident, ntrebarea: cum este invocat operaia paint() ?. Rspunsul, n mare, este
c operaia este invocat ca parte a execuiei firului de execuie n care este inclus applet-ul. Mai
multe amnunte, folosind formalismul UML, despre schimbul de mesaje necesar pentru a invoca
operaia paint(), n Figura 28. Diagrama de secven din Figura 28 explic, de fapt,
mecanismul invocrii operaiei paint(), ca rezultat al colaborrii ntre instana clasei Salutare
i cteva obiecte implicate pentru a asigura coerena i finalitatea colaborrii.





















Figura 28. Mecanismul invocrii operaiei paint() descris cu ajutorul unei diagrame
de secven

Nu voi intra n detalii referitoare la semantica diagramei din Figura 28. Este, ns, relativ uor
de observat faptul c diagrama din Figura 28 descrie o colaborare ntre patru tipuri de obiecte (trei
Java


applet
awt
lang
Salutar
e
run

:Thread :Toolkit :ComponentPeer Target:Salutare
handleExpose
callbackLoop
dintre ele fiind anonime: Thread, Toolkit i ComponentPeer). Diagrama de secven ne spune
urmtoarele:

1. Se creeaz un obiect fir de execuie, ca urmare a iniierii execuiei applet-ului;
2. Firul de execuie apeleaz operaia run a obiectului Toolkit;
3. Obiectul Toolkit apeleaz una din propriile lui operaii (autoapel), callbackLoop, care
apeleaz operaia paint() a obiectului ComponentPeer;
4. Obiectul ComponentPeer face supoziia c inta mesajului lui este un obiect de tip
Component, dar n cazul de fa inta este un descendent al tipului Component (obiectul
Salutare); astfel c operaia paint() a obiectului Salutare este invocat n context
polimorfic.

Evident, descrierea aspectelor comportamentale ale unei aplicaii este realizat folosind mai
multe tipuri de diagrame, pe care le vom prezenta n capitolul alocat modelrii aspectelor
comportamentale.
nainte de a ncheia acest paragraf, voi mai supune ateniei cititorului i diagrama din Figura
29.













Figura 29. Componente care apar n jurul aplicaiei Salutare

Diagrama din Figura 29 descrie colecia de componente care, mpreun, asigur
funcionalitatea cerut aplicaiei Salutare. n acest sens, remarc faptul c applet-ul, n mod normal,
este parte a unei pagini WEB, interpretat de un browser de WEB, care va executa, la momentul
potrivit, obiectul Thread asociat applet-ului.
Componenta central a diagramei din Figura 29 este Salutare.class, component obinut prin
transformarea de ctre compilatorul Java a componentei Salutare.java n format executabil.
Fiecare simbol din Figura 29 reprezint un element UML, asociat perspectivei implementaionale,
spre deosebire de celelalte diagrame prezentate, care descriu perspectiva logic asupra soluiei
aplicaiei Salutare.
Simbolul canonic pentru reprezentarea unei componente este dreptunghiul cu dou tab-uri.
Applet-ul binar Salutare.class este o variaie a acestui simbol de baz, avnd liniile ngroate, fapt
care indic caracterul executabil al componentei (la fel ca n cazul unei componente active).
Simbolul pentru componenta Salutare.java a fost nlocuit cu unul definit de utilizator,
reprezentnd un fiier text .a.m.d.
De remarcat, n sfrit, relaiile de dependen dintre componente.
















Salut.html Salutare.java
Salutare.class
Salut.jpg






















Capitolul 2
Modelarea aspectelor structurale.
Elemente-suport fundamentale

...Folosind UML, obiect orientarea devine un aliat pentru specialitii
n ingineria softului, de-a lungul ntregului ciclu de via al unui
sistem soft. Formalizarea obiect orientrii, introdus de UML,
deschide drumul unor experimente care urmresc automatizarea
procesului de modelare pe arii din ce n ce mai extinse.























2.1. Clase
Clasele sunt elementele constructive cele mai importante ale unui sistem obiect orientat. n
general vorbind, o clas este abstractizarea unei colecii de obiecte care partajeaz aceleai
atribute, aceleai operaii, aceleai relaii i aceeai semantic. UML ofer un formalizm grafic
pentru reprezentarea unei clase, asemntor celui din Figura 30.














Figura 30. Notaia UML pentru clas.

Dup cum se poate vedea, notaia propus n Figura 30 permite vizualizarea unei abstractizri,
independent de limbajul de programare i de o manier care permite evidenierea celor mai
importante pri ale abstractizrii: numele, atributele i operaiile clasei.

Numele unei clase
Fiecare clas trebuie s aib un nume care o identific n mod unic, printre alte clase. Un
nume de clas este un ir de caractere care se poate prezenta n dou moduri: nume simplu sau
nume cu cale. Un nume simplu de clas se poate observa n Figura 31a. Un nume cu cale, asociat
unei clase, se poate observa n Figura 31b, el indicnd, ca un prefix la numele clasei, pachetul n
care este rezident clasa.






Figura 31. Specificarea numelui unei clae n UML

Un nume de clas poate fi un ir de caractere de orice lungime, care conine litere, cifre i
semne de punctuaie, cu excepia simbolului ::, utilizat pentru a separa numele clasei de pachetul
sau lanul de pachete care o include. Evident, este necesar un compromis rezonabil ntre lungimea
numelui i puterea lui de sugestie. n practic, numele unei clase se obine prin juxtapunerea mai
multor cuvinte care pot dezvlui semantica clasei respective. De exemple, PoligonAbstract,
TriunghiEchilateral, FereastraDeDialog, etc. Se observ cum, pentru mai mult lizibilitate,
fiecare cuvnt din structura numelui ncepe cu liter mare.

Atributele unei clase
Un atribut este numele unei proprieti ( a unei clase) care abstractizeaz un domeniu de valori
pe care instanele proprietii le pot lua.
O clas poate avea orice numr de atribute sau, la limit, nici un atribut.
Un atribut desemneaz, astfel, o anumit proprietate a realitii modelate, proprietate partajat
de toate instanele realitii respective. Ca formalizm de reprezentare, atributele sunt listate n
compartimentul situat imediat sub numele clasei, ca n Figura 32.
n funcie de nivelul de abstractizare al clasei (conceptualizare, specificare, implementare),
atributele pot fi listate doar ca nume, dar pot fi listate i ca nume, mpreun cu tipul definitor i,
eventual, o valoare iniial. ca n Figura 33.






Poligon

coordonate

perimetru()
aria()
afisare()

nume clas
atribute
operaii
Client
java::awt::Rectangle
(a) (b)














Figura 32. Atributele unei clase

Aa cum sugereaz exemplele prezentate n Figurile 32 i 33, numele unui atribut poate
ncepe cu liter mic, celelalte cuvinte care formeaz numele atributului ncepnd cu liter mare.













Figura 33. Atribute, complet caracterizate
Operaiile unei clase
O operaie este abstractizarea unui serviciu, care poate fi solicitat oricrui obiect al unei clase.
Este clar, sper, sugestia c o operaie a unei clase este partajat de toate obiectele clasei
respective. O clas poate avea oricte operaii sau, la limit, nici o operaie. Operaiile unei clase
sunt listate n compartimentul situat imediat sub lista atributelor, ca n Figura 34.












Figura 34. Operaiile unei clase

n practic, regulile de formare i reprezentare a numelor operaiilor sunt asemntoare celor
folosite n cazul atributelor. O operaie poate fi reprezentat i la nivel de signatur, care se poate
referi la: nume, tipul returnat, lista parametrilor i valorile lor implicite, ca n Figura 35. n
Figura 35 am folosit secvena ... pentru a indica faptul c lista operaiilor este, n mod contient,
incomplet. Aceast secven, mpreun cu posibilitatea de a organiza listele de atribute sau
operaii, prea lungi, n categorii descriptive, folosind stereotipurile, contribuie la o mai bun
mapare a potenialului de descriere al unei clase peste nevoile de reprezentare specifice unui
punct de vedere al specialistului n IS.




Student

natricol
numePrenume
adresa
dataNasterii
Lista atributelor
Student

natricol : string[4]
numePrenume: string[40]
adresa: TAdresa
dataNasterii: TData
sex: char=F
Lista atributelor
Lista operaiilor
Student



adaugs()
stergs()
modifics()
afisez()

















Figura 35. Operaii descrise la nivel de signatur

Utilizarea stereotipurilor pentru clasificarea nsuirilor unei clase este exemplificat n Figura
36.



















Figura 36. Utilizarea stereotipurilor
Se cuvine s reamintim faptul c stereotipul este unul dintre mecanismele de extensie, de
baz, ale UML-ului, cu ajutorul cruia putem mbogi, progresiv, nsi semantica limbajului.
Asupra acestui mecanism de extensie vom mai reveni.


Responsabilitile unei clase
O responsabilitate este abstractizarea textual a unui serviciu furnizat de o clas. Este deja
lmurit faptul c, la definirea unei clase, este foarte important supoziia c toate obiectele acestei
clase au acelai comportament.
Aceast afirmaie, la un nivel de abstractizare mai nalt, nseamn c atributele i operaiile
sunt doar nite elemente-suport pentru ndeplinirea responsabilitilor clasei. Responsabilitile
unei clase, n cazul n care sunt definite, sunt listate ntr-un compartiment situat la baza simbolului
grafic al clasei, ca n Figura 37
n practic, elaborarea modelului claselor poate ncepe prin specificarea responsabilitilor
entitilor candidate, nregistrate n vocabularul realizat n faza de analiz a cerinelor. n acest
scop se pot folosi tehnici precum card-urile CRC
1
sau analiza bazat pe contexte de utilizare. n
procesul de rafinare a modelului claselor, responsabilitile sunt traduse ntr-un set de atribute i
operaii care asigur ndeplinirea optim a responsabilitilor.



1
CRC prescurtare de la Class Responsabilities Collaborators, o tehnic efectiv de explorare i identificare a
responsabilittilor unei clase
Lista operaiilor
Student



...
modificMatricol(m:string[4])
consultNume():string[40]
modificAdresa(a:TAdresa=)
...
Student



<<constructor>>
student()
student(m:string[4])
<<proces>>
modificAdresa(a:Adresa)
...
<<query>>
esteValid():boolean
afisez()
<<iterator>>
pentruToti(as:^Student)
...
















Figura 37. Responsabilitile unei clase

2.2 Relaii
n modelarea obiect-orientat exist trei tipuri de relaii care sunt considerate foarte
importante: dependenele, care abstractizeaz relaiile de utilizare existente ntre clase (rafinarea,
versionarea, legarea); generalizrile, care leag clasele generalizate de specializrile lor i
asocierile, care reprezint relaiile structurale dintre obiecte. Formalizmul UML pentru
reprezentarea acestor trei tipuri de relaii, precum i maniera de utilizare, pot fi urmrite, pentru
nceput, n Figura 38.






Figura 38. Reprezentarea relaiilor n UML
Relaia de dependen
Aa cum am mai precizat, o dependen este o relaie de utilizare care exprim faptul c o
schimbare n specificarea unei entiti (de exemplu, clasa Event) poate afecta alt entitate care o
folosete ( de exemplu, clasa Window). Dup cum vom vedea n Capitolul 3, exist un numr
semnificativ de stereotipuri, aplicabile relaiilor de dependen dintre entitile unui model UML.
Dac se consider necesar, relaia de dependen poate avea un nume, care ajut la
discriminarea ei ntr-un context n care mai sunt i alte dependene, ceea ce ajut la referirea mai
uoar a dependenei, n caz de nevoie.

Relaia de generalizare
O generalizare este o relaie ntre o entitate general (numit superclas sau clas printe) i o
varietate specific a acelei entiti (numit subclas sau clas copil)). n literatura de specialitate,
generalizarea mai este desemnat i prin sintagma relaie is a kind of. Generalizarea nseamn
Window



open()
close()
move()
display()
handleEvent()

Event
ConsoleWindow DialogBox
Control
dependen
generalizri
asociere
Student




Responsabilities

creare studeni
actualizare date personale studeni
validare date personale studeni
...


c obiectele copil pot fi folosite oriunde pot apare obiecte printe. Altfel spus, generalizarea ne
asigur de faptul c un copil poate fi un substitut al printelui su, nu i invers. Trivial, dar trebuie
s reamintim (pentru cei care nu sunt documentai suficient asupra paradigmei obiect-orientate)
faptul c un copil motenete toate proprietile printelui (n mod esenial, atributele i operaiile).
Adesea, dar nu ntotdeauna, copilul are atribute i/sau operaii adiionale. O operaie a unui copil
care are aceeai signatur cu o operaie a printelui se spune c suprascrie (redefinete) operaia
printelui, procedeu prin care se pun bazele polimorfismului. Pentru a evidenia toate cele
afirmate, supun ateniei Figura 39.









Figura 39. Exemple de utilizare a generalizrii

n Figura 39 au fost omise o serie de detalii tehnice, specifice problemei la care se refer
diagrama prezentat. Scuza pentru aceste omisiuni este faptul c am dorit ilustrarea ideilor de baz
n ceea ce provete utilizarea relaiei de generalizare. Pentru informarea cititorului trebuie s mai
menionez faptul c generalizarea poate s opereze i n relaia dintre interfee, contexte de
utilizare, pachete, etc..
n sfrit, comentariul fcut la relaia de dependen referitor la posibilitatea asocierii cu un
nume poate fi transpus, cu aceeai ncrctur semantic i n cazul generalizrii.

Relaia de asociere
O asociere este o relaie structural care specific faptul c instanele unei clase sunt conectate
la instanele altei clase. Conectarea de care am vorbit mai sus, trebuie neleas astfel: dat o
instan a a clasei A, n clasa B poate fi gsit cel puin o instan b, astfel nct perechea (a,b)
abstractizeaz o anumit cerin a modelului n curs de elaborare. ntr-un anumit sens putem vorbi
de navigare de la un obiect al unei clase ctre un obiect al altei clase i invers, dac cele dou clase
sunt n relaie de asociere. O asociere la care particip exact dou clase se numete asociere
binar. Dei nu este o situaie uzual, pot exista i asocieri la care particip mai mult de dou
clase. Astfel de asocieri se numesc asocieri n-are. Formalizmul pentru reprezentarea unei asocieri
poate fi dedus analiznd Figura 40.
n practic, numele unei asocieri nu este obligatoriu, fiind folosit pentru a spori claritatea
modelului. Tot din dorina de a spori claritatea unei asocieri se folosesc i rolurile, cu nelesul
deductibil din Figura 41. Evident, o clas poate s aib roluri diferite. Un alt aspect important
pentru caracterizarea unei asocieri este multiplicitatea. n majoritatea situaiilor de modelare este
important s tim cte obiecte pot fi conectate la o instan a unei asocieri.



Forma

origine

muta()
redimensioneaza()
afiseaza()
Dreptunghi

coltStangaSus:TPunct
Poligon

varfuri:TLista
Patrat
Cerc

raza:float














Figura 40. Numele unei asocieri










Figura 41. Rolurile ntr-o asociere











Figura 42. Multiplicitatea

Daca asocierea din Figura 42 este observat din perspectiva Persoana Lucreaz pentru
Firma, atunci o instan a asocierii nseamn un obiect de tip Persoana. Informaiile de
multiplicitate asociate rolurilor ne spun, n Figura 42, c o persoan poate lucra la niciuna sau
mai multe firme (*). Dac asocierea din Figura 42 este observat din perspectiva Firma
angajeaz Persoana, atunci o instant a asocierii nseamn un obiect de tip Firma. Informaia de
multiplicitate asociat clasei cu rolul angajat, n Figura 42, ne spune c o firm poate angaja una
sau mai multe persoane. n practic vom ntlni i alte tipuri de multiplicitate, precum: (1), (0..1),
(0..*), etc.. Imaginaia specialistului n IS poate merge mai departe specificnd multiplicitatea ca o
list, precum:

(0..1, 3..4, 6..*)

ceea ce nseamn c o instan a asocierii este conectat cu orice numr de obiecte, n afar de
dou sau cinci.

Relaia de agregare
O asociere obinuit ntre dou clase reprezint, aa cum am spus, o relaie structural ntre
egali, ceea ce nseamn c ambele clase sunt considerate, conceptual, la acelai nivel de
importan n relaie. Fcnd puin literatur, o asociere obinuit este abstractizarea unei relaii
de parteneriat. n realitate, exist nenumrate situaii, n care suntem nevoii s acordm un statut
special unor asocieri n care ideea de parteneriat nu mai opereaz. O astfel de situaie este cea n
care trebuie s modelm o relaie ntreg/parte, n care una dintre clase desemneaz o entitate
mai larg (ntregul) care const din entiti mai mici (prile). Acest tip de relaie se numete
agregare i n literatura de specialitate mai este recunoscut i ca relaie has-a, spre deosebire
angajator angajat
Persoana Firma
nume de roluri
* 1..*
angajator angajat
Persoana Firma
Lucreaz pentru
Persoana Firma
asociere
sensul navigrii nume asociere
de is-a-kind of (generalizarea). Formalizmul grafic folosit pentru specificarea unei agregri
este prezentat n Figura 43.














Figura 43. Exemplu de agregare

Dup cum sugereaz i Figura 43, agregarea este o relaie care, n esen, nseamn c un
obiect al clasei ntreg const din unul sau mai multe obiecte ale clasei parte n relaia de
agregare. Evident c, putem ntlni i situaii n care clasa ntreg agreg mai multe clase parte.
Cred, de asemenea, c este n folosul cititorului s afle faptul c o agregare nu reprezint nimic
altceva dect o potenial relaie ntreg-parte, nepreciznd nimic n ceea ce privete
competenele instanelor ntreg relativ la crearea i distrugerea instanelor parte. Aceast
problem i alte elemente care vizeaz sporirea semanticii modelelor care ncapsuleaz aspectele
structurale, vor fi discutate n Capitolul 3.

Consideraii relativ la utilizarea relaiilor n modelarea efectiv
Modelarea dependenei simple
Cel mai uzual tip de relaie de dependen este legtura dintre o clas care are una sau mai
multe operaii, care folosesc ca parametri o alt clas. Pentru a modela aceast relaie de utilizare,
procedai ca n Figura 44: utilizai simbolul afectat n UML pentru reprezentarea unei dependene,
cu originea n clasa care conine operaia i extremitatea n clasa parametru.
Dependena clasei PlanificareCurs de clasa Curs este ntemeiat pe faptul c operaiile
add() i remove() utilizeaz, ca parametru, clasa Curs. Figura 44 mai indic i o
dependen marcat cu stereotipul <<friend>>, dependen care arat utilizarea de ctre clasa
Iterator a clasei PlanificareCurs, clasa Iterator fiind prieten a clasei PlanificareCurs, situaie
perfect plauzibil n C++, de exemplu.
















Figura 44. Relaia de dependen

Modelarea motenirii simple
Unul dintre principiile de baz n modelarea obiect orientat este principiul motenirii. n
mod obiectiv, cnd ncepe procesul de elaborare a modelului claselor pentru o problem dat,
specialistul n IS este confruntat, printre altele, i cu problema gestiunii similaritilor
informaionale i comportamentale existente n domeniul problemei. Dincolo de solida
experien sau o intuiie remarcabil a esenialului, n ceea ce privete structura modelului claselor,
sunt extrem de utile urmtoarele precizri:
<<friend>>
PlanificareCurs

add(c:Curs)
remove(c:Curs)

Curs
Iterator
*
1
Companie
Departament
ntregul
agregarea
partea
multipliciti

1. Modelai, ntr-o prim faz, clasele ca i cnd ar fi abstracii independente.
2. ncepei procesul de specificare a relaiilor de motenire prin identificarea
caracteristicilor informaionale i comportamentale comune tuturor claselor i
plasarea lor ntr-o clas rdcin, care de multe ori este o clas abstract.
3. Avnd n vedere rezultatul de la 2, se poate trece la specificarea claselor
posibile, acceptnd ca imperativ satisfacerea anumitor responsabiliti
suplimentare comune. Se obine, astfel, un nou nivel de abstractizare care,
potenial, permite reluarea raionamentului de la punctul 3. n momentul n
care responsabilitile rmase nu mai ofer suport pentru depistarea
similaritilor, clasificarea i ierarhizarea similaritilor poate nceta.

Rezultatul acestui demers este, de regul, o ierarhie de clase, n care similaritile sunt
organizate judicios, avnd n vedere principiul motenirii. Un exemplu de utilizare a motenirii
simple (susinut de majoritatea limbajelor de programare) avem n Figura 45.












Figura 45. Aplicaie la motenirea simpl

Modelarea relaiilor structurale
Cnd n procesul de modelare utilizai relaiile de dependen sau generalizare, nseamn c
modelai clase care reprezint diferite nivele de abstractizare. Dat o dependen ntre dou clase,
una dintre ele depinde de cealalt, dar clasa independent nu are cunotine relativ la clasa
dependent. De asemenea, dat o relaie de generalizare ntre dou clase, clasa copil motenete
de la clasa printe, dar clasa printe nu are cunotine specifice relativ la clasa copil.
Concluzionnd, dependena i generalizarea sunt relaii unilaterale. n schimb, ntr-o relaie de
asociere fiecare clas se poate baza , ntr-o form sau alta, pe cealalt clas, ceea ce nseamn c
ntr-o relaie de asociere se poate naviga n ambele sensuri (vorbim de o asociere
bidimensional). n practica modelrii relaiilor structurale, este bine s inem cont de urmtoarele:

1. Dat o pereche de clase, dac este necesar navigarea de la obiectele unei clase la
obiectele celeilalte, este indicat s specificai o asociere ntre cele dou clase. O astfel
de perspectiv este desemnat prin sintagma asociere dirijat de date.

Poligon

varfuri:TLista

arie()
perimetru()
deseneaza()
clas abstract
Triunghi


arie()
Patrulater


Hexagon


arie()
Dreptunghi


arie()
Trapez


arie()

PatrulaterInscriptibil


arie()
metod abstract
2. Dat o pereche de clase, dac obiectele unei clase au nevoie s interacioneze cu
obiectele celeilalte, altfel dect ca parametri ai unei operaii, este, de asemenea,
indicat s specificai o asociere ntre cele dou clase. O astfel de perspectiv este
desemnat prin sintagma asociere dirijat de comportament.

3. Pentru fiecare asociere este indicat s specificai multiplicitatea, ndeosebi dac nu
este cea implicit (*), precum i nume de roluri, dac dorii s adugai un spor de
claritate modelului.

4. n sfrit, dac una dintre clasele care particip la o asociere, structural sau
organizaional este un ntreg n comparaie cu celelalte care pot fi socotite pri ale
ntregului, atunci aceast asociere este bine s fie desemnat ca agregare.

n Figura 46 avem un exemplu de modelare a relaiilor structurale, n cazul unei aplicaii de
interes pentru o instituie de nvamnt superior. ncercnd s deconspirm semantica ncapsulat
n diagrama prezentat n Figura 46, putem spune urmtoarele:

Asocierea dintre clasele Student i Curs arat faptul c studenii frecventeaz cursuri.
Putem spune chiar mai mult: fiecare student poate frecventa orice numr de cursuri i
fiecare curs poate fi frecventat de orice numr de studeni.
Analog poate fi explicitat i asocierea dintre clasele Profesor i Curs.
Asocierea dintre clasele Facultate i Student, precum i asocierea dintre clasele
Departament i Profesor sunt dou exemple de agregare. O facultate poate avea zero
sau orice numr de studeni. Un student poate fi nmatriculat la una sau mai multe
faculti, etc.
Merit un comentariu aparte relaia dintre clasa Facultate i clasa Departament. Rombul
plin, folosit pentru a particulariza aceast asociere, indic o compoziie. Compoziia este
o varietate de agregare, n care ntregul este investit cu responsabiliti clare n ceea
ce privete crearea i distrugerea prilor. Asupra acestei probleme voi mai reveni n
Capitolul 3.























Figura 46. Exemple de relaii structurale

2.3 Mecanisme comune
Anunat n Capitolul 1, relum n acest paragraf problema mecanismelor comune. S ne
amintim, aadar, faptul c UML este mai uor de neles i aplicat dac nelegem importana celor
patru mecanisme comune: specificaiile, ornamentele, separrile comune i mecanismele de
extindere. Voi prezenta, n cele ce urmeaz, modul de utilizare n procesul de modelare a dou
dintre aceste mecanisme comune: ornamentele i mecanismele de extindere.

0..1
efDepartament
0..1
frecventeaz
angajat la
1..*
1..*
pred
*
* *
1..*
1..* 1
are
Facultatea Departament
Student Curs
Profesor
Ornamentele
Fornd puin exprimarea, dat fiind i lipsa unui cuvnt nou pentru o semantic parial nou,
pentru a conine ct mai mult semantic i pentru a transmite, diferitelor persoane interesate, ct
mai mult din aceast semantic, modelele UML sunt mpodobite cu o serie de elemente
adiionale formalizmului de baz. Ornamentele asociate modelelor UML sunt de dou tipuri: note
i ornamente pentru vizualizarea i detalierea specificrii.
Ne amintim c o not este un simbol grafic folosit pentru redarea constrngerilor sau
comentariilor ataate unui element sau unei colecii de elemente. Formalizmul pentru o not UML
poate fi revzut n Figura 47.





















Figura 47. Moduri de utilizare a notelor

Notele prezentate n Figura 47 pot fi ataate unuia sau mai multor elemente care fac parte din
specificarea unui model UML. Pe de alt parte, UML permite utilizarea ornamentelor pentru
vizualizarea i detalierea specificrii. De exemplu, se tie c notaia de baz pentru asociere este o
linie; atunci cnd situaia o cere, aceast linie poate fi ornamentat cu detalii, cum sunt rolurile i
multiplicitile ataate fiecrui capt al asocierii. n utilizarea UML, regula general de urmat este:
Se pornete cu notaia de baz pentru fiecare element i se adaug alte ornamente numai
dac acestea sunt necesare pentru a furniza informaii importante pentru nelegera
modelului. Majoritatea ornamentelor sunt redate prin plasarea textului n apropierea elementului
vizat sau prin adugarea unui simbol grafic notaiei de baz. Este posibil ca, uneori, s dorii s
adugai unui element detalii mai multe, ceea ce poate fi destul de dificil folosind textul simplu sau
simbolurile grafice. n astfel de situaii, unor entiti precum clasele, componentele i nodurile le
putem aduga un nou compartiment, situat imediat sub compartimentele uzuale, pentru a furniza
informaii noi, ca n Figura 48.
















Figura 48. Utilizarea extra-compartimentelor

Tranzacie

addAction()
removeAction()

Exceptions
emptyTransaction
noSuchAction
:
Client

bill.exe
report.exe
contacts.exe
extra-compartiment anonim
compartiment suplimentar avnd un nume
legtur la document
ncapsulare URL text simplu
Aceast component
va fi livrat cel mai
trziu n 13/02/04
A se vedea
http://www.rational.com
A se vedea Heap.doc
pentru detalii asupra
acestui algoritm
Mecanismele UML de extindere
Stereotipurile
Dup cum am vzut, UML furnizeaz un limbaj pentru capturarea i reprezentarea semanticii
urmtoarelor tipuri de entiti; entiti cu funcii structurale, entiti cu funcii comportamentale,
entiti cu funcii de grupare i entiti cu funcii de documentare. Aceste patru tipuri de entiti
sunt suficiente pentru majoritatea sistemelor pe care le modelm. Exist, ns i situaii n care, n
domeniul problemei apar aspecte care reclam introducerea unor semantici noi, folosind n acest
scop formalizme asemntoare celor utilizate n cazul blocurilor constructive primitive. Pentru a
reglementa modul n care se procedeaz n astfel de situaii, n UML au fost specificate
mecanismele de extindere. Acestea sunt: stereotipurile, valorile etichetate i constrngerile.

Stereotipurile
Referindu-ne la aria claselor, un stereotip nu este similar cu o clas printe ntr-o relaie de
generalizare printe-copil. Mai degrab, putem gndi stereotipul ca un metatip, ale crui instane
sunt clase noi, n sintaxa UML. Ca un exemplu, dac suntem familiarizai cu modelul de
dezvoltare RUP, vom vedea c acesta conine recomandri precise n ceea ec privete modelarea
claselor, existnd stereotipuri pantru trei tipuri fundamentale de clase: clasele de frontier, clasele
cu funcii de prelucrare i clasele cu funcii de control. Fiecare din cele trei tipuri de clase poate
fi considerat un stereotip, care extinde posibilitile de modelare ale UML-ului, ca n Figura 49.















Figura 49. Exemple de stereotipuri utile n modelarea claselor
Dup cum reiese din Figura 49, un stereotip este recunoscut dup numele lui, situat ntre
simbolurile <<...>>, dedesubtul cruia se afl numele concret al modelului. De asemenea, n
Figura 50 se pot vedea o serie de soluii alternative la problema notaiei asociate unui sterotip, cu
exemple care se refer i la stereotipurile promovate de RUP n materie de clase.

Valorile etichetate
Fiecare entitate UML are propriul set de proprieti: clasele au nume, atribute i operaii;
asocierile au nume i dou sau mai multe capete cu propriile lor proprieti, etc. Dup cum am
vzut, folosim stereotipurile pentru a aduga soluiei noastre entiti noi. Pentru a aduga
proprieti noi entitilor, folosim valorile etichetate. n practic, valorile etichetate pot fi folosite
pentru a pstra diferite informaii despre proprietile entitilor. Astfel, informaii de interes
pentru managementul unui proiect (data crerii unui model, starea dezvoltrii lui, autorul, etc.) sau
informaii de interes n procesul de instalare a unei aplicaii (memoria intern necesar, memoria
extern necesar, limita inferioar a frecvenei procesorului, etc.) sunt dou exemple uzuale de
utilizare a valorilor etichetate. Formalizmul de prezentare a valorilor etichetate este , transparent
prezentat n Figura 51.
Dup cum se poate observa n Figura 51, valorile etichetate apar ntre acolade ca secvene de
tipul:

{<etichet>=<valoare>}

dac informaiile sunt adugate direct pe entitatea vizat, sau, folosind ca suport nota ataat,
urmnd aceeai sintax, dac este vorba de informaii care se refer la mai multe entiti, de
exemplu.




<<Boundary>>

PreluareDateStudent
<<Entity>>

PrelucrareDateStudent
<<Control>>

SupervizareBE

































Figura 50. Stereotipuri avnd ataate simboluri grafice


























Figura 51. Utilizarea valorilor etichetate


Server
{procesoare=2}
{aplicatie=serv.exe}
autor=Tudor Stelian
terminat=12/10/2001
serv.exe
{doarPeServer,
RamSize=600K}
element stereotipizat ca simbol grafic,
,echivalent cu <<Control>>
element stereotipizat ca simbol grafic,
echivalent cu <<Entity>>
stereotip cu nume i simbol grafic asociat
element stereotipizat prezentat ca simbol
grafic. Echivalent cu <<Boundary>>
<<Exception>>

Underflow

Constrngerile
Este de domeniul evidenei, probabil, faptul c orice construcie sintactic n UML are propria
ei semantic. De exemple, ntr-o relaie de generalizare opereaz principiul substituiei care afirm
c un obiect al clasei copil poate substitui un obiect al clasei printe, dar nu i invers. Acest dar
nu i invers este o constrngere, de care trebuie s fim contieni cnd lucrm cu o ierarhie de
clase.
Utiliznd constrngerile, putem, de asemenea, s adugm semantici noi modelelor sau s
modificm regulile fundamentale dup care opereaz modelele. n ultim analiz, o constrngere
specific o serie de condiii care trebuie ndeplinite pentru ca modelul s fie corect.
Formalizmul dup care adugm constrngeri modelelor este deductibil din Figura 52.






























Figura 52. Exemple de constrngeri
n general, specificarea constrngerilor poate fi realizat folosind un limbaj textual, liber n
expresie. Dac se dorete mai mult rigoare n specificarea constrngerilor se poate apela la
OCL (Object Constraint Language), un standard care nsoete specificarea complet a
UML-ului. Acest standard poate fi gsit n documentaia pus la dispoziie de firma Rational pe
site-ul www.rational.com.

2.4 Diagrame
2.4.1 Introducere
n paragraful 1.6 am precizat deja rolul diagramelor (ca entiti cu funcii de grupare) n
organizarea i vizualizarea blocurilor constructive ale unui model UML. n practic s-a dovedit,
deja, faptul c realizarea unor diagrame de calitate contribuie la o mai bun nelegere, att a
soluiei ct i a sistemului modelat. Necesitatea diagramelor n modelarea UML are o justificare
mult mai profund dect cea prezentat mai sus. Una dintre provocrile importante n procesul de
modelare a comportamentului unui sistem se numete stpnirea complexitii. Exist motive de
natur conceptual dar i motive de natur managerial pentru care, n ingineria softului, se
practic abordarea sistemic, cu necesara infuzie de elemente specifice. Aa se face c, la anumite
nivele de abstractizare a soluiei UML a unei probleme, se va vorbi n termeni de sisteme,
subsisteme, modele i diagrame care grupeaz aceste modele dup principii i reguli specifice
diferitelor perspective ntlnite n arhitectura soluiei UML a unui sistem soft. Aa cum am mai
spus, n UML exist nou tipuri de diagrame, utilizate pentru gruparea modelelor care descriu
aspectele statice sau dinamice ale unui sistem.
*
*
* 0..1
ContPersonal
ef
lucrator
angajat angajator
* ContFirma 1
Cont Firma
Persoana
{XOR}
Persoana
Firma
{Persoana.angajator=
Persoana.ef.angajator}
Pentru descrierea aspectelor statice avem:

1. Diagrame ale claselor
2. Diagrame ale obiectelor
3. Diagrame ale componentelor
4. Diagrame de desfurare

Pentru descrierea aspectelor dinamice avem:

1. Diagrame ale contextelor de utilizare
2. Diagrame de secven
3. Diagrame de colaborare
4. Diagrame de hri de stare
5. Diagrame de activitate

Abilitatea de a realiza diagrame de tipurile mai sus precizate, coerente, corecte i eficiente este
tot ceea ce i dorete, n ultim instan, un specialist n IS, n relaia cu UML. Fr aceast
abilitate, mnuirea, cu randament, a tools-urilo precum Rational Rose, ObjectiF, etc. este un vis
imposibil.

2.4.2 Diagrame structurale
Cele patru tipuri de diagrame structurale UML servesc la vizualizarea, specificarea,
construirea i documentarea aspectelor statice ale unui sistem. Prin aspecte statice ale unui
sistem nelegem relaiile invariante dintre componentele sistemului. Referindu-ne la ingineria
softului, din perspectiv UML, aspecte statice ale soluiei unui sistem soft sunt: relaiile dintre
clase, interfeele, colaborrile, ansamblul structurat al componentelor, topologia hard care
susine execuia sistemului. Odat definite relaiile dintre clase, introducem un element de
stabilitate, necesar pentru a putea continua efortul de realizare a soluiei. Odat specificate
interfeele, clienii lor se pot ocupa, n linite, de aspectele legate de utilizarea lor, etc..

Diagrame ale claselor
O diagram a claselor expune un ansamblu de clase, interfee i colaborri, mpreun cu
relaiile dintre ele. Diagramele claselor reprezint tipul de diagram cel mai des ntlnit n
modelarea sistemelor obiect orientate. Folosim diagramele claselor pentru a evidenia
perspectiva design (structural) a sistemului. De asemenea, putem observa faptul c
diagramele claselor care includ clase active sunt utile pentru a evidenia aspectele statice ale
perspectivei proces a unui sistem.

Diagrame ale obiectelor
O diagram a obiectelor expune un ansamblu de obiecte, mpreun cu relaiile dintre ele.
Folosim diagramele obiectelor pentru a ilustra structuri de date, instantanee statice ale instanelor
entitilor din diagramele claselor. ntr-o oarecare msur, se subnelege faptul c diagramele
obiectelor sunt destinate evidenierii perspectivei design (static) sau perspectivei proces (static) a
unui sistem, cum se ntmpl i n cazul diagramelor claselor, dar lund n obiectiv instane din
lumea real. Scopul unor astfel de diagrame este de a sublinia, prin infuzia aferent de concret,
semantica diagramelor claselor la care se raporteaz.

Diagrame ale componentelor
O diagrama a componentelor expune un ansamblu de componente, mpreun cu relaiile dintre
ele. Folosim acest tip de diagram pentru a ilustra aspectele statice ale perspectivei
implementaionale a unui sistem. Diagramele componentelor se afl n legtur cu diagramele
claselor, datorit faptului c, n mod normal, o component se mapeaz pe una sau maai multe
clase, interfee sau colaborri.

Diagrame de desfurare
O diagram de desfurare expune un ansamblu de noduri, mpreun cu relaiile dintre ele.
Folosim acest tip de diagram pentru a ilustra aspectele statice ale perspectivei desfurare a
hard-ului care susine execuia unui sistem soft. Diagramele de desfurare se afl n legatur cu
diagramele componentelor, datorit faptului c, n mod uzual, un nod conine una sau mai multe
componente.

Observaie
Exist anumite variante comune ale acestor patru tipuri de diagrame, avnd denumiri care
depind de coninutul lor fundamental. De exemplu, putem crea o diagram a subsistemelor pentru
a ilustra descompunerea sistemului n subsisteme.

2.4.3 Diagrame comportamentale
Dup cum am vzut, exist cinci tipuri de diagrame care pot fi folosite pentru a modela
dinamica (comportamentul) unui sistem soft.

1. Diagramele contextelor de utilizare (use case)
Acestea sunt diagrame care organizeaz comportamentul sistemului

2. Diagramele de sceven (sequence diagram)
Acestea sunt diagrame care se focalizeaz pe ordonarea n timp a mesajelor schimbate
ntre obiecte.

3. Diagramele de colaborare (collaboration diagram)
Acestea sunt diagrame care se focalizeaz pe organizarea structural a obiectelor, care
trimit i primesc mesaje.

4. Diagramele hri de stare (statechart diagram)
Acestea sunt diagrame care se focalizeaz pe schimbrile de stare ale unui sistem dirijat
de evenimente.

5. Diagramele de activitate (activity diagram)
Acestea sunt diagrame care se focalizeaz pe fluxul de control n procesul de trecere de la
o activitate la alta.

Diagramele contextelor de utilizare
O diagram context de utilizare expune un ansamblu de contexte de utilizare i actori (care pot
fi socotii un gen special de clas), mpreun cu relaiile eferente. Putem folosi diagramele context
de utilizare pentru a ilustra aspecte statice ale contextelor de utilizare a unui sistem (diferite
tipuri de relaii ntre contextele de utilizare) dar, mai ales, pentru a prefigura organizarea i
modelarea comportamentului unui sistem.

**
Diagramele de sceven i diagramele de colaborare (desemnate mpreun i prin sintagma
diagrame de interaciune) sunt echivalente semantic, ceea ce nseamn c putem modela
comportamentul unui sistem soft folosind unul dintre cele dou tipuri de diagram i apoi
transformm diagrama obinut n cellalt tip de diagram, fr a avea pierderi de informaii.
Astfel c, putem crea, mai nti, o diagram de sceven care ilustreaz ordonarea n timp a
mesajelor, dup care putem deduce diagrama de colaborare asociat, n care se pune accent i pe
relaiile structurale dintre clasele care particip la colaborare. Echivalen semantic i consideraii
similare avem i n ceea ce privete cuplul diagrame hri de stare - diagrame de activitate.

**

Diagrame de secven
O diagram de secven este o diagram de interaciune, care evideniaz ordonarea n timp a
mesajelor care rezolv problemele de comunicare dintre obiectele unei aplicaii. Astfel c, o
diagram de secven expune un ansamblu de obiecte i distribuia temporal a mesajelor, trimise
i primite, de ctre aceste obiecte. Obiectele, n mod uzual au nume, pot fi i instane anonime ale
claselor, dar pot reprezenta i instane ale altor tipuri de entiti precum: colaborri, componente
sau / i noduri. Evident, utilizm o diagram de secven pentru a reprezenta perspectiva
dinamic a unui sistem.

Diagrame de colaborare
O diagram de colaborare este o diagram de interaciune care pune accent pe organizarea
structural a obiectelor care trimit sau primesc mesaje. O diagram de colaborare expune un
ansamblu de obiecte, legturile dintre aceste obiecte i mesajele trimise sau primite de aceste
obiecte. n mod uzual, obiectele au un nume, pot fi instane anonime ale claselor, dar pot fi i
instane ale altor tipuri de entiti, precum colaborri, componente sau/i noduri. O diagram de
colaborare este, de asemenea, util pentru a reprezenta perspectiva dinamic a unui sistem.

Diagrame hri de stare (DHS)
O DHS este o main de stare n structura creia intr elemente precum: strile obiectelor,
tranziiile, evenimentele i activitile care pot fi asociate acestor obiecte. Evident, i DHS sunt
importante pentru a reprezenta perspectiva dinamic a unui sistem. Mai mult, putem spune c
DHS sunt utile pentru a accentua comportamentul dirijat de evenimente al unui obiect, lucru
absolut necesar n modelarea sistemelor reactive.

Diagrame de activitate
O diagram de activitate expune fluxul activitilor din interiorul unui sistem (flux care poate
fi secvenial sau ramificat) precum i obiectele asupra crora acioneaz, sau de care sunt demarate
aceste activiti. Diagramele de activitate sunt importante pentru modelarea funciei unui sistem,
ca flux de control, n dinamica activitilor unui obiect sau a unui ansamblu de obiecte-partenere la
rezolvarea unei probleme.

**
Toate aceste elemente introductive, care au urmrit introducerea semanticii de baz n ceea ce
privete lucrul cu diagrame, vor fi urmate de o expunere amnunit, respectiv, diagramele
structurale, n Capitolul 3 iar diagramele comportamentale n Capitolul 4.

2.4.4 Diagrame ale claselor
Diagrama claselor este tipul de diagram care nu poate lipsi din soluia obiect orientat a unui
sistem soft. Cum am mai spus, o diagram a claselor este o diagram care expune un ansamblu de
clase, interfee i colaborri precum i relaiile dintre acestea. Formalizmul grafic de reprezentare
al unei diagrame a claselor se exprim sintetic n formula colecie de noduri i arce. O diagram
de clase are un nume (ca orice alt tip de diagram UML) i o reprezentare grafic, care depinde de
structura entitilor coninute:
clase
(prezen obligatorie i esenial n orice diagram a claselor);
interfee
(prezen strict necesar cnd se modeleaz n spiritul obiectelor (componentelor)
programabile, care separ net interfeele de implementarea lor;
colaborri
(este vorba de colaborri din perspectiv structural, care pot fi numite piesele mari ale unei
diagrame a claselor);
dependene, generalizri, relaii de asociere.

Asemenea altor tipuri de diagrame, diagramele claselor pot conine note i constrngeri. Dac
necesitile de abstractizare o impun, diagramele claselor pot conine pachete sau subsisteme,
fiecare dintre acestea fiind utilizate pentru a grupa elemente ale modelului n curs de elaborare,
obinndu-se blocuri constructive cu o semantic specific, accesibil unui anumit tip de
beneficiar. Uneori, diagramele claselor pot conine i instane.
ncercnd un rspuns la ntrebarea Pentru ce elaborm diagramele claselor?, reamintesc
faptul c intenia lor declarat este de a modela aspectele statice ale perspectivei design
(structurale). Mergnd ceva mai departe, trebuie s subliniez faptul c cerinele funcionale ale
unui sistem soft trebuie s se mapeze convenabil peste ansamblul modelelor care compun
perspectiva design. De aceea se obinuiete s se afirme c stabilitatea structural a design-
ului static este esenial pentru longevitatea i calitatea unei soluii.
Din punctul de vedere al practicii, utilizm diagramele claselor n una din situaiile urmtoare:

Suntem preocupai de modelarea vocabularului sistemului
Dorim s modelm o colaborare
Dorim s modelm schema logic a unei baze de date

Modelarea vocabularului unui sistem
Aceast activitate implic o serie de decizii relativ la abstraciile care sunt pri componente
ale sistemului n curs de modelare i care vor rmne n afara frontierei sistemului. Folosim
diagrame de clase pentru a vizualiza i specifica aceste abstracii i responsabilitile lor n cadrul
sistemului.

Modelarea unei colaborri
O colaborare este o comuniune de clase, interfee i alte elemente care lucreaz mpreun
pentru a asigura un comportament, care nseamn mai mult dect suma mecanic a
comportamentelor elementelor care particip la colaborare (putem vorbi, astfel, despre necesitatea
valenelor sinergetice ale unei colaborri). Folosim diagrame de clase pentru a vizualiza i
specifica astfel de colaborri. Un exemplu de colaborare, simpl, poate fi urmrit n Figura 53.
Figura 53 prezint un set de clase, considerate eseniale pentru implementarea unui robot autonom.
Figura se focalizeaz asupra claselor implicate n mecanismul de deplasare a robotului pe un
traseu. Evident, exist mai multe clase implicate n simularea comportamentului unui robot
autonom. Diagrama din Figura 53 se concentreaz asupra abstraciilor care sunt direct implicate n
deplasarea robotului. Ne putem, lesne, imagina c exist i abstracii preocupate, de exemplu, de
gestiunea conflictelor care pot apare n timpul deplasrii robotului, n anumite condiii de mediu.
Vor exista, prin urmare, i alte colaborri n mulimea claselor care descriu, din punct de vedere
static, comportamentul unui robot autonom. Pentru a simplifica procesul de nelegere a sistemului,
este recomandabil procedeul separrii mai multor colaborri, cu relativ coeziune intern i
obiective specifice de ndeplinit.


Modelarea schemei logice a unei baze de date
Prin schem logic a unei baze de date nelegem rezultatul proiectrii conceptuale a bazei de
date (De exemplu, modelul relaional al unei baze de date, adus la o form normal convenabil).
Sunt numeroase aplicaiile n care
avem nevoie de asigurarea persistenei informaiilor, utiliznd baze de date relaionale sau baze de
date obiect orientate. Schema logic a unei baze de date poate fi modelat folosind diagrame de
clase, ca n Figura 54.


















Figura 53. Modelarea unei colaborri simple ntre clase, n UML





AgentTraseu


Responsabilities
cutare traseu
evitare obstacole

SenzorColiziuni
Driver
Motor de Crm MotorPrincipal
Motor


move(d:Directie;v:Viteza)
stop()
resetCounter()
stare status()
...




































Figura 54. Modelarea schemei logice a unei baze de date

n Figura 54 se poate observa utilizarea valorii etichetate {persistent} pentru a indica faptul c
obiectele claselor n cauz sunt persistente. Totodat, se poate observa strategia de definire a
comportamentului claselor, care presupune amplasarea operaiilor utile n manipularea obiectelor
unei clase, n clasa de nivel de persisten imediat superioar (cum este cazul n relaia dintre clasa
Facultate i clasa Catedra).

Cteva observaii de luat n seam cnd elaborm o diagram a
claselor
O diagram a claselor bine structurat va ine cont de urmtoarele cerine:
Focalizarea pe un anumit aspect al perspectivei design view; este tiut faptul c
perspectiva design view a ntregului sistem poate fi reprezentat n mai multe diagrame
ale claselor;
Cuprinderea doar a elementelor care sunt eseniale pentru a nelege respectivul aspect;
Furnizarea de detalii, conforme nivelului de abstractizare i ataarea doar a ornamentelor
strict necesare;
Nu va avea niciodat attea omisiuni nct s rite informarea greit a cititorului asupta
semanticii importante a clasei.
Complementar cerinelor de mai sus putem accepta urmtoarele reguli de stil:

Asocierea unei diagramei de clase cu un nume sugestiv (care s deconspire semantica
diagramei);
Expunerea elementelor diagramei astfel nct s reducem la minimum liniile care se
intersecteaz;
Folosirea notelor i a culorilor, ca prghii vizuale de dirijare a ateniei asupra aspectelor
importante ale diagramei.
1..*
*
Frecventeaz
Pred
nmatriculat
Angajat la
Are
Facultate
{persistent}

nume:TNume
adresa:string
telefon:integer

adaugstud()
stergstud()
citestestud()
adaugDepartament()
sterDepartament()
citesteDepartament()

Catedr
{persistent}

nume:TNume
adaugProf()
stergProf()
citescProf()

1 1..*
Profesor
{persistent}

nume:TNume



Curs
{persistent}

nume:TNume
codCurs:integer


Student
{persistent}

nume:TNume
matricol:integer






























Capitolul 3
Modelarea aspectelor structurale.
Elemente-suport avansate

...Chiar dac se va dovedi c obiect orientarea nu este totul n materie
de modelare, chiar dac, n viitorul nedefinit, UML va ajunge o
amintire oarecare, n modelarea sistemelor soft, prezentul este al
obiect orientrii.























3.1 Elemente avansate referitoare la modelarea claselor
Este de necontestat importana claselor n economia de resurse a oricrei soluii obiect
orientate. Clasele sunt doar o varietate a unui bloc constructiv UML mai general, numit
clasificator (clasifier). n categoria clsificatorilor intr tipuri de entiti pe care le-am discutat deja,
dintr-o anumit perspectiv, dar i tipuri de entiti care, n acest moment, ne sunt necunoscute,
precum: clase, interfee, tipuri de date, semnale, componente, noduri, contexte de utilizare i
subsisteme. Se nelege, i din enumerarea de mai sus, faptul c un clasidicator este un concept
care descrie nsuiri structurale i comportamentale ale diferitelor tipuri de obiecte ntlnite n
procesul de modelare. Clasificatorii, ndeosebi clasele, au o serie de posibiliti, socotite avansate
n literatura de specialitate, posibiliti care lrgesc suportul referitor la descrierea atributelor i a
operaiilor prezentat n Capitolul 2. Vizibilitatea resurselor unei clase, signatura complet a
operaiilor, aspectele polimorfice, etc. pot fi reprezentate cu exactitate n modelele UML, atunci
cnd nivelul de rafinare o cere.

Clasificatori
n procesul de modelare putem descoperi abstracii care reprezint entiti din lumea real sau
intrinseci soluiei. De exemplu, dac suntem interesai de realizarea unei aplicaii de tip magazin
electronic, cu suport WEB, vocabularul proiectului va include obligatoriu o clas Client (care
abstractizeaz indivizii care vor comanda produse), dar i o clas Tranzacie (introdus din
motive de eficientizare la nivel de implementare a traficului de date client-aplicaie, tranzacia
fiind cea mai mic aciune (atomic), care poate face obiectul unui eec n comunicaia client-
aplicaie. Toate aceste abstracii au instane care se manifest n timpul execuiei componentelor n
noduri. n UML exist i tipuri de entiti care nu au instane (pachetele sau relaiile de
generalizare, de exemplu). n general vorbind, acele elemente de modelare care pot avea instane
sunt numite clasificatori. Ceea ce este i mai important este faptul c un clasificator are nsuiri
structurale (lista atributelor) precum i nsuiri comportamentale ( lista operaiilor). Fiecare
instan a unui clasificatorj dat partajeaz aceleai nsuiri, Cel mai important gen de clasificator
din UML este clasa. UML dispune de nc o serie de ali clasificatori, care pot fi folosii n
procesul de modelare, pe care i caracterizez, pe scurt, n continuare.

Interfaa
O colecie de operaii care sunt folosite pentru a specifica un serviciu al unei clase sau
componente.

Tipul de dat
Un tip ale crui valori nu au identitate, incluznd tipuri primitive (recunoscute de limbajele de
programare, precum ntregii, numerele reale, caracterele, etc.) precum i tipurile enumerate.
Tipurile de dat se definesc, matematic vorbind, fcnd abstracie de implementarea lor la
nivelul limbajelor de programare. La fel stau lucrurile n ceea ce privete operaiile definite
asupra tipurilor de date.

Semnalul
Specificarea unui stimul asincron transmis ntre instane.

Componenta
O parte fizic substituibil a unui sistem, care realizeaz un set specificat de interfee.

Nodul
Un element fizic, care exist n timpul execuiei sistemului, reprezentnd o resurs de calcul
avnd cel puin anumite tipuri de memorie i alte capabiliti de procesare.

Contextul de utilizare
O descriere a unui set de secvene de aciuni, incluznd variante, pe care sistemul le execut
pentru a produce un rezultat ateptat de un actor.

Subsistem
O grupare de elemente, dintre care unele constituie specificarea comportamentului oferit de
alte elemente coninute.

De cele mai multe ori, fiecare tip de clasificator are att nsuiri structurale ct i nsuiri
comportamentale. Excepia este reprezentat de interfee care nu pot avea atribute informaionale.
Formalizmul grafic UML pentru reprezentarea clasificatorilor este schiat n Figura 55.
Problema clasificatorilor va fi reluat n amnunt, pe tipuri studiate separat, n continuare.

Vizibilitate
Un detaliu de mare importan pe care l specificm cnd utilizm un clasificator este
vizibilitatea atributelor i a operaiilor. Vizibilitatea unei proprieti indic dac aceasta poate fi
folosit de ali clasificatori. n UML putem specifica trei nivele de vizibilitate.














Figura 5 Clasificatori UML


Vizibilitate de tip public
Orice clasificator exterior, care are vizibilitate asupra unui clasificator dat poate folosi o
proprietate public a acestuia; o proprietate public este prefixat de semnul +.

Vizibilitate de tip protected
Orice descendent al unui clasificator poate folosi o proprietate protected a acestuia;
specificarea unei proprieti protected se face prin prefixarea acesteia cu simbolul #.
Vizibilitate de tip private
O proprietate de tip private a unui clasificator poate fi folosit, direct, doar de clasificator
nsui. Orice alt clasificator are acces la proprietatea privat a unui clasificator dat doar dac
interfaa acestuia (public, evident) ngduie acest lucru. O proprietate private este indicat
prin prefixarea ei cu simbolul -.

Combinarea acestor tipuri de vizibilitate n procesul de modelare urmrete, n general,
ascunderea detaliilor de implementare i expunerea doar a acelor proprieti (dogmatic vorbind)
care contribuie la ndeplinirea responsabilitilor abstraciei n cauz. Dup cum se poate constata,
orice cititor cu experien n programare, viziunea UML asupra vizibilitii iese n ntmpinarea
semanticii, comune unor limbaje precum C++, Java, Ada, Eifel, n materie de vizibilitate a
proprietilor abstraciilor.


Forma

origine

muta()
redimensioneaza()
afiseaza()

clas
IUnknown
interfa
<<type>>
Int
{values range from
-2**31-1 to 2**31}
tip de dat
<<signal>>
SemnalRobot
kernel32.dll
Sever
ShopLibrary
semnal
component
nod


Consultare Ofert
<<subsistem>>
Subsistem ServireClient
context de utilizare subsistem

Competena
Alt detaliu important care poate fi precizat relativ la atributele i operaiile unui clasificator
este competena n cadrul deinorului lor. Competena n cadrul deintorului a unei nsuiri
ne arat dac nsuirea se manifest distinct pentru fiecare instan a clasificatorului sau dac
exist o singur manifestare a nsuirii pentru toate instanele clasificatorului. Acesta este motivul
pentru care n UML specificm dou tipuri de competen n cadrul deintorului: competena
instan (instance scope) i competena clasificator (classifier scope).
n cazul competenei de tip instance fiecare instan a clasificatorului pstreaz propria
valoare pentru proprietate.
n cazul competenei classifier exist o singur valoare a proprietii pentru toate instanele
clasificatorului.
Reprezentarea grafic a competenei unei proprieti poate fi urmrit n Figura 56.












Figura 56. Competena unei proprieti n cadrul deintorului ei
Exemplul prezentat n Figura 56 ne arat c o proprietate subliniat are competen
clasificator iar o proprietate nesubliniat are competen instan.
Punndu-ne, pentru o clip, n postura celor care, la nivelul limbajelor de programare, au
implementat polimorfismul, atunci suntem nevoii s presupunem c adresa tabelei VMT, asociat
unei clase care are metode virtuale, este pstrat ntr-o proprietate care are competen
clasificator, valoarea ei fiind partajat de toate obiectele care sunt instane ale clasi n discuie.
n sfrit, s mai observm c la nivelul limbajelor de programare proprietile cu competen
clasificator sunt, de regul, atribute sau operaii statice (C++, Java).

Elemente abstracte, rdcin, frunz i polimorfice
Utiliznd relaia de generalizare, soluia unei probleme, din perspectiv structural, poate fi
exprimat ca o ierarhie de clase, n care vom ntlni:

Clase cu nivel nalt de abstractizare, n vrful ierarhiei i clase cu comportament specific
bine conturat la nivelele inferioare ale ierarhiei.
nuntrul acestei ierarhii este uzual s se specifice faptul c anumite clase sunt abstracte,
adic sunt clase care nu pot avea instane direct.

n UML vom specifica faptul c o anumit clas este abstract prin scrierea numelui ei cu
caractere italice. Utilizarea unei clase A poate s nsemne motenirea proprietilor unei clase mai
generale B sau obinerea unei clase specializate C prin derivare din clasa A. Exist, ns i dou
situaii limit n aceast privin. Pe de o parte, putem avea situaii n care considerm c o
anumit clas nu este util s aib urmai. O astfel de clas se nuimete clas frunz i este
semnalat de ataarea contrngerii {leaf} sub numele clasei n cauz. Operaiile unei clase pot
avea, n mare, proprieti similare. ntr-o ierarhie de clase, care abstractizeaz soluia unei
probleme, este, de asemenea, un fapt comun, posibilitatea de a avea operaii polimorfice, prin care
desemnm faptul c ntr-o ierarhie de clase putem specifica operaii cu aceeai signatur, n
diferite clase ale ierarhiei care formeaz un lan de derivare. ntr-un astfel de lan de derivare, o
operaie polimorfic dintr-o clas descendent suprancarc (suprascrie) comportamentul operaiei
echivalente (din punct de vedere al signaturii) din clasa strmo. Dac, n timpul execuiei
sistemului soft, bazat pe aceast ierarhie, trimitem un mesaj care implic invocarea unei operaii
polimorfice, determinarea versiunii vizate de mesaj se face polimorfic, n funcie de tipul clasei
implicat n crearea variabilei obiect context a mesajului (de regul, marca clasei definitoare este
pus pe un obiect de un constructor al clasei respective).
S mai adugm faptul c, ntr-o ierarhie de clase, la limit, mai putem ntlni operaii
abstracte (care trebuie suprancrcate obligatoriu n descendeni pentru a beneficia de
Frame

header:FrameHeader
uniqueID:Long

competen
clasificatot
competen
instan
implementare) i operaii frunz, care nu sunt polimorfice i s-ar putea s nu fie suprancrcate.
Elementele discutate mai sus pot fi urmrite i n Figura 57.

















Figura 57. Clase i operaii concrete i abstracte

Multiplicitate unei clase
Cnd se lucreaz cu clasele, este firesc s presupunem c acestea vor avea un numr oarecare
de instane (exceptnd, evident, clasele abstracte, care nu pot avea instane directe ci doar instane
ale descendenilor concrei). n anumite situaii, logica utilizrii claselor se poate baza pe
restricionarea numrului de instane pe care le pot avea. Nu puine sunt, aadar, situaiile n care
dorim s indicm faptul c o clas are zero instane (ceea ce nseamn expunerea de ctre clasa n
cauz a unor atribute i operaii cu competene la nivelul clasei, o singur instan (singleton
class), un numr specificat de instane sau un numr arbitrar de instane (de cele mai multe ori,
situaie considerat, de altfel, implicit).

Numrul de instane pe care le poate avea o clas determin multiplicitatea clasei

n UML putem specifica multiplicitatea unei clase prin indicarea acesteia n colul din dreapta,
sus, al icon-ului asociat clasei, ca n Figura 58.








Figura 58. Clase i multipliciti

Lucreaz cu
1
Server
3
Client
clas abstract
Icon
{root}

origine:TPunct

afisare()
citireID(): Long {leaf}
clas abstract
clas de baz
operaie abstract
operaie concret
IconDreptunghiular

inaltime:Long
latime:Long

IconOarecare

muchii:TColectieDeLinii

esteInauntru(p:TPunct):boolean
Buton

afisare()

ButonOK
{leaf}


afisare()
clas abstract
clas concret
clas frunz
Atribute
La nivelul de abstractizare cel mai nalt, cnd modelm nsuirile structurale ale unei clase
(adic precizm lista atributelor), este suficient s indicm numele atributelor. n procesul de
detaliere a modelului claselor avem nevoie de sintax-suport pentru a preciza aspecte precum:
vizibilitatea, competena, multiplicitatea, tipul, valoarea iniial i disponibilitatea la schimbri a
valorilor atributelor. Astfel c sintaxa complet pentru specificarea unui atribut ntr-o clas UML
este:

[vizibilitate] nume_atribut [multiplicitate]
[:tip][=valoare_iniial][ir_de_prprieti]

vizibilitatea este indicat cu ajutorul unor simboluri dedicate, astfel:

+ (public) orice clas care vede clasa deintoare vede atributul
# (protected) orice descendent al clasei poate vedea atributul
-(private) doar clasa poate vedea atributul

nume_atribut este indicat ca un identificator; sugestiile relativ la formarea
identificatorilor au fost prezentate n numeroase exemple.

tipul este indicat ca o expresie ir de caractere desemnnd un clasificator. n ceea ce
privete modul de indicare a tipului, aceasta este o problem care este tratat diferit de
limbaje de programare diferite. Singurul lucru bine stabilit const n faptul c poate fi
folosit pe post de tip asociat unui atribut un nume de clas sau un nume de tip de dat.

multiplicitatea este indicat ca o expresie-multiplicitate inclus ntre paranteze drepte,
plasat dup numele atributului. Dac multiplicitatea atributului este exact unu, atunci
parantezele drepte pot fi omise. Cteva exemple vor ajuta la o nelegere mai bun a
modului de utilizare a multiplicitii atributelor.

culori[7]:TipCuloare //specific un vector de 7 culori
puncte[2..*]:TipPunct //specific un vector de dou sau mai multe
puncte

nume[0..1]:String //aceast multiplicitate este utilizat, de regul,
pentru a indica asocierea cu o valoare nul atunci cnd
un nume efectiv lipsete

Atrag atenia programatorilor nrii s nu confunde declaraia de multiplicitate
cu declararea modului de indexare n cazul unui tablou

valoarea iniial este indicat ca un ir de caractere. Dac valoarea iniial lipsete,
atunci irul de caractere i semnul egal vor lipsi. Atunci cnd valoarea iniial este
prezent, specificarea ei poate fi realizat ca n exemplul:

origine:TipPunct=(0,0)

ir_de_proprieti permite includerea de informaii referitoare la:
o disponibilitatea la schimbri a atributului indicat cu ajutorul unuia dintre
cuvintele cheie de mai jos, inclus ntre acolade:

changeable ceea ce nseamn c nu exist nici o restricie n ceea ce privete
modificarea valorilor atributului.
addOnly pentru atributele cu multiplicitate mai mare dect unu, pot fi
adugate valori adiionale, dar odat create nu pot fi terse sau modificate

frozen valoarea atributului nu poate fi schimbat dup iniializare

o n plus fa de ceea ce sugereaz explicit sintaxa pentru specificarea unui atribut,
s mai menionm faptul c putem asocia unui atribut una sau mai multe valori
etichetate. Atunci cnd aceste valori etichetate sunt necesare ele apar ntre
acolade care, opional, pot include i disponibilitatea la schimbri, ca n
exemplul de mai jos.

handle:Integer {frozen}
conturi[0..5]:TipCont;{addOnly,primul=11.01}

n sfrit, s ne amintim c putem marca i competena unui atribut subliniind atributul dac
acesta are competen de nivel clas.

Operaii
La nivelul de abstractizare cel mai nalt, cnd modelm nsuirile comportamentale ale unei
clase (adic precizm lista operaiilor i semnalele ei) indicm doar numele fiecrei operaii.
Necesitile de rafinare a modelului claselor impun precizarea i a altor elemente importante
referitoare la operaii, a cum rezult din sintaxa complet de specificare a unei operaii n UML.

[vizibilitate]nume_operaie[(list_de_parametri)]
[:tip_returnat] [ir_de_prprieti]

Precizrile fcute la atribute, relativ la vizibilitate sunt valabile i n cazul operaiilor.
Referitor la numele unei operaii s menionm i faptul c atunci cnd operaia are competene la
nivelul clasei, numele ei trebuie subliniat.
Aa cum rezult din sintax, signatura unei operaii poate expune niciunul sau mai muli
parametri. Sintaxa UML pentru specificarea unui parametru este:

[orientare]nume_parametru:tip[=valoare_implicit]

Proprietatea orientare poate lua oricare din valorile in (dac parametrul este de intrare),
out (ceea ce nseamn c parametrul este de ieire) i inout (ceea ce nseamn c avem un
parametru de intrare care poate fi modificat).
Seciunea ir_de_proprieti permite inserarea a o serie de informaii importante
pentru nelegerea semanticii unei operaii. Astfel, n afar de proprietatea leaf, ntlnit la atribute,
UML introduce nc patru proprieti care pot fi asociate cu operaiile:

isQuery
Execuia operaiei nu afecteaz starea sistemului. isQuery=true indic faptul c operaia nu
altereaz starea sistemului. Aceeai semnificaie are i utilizarea cuvntuuli cheie query.

sequential
Apelanii trebuie s aib n vedere rezolvarea extern a problemei sincronizrii accesului la
operaie, astfel nct s nu apar conflicte n cazul unor fluxuri multiple de acces la obiect.

guarded
Semantica i integritatea obiectului este garantat n caz de acces multiplu, prin
secvenializarea apelurilor operaiilor marcate de proprietatea guarded. De fapt, problema
este rezolvat n sensul c, la un moment dat o singur operaie marcat guarded a unui obiect
poate fi invocat, de ctre un apelant.

concurent
O operaie concurent poate suporta invocri multiple simultan, fr ca semantica i
integritatea obiectului s aib de suferit.

Evident, proprietile sequential, guarded, concurent i gsesc valoare de ntrebuinare n
cazul n care lucrm cu obiecte active, procese sau fire de execuie.

Clase ablon
Un ablon, n genere, este un element parametrizat. n limbaje precum C++ i Ada pot fi scrise
clase ablon (template), fiecare clas ablon definind o familie de clase. Programatorii
experimentai tiu, de asemenea, c n C/C++ putem scrie i funcii ablon. Funciile ablon i
clasele ablon sunt instrumente deosebit de puternice n programarea generic, tehnic de
programare care urmrete invocarea aceluiai comportament asupra unor tipuri de date diferite.
Evident, se face reutilizare important de cod i se asigur suport sistematic pentru conservarea
fiabilitii, odat ce s-a investit efort de programare n acest sens.
Aadar, definiia unui ablon presupune stabilirea listei de tipuri generice implicate n
comportamentul ablonului. Aceste tipuri generice se numesc parametrii ablonului.
Pentru a fi utilizat, ablonul trebuie, mai nti, s fie instaniat. Instanierea implic, n esen,
legarea parametrilor formali ai ablonului (tipurile generice) de parametrii actulai (tipurile de date
concrete). Operaia de legare (binding) este realizat la compilare, rezultatul legrii fiind o clas
sau o funcie concret. Pentru a exemplifica, n C++ putem avea codul template:

template <class T1, class T2>
class NumarComplex
{
T1 x;
T2 y;
public:
NumarComplex(T1 xx,T2 yy);
:
}

Acest ablon este instaniat printr-o declaraie de tipul:

NrComplex<int,float> nrc (1,1.5);

Este de ateptat ca UML s ofere suport pentru reprezentarea semanticii pe care am discutat-o
mai sus. Pentru exemplificare, codul C++ prezentat mai sus se va reflecta n formalizmul UML ca
n Figuraq 59.
Aa cum rezult i din Figura 59, instanierea unei clase ablon poate fi modelat n dou
moduri.



































Figura 59. Clase ablon n UML

NumarComplex

-x:T1
-y:T2

+NumarComplex(T1 x1,T2 y1)

T1
T2
clasa ablon parametrii formali ai ablonului
NumarComplex<int,float>
IntFloatNC
<<bind>>(int,float)
legare implicit
legare explicit
Prin legare implicit, declarnd o clas al crei nume conine sintaxa specific legrii (
=fixarea tipurilor cu care se lucreaz) sau, explicit, utiliznd o dependen stereotipizat, numele
stereotipului fiind <<bind>>. n acest al doilea caz, stereotipul <<bind>> specific faptul c
sursa (clasa IntFloatNC) instaniaz inta (clasa sablon NumrComplex) folosind parametrii
actuali specificai.

UML definete patru sterotipuri standard care se pot aplica claselor:

<<metaclass>> Specific un clasificator ale crui instane sunt clase
<<powertype>> Specific un clasificator ale crui instane sunt descendeni ai unui
strmo dat.
<<stereotype>> Specific faptul c acel clasificator cruia i se aplic este un stereotip
care poate fi aplicat altor elemente.
<<utility>> Stecific o clas ale crei atribute i operaii au, toate, competene la nivel
de clas.

Elemente standard
n ncheierea paragrafului 3.1 s mai remarcm faptul c toate mecanicmele de extensie ale
UML-ului se aplic, ori de cte ori este necesar, claselor. Astfel, este un lucru obinuit s folosim
valorile etichetate pentru a extinde semantica clasei (specificnd, de exemplu, versiunea clasei) dar
i stereotipurile pentru a specifica noi tipuri de componente.

3.2. Elelemente avansate referitoare la relaii
Structura unui sistem este determinat de ansamblul relaiilor invariante dintre componentele
sistemului. Relaiile dintre componentele unui sistem sunt, la rndul lor, dependente de obiectivele
sistemului i modul de operaionalizare a acestor obiective. Un sistem solid i ntemeiaz
dinamica pe componente solide. Soliditatea despre care vorbesc, n ingineria softului se refer la
capacitatea componentelor sau a sistemului ca ntreg, de a onora contractele asumate, n condiii de
calitate.
Identificarea structurii unui sistem este o problem, n egal msur, dificil i
important. Este dificil deoarece, pe lng exerciiul rutinei, presupune i un anume tip de
disponibiliti creative. Este important pentru c, odat stabilit o viziune asupra structurii
unui sistem soft, restul soluiei va purta definitiv i esenial marca acestei viziuni.

Relaia de dependen
Aa cum am subliniat i cu alt prilej, dependena este o relaie de utilizare care indic faptul c
o schimbare n specificarea termenului A al relaiei poate afecta termenul B al relaiei, care se
folosete, ntr-un mod oarecare de A. Ideea precizat mai sus se reprezint grafic, ca n Figura 60.





Figura 60. Relaia de dependen. Formalizm de reprezentare

O relaie de dependen fr alte ornamente este, n multe situaii satisfctoare. Totui, dac
dorim s specificm o anumit nuan a semanticii unei relaii de dependen, UML ne pune la
dispoziie o serie de stereotipuri care pot fi aplicate relaiei de dependen. Exist 17 astfel de
stereotipuri, care pot fi organizate n ase grupe dup valoarea lor de ntrebuintare.

Grupa 1
Stereotipuri care se aplic relaiei de dependen dintre clase i obiecte n diagrame de
clase.

<<bind>> - Specific faptul c sursa instaniaz ablonul int, folosind parametrii actuali
dai. Am vzut, deja, la lucru acest stereotip.
<<derive>> - Specific faptul c sursa poate fi calculat folosind date furnizate de int.
Folosim acest stereotip cnd dorim s modelm relaia dintre dou atribute sau dou asocieri,
dintre care unul (una) este concret() iar cellalt(cealalt) este, conceptual, derivabil din
primul (prima). Modul de utilizare a stereotipului este ilustrat n Figura 61.

B A









{Persoana.angajator=Persoana.departament.angajator}


Figura 61. Exemplu de atribut derivat i asociere derivat

n Figura 61 se poate observa c un element derivat este indicat prin prezena unui simbol (/)
n faa numelui elementului derivat. Dac lizibilitatea modelului nu are de suferit se poate folosi i
indicarea cu sgeat stereotipizat a relaiei de dependen.

<<friend>> Specific faptul c sursei i se confer o vizibilitate special
asupra intei.

Acest stereotip l utilizm cnd vrem s modelm relaii asemntoare celor existente ntre
clasele prietene din C++.

















Figura 62. Diferite tipuri de dependene ntre clase

Utilizarea stereotipului <<friend>> reiese, destul de clar, din Figura 62.

<<instanceOf>> Specific faptul c obiectul surs este o instan a
<<instantiate>>
<<friend>>
<<friend>>
<<call>>
Clasa A Clasa B
Clasa C
Clasa D

operaiez()
departament
angajator
*
1
*
1
1
* /LucreazaPentruCompania
{varsta=dataCurenta
-dataNasterii}
Persoana

dataNasterii
/varsta
Companie
Departament
Persoana
LucreazaPentru
Departament
clasificatorului int.

<<instantiate>> Specific faptul c sursa creaz instane ale intei.

Utilizm stereotipul <<instanceOf>> dac vrem s modelm o relaie de dependen dintre o
clas i un obiect, n aceeai diagram sau o relaie de dependen dintre o clas i metaclasa ei.
Folosim stereotipul <<instantiate>> cnd dorim s specificm faptul c un anumit element
creaz obiectele altui element. A se vedea i Figura 62.

<<powertype>> Specific faptul c inta este supertip al sursei; reamintesc faptul c numim
supertip (powertype) un clasificator ale crui obiecte sunt descendeni ai unui printe dat.














Figura 63. Exemplificarea noiunii de supertip

Se cuvine s facem o scurt parantez pe marginea semanticii reprezentat n Figura 63.
Aadar, clasa Arbore generalizeaz clasele Stejar, Ulm i Salcie. Ca urmare, instanele clasei
Arbore sunt compatibile la atribuire cu instanele claselor Stejar, Ulm i Salcie. Dac, ns, vom
considera clasele Stejar, Ulm i Salcie ca nite obiecte (fcnd oarecare abuz de limbaj) atunci
aceste obiecte pot fi socotite instane ale metaclasei SpeciiArbori.

<<refine>> Specific faptul c sursa este, din punct de vedere al abstractizrii, rezultatul unui
proces de rafinare a intei.
Altfel spus, sursa i inta sunt, n esen, similare, dar sursa conine mai multe detalii dect
inta. Aa se ntmpl cu o clas, care expune un numr redus de atribute i operaii i de detalii de
specificare a acestora n faza de analiz a cerinelor, urmnd ca n faza de design s se adauge
aproape toate detaliile necesare la implementare.

<<use>> Specific faptul c semantica elementului surs depinde de semantica prii publice
a elementului int.
Folosim acest stereotip cnd vrem s indicm coninutul exact al unei relaii de dependen
dintre dou elemente.

Grupa 2
Stereotipuri care se aplic relaiilor de dependen dintre pachete

<<access>> Specific faptul c pachetului surs i este acordat dreptul de a referi elemente ale
pachetului int.

<<import>> O varietate de acces care specific faptul c tot coninutul public al pachetului
int intr n spaiul de nume total al pachetului surs, ca i cnd ar fi fost declarat n pachetul
surs.

Fr ndoial, exist ntre aceste dou stereotipuri, o diferen care trebuie comentat.
Amndou stereotipurile sunt folosite pentru a da un neles specific modului n care elementele
unui pachet pot fi referite de elementele altui pachet. Presupunnd c pachetul int P2 conine
clasa C1, atunci un element din pachetul surs P1 (aflat n relaie de dependen cu pachetul P2)
poate referi clasa C1 folosind operatorul de rezoluie global (P2::C1), dac dependena este de tip
<<access>>. Dac specificm o dependen de tip <<import>> de la P1 la P2, atunci elementele
lui P1 pot referi clasa C1 folosindu-i doar numele.
Arbore
Stejar Ulm Salcie
<<powertype>>
Specii de arbori

Merit o remarc aparte conceptul de spaiu de nume (namespace) utilizat din ce n ce mai
insistent n noile paradigme de modelare i programare (UML, Java, C#) pentru a clarifica
problema condiiilor n care o anumit resurs poate fi referit fr a introduce ambiguiti,
folosind doar numele acesteia.

Grupa 3
Stereotipuri care se aplic relaiilor de dependen dintre contexte de utilizare

<<extend>> Specific extinderea de ctre contextul de utilizare surs a comportamentului
contextului de utilizare int.
Exprimndu-ne altfel, o relaie de extindere reflect dependena dintre un context de utilizare
- extensie i un context de utilizare de baz. n cadrul acestei relaii, contextul de utilizare de
baz trebuie s defineasc un set de puncte de exetnsie, fiecare referind o locaie sau un set de
locaii n contextul de utilizare de baz, unde se poate insera comportamentul adiional.
Un context de utilizare-extensie conine o list de segmente de inserie, fiecare segment
descriind o secven comportamental. Atunci cnd execuia instanei unui context de utilizare de
baz ajunge ntr-o locaie referit de un punct de extensie i condiia asociat punctului de extensie
este ndeplinit ( condiie care este specificat n relaie, alturi de punctul de extensie cruia i se
aplic) execuia instanei transfer controlul secvenei segmentului corespunztor al contextului de
utilizare - extensie; la terminarea execuiei segmentului, contextul de utilizare de baz preia
controlul imediat dup referina la punctul de extensie.
S mai adugm faptul c o asemenea abordare, introduce, la un anumit nivel de abstractizare,
o perspectiv modular asupra comportamentului sistemului. Aceast perspectiv admite c
extensia poate accesa i modifica atributele bazei, dar baza nu poate vedea extensia i nu-i poate
accesa atributele sau operaiile. Formalizmul de reprezentare al unei extinderi poate fi dedus din
Figura 64.









Figura 64. Extinderi imbricate

<<include>> Specific ncorporarea explicit (de ctre contextul de utilizare surs) a
comportamentului unui alt context de utilizare, la o locaie specificat de surs.

ntr-o astfel de relaie, contextul de utilizare care include poate vedea contextul de utilizare
inclus, dar nici contextul care include nici cel inclus nu pot accesa atributele celuilalt. Spre
deosebire de cazul extinderii, unde adugarea de comportament adiional era condiionat,
secvena inclus este executat necondiionat n timpul execuiei contextului de baz ( care
include).
<<extend>>(Y)
<<extend>>(X)
A
puncte de extensie
X
B
puncte de extensie
Y


C
Descrierea, ca scenariu, a contextului de utilizare Sesiune bancomat (prezentat n Figura 65)
ar putea arta ca mai jos.




Figura 65. Exemplu de utilizare a stereotipului <<include>>

afiarea reclamei zilei
include Identificare client
include Validare cont
tiprire chitan

Contextul Identificare client ar putea fi:

preluare nume client
include Verificare identitate
Dac verificarea eueaz atunci terminare sesiune
obinere numere de cont pentru client, etc.

Grupa 4
Stereotipuri utilizate cnd se modific interaciunea dintre obiecte

<<become>> Specific faptul c inta este acelai obiect cu sursa, dar n momente de timp
diferite i cu posibile schimbri de valori ale atributelor, ceea ce poate implica modificarea strii i
a relaiilor.

<<call>> Specific faptul c operaia surs apeleaz operaia int.

<<copy>> Specific faptul c obiectul int este o copie identic, dar independent a sursei.

Relativ la aceast grup de stereotipuri putem concluziona urmtoarele: vom folosi
<<become>> i <<copy>> cnd dorim s evideniem rolul, starea sau valorile atributelor unui
obiect n momente de timp diferite. Vom folosi <<call>> cnd dorim s modelm relaia de
apelare ntre operaiile obiectelor.

Grupa 5
Alte stereotipuri

<<send>> Specific faptul c operaia surs trimite semnalul int.

<<trace>> Specific faptul c inta este un strmo istoric al sursei.

Stereotipul <<send>> l folosim pentru a modela o operaie. nelegerea deplin a
stereotipului <<send>> va fi posibil n momentul n care vom trece la prezentarea formalizmului
<<include>>
<<include>
>

Sesiune bancomat

Identificare client

Validare client

UML pentru modelarea aspectelor comportamentale. n Figura 66 se poate vedea un prim exemplu
de utilizare a stereotipului <<send>>.













Figura 66. Utilizarea stereotipului <<send>>

Dependena din Figura 66 indic posibilitatea ca metoda stergeStud() s ridice o excepie de
tipul ExceptCStud, stereotipizat ca <<signal>>, situaie n care este clar relaia stereotipizat ca
<<send>>. n sfrit, s observm c stereotipul <<trace>> l vom utiliza atunci cnd dorim s
modelm relaia dintre elemente care las urme n modele diferite. De exemplu, un context de
utilizare se poate reflecta ntr-un pachet care ncapsuleaz soluia la nivel de design, care
realizeaz respectivul context de utilizare.

Relaia de generalizare
O relaie de generalizare simpl, fr ornamente, este suficient pentru cea mai mare parte a
situaiilor n care apelm la motenire. Pentru situaii deosebite, UML pune la dispoziia
specialitilor un stereotip i patru constrngeri care pot fi aplicate relaiilor de generalizare.

Stereotipul
<<implementation>> Specific faptul c descendentul motenete implementarea
strmoului dar nu public interfaa acestuia i nici nu ofer suport pentru utilizarea ei, la nivelul
clientului. Evident, principiul substituirii strmoului de ctre descendent este nclcat. Acest
stereotip este tocmai bun pentru a modela motenirea privat a clasei A de ctre clasa B, n C++.

Constrngerile
<<complete>> Specific faptul c o anumit generalizare are toi descendenii specificai.
Chiar dac unii s-ar putea s lipseasc din diagram, ei nu mai pot fi adugai.

<<incomplete>> Specific faptul c mai exist copii care nu au fost specificai ntr-o anumit
generalizare. Este permis adugarea de noi descendeni.

<<disjoint>> Specific faptul c descendenii generalizrii nu pot avea mai mult dect un
copil al strmoului comun ca tip.

<<overlaping>> Specific faptul c descendenii generalizrii pot avea mai mult dect un
copil al strmoului comun ca tip.

Ultimele dou stereotipuri sunt introduse n UML pentru a distinge ntre clasificarea static
(<<disjoint>>) i clasificarea dinamic (<<overlaping>>). Evident, este nevoie de ele acolo unde
exist suport pentru motenirea multipl (C++, de exemplu).

Modelarea clasificrii dinamice este o chestiune complex, att din punct de vedere al
programrii, ct i din punct de vedere al nelegerii. UML, ns, dispune de elemente suport
convenabile pentru a explica modul n care motenirea i polimorfismul permit clasificarea
dinamic a obiectelor.

Diagrama (a) din Figura 67 ne informeaz c un lucrtor poate avea o singur ocupaie i c
lista ocupaiilor este incomplet. Astfel c, utilizarea corect a acestei generalizri nseamn
derivarea unor clase avnd ca strmoi una dintre clasele Brutar, Mcelar sau Lutier.



<<send>>
<<signal>>
ExceptCStud

mesaj
cod
...

Lista

AStart
APrec
...

stergeStud()























Figura 67. Utilizarea constrngerilor n generalizri.

Diagrama (b) din Figura 67 ne informeaz c un atlet poate practica mai multe sporturi i c
lista sporturilor atletice este, de asemenea, incomplet. Prin urmare, vor putea exista descendeni ai
acestei generalizri care au mai mult de un strmo printre copii clasei Atlet. Altfel spus, aceti
descendeni vor avea instane care posed o singur copie a resurselor clasei Atlet. Situaii de acest
gen se pot ntlni n programarea obiect orientat C++, contextul {overlapping} fiind forat prin
operaia de derivare virtual.

Relaia de asociere
Dup cum am prezentat, deja, exist patru tipuri de ornamente de baz care se pot aplica unei
asocieri: numele asocierii, rolurile claselor n cadrul asocierilor, multiplicitile asociate capetelor
asocierii i agregarea. Pentru utilizatorii avansai exist o serie de alte proprieti care pot fi
folosite pentru a modela aspecte subtile ntr-o asociere, precum: navigarea, calificarea i diferite
nuane de agregare.
Navigarea
Dat o asociere simpl ntre dou clase, n principal este posibil navigarea de la obiectele
unei clase la obiectele celeilalte clase i invers. Aadar, fr specificri suplimentare, navigarea n
asocierea dintre dou clase este bidirecional. n practic exist i situaii n care dorim s limitm
navigarea la o singur direcie. O astfel de situaie va fi reprezentat ca n Figura 68.












Figura 68. Navigarea unidirecional ntr-o asociere

Semantica ncapsulat n asocierea din Figura 68 este: un utilizator ( al unui sistem de calcul
Desktop sau al unei reele de calculatoare) va avea acces la o sesiune de lucru, n urma asocierii lui
cu una sau mai multe parole; asocierea, definit n Figura 68 sugereaz explicit c nu este permis
localizarea utilizatorului care conine o anumit parol.


proprietar
* 1
Utilizator Parol
asociere direcia de navigare
Lucrtor
Brutar Mcelar Lutier
{disjoint, incomplete}
ocupaie
(a)
Atlet
Sritor la nlime
Maratonist
{overlapping, incomplete}
(b)
Vizibilitatea
Dat o asociere ntre dou clase, obiectele unei clase pot s vad obiectele celeilalte clase,
exceptnd situaia n care navigarea este restricionat explicit. Mi se pare nimerit s aprofundm
aceast discuie, invitndu-v la analiza Figurii 69.











Figura 69. Vizibilitatea, ca problem n specificarea unei asocieri

Dup cum se vede, problema care se pune este urmtoarea: putem controla vizibilitatea unui
rol ntr-o asociere sau ntr-un sistem de asocieri? Rspunsul este afirmativ. Termenii n care
discutm despre vizibilitatea rolurilor ntr-o asociere sunt:

1. Dac nu se face alt meniune, vizibilitatea unui rol ntr-o asociere este public. Dac
se consider util, vizibilitatea public poate fi evideniat explicit prefixnd numele de rol cu
simbolul +.

2. Asocierea unui rol cu o vizibilitate privat (=prefixarea rolului cu simbolul -) indic
faptul c obiectele acelui rol nu sunt accesibile nici unui obiect din afara asocierii.

3. Asocierea unui rol cu o vizibilitate protected (=prefixarea numelui de rol cu simbolul
#) indic faptul c obiectele acelui rol nu sunt accesibile obiectelor din afara asocierii care nu
sunt descendeni ai rolului.

n consecin, n Figura 69 ni se spune c un obiect de tip Grup de utilizatori are acces la
utilizatorii corespunztori, dar nu poate accesa obiectele Parol asociate (din cauza declarrii
rolului cheie ca privat n asocierea dintre clasa Utilizator i clasa Parol.

Calificarea
Una dintre problemele comune n interpretarea unei asocieri (la diferite nivele de
abstractizare) este urmtoarea: dat un obiect, la unul dintre capete unei asocieri, cum putem
identifica un obiect sau o mulime de obiecte la cellalt capt al asocierii? n faa unei astfel de
ntrebri, n anumite mprejurri s-ar putea s fim interesai de reducerea efectului de
multiplicitate, atunci cnd acesta este prezent, ca n exemplul din Figura 70.












Figura 70. Utilizarea calificrii pentru a reduce efectul de multiplicitate

Semantica celor dou ipostaze ale asocierii claselor Furnizor i Produs este descris mai jos.
Asocierea (a), unidirecional, abstractizeaz situaii de tipul: un furnizor poate livra zero,
unul sau mai multe produse. Ce se ntmpl, ns, atunci cnd dorim, n contextul clasei Furnizor,
accesul la un anumit produs? Evident, soluia este asocierea (b), unidirecional, n care elementul
noutate este introducerea calificatorului codProdus ca atribut al asocierii, cu scopul de a repera, n
contextul clasei Furnizor, exact un anumit produs.

*
1 * *
-cheie
+proprietar +utilizator
Grup de
utilizatori
Utilizator
Parol
vizibilitate n cadrul asocierii
* Livreaz 1
*
Livreaz
*
Furnizor Produs (a)

Furnizor
Cod Produs
Produs
(b)
Specificator de interfa
O interfa este o colecie de operaii care sunt folosite pentru a specifica un serviciu al unei
clase sau componente; fiecare clas poate realiza mai multe interfee. La fel, o clas poate s-i
expun serviciile prin intermediul mai multor intefee. n termeni asemntori, ne exprimm i
cnd este vorba de obiecte programabile, gen ActiveX. Exemple interesante de obiecte
programabile pot fi socotite produsele Microsoft care constituie pachetul Office (Word, Excel,
PowerPoint, etc.). Word-ul, atunci cnd este utilizat ca obiect programabil, expune dou interfee:
una este Word.Basic (interfa clasic, pe baz de comenzi), cealalt este Word.Application
(interfat obiect orientat).
n relaia dintre o clas i interfeele realizate de ea putem spune c interfeele realizate de o
clas reprezint o specificare complet a comportamentului acelei clase. Uneori, n contextul
asocierii cu o clas int, o clas surs poate opta pentru a expune doar o parte din interfaa sa cu
restul lumii. Astfel, n vocabularul unui sistem care se ocup de managementul datelor referitoare
la resursa uman, clasa Persoana poate expune (realiza) mai multe interfee: IManager,
IAngajat, IFuncionar, etc. Aa cum rezult i din Figura 71, putem modela relaia dintre un ef
i subordonaii si cu o asociere unu-la-mai muli, etichetnd explicit rolurile n aceast asociere
prin ef i Lucrtor. n contextul acestei asocieri, o Persoana n rol de ef expune doar interfa
IManager, relativ la rolul Lucrtor, iar o Persoana n rol de Lucrtor expune doar interfaa
IAngajat relativ la rolul ef.











Figura 71. Specificatorii de interfa ntr-o asociere

Compunerea
Revin cu o serie scurt de observaii relativ la varietatea de agregare numit compunere. Se
tie c agregarea este o relaie ntre o clas A (numit clas ntreg) i una sau mai multe clase
(numite clase pri). Agregarea, n esen, este o asociere n care se evideniaz cine este ntregul i
care sunt prile. ntr-o agregare este posibil, de exemplu, ca un obiect s aparin la mai multe
instane ntreg. O astfel de situaie apare, de exemplu, n modelul unei case, unde obiectul Perete
poate fi parte n mai multe obiecte Camera. Realitatea conine i exemple de agregare n care
sublinierea ntregului i a prilor este insuficient. De exemplu, ntr-un sistem de operare orientat
pe ferestre (din punct de vedere al interfeei) un obiect Frame aparine exact unui obiect Window.
Mai mult, obiectul Window este, n mod natural, responsabil pentru amplasarea prilor de tip
Frame, ceea ce presupune asumarea de ctre obiectul Window a proceselor de creare i
distrugere a prilor lui. O astfel de semantic este reprezentat ca n Figura 72.














Figura 72. Compunerea, ca varietate de agregare

Clasele asociere
Clasele asociere permit celor care modeleaz s adauge atribute, operaii i alte proprieti
unor asocieri, aa cum se ntmpl, n Figura 73.
*
1
Window
Frame partea
compunerea
ntregul
1
ef:IManager
lucrtor:IAngajat
*
Persoana
specificator de interfa
Dup cum se vede n Figura 73, o persoan poate lucra, o perioad de timp, pentru o singur
firm. Este necesar, aadar, s pstrm informaii despre perioada n care un angajat lucreaz
pentru acea firm. Putem rezolva aceast problem adugnd atributul perioada asocierii. Este
oportun s adugm acest atribut clasei Persoana? n practic, nu, deoarece, n timp, o persoan
poate lucra la alt firm, deci se poate schimba angajatorul persoanei, fapt care nu ar fi prea clar
modelat ntr-o asociere la care clasa Persoana ar participa cu atributul perioada. Nici ntr-un caz
atributul perioada nu are ce cuta n lista de atribute a clasei Firma. Situaia prezentat n Figura
73 ar putea fi modelat i ca n Figura 74.















Figura 73. Un exemplu de clas asociere











Figura 74. Echivalenta Full class a unei clase asociere

De ce trebuie atunci s promovm extra-notaia corespunztoare unei clase asociere?
Rspunsul ar fi urmtorul: deoarece clasa asociere adaug o constrngere suplimentar (benefic
n anumite situaii) care const n faptul c pentru fiecare dou obiecte participante exist o singur
instan a clasei asociere.

Constrngeri
Elementele prezentate pn acum relativ la asocieri sunt, de regul, suficiente pentru cele mai
multe dintre relaiile ntlnite n realitate. Pentru situaii deosebite, UML mai pune la dispoziie
cinci constrngeri care pot fi aplicate relaiilor de asociere.

implicit Specific faptul c relaia nu este indicat efectiv, ci este motivat conceptual.













Figura 75. Manifestarea constrngerii {implicit}

{implicit}
*
*
Poligon Cadru
Triunghi Patrulater
Cadru
dreptunghiular
Cadru eliptic
Angajator
0..1 *
Persoana Firma
Angajare

perioada:TInterval


clasa asociere
/angajator
0,1
* 1
1 0..1
Persoana
Angajare

perioada:TINterval
Firma
Figura 75 ne indic faptul c relaia de asociere dintre clasele de baz Poligon i Cadru se
manifest i ntre descendenii lor.

ordered Specific faptul c o mulime de obiecte de la captul unei asocieri se afl ntr-o
relaie de ordine explicit.







Figura 76. Manifestarea constrngerii {ordered}

n asocierea din Figura 76 parolele asociate cu un user se vor pstra, de exemplu, n ordinea
cel mai recent utilizat.

changeable Specific faptul c legturile dintre obiecte pot fi adugate, terse i schimbate,
fr restricii.

addOnly Specific faptul c sunt permise adugri de noi legturi, pentru un obiect, la
captul opus al asocierii.

frozen Specific faptul c o legtur a unui obiect, odat ce a fost adugat la captul opus
al asocierii, nu poate fi modificat sau taers.

Relaia de realizare
Acest tip de relaie este folosit pentru a specifica relaia dintre o interfa i clasa sau
componenta care furnizeaz serviciile sau operaiile angajate de interfa. Formalizmul asociat
reprezentrii unei astfel de relaii poate fi urmrit n Figura 77.
























Figura 77. Realizarea unei interfee

Relaia de realizare mai poate fi folosit i pentru a specifica relaia dintre un context de
utilizare i colaborarea care realizeaz acest context de utilizare. n acest caz folosim ntotdeauna
forma canonic pentru reprezentare, ca n Figura 78.




sevd.dll
<<interface>>
IDecan

sendmail()
displayState()
Decan
realizare forma canonic
realizare forma eliptic
{ordered}
* 1
Utilizator Parola








Figura 78. Realizarea unui context de utilizare

3.3 Rolul pachetelor n elaborarea modelelor UML
3.3.1 Introducere
Vizualizarea, specificarea, construirea i documentarea sistemelor de mare complexitate
implic manipularea unui numr mare de clase, interfee, componente, noduri, diagrame i alte
elemente. Din motive de comunicare, ntre partenerii de proiect, a semanticii soluiei, precum i
din motive de stpnire a complexitii soluiei, ndeosebi n cazul sistemelor de mare
complexitate, se impune organizarea acestor tipuri de entiti n entiti cu nivele de abstractizare
mai mari. Suportul UML pentru rezolvarea problemelor de organizare a entitilor care
compun diferite modele este reprezentat, dup cum am spus deja, de diagrame, crora li se
adaug, la nivel arhitectural i pachetele.
Gruparea elementelor care compun diferite modele n pachete este util pentru introducerea
unor reguli clare de control al vizibilitii, precum i pentru a prezenta diferite perspective asupra
unui sistem.
Pachetele bine proiectate grupeaz elemente care sunt apropiate semantic i care manifest
sensibiliti similare la schimbri. Folosind un element de limbaj specific modularizrii, pachetele
trebuie s fie nalt coezive din punct de vedere semantic. Natural este i observaia potrivit
creia cuplajul dintre pachete (atunci cnd exist) trebuie s fie ct mai slab.

3.3.2 Concepte utilizate n lucrul cu pachete
Aadar, putem spune c un pachet este un mecanism de interes general pentru organizarea
elementelor care compun soluia UML a unei probleme n grupuri. Am mai vzut i cu alt prilej
faptul c un pachet se reprezint ca n Figura 79.















Figura 79. Pachet UML

Numele unui pachet
Fiecare pachet are un nume care l identific unic. Un nume este un ir de caractere i se poate
prezenta sub una din urmtoarele dou forme: nume simplu sau nume cu cale. Numele cu cale se
compune din numele simplu al pachetului, prefixat de numele pachetelor n care este rezident
(evident, o astfel de situaie apare doar atunci cnd pachetele sunt cuibrite unele n altele).
De regul, un pachet este reprezentat ca n Figura 79. La fel ca i n cazul claselor, pachetele
pot fi redate ornamentate cu valori etichetate sau compartimente adiionale pentru expunerea
detaliilor.
n Figura 80 sunt trei exemple de pachete care ilustreaz cele spuse mai sus, relativ la numele
unui pachet.






Aprovizionare

nume pachet
Validare
utilizator

Validare
realizare




















F





Figura 80. Pachete simple i cu proprieti extinse n UML

Elemente coninute
Un pachet poate conine alte elemente precum: clase, interfee, componente, noduri,
colaborri, contexte de utilizare, diagrame i chiar alte pachete. Apartenena unui element la un
pachet este o relaie de compunere. Aceasta nseamn c respectivul element este declarat n
pachet iar n cazul n care pachetul este distrus i elementul este distrus.. Un element este unic n
cadrul unui pachet. Un pachet reprezint pentru elementele pe care le conine ceea ce n limbajele
de programare se numete spaiu de nume. Faptul c un pachet este spaiu de nume pentru
elementele pe care le conine nseamn:
elemente de acelai tip trebuie s aib denumiri diferite, n cadrul aceluiai pachet;
putem avea elemente cu acelai nume, diferite ca tip, n pachete diferite;
elemente diferite ca tip pot avea acelai nume i n cadrul aceluiai pachet
Evident, a treia posibilitate nu este bine s fie folosit abuziv, genernd confuzie, n mai multe
sensuri.
S-a semnalat deja faptul c un pachet poate conine un alt pachet, posibilitate care ofer suport
pentru descompunerea ierarhic a modelelor. Aceast posibilitate este o practic curent n
programarea Java, de exemplu. Practica spune c nu este recomandat s se abuzeze nici de
facilitatea ncuibrii pachetelor.
Coninutul unui pachet poate fi evideniat att textual ct i grafic, ca n Figura 81.















Figura 81. ncuibarea pachetelor



Comercial
+Contabilitate
+Facturi
-Rapoarte
Client
pachete cu nume simple
nume pachet
nume pachet gazd
pachet cu proprieti extinse

Comercial::Marketing
{version=1.1.2}
+Contabilitate
+Facturi
-Rapoarte

Client

Client
+Contabilitate
+Facturi
-Rapoarte
Vizibilitatea elementelor mpachetate
Vizibilitatea elementelor coninute de un pachet poate fi controlat n acelai mod n care se
controleaz vizibilitatea atributelor i operaiilor unei clase. Implicit, un element coninut de un
pachet este public, ceea ce nseamn c elementul este vizibil coninutului oricrui pachet care
import pachetul care conine elementul.
Elementele protejate pot fi vzute doar de descendeni iar elementele private nu sunt vizibile
n afara pachetului n care sunt declarate. Simbolurile pentru controlul vizibilitii sunt cele
folosite n cazul claselor.

Importul i exportul de pachete
Dac soluia obiect orientat a unei probleme se reduce la dou clase A i B, aflate, ntr-o
form sau alta, n relaii de prietenie, se tie c A o vede pe B i invers. Pentru aceste dou clase,
recurgerea la mpachetare este pur i simplu o enormitate. Ce se ntmpl, ns, dac soluia obiect
orientat a problemei se exprim printr-o colecie de cteva sute de clase, cum se poate ntmpla,
fr eforturi, n cazul sistemelor de mare complexitate?
O modalitate de a structura, ct de ct, procesul de utilizare a unei colecii de clase, o
reprezint utilizarea pachetelor. Recurgnd la mecanismul pachetelor pentru organizarea unei
colecii mari de clase, rezolvm, n principal, dou probleme:
Clasificarea claselor, repartizndu-le n acelai pachet dac ntre ele exist relaii
strnse (generalizri, asocieri, agregri, etc.) sau n pachete diferite dac
afinitile dintre clase nu sunt att de puternice (De exemlu, o relaie de dependen
ntre dou clase, nu este un motiv de a le ngrmdi n acleai pachet).
Reglm relaiile de vizibilitate a claselor mpachetate, manevrnd potrivit
intereselor imediate regulile de vizibilitate a acestor resurse.
Marea gselni a pachetelor se rezum la urmtorul scenariu: clasa A este rezident, ca
public, n pachetul P. Dac clasa B vrea s fie un descendent al clasi A, ea nu va vedea, din
oficiu, pe A. Pachetul este un zid pe care clasa B l strpunge dac n contextul n care se afl B se
import pachetul P.
Exist, de fapt, urmtoarea nuanare n legtur cu modul n care clasa B poate accede la
resursele lui P:
Clasa B poate accede la resursele lui P lrgind propriul spau de nume astfel nct
acesta s-l cuprind i pe P. Acest procedeu se semnaleaz n UML cu stereotipul
<<import>>. Exist o mic problem n acest caz; dac nu suntem ateni, pot apare
conflicte ntre numele claselor, dac renunm sistematic la calificarea cu numele
pachetului (ceea ce, de altfel, justific importul).
Clasa B poate accede la resursele lui P, calificndu-le numele cu numelee lui P.
Acest procedeu se semnaleaz n UML cu stereotipul <<access>>.
Deplasnd discuia la sfera relaiilor dintre pachete, va fi normal s existe pachete care fac
import i, n replic, vor exista pachete care vor avea ceva de exportat. Un pachet export numai
ceea ce declar public sau vizibil, n condiii bine determinate. n sfrit, s mai observm c, n
cazul pachetelor imbricate, un element vizibil n interiorul unui pachet este vizibil tuturor
pachetelor imbricate.
O parte din semantica desfurat mai sus se reprezint n UML ca n Figura 82.


















Figura 82. Importul i exportul de resurse n condiii de mpachetare. Notaie UML.

<<import>>
+Factura
+Cont

Client
+Proprietate
-Verificare

Produs
dependen stereotipizat cu
cuvntul cheie <<import>>
3.3.3 Relaia de generalizare ntre pachete
ntre dou pachete sunt posibile dou tipuri de relaii:
relaia de dependen, cu cele dou variante de stereotipizare (<<import>> i
<<access>>);
relaia de generalizare; generalizarea opereaz n cazul pachetelor asemntor modului
n care opereaz ntre clase.


























Figura 83. Generalizarea ca relaie ntre pachete

Dup cum se observ n Figura 83, pachetul GUI export dou clase (Window i Form) i o
clas protejat (EventHandler). De asemenea, se poate observa cum dou pachete specializeaz
pachetul GUI, mai general: WindowsGUI i MacGUI, etc. Asemnrile cu clasele sunt prea
evidente, aa nct nu mai lungesc prezentarea.

3.3.4 Elemente standard n lucrul cu pachete
Toate mecanismele UML de extindere se pot aplica pachetelor. De exemplu, valorile
etichetate pot fi utilizate pentru a specifica autorul unui pachet. Este intens folosit i
stereotipizarea pachetelor. UML definete cinci stereotipuri standard care se pot aplica pachetelor:
<<facade>> - specific un pachet care este doar o perspectiv asupra altui pachet.
<<framework>> - specific un pachet care, n principal, conine pattern-uri.
<<stub>> - specific un pachet care servete ca mandatar (proxy) pentru coninutul
public al altui pachet.
<<subsystem>> - Specific un pachet care reprezint o parte independent a sistemului
n curs de modelare.
<<system>> - Specific un pachet care reprezint ntregul sistem n curs de realizare.












+Window
+Form
#EventHandler
GUI
+GUI::Window
+Form
#GUI::EventHandler
+VBForm
WindowsGUI



MacGUI




























Capitolul 4
Modelarea aspectelor comportamentale.
Elemente-suport fundamentale

...Elaborai soluii obiect orientate, pentru problemele dumneavoastr,
mprumutnd ct mai mult din spiritul UML! Adugai UML-ului
noi dimensiuni, dac experiena i puterea de sintez v permit!






















4.1 Interaciuni
ntr-un sistem, interesant din punct de vedere comportamental, obiectele interacioneaz ntre
ele utiliznd ca tehnic de baz transmiterea de mesaje.

Se numete interaciune un comportament care se exprim printr-o serie finit de
mesaje, schimbate ntre obiectele situate n interiorul unui anumit context, pentru
ndeplinirea unui anumit scop.

n practica modelrii vom folosi interaciunile pentru a modela aspecte dinamice ale
colaborrilor, care reprezint uniuni de obiecte jucnd roluri specfice, coopernd pentru
realizarea unui anumit comportament, despre care putem spune, cu rezerva de rigoare, c este mai
mare dect suma mecanic a elementelor.
Aceste roluri reprezint instane prototipice ale claselor, interfee, componente, noduri i
contexte de utilizare. Aspectele lor dinamice sunt vizualizate, specificate, construite i
documentate ca fluxuri de control care pot cuprinde fire de execuie secveniale, precum i fluxuri
mai complexe, care implic ramificri, iteraii, recursii sau concuren.
Putem modela o interaciune n dou moduri: prin accentuarea ordonrii n timp a
mesajelor (obinnd modele numite diagrame de secven) sau prin accentuarea secvenrii
mesajelor n contextul unor colecii structurate de obiecte (obinnd modele numite diagrame
de colaborare).
Este evident faptul c interaciunile bine structurate sunt asemenea algoritmilor bine
structurai: eficiente, simple, adaptabile i inteligibile.
S mai subliniem faptul c putem folosi interaciunile pentru a modela fluxuri de control n
interiorul unor operaii, clase, componente, contexte de utilizare sau la nivelul sistemului ca ntreg.
Utiliznd diagramele de interaciune, putem reflecta asupra acestor fluxuri n dou moduri. Mai
nti, ne putem focaliza atenia asupra modului n care sunt expediate mesajele n timp. n al doilea
rnd, ne putem concentra atenia asupra relaiilor structurate dintre obiectele aflate ntr-o
interaciune i, pe acest temei, s considerm modul n care mesajele circul ntre componentele
contextului structurat.
UML furnizeaz o reprezentare grafic a mesajului, aa cum se poate vedea n Figura 84.

Concepte vehiculate n modelarea interaciunilor
Contextul n care se manifest interaciunile
Exist o interaciune n orice situaie n care obiectele sunt legate ntre ele. Mai exact spus,
vom descoperi interaciuni n colaborarea dintre obiectele care exist n contextul sistemului sau
subsistemului modelat. Mai putem descoperi interaciuni i n contextul unei operaii. n sfrit,
putem identifica interaciuni i n contextul unei clase.
Cel mai adesea, descoperim interaciuni n colaborarea obiectelor care exist n contextul
sistemului sau subsistemului modelat.















Figura 84. Mesaje, legaturi i secvenierea mesajelor

De exemplu, subsistemul Planificarea activitii didactice din cadrul sistemului
informaional al unei faculti este contextul n care instane ale unor clase, precum StatDeFuncii,
PlanDenvmnt, FormaieDeLucru vor interaciona pentru a contribui la rezolvarea
problemei orarului semestrial al grupelor de la fiecare specializare i, de ce nu, al fiecrui profesor
n parte.
CitesteUrmNote()
{ordered}
1:PrelNotMat(n)
f:Foaia_Matricola

n:Note
numr de secven mesaj
obiect legtur obiect
Interaciuni ntre obiecte descoperim i n procesul de implementare a unei operaii. Parametrii
unei operaii, orice variabil obiect local operaiei i orice obiecte globale (dar nc vizibile
operaiei) pot interaciona pentru a materializa algoritmul corespunztor implementrii operaiei.
Astfel, invocarea operaiei suma() care simuleaz adunarea a dou numere mari, fiecare
numr fiind o instan a clasei NumarMare, este evident c poate fi implementat astfel nct
invocarea s aib sintaxa:

nr1.suma(nr2)

ceea ce inseamn interaciune ntre obiectul global nr1, obiectul transmis prin lista de
parametrii ( nr2 ) i un obiect local operaiei, folosit pentru a genera obiectul sum pe care l va
returna operaia suma().
n al treilea i ultimul rnd, descoperim interaciuni n contextul unei clase. Altfel spus, putem
folosi interaciunile pentru a vizualiza, specifica, construi i documenta semantica unei clase.
Revenind la exemplul clasei NumarMare, pentru a ilustra comportamentul obiectelor acestei
clase, putem imagina interaciuni care arat cum colaboreaz atributele acestei clase pentru a
permite ndeplinirea responsabilitilor asumate de clas, la specificare.

Observaie
Putem descoperi interaciuni i n reprezentarea unor componente, noduri sau contexte de
utilizare, fiecare dintre aceste concepte fiind socotit n UML o specie de clasificator.

Obiecte i roluri
Obiectele care particip ntr-o interaciune sunt sau lucruri concrete sau lucruri prototipice. n
calitate de lucru concret, un obiect reprezint un aspect din lumea real. De exemplu, p, o instan
a clasei Persoana poate desemna o persoan particular, ca lucru concret, sau o instan oarecare a
clasei Persoana, ca lucru prototipic.

Observaie
Pentru o colaborare este caracteristic faptul c obiectele participante sunt lucruri
prototipice, care joac roluri particulare, nu obiecte specifice din lumea real.
Dup cum am subliniat deja, n contextul unei interaciuni, putem ntlni instane ale claselor,
componente, noduri i contexte de utilizare. Dei clasele i interfeele abstracte, prin definiie nu
pot avea o instan direct, puem ntlni instane ale lor n interaciuni, ele reprezentnd, de fapt
instane prototipice ale unor descendeni concrei ai clasei abstracte sau ale unei clase concrete
care realizeaz interfaa.
Putem privi o diagram de obiecte ca o reprezentare a aspectelor statice ale unei interaciuni,
care aranjeaz scena pentru interaciune prin specificarea tuturor obiectelor care lucreaz
mpreun. O interaciune merge mai departe, prin introducerea unei secvene dinamice de mesaje
care pot circula de-a lungul legturilor dintre obiecte.

Legturi
O legtur este o conexiune semantic ntre obiecte. n general, o legtur este o instan a
unei asocieri. Aa cum rezult i din Figura 85, n momentul n care o clas are o asociere cu alt
clas, putem avea i o legtur ntre instanele celor dou clase; odat ce exist o legtur ntre
dou obiecte, unul dintre ele poate trimite un mesaj celuilalt.
O legtur specific o cale de-a lungul creia un obiect poate trimite un mesaj altui obiect sau
chiar lui nsui.
De cele mai multe ori, este suficient s specificm faptul c o astfel de cale exist. Dac este
nevoie de mai mult precizie n ceea ce privete aceast cale, putem ornamenta captul potrivit al
legturii cu unul din urmtoarele stereotipuri standard:
<<association>> - specific faptul c obiectul corespunztor este vizibil prin asociere;
<<self>> - specific faptul c obiectul corespunztor este vizibil deoarece el este
executantul operaiei;
<<global>> - specific faptul c obiectul corespunztor este vizibil deoarece aparine
unui domeniu acoperitor;
<<local>> - specific faptul c obiectul corespunztor este vizibil deoarece aparine unui
domeniu local;
<<parameter>> - specific faptul c obiectul corespunztor este vizibil n calitate de
parametru.














Figura 85 Asociere i legtur

Mesaje
Presupunem c avem o colecie de obiecte i un set de legturi care conecteaz aceste obiecte.
Un astfel de model este un model static care poate fi asimilat cu o diagram de obiecte.
Diagramele de obiecte modeleaz starea coleciei de obiecte, la un moment dat i sunt folositoare
atunci cnd dorim s vizualizm, s specificm, s construim sau s documentm o structur
static de obiecte.S presupunem, acum, c dorim s modelm schimbarea strii unei colecii de
obiecte de-a lungul unei perioade de timp.
Dac, prin absurd, am putea imagina un procedeu de fotografiere a coleciei de obiecte, la
intervale succesive de timp, atunci ar trebui s observm: obiecte care schimb mesaje ntre ele,
provoac evenimente i invoc operaii. n plus fa de perspectiva asociat scenariului de mai sus,
ne putem propune vizualizarea explicit a strii curente i a rolului instanelor individuale.
Un mesaj este specificarea unei comunicri ntre obiecte, care transmite informaia necesar
pentru producerea unei activiti. Primirea unei instane mesaj poate fi considerat o instan a
unui eveniment. Ca urmare a formulrii unui mesaj, o aciune rspuns va fi declanat. O astfel de
aciune poate produce o schimbare de stare.
n UML pot fi modelate urmtoarele tipuri de aciuni:
Call invocarea unei operaii a unui obiect; un obiect i poate transmite lui nsui un
mesaj, ceea ce este interpretat ca invocare local a unei operaii;
Return ntoarcerea unei valori la apelant;
Send expedierea unui semnal ctre un obiect;
Create crearea unui obiect;
Destroy distrugerea unui obiect; un obiect se poate, la nevoie, autodistruge.
UML ofer o notaie care permite deosebirea, sub aspect vizual, a acestor tipuri de aciuni,
care pot fi asociate unui mesaj. O prim prespectiv asupra acestei notaii poate fi observat n
Figura 86, care este, anticipnd, o diagram de secven.





















Figura 86. Mesaje i tipuri de aciuni asociate
afectare(financiar)
*
1..*
angajator angajat
Persoana


afectare (d:Departament)
Firma
p:Persoana
:Firma
ruta
create
call
notificare()
<<destroy>>
calculRuta()
setItinerar(i)
<<create>>
c:Client p:AsistentPlanificare
:AgentBilete
send
call (invocare
local)
return
destroy
Figura 86, dei ipotetic conine elementele fundamentale pentru a nelege importana
noiunii de mesaj n reprezentarea interaciunilor dintre obiecte. Obiectul c (de tip Client) creeaz
un obiect anonim de tip AgentBilete (folosind un mesaj asociat cu o aciune stereotipizat
<<create>>); obiectul c apeleaz metoda setItinerar() a obiectului anonim de tip
AgentBilete (care primete ca parametru, un obiect i de tip Itinerar); obiectul anonim apeleaz
propria metod calculRuta() pentru a determina elementele caracteristice ale rutei. Urmtorul
mesaj este asociat cu o aciune de tip return, dup care urmeaz distrugerea obiectului anonim de
ctre obiectul i. n sfrit, avem i un exemplu de trimitere a unui semnal de la c la p.
Cititorul atent i curios simte infuzia de semantic dintr-o astfel de diagram, precum i
numeroasele probleme, nc neclare, asupra crora va trebui s revenim n continuare.

Secvenare
n practica descrierii interaciunilor dintre obiecte, un obiect trimite un mesaj altui obiect;
receptorul, la rndul lui, trimite un mesaj altui obiect .a.m.d. Acest potenial flux de mesaje
formeaz o secven. Orice secven are un nceput, care este localizat ntr-un proces sau fir de
execuie. Secvena poate s fie activ, cel mult ct timp este activ procesul sau firul de execuie.
Fiecare proces i fir de execuie din interiorul unui sistem definete un flux de control distinct
i n interiorul fiecrui flux mesajele sunt ordonate n secvene care in cont de succesiunea lor n
timp. Pentru o mai bun vizualizare a scevenelor de mesaje, n UML putem modela explicit
ordinea de intrare a mesajului, relativ la nceputul secvenei din care face parte, prin prefixarea
mesajului cu un numr de secven, separat cu simbolul : de mesaj. De domeniul uzualului este
s specificm fluxuri de control procedurale, redate folosind o sgeat de tipul celei din Figura
87.











Figura 87. Secven procedural

Mai puin uzuale, dar, evident posibile sunt fluxurile de control plate, care se redau folosind
o sgeat asemntoare celei din Figura 88.















Figura 88. Secven plata

n practica modelrii UML distincia dintre secvena plat i cea procedural este subtil. De
exemplu, modelarea interaciunilor din perspectiva contexte de utilizare se preteaz la utilizarea
secvenelor plate. Odat cu adncirea procesului de rafinare a soluiei vom fi nevoii s folosim i
secvenele procedurale, omniprezente n oferta limbajelor de programare pentru organizarea
fluxurilor de prelucrare.

2.2:Insert(m)
2.2
2:selectN(S)
2.1:m=CalcMed()
s:Student n:Note f:FoaieMa-
ricola
2:generare(o)
1:procesare(p)
p:Persoana o:OreLucrate
f:Fluturas
Crearea, modificarea i distrugerea obiectelor
n majoritatea cazurilor, obiectele care particip ntr-o interaciune exist atta timp ct exist
i interaciunea. Totui, n anumite interaciuni, obiectele pot fi create i/sau distruse n intervale de
timp cuprinse strict ntre nceputul i terminarea interaciunii. La fel stau lucrurile i n cazul
legturilor dintre obiecte. Pentru a indica faptul c un obiect sau o legtur intr ntr-o interaciune
i/sau prsete interaciunea, putem ataa elementului vizat una din urmtoarele constrngeri:

new - specific faptul c instana sau legtura este creat pe timpul execuiei inetraciunii
care o include;
destroyed - specific faptul c instana sau legtura este distrus nainte de terminarea
execuiei interaciunii care o include;
transient - specific faptul c instana sau legtura este creat pe timpul execuiei
interaciunii care o include, dar este distrus nainte de terminarea execuiei.

n sfrit, dac ntr-o interaciune, un obiect suport modificri ale valorilor atributelor lui,
modificri de stare sau de rol, fiecare variant a obiectului poate apare pe aceeai linie a vieii,
variantele diferite putnd fi, eventual, conectate cu mesaje marcate de stereotipul < << << << <become> >> >> >> >.

Reprezentarea unei interaciuni
Am vazut deja faptul c o interaciune pune probleme de semantic i de notaie. Din punct de
vedere semantic, o interaciune poate pune accent pe ordonarea n timp a mesajelor (ceea ce ne
conduce la realizarea de diagrame de secven) sau pe accentuarea organizrii structurale n
interiorul interaciunii, ceea ce conduce la realizarea digramelor de colaborare.
Aceste dou tipuri de diagrame sunt, n mare parte izomorfe, conversia de la un tip la altul
fcndu-se fr pierdere de informaie.
Din punct de vedere al notaiei este important s semnalm prezena i semnificaia liniei
vieii unui obiect ntr-o diagram de secven, element care ofer suport pentru reprezentarea n
timp a existenei unui obiect.
De asemenea, diagramele de colaborare permit modelarea legturilor structurale care exist
ntre obiecte.


4.2. Contexte de utilizare
Elemente introductive
Dei nu au explicitat ntotdeauna acest lucru, specialitii n ingineria softului au acionat
conform principiului: nainte de a realiza un lucru nou, trebui s hotrti cum l vei folosi (=
care este valoarea lui de ntrebuiare)?
Pare de neconceput, dar adevrul este c mult vreme nu s-a sesizat importana covritoare a
problematizrii i formalizrii temeinice a principiului mai sus formulat. Specificare de cerine s-a
fcut, ntr-o form sau alta, dintotdeauna n industria softului. Ceea ce separ optica UML, n ceea
ce privete specificarea cerinelor, de alte limbaje de modelare este unghiul din care se face
specificarea cerinelor. UML spune rspicat: nainte de a gndi la soluia unui sistem soft,
determin, cu maximum de acuratee, tipul utilizatorului acestui sistem soft.
ncerc s sugerez faptul c tipul utilizatorului este o abstracie n care se reflect o serie de
cerine funcionale specifice dar i o serie de cerine aa zis nefuncionale. Un sistem soft
burduit cu cerine funcionale, expuse ignornd cele mai elementare reguli de proiectare a unor
interfee ergonomice, nu va putea nfrunta niciodat un sistem echivalent funcional dar cu
interfaa ergonomic.
Dup cum sugereaz i perspectiva UML asupra arhitecturii unui sistem soft, n centrul
efortului de dezvoltare a soluiei unui sistem soft, utiliznd UML, se afl perspectiva context de
utilizare (use case). Perspectiva context de utilizare va descrie comportamentul unui sistem soft
aa cum este el vzut de ctre end-user-i, analiti i tester-i.
Un element cheie n crearea contextelor de utilizare este abilitatea de a spune ce face contextul
de utilizare fr a specifica nimic despre implementarea lui. Astfel c putem concluziona faptul c
un context de utilizare specific un comportament dorit (de end-user-i), fr a impune nimic relativ
la modul n care va fi implementat acest comportament. Marele ctig al unui astfel de demers
const n faptul c un context de utilizare permite, n egal masur utilizatorilor finali i experilor
n domeniu, s comunice cu specialitii n ingineria softului, care lucreaz la soluia sistemului
soft, n cadrul creia a fost specificat contextul de utilizare.
Pentru moment, un context de utilizare descrie un set de secvene, n care fiecare secven
reprezint interaciunea entitilor din afara sistemului (actorii lui) cu sistemul nsui (i
abstraciile lui eseiale). De fapt, comportamentele astfel specificate sunt funcii de nivel sistem,
utilizate pentru a vizualiza, specifica, construi i documenta comportamentul scontat al sistemului
n timpul fazei de identificare i analiz a cerinelor.
Un context de utilizare reprezint o cerin funcional a sistemului ca ntreg. Ca un
exemplu, un context de utilizare important ntr-o firm care produce automobile este Gestiunea
vnzrilor.
Un context de utilizare implic interaciunea dintre actori i sistem. Un actor reprezint un
set coerent de roluri, pe care utilizatorii contextului de utilizare le joac n timp ce
interacioneaz cu acesta. Poate fi actor o fiin uman, un alt sistem soft sau un anumit tip de
sistem automat, capabil de interaciune.

n majoritatea proceselor de dezvoltare a unor sisteme soft gsim contexte de utilizare care
sunt versiuni specializate ale altor contexte de utilizare, contexte de utilizare care sunt considerate
ca pri ale altor contexte de utilizare i contexte de utilizare care extind comportamentul unor
contexte de utilizare, care definesc miezul/coloana vertebral a comportamentului sistemului.
Pentru a clasifica i organiza comportamentele contextelor de utilizare, n spiritul reutilizrii,
apelm la cele trei tipuri de relaii, mai sus precizate: generalizarea, includerea i extinderea.
Un context de utilizare ndeplinete, n mod normal, o sarcin concret. Din perspectiva unui
actor dat, un context de utilizare poate efectua nite calcule, poate furniza nite rezultate, poate
prelua nite date de intrare, etc.
Contextele de utilizare pot fi identificate la nivelul ntregului sistem, dar i la nivelul
componentelor sistemului (subsisteme, clase, interfee).
n fiecare caz este important s reinem urmtoarea idee: Contextele de utilizare reprezint
comportamentul scontat al sistemului sau al componentelor acestuia, furniznd, n acelai timp,
elemente fundamentale pentru testarea acestor componente n timpul procesului de dezvoltare.
Contextele de utilizare aplicate la nivelul subsistemelor sunt surse ideale pentru testele desfurate
asupra soluiei n curs de elaborare.
Aplicate la nivelul ntregului sistem, contextele de utilizare sunt surse excelente pentru efortul
de integrare i testare a sistemului.
UML furnizeaz o reprezentare grafic simpl pentru actori i contextele de utilizare. Aceast
notaie permite vizualizarea unui context de utilizare separat de realizarea lui i n comuniune cu
alte contexte de utilizare. Fundamentele notaiei aferente contextelor de utilizare sunt prezentate n
Figura 89.

















Figura 89. Notaia UML pentru actori i contexte de utilizare

Concepte UML din sfera contextelor de utilizare
Dup cum am menionat deja, un context de utilizare este o descriere a unui set de secvene de
aciuni, incluznd variante, pe care sistemul le execut pentru a produce un rezultat observabil,
ateptat de un actor; reprezentarea grafic a unui context de utilizare este realizat cu ajutorul unei
elipse.

Numele contextelor de utilizare
Fiecare context de utilizare trebuie sa aib un nume, care l distinge de alte contexte de
utilizare. Acest nume este un ir de caractere care poate fi asimilat cu un nume simplu, dac apare
singur. Dac numele apare prefixat de numele pachetului n care contextul de utilizare este
rezident, atunci vom vorbi despre un nume cu cale. Exemple n Figura 90.

context de utilizare
Decan
actor
nume actor
Consultare
planuri de
invatamant
nume context de utilizare












Figura 90. Numele contextelor de utilizare UML
Contextele de utilizare i actorii
Un actor reprezint un set coerent de roluri pe care utilizatorii unui context de utilizare le
joac cnd interacioneaz cu acesta. n mod obinuit, un actor reprezint un rol pe care o fiin
uman, un dispozitiv periferic sau chiar alt sistem l joac n relaia cu sistemul cruia i este
asociat contextul de utilizare cu care comunic actorul. De exemplu, un lucrtor la o banc ar
putea, abstractizat ca actor, s joace rolul de Agent-de-mprumuturi; dac, pe de alt parte,
suntem interesai s abstractizm rolul unui client n relaia cu banca, putem reflecta asupra unui
actor numit Client. O instan a unui actor reprezint o interaciune individual specific cu
sistemul n cauz. Dei n modelele UML apar actori, acetia nu sunt considerai pri ale
sistemului, fiind rezideni n afara sistemului. Reprezentai grafic sub forma unor omulei stilizai,
actorii suport, atunci cnd este cazul relaia de generalizare, ca n Figura 91.


















Figura 91. Actorii n UML
Actorii pot fi conectai la un context de utilizare numai prin asociere. O asociere ntre un actor
i un context de utilizare precizeaz faptul c ntre aceste entiti exist o relaie de comunicare, n
sensul c fiecare poate trimite sau primi mesaje.
S mai subliniem faptul c, apelnd la mecanismele UML de extensie putem stereotipiza un
actor pentru a introduce o notaie diferit, n ideea c aceasta reprezint o replic vizual mai
adecvat scopurilor noastre de moment.

Contextele de utilizare i fluxurile de evenimente
Un context de utilizare descrie ce face un sistem dar nu specific cum face sistemul ceea ce
are de fcut. n general, n procesul de modelare a soluiei unei probleme, este foarte important
abilitatea de a distinge interfaa unui sistem ( ce face? ) de implementarea lui (cum face?).
Putem specifica comportamentul unui context de utilizare prin descrierea textual a unui flux
de evenimente, suficient de clar pentru ca un neiniiat s l poat nelege uor. Cnd se redacteaz
acest flux de evenimente, trebuie s specificm cum i cnd ncepe i se termin contextul de
utilizare, cnd interacioneaz contextul de utilizare cu actorii i ce obiecte sunt schimbate, fluxul
principal de evenimente, precum i fluxurile alternative de evenimente.
Exemplificm cu un scenariu asociat contextului de utilizare ValidareUtilizator, din cadrul
unui sistem soft care gestioneaz o reea de bancomate.

ClientPersoanaJuridica ClientPersoanaFizica
Client
generalizare
actor
actor
Validare
utilizator

Financiar::PreluarePontaj
nume simplu nume cu cale
Flux principal de evenimente: Contextul de utilizare ncepe n
momentul n care sistemul invit Clientul s introduc codul PIN.
Clientul poate introduce, n acest moment, codul PIN, de la
tastatur. Clientul termin de introdus codul PIN prin apsarea
butonului Enter. Sistemul verific validitatea codului PIN. Dac
codul PIN este valid, sistemul confirm introducerea codului PIN,
ceea ce nseamn terminarea contextului de utilizare.

Flux excepional de evenimente: Clientul poate anula o
tranzacie n orice moment prin apsarea butonului Cancel, fapt
care restarteaz contextul de utilizare. ntr-o astfel de situaie
nu se efectueaz nici o modificare asupra contului Clientului.

Flux excepional de evenimente: Clientul poate terge codul
PIN, n orice moment care precede terminarea introducerii prin
apsarea tastei Enter avnd astfel posibilitatea s reia
introducerea codului PIN.

Flux excepional de evenimente: Dac Clientul introduce un cod
PIN invalid, contextul de utilizare este restartat. Dac acest
lucru se ntampl de trei ori la rnd, sistemul anuleaz ntreaga
tranzacie, mpiedicnd Clientul s mai interacioneze cu
bancomatul timp de 60 secunde.

Obesrvaie
Fluxul de evenimente al unui context de utilizare poate fi specificat n mai multe moduri: text
structurat informal (ca n exemplul de mai sus), text structurat formal (cu pre i post - condiii) sau,
pur i simplu, pseudocod.

Contextele de utilizare i scenariile
n practic exist obinuina de a descrie, la nceput, textual, fluxul de evenimente asociat unui
context de utilizare. Pe msur ce nelegerea cerinelor fa de sistem se rafineaz (=intr n
detalii), se pot utiliza diagrame de interaciune pentru a specifica vizual acest flux de evenimente.
De regul, se poate apela la diagrame de secven pentru specificarea fluxurilor principale de
evenimente i variaiuni ale acestor diagrame pentru a specifica fluxurile excepionale de
evenimente ale unui context de utilizare.
Este de dorit s separm fluxurile principale de fluxurile alternative deoarece un context de
utilizare descrie un set de secvene, nu doar o singur secven i de cele mai multe ori este destul
de dificil s surprindem toate detaliile unui context de utilizare complex ntr-o singur secven.
De exemplu, sistemul informaional al unei instituii de nvmnt superior poate include
contextul de utilizare nmatriculareStudeni. n practic, ns, se tie c operaia de nmatriculare
se poate derula n mai multe ipostaze:

1. Candidaii admii, n urma unei sesiuni de admitere, pot fi nmatriculai, la o
anumit specializare;

2. Studenii admii la aceeai specializare n alte universiti, pot fi nmatriculai, n
anumite condiii;


3. Studenii admii la specializri nrudite ca profil, n aceeai universitate, pot fi
nmatriculai, n anumite condiii, etc.

Este evident faptul c descrierea contextului de utilizare nmatriculareStudeni trebuie s ia
n consideraie mai multe variante, fiecare variant avnd asociat propria secven de aciuni. n
acest caz, fiecare secven se numete scenariu. Vom numi scenariu o secven specific de
aciuni care ilustreaz o variant de comportament a unui context de utilizare. Din alt
perspectiv privind lucrurile, un scenariu este, n relaia cu contextul de utilizare gazd, ceea ce
este un obiect n relaia cu clasa lui definitoare.

Contextele de utilizare i colaborrile
Aa cum am menionat deja, un context de utilizare reprezint comportamentul unui sistem (al
unui subsistem, al unei clase sau interfee) n curs de dezvoltare, fr a specifica modul de
implementare a comportamentului. Exist o explicaie plauzibil a acestui mod de a privi lucrurile:
analiza sistemului, printre ale crui rezultate se afl i specificarea comportamentului
acestuia, trebuie s fac abstracie, cu bun tiin, de aspectele implementaionale, pentru a
feri astfel soluia de efectele, previzibile, ale schimbrilor la nivel implementaional. La
momentul potrivit, contextul, de utilizare va trebui, totui, s beneficieze de o implementare i
n acest scop va trebui identificat familia de clase i alte entiti care, lucrnd mpreun,
implementeaz contxtul de utilizare. Aceast familie de elemente, incluznd att structura
static, ct i structura dinamic este modelat n UML sub forma unei colaborri.
La nivel nalt de abstractizare , putem specifica explicit realizarea unui context de utilizare de
ctre o colaborare ca n Figura 92.














Figura 92. Realizarea unui context de utilizare

Trecerea de la posibilitatea de a asocia unui context de utilizare o colaborare care l realizeaz,
n contextul sistemului, ca ntreg, este o problem nou, care este rezolvat corect dac deciziile
arhitecturale sunt luate n zodia inspiraiei.

Organizarea contextelor de utilizare
Contextele de utilizare pot fi organizate prin gruparea lor n pachete, n acelai mod n care
procedm cu clasele.
Organizarea contextelor de utilizare poate fi realizat i apelnd la relaiile de generalizare,
includere i extindere.
n esen, toate aceste tipuri de relaii sunt utilizate pentru a partaja comportamente comune.

Relaia de generalizare
Generalizarea ntre contexte de utilizare este asemntoare generalizrii dintre clase. Mai
exact, aceasta nseamn c orice context de utilizare copil motenete comportamentul i
semantica contextului de utilizare printe; copilul poate aduga elemente de comportament
noi sau poate suprascrie comportamentul printelui. De asemenea, printele poate fi
substituit de oricare dintre copii lui (dac ne exprimm n termeni de instane).
De exemplu, n sistemul informaional al unei bnci putem avea un context de utilizare
Validare utilizator (responsabil de verificarea identitii unui utilizator). Putem, de asemenea,
avea doi copii specializai ai acestui context de utilizare (Verificare parol i Scanare retin).
Fiecare dintre aceste dou contexte se comport la fel ca Validare utilizator, putnd fi aplicate
oriunde apare Validare utilizator, n plus, fiecare putnd aduga propriul comportament (primul,
prin verificarea unei parole textuale, al doilea prin verificarea ablonului retiniar unic al
utilizatorului).
Notaia pentru relaia de generalizare este cunoscut de la generalizarea ntre clase.

Relaia de includere
O relaie de includere ntre contexte de utilizare se refer la faptul c un context de utilizare
de baz ncorporeaz explicit comportamentul unui alt context de utilizare la o locaie
specificat n baz. Contextul de utilizare inclus nu poate opera singur niciodat, ci doar instaniat
ca parte a unui context de utilizare de baz, care l include.
Folosim relaia de includere pentru a evita descrierea aceluiai flux de evenimente de mai
multe ori, prin descrierea comportamentului comun ntr-un context de utilizare separat, care va fi
inclus n unul sau mai multe contexte de utilizare de baz. Nu mai dezvoltm subiectul deoarece a
beneficiat de o atenie sporit n Capitolul 3. O relaie de includere se reprezint ca o relaie de
dependen marcat cu stereotipul <<include>>. n descrierea asociat contextului de utilizare de
baz, includerea este marcat ca n exemplul de mai jos.
Gestiune
planuri
Consultare
planuri de
nvmnt
colaborare realizare context de utilizare

Fluxul principal de evenimente:
Preluare nume utilizator i parol. include
(Validare parol).
Configurare sesiune.
Start sesiune.

Relaia de extindere
O relaie de extindere ntr contexte de uilizare se refer la faptul c un context de utilizare de
baz ncorporeaz implicit comportamentul unui alt context de utilizare, la o locaie
specificat indirect de contextul de utilizare care realizeaz extinderea.
Folosim relaia de extindere pentru a modela o parte a unui context de utilizare pe care
utilizatorul o percepe ca fiind un comportament opional al sistemului. n acest mod, separm
comportamentul opional de comportamentul imperativ.
O relaie de extindere este redat ca o relaie de dependen, marcat cu stereotipul
<<extend>>. Punctele de extensie pot fi precizate ca simple etichete n fluxul principal de
evenimente, ca mai jos:

Fluxul principal de evenimente:
include (Validare parol).
Configurare sesiune(setare_drepturi_suplimentare).
Start sesiune.

n exemplul de mai sus setare_drepturi_suplimentare este un punct de extensie.
Ideea este c, pentru un utilizator obinuit se face validarea parolei, configurarea standard a
sesiunii i nceperea sesiunii. Pentru un utilizator cu privilegii, va fi executat un context de
utilizare care permite stabilirea resurselor suplimentare necesare utilizatorului.
i despre relaia de extindere am discutat, pe larg, n Capitolul 3.
4.3. Diagrame de contexte de utilizare
Diagramele de contexte de utilizare sunt unul din cele cinci tipuri de diagrame folosite n
UML pentru modelarea aspectelor dinamice ale sistemelor (celelalte patru tipuri sunt: diagramele
de colaborare, diagramele de secven, diagramele hri de stare, diagramele de activitate).
Diagramele de contexte de utilizare sunt eseniale pentru modelarea comportamentului unui
sistem, subsistem sau al unei clase. Fiecare diagram de contexte de utilizare expune un set de
contexte de utilizare, mpreun cu actorii asociai lor, precum i relaiile dintre aceste elemente.

Concepte UML utilizate n sfera diagramelor de contexte
de utilizare
O diagram de contexte de utilizare este un tip de diagram care afieaz proprieti comune
altor tipuri de diagrame: asocierea cu un nume i un coninut grafic care realizeaz un anumit tip
de proiecie ntr-un model. Coninutul grafic deosebete diagramele de contexte de utilizare de
alte tipuri de diagrame.

Coninutul unei diagrame de contexte de utilizare
n mod uzual, diagramele de contexte de utilizare conin:

Contexte de utilizare
Actori
Relaii de dependen, generalizare i/sau asociere.

Ca oricare alt tip de diagram, ele mai pot conine note i constrngeri.
n sfrit, diagramele de contexte de utilizare mai pot conine pachete, folosite pentru a grupa
elementele modelului n uniti mai mari, cu scopul de a mri lizibilitatea modelului.
Uneori, diagramele de contexte de utilizare pot conine i instane ale contextelor de utilizare,
ndeosebi cnd dorim s vizualizm un sistem specific de execuie.

Mod de utilizare
Folosim diagrame de contexte de utilizare pentru a modela aspectele statice ale perspectivei
context de utilizare a unui sistem.
Aceast perspecitv este prima care se angajeaz n captarea comportamentului unui
sistem serviciile vizibile extern, pe care sistemul le furnizeaz n relaia cu mediul su.
Atunci cnd modelm aspectele statice ale perspectivei context de utilizare, ne aflm n una
din urmtoarele situaii:

1. Vrem s modelm contextul unui sistem.
Modelarea contextului unui sistem implic trasarea unei linii n jurul sistemului ca ntreg
i stabilirea actorilor care se afl n afara sistemului i interacioneaz cu el. n acest fel,
vom putea specifica actorii i coninutul rolurilor acestor actori, n dinamica
comportamental a sistemului.
2. Vrem s modelm cerinele fa de un sistem.
Modelarea cerinelor unui sistem implic specificarea a ceea ce sistemul trebuie s fac,
fr a problematiza modul n care sistemul va face ceea ce trebuie s fac. O diagram de
contexte de utilizare, care va proceda n acord cu ideea prezentat n paragraful precedent,
va fi asemenea unei perspective de tip black boxasupra unui sistem.
Trebuie s accentuez, dac n-am fost suficient de explicit, faptul c atunci cnd modelm
contextul unui sistem, preocuparea noastr principal sunt actorii i modul n care
acetia interacioneaz cu sistemul, iar atunci cnd modelm cerinele, preocuparea
noastr principal este de a nu omite nimic din ceea ce ar putea fi important ca
cerin fa de sistemul soft.

Modelarea contextului unui sistem
n UML putem modela contextul unui sistem cu ajutorul diagramelor de contexte de utilizare,
n care punem accent pe organizarea actorilor care interacioneaz cu sistemul. Decizia referitoare
la includerea sau nu a unui actor este important deoarece de ea depinde specificarea sau nu a unei
clase de elemente (utilizatori, alte sisteme) care interacioneaz cu sistemul, aceast specificare
avnd n vedere, n mod sistematic, eliminarea redundanelor dar i asigurarea optimului din punct
de vedere al cerinelor.
Paii, teoretici, de urmat cnd modelm contextul unui sistem sunt:
1. Identificarea actorilor care vor interaciona cu sistemul, mprindu-i de regul, n
mai multe categorii:
actori care au nevoie de ajutor din partea sistemului pentru a-i ndeplini
propriile sarcini;
actori implicai n execuia funciilor de baz ale sistemului;
actori care interacioneaz cu componente hard externe sau alte sisteme soft;
actori care execut funcii secundare ale sistemului (administrare i ntreinere).
2. Organizarea actorilor care partajeaz similariti, ntr-o ierarhie bazat pe
generalizare/specializare.

3. Acolo unde este n folosul sporirii lizibilitii diagramei, se poate apela la
stereotipizarea actorilor.

4. Pentru fiecare actor care apare ntr-o diagram de contexte de utilizare, se va
specifica modul de comunicare cu contextele de utilizare ale diagramei.
Un exemplu de modelare a contextului unui sistem, n Figura 93.
n Figura 93 este prezentat o viziune ipotetic asupra contextului unui subsistem de asistare a
managementului la nivel de departament, ntr-o instituie de nvmnt superior.

Modelarea cerinelor fa de un sistem soft
Cerinele fa de un sistem soft pot fi exprimate n diferite forme care merg de la text
nestructurat (forma cea mai apropiat de limbajul natural) pn la exprimarea ntr-un limbaj cu
exigene formale (forma cea mai adecvat dac se dorete rigoare de nivel nalt, acceptnd preul
pltit prin ndeprtarea de limbajul natural) i evident orice altceva care penduleaz ntre aceste
dou extreme.

Aproape toate cerinele fa de un sistem soft pot fi exprimate utiliznd contextele de utilizare
i diagramele UML de contexte de utilizare.












Figura 93. Modelarea contextului unui sistem

Paii pe care, n principiu, trebuie s-i urmm cnd model, cerinele fa de un sistem soft
sunt:

1. Stabilirea contextului sistemului, prin identificarea actorilor care interacioneaz cu
el.
2. Pentru fiecare actor n parte se va identifica comportamentul pe care acesta l
ateapt de la sistem / sau, altfel spus, cerinele acestuia fa de sistem.
3. Comportamentele care corespund satisfacerii unor sisteme unitare de cerine sunt
grupate iar gruprile rezultate sunt contexte de utilizare avnd un nume sugestiv.
4. Elementele de comportament folosite n cadrul mai multor contexte de utilizare sunt
desemnate ca fiind contexte de utilizare noi; de asemenea, elementele de
comportament care extind opional comportamentele unor contexte de utilizare sunt
desemnate ca fiind contexte de utilizare noi, partajate de ctre mai multe contexte
de utilizare.
5. Modelai contextele de utilizare, actorii i relaiile aferente lor ntr-o diagram de
contexte de utilizare.
6. Adugai, dac considerai util, note care declar cerine non-funcionale; astfel de
note pot fi ataate i ntregului sistem.

Un exemplu de modelare a cerinelor fa de sistem, n Figura 94

Scurt not, relativ la ingineria direct i invers a diagramelor UML
Ingineria direct este procesul de transformare a unui model n cod, n conformitate cu
limbajul ales pentru implementare, transformare realizat de ctre un tools care nelege
modelarea UML.
Ingineria invers este operaia prin care, pornind de la cod, putem obine modelul UML
asociat.
Ambele operaii urmresc asigurarea unei mapri benefice a soluiei UML a unei probleme,
peste soluia-limbaj de implementare int i invers. Avantajele sunt evidente, att n cazul
ingineriei directe ct i n cazul ingineriei inverse.

Secretar
tiinific
Subsistem asistare management la
nivel de departament
ef
catedr
Persoana
Asistare
management
operativ
Automatizare
activiti de
secretariat
Gestiune relaii cu
alte departamente
i instituii
Secretar
Revenind la lumea contextelor de utilizare, trebuie s spunem c, spre deosebire de alte tipuri
de diagrame (diagrame de clase, diagrame de stare, etc., candidate evidente la ingineria direct i
invers, avnd corespondene la nivelul sistemului executabil), diagramele de contexte de utilizare
sunt puin diferite, n sensul c ele mai mult reflect dect specific implementarea unui sistem,
subsistem, etc. Un context de utilizare descrie cum se comport un element, nu cum este
implementat comportamentul, motiv pentru care nu poate fi supus, n mod natural unei operaii de
inginerie direct sau invers.

4.4. Diagrame de interaciune
Diagramele de secven i diagramele de colaborare numite, mpreun, diagrame de
interaciune, sunt, dup cum am mai spus, dou din cele cinci tipuri de diagrame folosite de UML
pentru modelarea aspectelor dinamice ale sistemelor.

Diagramele de interaciune sunt importante nu doar pentru modelarea aspectelor dinamice ale
unui sistem ci i pentru obinerea codului executabil, att prin inginerie direct ct i prin ingineria
invers.































Figura 94. Modelarea cerinelor fa de un sistem


Conceptele vehiculate n procesul de elaborare i
nelegere a diagramelor de interaciune

O diagram de interaciune expune o interaciune, determinat de o mulime de obiecte,
mpreun cu relaiile dintre ele, inlcuznd i mesajele care pot fi schimbate ntre aceste obiecte.
O diagram de secven este o diagram de interaciune care pune accent pe ordonarea n
timp a mesajelor. Ca formalism de reprezentare, o diagram de secven poate fi asimilat cu un
tabel care expune obiectele aranjate de-a lungul axei absciselor i mesajele ordonate dup evoluia
n timp de-a lungul axei ordonatelor.
O diagram de colaborare este o diagram de interaciune care pune accent pe organizarea
structural a obiectelor care trimit sau recepioneaz mesaje. Ca formalism de reprezentare, o
diagram de colaborare este o colecie de noduri i arce.
Asistare
management la
nivel operativ
Asistafre activiti
consiliu profesoral
Asistare ntocmire
orar
Asistare admitere
Subsistem asistare management la nivel de decanat
Automatizare
activiti de
secretariat
Gestiune relaii cu
alte instituii
Validare
utilizator
Dependene
<<include>>
Decan
Prodecan
Cancelar
Secretar
S mai precizez, n aceast faz a prezentrii, faptul c, asemenea tuturor tipurilor de
diagrame, diagramele de interaciune au un nume i un coninut grafic, care, de altfel, face
distincia ntre diagramele de interaciune i alte tipuri de diagrame.

Coninutul unei diagrame de interaciune
n mod uzual, o diagram de interaciune conine:

obiecte
legturi
mesaje

Atunci cnd este cazul, o diagram de interaciune mai poate conine note i constrngeri.

Diagrame de secven
Cum am mai spus, o diagram de secven pune accent pe ordonarea n timp a mesajelor. Cum
se poate vedea i n Figura 95, realizarea unei diagrame de secven presupune, plasarea, pentru
nceput, a obiectelor care particip la interaciune, n partea de sus a diagramei, de-a lungul axei
absciselor, figurat simbolic.























Figura 95. Diagram de secven

n mod normal, obiectul cel mai din stnga va fi obiectul care declaneaz interaciunea,
urmat, spre dreapta, de celelalte obiecte, n ordinea participrii la interaciune. Urmeaz, precizarea
mesajelor pe care aceste obiecte le expediaz i le recepteaz, de-a lungul axei ordonatelor,
figurat, de asemenea, simbolic.
Alinierea mesajelor se face, de sus n jos, n ordinea cresctoare a timpului n care sunt emise,
obinndu-se o redare vizual clar a fluxului de control, n timp.
Diagramele de secven au dou caracteristici care le deosebesc de diagramele de colaborare.
Mai nti, este vorba despre linia vieii obiectului. O linie a vieii unui obiect este o linie
vertical ntrerupt, care reprezint existena unui obiect de-a lungul unei perioade de timp.
Majoritatea obiectelor care apar ntr-o diagram de interaciune vor avea durata de via ct timp
exist interaciunea, prin urmare, aceste obiecte vor fi aliniate n partea de sus a diagramei; pentru
aceste obiecte linia vieii acoper toat verticala diagramei, ncepnd de la obiect n jos. Pot exista
i obiecte care sunt create pe timpul interaciunii, la primirea unui mesaj purtnd marca
stereotipului < << << << <create> >> >> >> >. Pentru aceste obiecte linia vieii ncepe din momentul receptrii
mesajului (a se observa linia vieii pentru obiectul m, n Figura 95). Obiectele pot fi distruse pe
timpul interaciunii. Linia vieii pentru un astfel de obiect se termin odat cu primirea mesajului
purtnd marca stereotipului < << << << <destroy> >> >> >> >, moment marcat prin prezena unui X lrgit, care
puncteaz terminarea liniei vieii (a se observa linia vieii pentru obiectul m, n Figura 95).
n al doilea rnd, este vorba despre focalizarea controlului pe un obiect. Focalizarea
controlului pe un obiect este indicat printr-un dreptunghi nalt i de lime mic, prin care se
T
i
m
p
u
l

return
<<destroy>>
insert(m)
prelNote(m) setDatePer()
<<create>>
s:Student m:FoaieMatricola n:Note
linia vieii
f:FluxFoiMatricole
Obiecte
figureaz perioada de timp n care un obiect execut o aciune, direct sau dintr-o procedur
subordonat. Partea de sus a dreptunghiului coincide cu startul aciunii; partea de jos este asociat
cu terminarea aciunii i poate fi nsoit de un mesaj de tip return (cum se ntmpl n Figura 95,
la terminarea aciunii obiectului n; de observat i forma particular a sgeii n cazul unui mesaj de
tip return).
Imbricarea focalizrii controlului (datorit apelurilor recursive, apelului unei self-operaii,
etc.) poate fi redat cu ajutorul unor dreptunghiuri desenate uor la dreapta focus-ului printe, ca n
Figura 96.












Figura 96. Imbricarea focalizrii controlului

n sfrit, monopolizarea controlului de ctre o aciune (n sensul c aceasta nu poate pasa
controlul aciunii altui obiect) se indic, dac se consider necesar, ca un dreptunghi al crui
interior poate suporta efectul de umbrire.

Diagrame de colaborare
O diagram de colaborare pune accent pe organizarea obiectelor care particip la o
interaciune. Dup cum se poate vedea i n Figura 97, realizarea unei diagrame de colaborare
poate ncepe prin reprezentarea obiectelor care particip la interaciune, n calitate de vrfuri ale
unui graf. n al doilea rnd, se adaug legturile dintre obiecte, n calitate de arce ale grafului. n
sfrit, legturile n cauz sunt mbogite semantic prin ataarea de mesaje pe care obiectele le
trimit sau le primesc.
n acest fel, persoana care urmrete o diagram de colaborare beneficiaz de indicaii vizuale
clare relativ la fluxul de control al interaciunii, fr a pierde din vedere organizarea structural a
obiectelor care colaboreaz.




















Figura 97. Diagram de colaborare

Diagramele de colaborare au dou caracteristici care le deosebesc de diagramele de secven.
Mai nti, este vorba de indicarea modului n care un obiect este legat de altul (=calea de acces la
obiect).
print()
<<global>
2.1:prelNote(m)
2.2
2.3.1:<<destroy>>
<<global>> 2.3:insert(m)
2:setDatePers()
1:<<create>>
s:Student
m:FoaieMatricola
n:Note
f:FluxFoiMatricole
n acest scop, putem ataa legturii un stereotip de cale la captul unei legturi, indicnd
natura vizibilitii obiectului vizat, pentru obiectul care expediaz mesajul. n Figura 97, f este
global pentru m, de exemplu.
n al doilea rnd, este vorba de sistemul de secvenare prin ataare de numere de secven
explicite. Pentru a specifica ordonarea n timp a mesajelor, mesajul este prefixat cu un numr
(ncepnd cu mesajul numrul 1), incrementnd cu o unitate prefixul fiecrui mesaj nou (2,3,...).
n situaia n care avem imbricare de mesaje, se apeleaz la numerotarea zecimal Dewey
(ceea ce nseamn c, dac 1 este primul mesaj, atunci 1.1 poate fi primul mesaj imbricat n 1, 1.2
este al doilea mesaj imbricat n 1, etc. ). Se poate vizualiza imbricarea mesajelor pe oricte nivele
dorim. Dup cum se vede i n Figura 97, de-a lungul aceleeai legturi putem reprezenta mai
multe mesaje (eventual cu direcii de expediere diferite) dar avnd numere de secven unice.
De cele mai multe ori, n practic modelm fluxuri de control secveniale. Atunci cnd este
cazul , putem modela i fluxuri de control mai complexe (iteraii sau ramificri). O iteraie
nseamn o secven repetat de mesaje. Pentru a modela o iteraie, trebuie s prefixm numrul de
secven al mesajului cu o expresie iteraie de tipul [i:=1..n] sau, pur i simplu * dac dorim
s semnalm prezena iteraiei fr a specifica alte detalii.
O iteraie indic faptul c mesajul vizat i orice mesaj imbricat vor fi repetate n conformitate
cu expresia asociat iteraiei.
Pentru a indica mesaje cu execuie condiionat, mesajele n cauz pot avea numrul de
secven prefixat cu o clauz de condiie, de tipul [x>0]. Un mesaj alternativ va avea acelai
numr de secven, dar prefixat de o condiie n relaia de SAU EXCLUSIV cu celelalte mesaje
avnd acelai numr de secven.
UML nu impune o anumit sintax pentru expresiile din interiorul parantezelor drepte. Putem
folosi convenii pseudocod sau sintax specific unui anumit limbaj de programare.

Echivalen semantic
Dat fiind faptul c i propun s modeleze acelai tip de comportament (interaciunile dintre
obiecte), diagramele de secven i diagramele de colaborare sunt echivalente semantic. Ca
urmare, conversiile de la un tip de diagram la altul sunt posibile, fr a pierde informaie
esenial. Aceast posibilitate este probat i de compararea diagramelor prezentate n Figurile 95
i 97. Exist, totui, elemente de vizualizare specifice fiecrui tip de diagram, care ne pot
convinge s optm pentru o reprezentare sau alta.

Mod de utilizare
Aa cum, probabil, s-a neles, folosim diagramele de interaciune pentru a modela aspectele
dinamice ale unui sistem. Aceste aspecte dinamice se pot referi la interaciunea dintre orice tip de
instan, a oricrei perspective a arhitecturii sistemului (instane ale claselor, inclusiv clase active,
interfee, componente i noduri).
Cnd modelm aspectele dinamice ale unui sistem, folosind diagrame de interaciune, putem
face acest lucru n contextul sistemului ca ntreg, n contextul unui subsistem, n contextul unei
operaii sau n contextul unei clase. De asemenea, putem asocia diagrame de interaciune
contextelor de utilizare (pentru a modela scenariile) i colaborrilor (pentru a modela aspecte
dinamice ale unor familii de obiecte.)
Deja ne amintim faptul c atunci cnd modelm aspecte dinamice ale unui sistem, folosim
diagrame de interaciune n dou moduri.
1. Pentru a modela fluxurile de control prin ordonarea n timp
Evident, dac optm pentru aceast variant, operm cu diagrame de secven. Modelarea
unui flux de control prin ordonarea n timp pune accent pe transmiterea mesajelor innd
cont de desfurarea lor n timp, ceea ce este un mod particular, util, de vizualizare a
comportamentului dinamic n contextul unui scenariu al unui context de utilizare. De
asemenea, diagramele de secven se descurc mai bine dect diagramele de colaborare
cnd este vorba de vizualizarea iteraiilor i ramificaiilor simple.

2. Pentru a modela fluxurile de control punnd accent pe organizare.
n acest caz, operm cu diagrame de colaborare. Modelarea unui flux de control, punnd
accent pe organizare, presupune vizualizarea relaiilor structurale dintre instanele aflate
n interaciune, relaii materializate prin legturi de-a lungul crora pot fi transmise
mesajele. Diagramele de colaborare se descurc mai bine dect diagramele de secven,
cnd este vorba de vizualizarea iteraiilor i ramificaiilor complexe, precum i cnd este
vorba de vizualizarea fluxurilor de control concurente, multiple.

Modelarea fluxurilor de control prin ordonarea n timp
Pentru a modela un flux de control prin ordonarea n timp, n principiu, avem de parcurs
urmtorii pai:
1. Stabilirea contextului interaciunii (sistem, subsistem, operaie, clas, un scenariu al
unui context de utilizaresau o colaborare);
2. Stabilirea participanilor la interaciune, prin identificarea obiectelor care joac un
rol n interaciune. Aezarea lor n partea de sus a diagramei de secven, de la stnga
la dreapta, amplasnd obiectele cele mai importante n stnga;
3. Stabilirea liniei vieii pentru fiecare obiect. n majoritatea situaiilor, obiectele
persist pe toat durata interaciunii. n cazul obiectelor care sunt create i distruse pe
timpul interaciunii, se stabilete linia vieii n funcie de momentele naterii i
morii lor, momente indicate prin mesaje stereotipizate corespunztor;
4. ncepnd cu mesajele care iniiaz interaciunea, se reprezint mesajele
ulterioare, de sus n jos, ntre liniile vieii corespunztoare emitorului i
receptorului, indicnd proprietiile fiecrui mesaj (proprieti necesare pentru a
explica semnatica interaciunii n cauz);
5. Dac este nevoie s vizualizm imbricarea mesajelor sau momentele n care este
preluat controlul execuiei, linia vieii obiectului este ornamentat cu simbolul
care indic focalizarea controlului pe obiect;
6. Dac este nevoie s indicm constrngeri de timp sau de spaiu, ornamentm
mesajele vizate cu marcaje de timp (o etichet amplasat sub sgeata-mesaj) i
atam constrngerile de timp i/sau spaiu adecvate;
7. Dac exigenele de formalizare sunt sporite, atunci fiecare mesaj poate avea
ataate precondiii i postcondiii.

O diagram de secven poate modela i expune un singur flux de control. n practic putem
avea i mai multe diagrame de interaciune, dintre care una este principal iar celelalte reprezint
fluxuri alternative sau fluxuri care corespund tratrii unor excepii.
Putem folosi pachete pentru a organiza aceste colecii de diagrame de secven, dnd fiecrei
diagrame un nume sugestiv i unic. n Figura 98, se prezint diagrama de secven care specific
fluxul de control presupus de iniierea unei convorbiri telefonice ntre dou persoane.






















Figura 98. Modelarea unui flux de control prin ordonarea n timp a mesajelor

Comentnd, sumar, semantica Figurii 98, s observm c secvena ncepe cu ridicarea
receptorului de ctre obiectul s, ceea ce nseamn trimiterea mesajului ridicareReceptor ctre
obiectul anonim :Switch. Apoi, pe rnd, obiectul :Switch activeaz tonul de apel pentru obiectul s,
care itereaz pe formarea numrului (simbolul * care prefixeaz mesajul formareNumr indic
iteraia). S mai observm c mesajul formareNumr cere un marcaj de timp (timpFormare)
asociat cu o constrngere. Evident, aceast diagram de secven nu ne spune ce se ntmpl dac
nu este respectat constrngerea asociat marcajului de timp. ntr-o alt viziune, diagrama ar
trebui s includ o construcie branch. Revenind, n caz de succes, la formarea numrului, oiectul
conectare(r)
conectare(r,s)
conectare(s)
ridicareRec
suna()
<<create>>
{timpFormare<30 sec}
rutareApel(s,n)
timpFormare
*formareNumar(d)
activareTonApel()
ridicareReceptor
s:Apelant :Switch
c:Conversatie
r:Apelat
s,r pot schimba informatii numai
dupa ce sunt ambii conectati
:Switch se autoapeleaz (prin mesajul rutareApel() ) pentru a deschide un circuit de apel pentru
numrul format. Tot obiectul :Switch creeaz obiectul c, cruia i deleg, practic, restul lucrului;
considernd c am dezvoltat suficient tema nu mai insist. A mai sublinia doar faptul c, ntre
obiectele din aceast interaciune, se schimb att mesaje sincrone (de exemplu,
activareTonApel()) ct i mesaje asincrone (de exemplu, ridicareReceptor).

Modelarea fluxurilor de control prin organizare
Pentru a modela un flux de control prin organizare, n principiu avem de parcurs urmtorii
pai:
1. Stabilirea contextului interaciunii (sistem, subsistem, operaie, clas, un scenariu al
unui context de utilizare sau o colaborare);
2. Stabilirea participanilor la interaciune, prin identificarea obiectelor care joac un
rol n interaciune. Amplasarea lor pe diagrama de colaborare, asemenea unor noduri
ntr-un graf; plasarea obiectelor mai importante n centrul diagramei i plasarea n jurul
lor a celorlaltor obiecte;
3. Stabilirea proprietilor iniiale ale tuturor obiectelor mai sus menionate. Dac
valorile atributelor, valorile etichetate, starea sau rolul vreunui obiect se schimb n
mod semnificativ pe timpul interaciunii, amplasai o copie a obiectului pe diagram,
actualizai-i valorile proprietilor i conectai-l de vechea stare prin mesaje
stereotipizate cu < << << << <become> >> >> >> > sau < << << << <copy> >> >> >> >, numerotate corespunztor.
4. Specificai legturile ntre aceste obiecte, legturi de-a lungul crora vor circula
mesaje;
4.1. Mai nti, reprezentai legturile de tip asociere; aceste legturi sunt foarte
importante deoarece reprezint conexiuni structurale.
4.2. Apoi, reprezentai alte tipuri de legturi i stereotipizai-le corespunztor,
pentru a specifica explicit cum se leag aceste obiecte ntre ele (< << << << <global> >> >> >> > i
< << << << <local> >> >> >> >);
5. ncepnd cu mesajul care iniiaz interaciunea, numerotai fiecare mesaj; n
cazul imbricrii se folosete numerotarea zecimal Dewey, chestiune la care m-am
referit deja n paragraful 4.4;
6. Dac este nevoie s indicm constrngeri de timp sau de spaiu, vom ornamenta
mesajele vizate cu marcaje de timp (o etichet amplasat sub sgeata mesaj) i atam
constrngerile de timp i/sau spaiu adecvate;
7. Dac exigenele de formalizare cresc, putem ataa precondiii i postcondiii mesajelor.

La fel ca n cazul diagramelor de secven, o diagram de colaborare poate expune un singur
flux de control. n practic putem avea i mai multe diagrame de colaborare, dintre care una este
principal iar celelalte vor reprezenta fluxuri alternative sau fluxuri care corespund tratrii unor
excepii.
n Figura 99 se prezint un exemplu de diagram de colaborare care specific fluxul de
control presupus de nregistrarea unui elev ntr-o coal, punnd accent pe relaiile structurale
dintre obiecte.



















Figura 99. Modelarea unui flux de control prin organizare

{asociation} {asociation}
3.3:adaug(e)
3.2:adaug(e)
2:inmatriculare(s)
consultOrar()
{self}

1:<<create>>
3:inreg()

<<local>>
s:Secretar :Scoala
e:Elev

inregistrat=False
c1:Curs c2:Curs
e:Elev

inregistrat=True

Scurt not relativ la ingineria direct i invers a
diagramelor de interaciune.
Ingineria directa (=obinerea codului pornind de la model) este posibil pentru ambele tipuri
de diagrame de interaciune, ndeosebi, atunci cnd contextul diagramei este o operaie. Cantitatea
i acurateea codului generat depinde att de inteligena softului care proceseaz modelul (n
cazul nostru diagrama de interaciune) ct i de cantitatea i acurateea informaiei coninut de
model.
Este previzibil faptul c ne aflm ntr-un stadiu de abstractizare n care mai sunt nc muli
pai de fcut pentru a mapa eficient modelul pe codul care l implementeaz.
Ingineria invers (=crearea modelului pornind de la cod) este, de asemenea, posibil, pentru
ambele tipuri de diagrame de interaciune, ndeosebi atunci cnd codul n cauz este
implementarea unei operaii.
4.5. Diagrame de activitate
O diagram de activitate este, n esen, o schem care descrie fluxul de control, n procesul
trecerii de la o activitate la alta. Folosim diagrame de activitate pentru a modela aspecte
dinamice ale sistemelor. n cele mai multe situaii, aceasta nseamn modelarea pailor
secveniali (uneori concureniali) ai unui proces de calcul.
De asemena, putem folosi diagrame de activitate pentru a modela trecerea unui obiect dintr-
o stare n alta, prin punctele specifice fluxului de control.
Diagramele de activitate pot fi utilizate pentru a vizualiza, specifica, construi i
documenta aspecte dinamice ale unei societi de obiecte sau pentru a modela fluxul de
control specific unei operaii. n vreme ce diagramele de interaciune pun accent pe fluxul de
control fundamentat pe trecerea, ntr-o anumit ordine, de la un obiect la altul, diagramele de
activitate pun accent pe fluxul de control care urmrete trecerea, ntr-o anumit ordine, de
la o activitate la alta. Prin activitate desemnm o prelucrare neatomic, n curs de desfurare
n interiorul unei maini cu stri. Calculatoarele reale sunt exemple remarcabile de maini cu
stri, privite, de exemplu, din punct de vedere al modului n care funcioneaz procesorul. Ideea de
neatomic subliniaz faptul c din punct de vedere al mainii cu stri pe care se mapeaz activitatea,
aceasta poate fi descompus. n ultim analiz, activitile sunt secvene de aciuni atomice
(nentreruptibile din punct de vedere al modului n care funcioneaz maina cu stri) care au ca
rezultat schimbri n starea sistemului sau returnarea unei valori. Diagramele de activitate sunt
importante nu doar pentru modelarea aspectelor dinamice ale unui sistem ci i pentru construirea
sistemelor executabile prin inginerie direct sau invers.

Concepte folosite n realizarea diagramelor de activitate
Prin cele spuse mai sus am anticipat, deja, faptul c o diagram de activitate expune un
anumit flux de activiti. Am menionat deja ce se nelege prin activitate i prin aciune.
Din punct de vedere al reprezentrii, o diagram de activitate poate fi privit ca o colecie de
noduri i arce.
Pentru conformitate, s menionm i faptul c o diagram de activitate, asemenea celorlaltor
tipuri de diagrame, are un nume i un coninut grafic specific.

Coninutul unei diagrame de activitate
n mod vizual, o diagram de activitate conine:

stri de activitate i stri de aciune;
tranziii;
obiecte.

n esen, o diagram de activitate este o proiecie a elementelor care pot fi gsite ntr-un graf
de activitate, care este un caz particular de main de stare, n care toate tranziiile sunt
declanate de terminarea activitiilor n starea surs.
Deoarece o diagram de activitate este un gen de main de stare, va avea toate caracteristicile
unei maini de stare. Aceasta nseamn c diagramele de activitate pot conine stri simple i
compuse, ramificri (specifice unor prelucrri secveniale sau paralele), etc.
Evident, asemenea tutror celorlaltor diagrame, diagramele de activitate mai pot conine i
constrngeri.

Stri de aciune i stri de activitate
n fluxul de control modelat de o diagram de activitate, se ntmpl diferite lucruri. Se pot
evalua expresii pentru a seta valorile unor atribute sau pentru a returna o valoare. Se poate apela o
operaie a unui obiect, se poate trimite un semnal unui obiect, se poate crea sau distruge un obiect.
Aceste operaii atomice, executabile pe un calculator real, se numesc stri de aciune
deoarece sunt stri ale sistemului, fiecare dintre ele reprezentnd execuia unei aciuni.
O stare de aciune se reprezint ca n Figura 100.












Figura 100. Stri de aciune

Strile de aciune nu pot fi descompuse. Mai mult chiar, strile de aciune sunt atomice, ceea
ce, la modul consistent, nseamn c chiar dac apar evenimente, ele nu pot fi ntrerupte.
Pe de alta parte, strile de activitate pot fi, ulterior descompuse, activitatea lor putnd fi
reprezentat de alte diagrame de activitate. Strile de activitate nu sunt atomice, ceea ce nseamn
c pot fi ntrerupte i execuia lor are durat n timp.
Dup cum se vede n Figura 101, nu exist deosebire de notaie esenial ntre strile de
aciune i activitate, cu excepia faptului c starea de activitate poate conine elemente adiionale,
precum: aciunile iniiale i finale sau specificrile de submaini.

Observaie
Mainile de stare sunt concepte importate n UML pentru a modela aspectele dinamice ale
unui sistem, punnd accent pe fluxul activitilor sau pe strile poteniale ale obiectelor i
tranziiile dintre aceste stri.
Sistemele de complexitate mare, pentru a fi nelese i manipulate mai uor, apeleaz la
submaini, ca abstracii care urmeaz s suporte un proces de rafinare ulterior.

Tranziiile
n momentul n care o aciune sau o activitate este terminat fluxul de control este preluat de
urmtoarea aciune sau activitate. Trecerea de la o stare la alta se numete tranziie i se
reprezint ca o linie simpl orientat (a se vedea Figura 101).
Semantic vorbind, acest gen de tranziii, se numesc tranziii fr declanator sau de
terminare, deoarece controlul trece de la starea surs la starea destinaie de ndat ce
aciunea/activitatea din starea surs este terminat.
















Figura 101. Reprezentarea tranziiilor n UML

Selectare etaj
Start
aciuni simple
I:=I+1
V[I]:=I+10
Expresii
starea de start
starea final
stri de aciune
tranziii
n momentul n care aciunea unei stri surs date este terminat, se va executa aciunea
specific ieirii, dac exist vreuna. Dup care, necondiionat, are loc tranziia ctre urmtoarea
aciune sau activitate. Urmeaz executarea aciunii specifice intrrii n noua stare (dac exist) i
executarea aciunii/activitaii asociate noii stri, etc. Exist situaii n care fluxul de control
evolueaz nedefinit, dar exist i foarte multe situaii n care acesta nceteaz la ntlnirea unei
stri finale.
Notaiile pentru starea iniial i starea final pot fi observate n Figura 101.

Ramificarea (branching) i unirea (merge)
Tranziiile secveniale, simple, sunt destul de obinuite, dar nu sunt singurele ntlnite n
procesul de modelare a fluxurilor de control. La fel ca n cazul schemelor logice (hrile de fluxuri
flowchart-uri), putem apela la ramificri pentru a specifica tranziii alternative, ghidate de o
anumit expresie boolean. O ramificare, se introduce, din punct de vedere al notaiei, ca un romb;
poate avea o singur tranziie la intrare i dou sau mai multe tranziii la ieire. Pe fiecare tranziie
de ieire se indic o expresie boolean, evaluat la intrarea n ramificare. Evident, expresiile
boolene asociate tranziiilor care ies dintr-o ramificare (numite i expresii de gard) trebuie s fie
mutual exclusive. Un exemplu, n Figura 102.
Se mai adaug i faptul c simularea unei iteraii este destul de simpl, folosind ramificarea.


















Figura 102. Ramificarea ntr-o diagram de activitate

Diagrama din Figura 102 poate fi completat, ca semantic i din punct de vedere al notaiei,
ca n Figura 103.





















Figura 103. Un exemplu complet de ramificare

unire (merge, n englez)
[else]
[exist suma]
Do verificareCont(s)
Do afisareStareCont()
Do tranzactie(s)
ramificarea
(branch, n englez)
expresii de gard
[exista suma] [else]
Do verificareCont(s)
Do afisareStareCont() Do tranzactie(s)
Bifurcare (fork) i imbricare (join)
Tranziiile secveniale i ramificrile sunt elementele cel mai frecvent ntlnite n diagramele
de activitate. Cu toate acestea, att n modelarea fluxurilor de lucru dintr-o organizaie, ct i n
anumite tipuri de aplicaii, care mizeaz pe multitasking, apare problema fluxurilor de activiti
concurente. n UML, putem utiliza o bar de sincronizare pentru a specifica bifurcarea i
imbricarea fluxurilor de control paralele. O bar de sincronizare se red ca o linie orizontal sau
vertical, ngroat, dup cum se vede i n Figura 104, n care prezint un exemplu dintr-o lucrare
de licen a unui fost student.



















Figura 104. Diagrama de activitate n cazul unui osp bazat pe pizza

Diagrama din Figura 104 ne indic posibilitatea ca activitiile GtirePizza, PreparareSos i
DestupareSticlVin s se desfoare n paralel, deci sunt introduse folosind bifurcaia. Dintre
aceste trei activiti, care pot avea fire de execuie paralele (ca s mai colorm puin expunerea),
dou dintre ele (GtirePizza i PreparareSos) trebuie s fie terminate nainte de a se trece la
combinare (de aici necesitatea primei mbinri).
Tot n Figura 104 se mai observ i posibilitatea, natural, de altfel, de a introduce fire de
execuie condiionate.
Participarea la osp poate s aib succes i cu sau fr vin, conform diagramei din Figura
104.

Culoare
Dup cum s-a putut deduce din cele spuse pn acum, o diagram de activitate ne spune ce se
ntmpl n sistem, dar nu ne ofer indicii relativ la clasa responsabil pentru fiecare activitate. O
modalitate UML de a furniza aceste informaii este etichetarea fiecrei activiti cu numele clasei
sau persoanei responsabile de activitatea respectiv (persoana, n cazul unei diagrame care
modeleaz fluxurile de lucru ntr-o organizaie). Soluia aceasta, ns, are dezavantajul c nu pune
ntr-o lumin corespunztoare comunicarea dintre obiecte.
De aceea, n UML se poate folosi i tehnica culoarelor. Folosirea acestei tehnici presupune
aranjarea diagramei de activitate n zone verticale (culoare) separate prin linii.
Fiecare culoar abstractizeaz, ntr-un anumit sens, responsabilitile unei clase particulare sau
ale unui anumit departament al organizaiei. Atunci cnd sunt folosite, culoarele combin
descrierea logic dintr-o diagram de activitate cu descrierea responsabilitilor, mai atent pus n
lumin de ctre diagramele de interaciune. Un exemplu, n Figura 105.
Se poate concluziona c diagramele de activitate devin folositoare n combinaie cu alte
tehnici. Fora lor vine de la faptul c asigur suport pentru reprezentarea comportamentului paralel,
slbiciunea lor vine de la faptul c nu prezint foarte clar legturile dintre obiecte.
Pentru a compensa, parial, aceast slbiciune, n UML exist i posibilitatea de a implica
obiectele n realizarea diagramelor de activitate, dup cum voi arta n continuare.

Fluxuri de obiecte
Pentru a spori cantitatea de informaie coninut de o diagram de activitate, putem implica
obiectele n fluxul de control asociat cu o diagram de activitate. Obiectele n cauz vor fi
conectate, folosind relaia de dependen, la activitile sau tranziiile care le creaz, modific sau
distrug.
[se dorete vin]
bifurcaia
GtirePizza PreparareSos
DestupareSticlVin
Combinare
mbinri
Acest mod de utilizare a relaiei de dependen i a obiectelor este numit flux de obiecte, pe
motiv c reprezint participarea unui obiect ntr-un flux de control.
n plus fa de ilustrarea fluxului unui obiect ntr-o diagram de activitate, putem arta cum se
schimb rolul acestuia, starea i valorile atributelor lui.
Pentru mai mult claritate, se poate urmri Figura 106.
n Figura 106 am indicat prin numerotarea cu 1, 2, 3 fluxul parcurs de obiectul c iar prin
numerotarea cu 1', 2', 3' fluxul parcurs de obiectul f.
Numerotarea folosit nu are nici o legtur cu exigenele de notaie UML.
































Figura 105. Tehnica culoarelor

Modul de utilizare a diagramelor de activitate
n procesul de modelare a aspectelor dinamice ale unui sistem, uzual, folosim diagramele de
activitate n dou moduri:

1. Pentru modelarea fluxurilor de lucru
2. Pentru a modela o operaie

n primul caz, ideea este de a ne concentra atenia asupra activitilor aa cum sunt ele
percepute de actorii care colaboreaz cu sistemul.
Adeseori, fluxurile de lucru merg dincolo de marginile luate n calcul la modelarea sistemului
soft i sunt folosite pentru a vizualiza, specifica, construi i documenta procesele afacerii n curs de
modelare. n acest caz de utilizare a diagramelor de activitate, modelarea fluxurilor de obiecte este,
cu deosebire, important.
n cel de-al doilea caz, folosim diagramele de activitate ca un substitut pentru schemele logice
ale fluxurilor (flowchart-uri), cu scopul de a modela o serie de detalii de calcul. n acest caz de
utilizare a diagramelor de activitate, modelarea ramificrilor, bifurcrilor i mbinrilor capt o
importan deosebit. Contextul unei diagrame de activitate folosit n acest mod este definit de
parametrii operaiei i obiectele ei locale.

Aprovizionare Servire clieni Financiar-contabil
Preluare comand
Completare factur
Completare comand
Expediere comand
ncasare factur
nchidere comand





















Figura 106. Flux de obiecte


'
'
'


Client Gestionar Depozit
Solicitare produs
Procesare solicitare
c:Comanda
[n curs de rezolvare]
Pregtire comand
Transport comand
Primire comand Taxare client
Achitare factur
f:Factur
[ncasat]
nchidere comand
f:Factur
[nencasat]
c:Comanda
[rezolvat]





















Capitolul 5
Modelarea aspectelor comportamentale.
Elemente-suport avansate

...Mesajul cel mai important al acestei cri, prezent obsesiv n
ntreaga construcie a UML-ului, este simplu: nainte de a
implementa, modelai! Se accept i invers, dar numai ca exerciiu de
nvare a limbajului de modelare pentru care ai optat.
























5.1 Introducere
n lumea cunoscut de om nu exist sisteme perfect statice. Divagnd puin, s-ar spune c, la
scara ntregului univers, structurile ncremenite sunt o aberaie. Unul dintre principiile
constructive fundamentale, n univers, se poate formula astfel: n orice col de lume,
echilibrul este asigurat de un dinamism structurat eficient. Altfel spus, nu exist sisteme care
pot evita schimbrile. Staionaritatea, stabilitatea structural temporar sunt doar nite etape
necesare sistemelor, pentru a reflecta la formule noi de integrare n ambient.
Astfel c, nu vom fi surprini s constatm c una dintre conotaiile de baz ale supravieuirii
unui sistem este optimizarea formelor de comunicare cu ambientul. Aceast optimizare nu trebuie
s fie gndit ignornd alte echilibre. Un sistem este cu adevrat puternic dac i conserv
stabilitatea structural i un trend structural ascendent, fr a apela la agresarea altor
sisteme. Sistemele soft, n cea mai mare parte, sunt modele ale unor sisteme, imaginate de om,
pentru a asigura fluxurile informaionale vitale n orice sistem cu un nivel ridicat de organizare.
Astfel c, specialitii n ingineria softului au, n permanen, pe masa de lucru, dou teme:

elaborarea de modele, purtnd pecetea stabilitii structurale de moment; este vorba
de stabilitatea relaiilor cu impact informaional;
elaborarea de modele care determin restructurarea formulelor de stabilitate
structural din punct de vedere informaional.

Accentul pus, n ultima vreme, pe cea de-a doua tem are efecte devastatoare la nivelul tuturor
tipurilor de activitate uman. Nevoia de confort informaional n orice tip de activitate s-a
transformat, deja, ntr-un mod de a face istorie. Nu ne rmne dect s ncercm s greim ct mai
puin n asumarea acestui exerciiu.
Folosind UML, putem aborda descrierea dinamicii unui sistem ( a comportamentului lui) ct
mai aproape posibil de datele realitii. n acest capitol vom aduga argumente noi, n acest sens,
prin discutarea importanei conceptului de main de stare, asociat descrierii comportamentului
unui sistem i a implicaiilor acestui concept asupra nelegerii i utilizrii unor concepte strns
nrudite (diagramele de activitate i diagramele de hri de stare).

5.2. Evenimente i semnale
Toate ntmplrile care determin schimbrile de stare ale sistemelor modelate n UML se
numesc evenimente. Un eveniment este abstractizarea unei modificri care poate influena
dinamica unui sistem, modificare care are o determinare spaio-temporal precis. Exist
mai multe tipuri de evenimente care pot afecta funcionarea sistemelor. Care sunt acestea i ce
probleme de specificare ridic n faa modelatorilor, vom ncerca s aflm n continuare. Pentru
moment s mai subliniez un aspect important: n contextul unei maini cu stri (un anumit gen de
abstractizare a comportamentului sistemelor) producerea unui eveniment poate declana o
schimbare de stare, motiv pentru care ncepem aceast prezentare mai atent a problematicii
evenimentelor.

Tipuri de evenimente
Dintr-o perspectiv mai larg privind, evenimentele care pot afecta funcionarea unui sistem
pot fi interne sau externe. Evenimentele externe, idealiznd n acord cu exigenele ingineriei
softului, sunt acele evenimente care sunt datorate relaiei dintre un sistem soft i actorii si.
De exemplu, apsarea unei taste de ctre actorul care opereaz o aplicaie este un exemplu
tipic de eveniment extern.
n cazul unui sistem care a activat, datorit nefolosinei ndelungate funcia de screen-saver,
apsarea unei taste este interpretat ca o cerere de reluare a activitii, ceea ce provoac o
schimbare n starea sistemului de operare. Pe de alt parte, utilizarea necorespunztoare a
memoriei interne a unui sistem de calcul poate ocaziona producerea unor excepii cu valoare de
eveniment, att pentru sistemul de operare ct i pentru aplicaia n care se produce. O astfel de
excepie este un exemplu tipic de eveniment intern.
UML ofer suport pentru a modela patru tipuri de evenimente: semnale, apeluri de operaii,
scurgerea timpului i schimbrile de stare ale obiectelor.

Semnale
Se numete semnal un anumit obiect, expediat asincron de ctre un obiect cu scopul de a
fi receptat de alt obiect. Cum am mai spus, excepiile sunt exemple tipice de astfel de obiecte. n
limbajele de programare care ofer suport pentru tratarea structurat a excepiilor, lansarea unei
excepii de ctre program presupune, mai nti, crearea unui obiect de un anumit tip. Amintindu-ne
de cele spuse relativ la clase i innd cont i de modul n care sunt gestionate excepiile n limbaje
precum C++, Java, Object Pascal, etc., realizm marea asemnare dintre semnale i clasele care
modeleaz funciile unui sistem. Astfel c, dac soluia UML a unei probleme nseamn o
diagram complex de clase, ne putem atepta la o diagram pe msur a claselor care modeleaz
tratarea excepiilor. Notaia UML pentru evenimente, n ceea ce are ea esenial, este prezentat n
Figura 107, n care se ilustreaz necesitatea declarrii evenimentelor, sub forma unor clase
stereotipizate cu <<signal>>, precum i modul de utilizare a unei instane eveniment pentru a
declana o schimbare de stare n dinamica unui sistem.



















Figura 107. Evenimente n UML

Declararea unui eveniment nseamn, n ultim analiz, specificarea unei clase care
abstractizeaz evenimentul respectiv: atribute i operaii specifice.
Aadar, un semnal poate fi trimis ca o aciune care urmrete o schimbare de stare ntr-o
main de stare sau sub forma unui mesaj ntr-o interaciune. De asemenea, n timpul execuiei
unei operaii pot fi trimise semnale. n UML putem modela relaia dintre o operaie i
evenimentele pe care le poate trimite ca o relaie de dependen stereotipizat cu <<send>>, ca n
Figura 108.

















Figura 108. Operaii i semnale.


Evenimente-apel de operaii
Am vzut ce nseamn un eveniment semnal. Am vzut i faptul c semnalele se expediaz
asincron (ceea ce nseamn c expeditorul nu trebuie s atepte rspunsul destinatarului).
Apelurile de operaii sunt evenimente care, atunci cnd se produc (=execuia operaiilor) pot
determina schimbri de stare ntr-o main de stare.
De cele mai multe ori, apelurile de operaii sunt implementate sincron. Altfel spus, atunci
cnd un obiect invoc o operaie a altui obiect, care are o main de stare, controlul trece de la
expeditor la destinatar (= de la apelant la apelat), acest eveniment opereaz tranziia asociat lui,
OffPrinter/waitForOnPrinter()
<<signal>>
OffPrinter
declarare tip de eveniment
PregtireListare
Ateptare
eveniment
<<send>>
<<signal>>
Coliziune
DeplasareRobot

pozitie
:
mergiLa()
:
semnal
dependen <<send>>
operaia este terminat i numai dup aceea apelatul trece ntr-o stare nou, rednd apelantului
controlul. n cazul limbajelor care ofer suport pentru calculul paralel este evident faptul c
apelurile de operaii pot fi i asincrone. Din perspectiva notaiei UML, modelarea unui eveniment
apel nu se deosebete de modelarea unui eveniment semnal, cum se poate observa i n Figura 109.











Figura 109. Eveniment-apel de operaie.

Evenimente-timp i evenimente-schimbare
Un eveniment-timp este un eveniment determinat de scurgerea timpului. n UML putem
modela evenimentele-timp utilznd cuvntul cheie after urmat de o anumit expresie, care este
evaluat periodic. O astfel de expresie poate fi simpl (de exemplu, after 2 secunde) sau
complex (de exemplu, after 1 secund de la prsirea strii Ateptare).
Dac nu se specific explicit referina la care se raporteaz scurgerea indicat de after, referina
implicit este timpul de intrare n starea curent.
Un eveniment-schimbare este un eveniment care reprezint o schimbare n starea sau
satisfacerea unei anumite condiii.
n UML modelm un eveniment-schimbare prin folosirea cuvntului cheie when, urmat de o
anumit expresie boolean. Putem folosi astfel de expresii booleene pentru a indica un timp
absolut (ca de exemplu, when time=10:00) sau pentru testarea continu a unei expresii (de
exemplu, when altitudine<10000). Un mic exemplu, n Figura 110.


Alte consideraii relativ la trimiterea i primirea mesajelor
Evenimentele-semnal i evenimentele-apel de operaii implic cel puin dou obiecte: obiectul
care trimite semnalul sau invoc operaia i obiectul ctre care este ndreptat evenimentul.
Deoarece semnalele sunt asincrone i ntruct apelurile asincrone sunt ele nsele adevrate
semnale, semantica evenimentelor interfer cu semantica obiectelor pasive i active.
















Figura 110. Evenimente-timp i evenimente-schimbare n UML.

Orice instan a unei clase poate trimite un semnal sau poate apela o operaie a unui obiect.
Cnd un obiect trimite un semnal, dup ce efectueaz operaia de trimitere a semnalului, va
continua urmrirea fluxului de control propriu, fr a atepta rspuns de la destinatarul semnalului.
Din contr, cnd un obiect apeleaz o operaie, dup ce pred controlul operaiei va atepta
rspunsul din partea destinatarului.
Exist, n practic i situaii n care s-ar putea s dorii s artai cum trimite un obiect un
semnal unei mulimi de obiecte (multicasting) sau oricrui obiect din sistem care s-ar putea s
fie n ascultare (broadcasting). Pentru a modela multicasting-ul ar trebui s reprezentai un
startAutoPilot(true)
Manual
Automat
eveniment parametru
after (2 secunde)/stopConexiune()
when (10:00 AM)/selfTest()
Ateptare
Activ
eveniment-timp
eveniment-schimbare
obiect care trimite un semnal unei colecii de destinatari. Pentru a modela broadcasting-ul ar trebui
s reprezentai un obiect care trimite un semnal altui obiect, care reprezint sistemul ca ntreg.
Pe de alt parte, orice instan a unei clase poate primi un eveniment-apel sau un semnal. n
cazul n care este vorba despre un eveniment-apel sincron, atunci expeditorul i destinatarul sunt n
protocol rendezvous pe timpul execuiei operaiei. Dac, ns, evenimentul primit este un semnal,
atunci expeditorul i destinatarul semnalului nu vor fi n protocol rendezvous. Expeditorul trimite
semnalul fr s atepte rspunsul de la destinatar. n ambele situaii, evenimentul poate rmne
fr rspuns (dac un astfel de rspuns nu este specificat). Pentru a fi mai concrei, n programarea
vizual Windows, putem ntlni situaii n care anumite evenimente (apsarea unui buton push, de
exemplu) pot rmne fr rspuns pn n momentul n care proprietatea corespunztoare va avea
asociat o funcie de rspuns. De asemenea, putem lansa mesaje Windows pe care nici o aplicaie
i nici sistemul de operare nu le recunoate. Aceste mesaje vor fi, pur i simplu, ignorate.
Deducem, aadar, faptul c n UML modelm evenimentele apel pe care un obiect le poate primi
ca operaii specifice clasei definitoare a obiectului. n UML, vom reprezenta semnalele pe care un
obiect le poate primi prin specificarea acestora ntr-un extra-compartiment al clasei, ca n Figura
111.












Figura 111. Reprezentarea semnalelor asociate unei clase active

Aspecte referitoare la modelarea semnalelor
n sistemele dirijate de evnimente, problema gestiunii evenimentelor semnal ocup un loc
aparte. Astfel c, arhitectura acestor sisteme va pune clar n eviden necesitatea separrii
problemei tratrii evenimentelor de celelalte probleme eseniale n realizarea unei aplicaii sau a
unui sistem: organizarea, prelucrarea i interogarea coleciilor de date , organizarea interfeei cu
utilizatorul, etc. Elocvent n aceast privin este arhitectura MVC (Model-View-Controller).
Tendina de organizare a tratrii evenimentelor este susinut, pn la un punct, i de mediile
vizual de dezvoltare.
Ideea de baz, ntr-un sistem dirijat de evenimente, este c fiecare component nou introdus
n aplicaie este nsoit de un sistem propriu de reacie la evenimente. n cazul n care
componentele sunt diversificate tipologic, dar comportamentul lor ridic i probleme de gestiune a
similaritilor, evident se impune o modelare ierarhic a tipurilor de semnale care pot apare ntr-un
sistem. Cel mai bun exemplu n aceast privin l reprezint stilul Java de tratare a excepiilor
unui sistem, stil care presupune asocierea diagramei claselor care modeleaz cmpul informaional
al unui sistem cu o diagram, aproape izomorf, a ierarhiei excepiilor corespunztoare claselor din
diagrama care modeleaz cmpul informaional.

5.3. Maini de stare
Dup cum am vzut n Capitolul 4, cu ajutorul interaciunilor putem modela comportamentul
unei societi de obiecte. Folosind o main de stare, vom putea modela comportamentul unui
obiect individual.
O main de stare descrie comportamentul unui obiect, ca o secven de stri, prin care
obiectul trece, n timpul vieii, ca rspuns la producerea unor evenimente.
Vei folosi mainile de stare pentru a modela aspectele dinamice ale unui sistem. De cele mai
multe ori aceasta implic specificarea duratei de via a instanelor unei clase (un context de
utilizare sau ntregul sistem). Aceste instane ar putea rspunde la evenimente precum: semnalele,
operaiile, scurgerea timpului. Atunci cnd apare un eveniment, o anumit activitate se va
desfura; care anume, depinde de starea curent a obiectului. Starea unui obiect abstractizeaz o
anumit parte din durata de via a acestuia, n care sunt ndeplinite anumite condiii, se execut o
anumit activitate sau se ateapt producerea unui eveniment.
Se poate vizualiza o main de stare n dou moduri: prin evidenierea fluxului de control
de la o activitatea la alta (modelele obinute se numesc diagrame de activitate) sau prin
GestiuneTastatura


signals

pageUp()
pageDown()
:
clas activ
semnale
evidenierea strilor poteniale ale obiectelor i a tranziiilor ntre aceste stri (modelele
obinute se vor numi diagrame hri de stare).
n sfrit, nu facem nici o descoperire repetnd ceea ce ar trebui s tie deja orice specialist n
ingineria softului: mainile de stare bine-structurate sunt asemenea algoritmilor bine
structurai: eficiente, simple, adaptabile, uor de neles.

Concepte utilizate n realizarea mainilor de stare
O main de stare este un model care specific secvenele de stri prin care trece un obiect,
pe timpul vieii, ca rspuns la anumite evenimente, precum i rspunsurile obiectului la aceste
evenimente. O stare este abstractizarea unei perioade din viaa unui obiect, perioad n care
obiectul satisface o anumit condiie, execut o anumit activitate sau ateapt producerea unui
eveniment. Un eveniment este specificarea unei schimbri semnificative, localizabil n spaiu i
timp.
n contextul unei maini de stare, un eveniment este apariia unui stimul care poate provoca o
schimbare de stare. O tranziie este o relaie ntre dou stri prin care se specific faptul c un
obiect, aflat n prima stare, va executa o serie de aciuni i va intra n cea de-a doua stare n
momentul n care se produce un anumit eveniment i anumite condiii sunt ndeplinite. Am
precizat deja ce se nelege prin activitate i aciune. Cam acesta este, n esen, vocabularul cu
care ne ntlnim cnd avem de lucru cu mainile de stare. O abordare sistematic a conceptelor de
care uzm cnd realizm maini de stare, n cele ce urmeaz.

Contextul de utilizare a mainilor de stare
Fiecare obiect are o durat de via. Exist un moment n care obiectul se nate. Exist i un
moment n care obiectul este distrus. ntre aceste dou momente, obiectul poate aciona asupra
altor obiecte (prin trimiterea de mesaje ctre acestea) sau, n egal msur, poate fi inta aciunii
altor obiecte (primind mesaje de la acestea).
n numeroase situaii, aceste mesaje vor fi simple apeluri sincrone de operaii. Dac este aa,
atunci un astfel de obiect nu are nevoie de o main de stare pentru a-i descrie comportamentul
deoarece comportamentul lui curent nu are o dependen consistent de comportamentul lui trecut.
n cazul altor tipuri de sisteme se ntlnesc, ns, obiecte care trebuie s rspund la semnale,
nelese ca stimuli asincroni, care circul ntre instane. De exemplu, un sistem de operare
trebuie s fie pregtit n orice moment s dea un rspuns adecvat tuturor semnalelor care pot veni
din partea diferitelor task-uri aflate n focus-ul sistemului de operare. n termeni de obiecte
vorbind, dac, de exemplu, avem un obiect OLE programabil, acesta poate primi, n acelai timp,
semnale sincrone i asincrone, care i pot modifica esenial comportamentul.
Comportamentul obiectelor care trebuie s rspund unor stimuli asincroni sau al cror
comportament curent depinde de trecutul lor este cel mai bine specificat folosind maini de stare.

Observaie
De cele mai multe ori, modelarea comportamentului unui context de utilizare se face utiliznd
interaciunile; n acelai scop, ns, putem folosi mainile de stare. n mod similar, putem folosi
mainile de stare pentru a modela comportamentul unei interfee. Dei o interfa nu poate avea
instane directe, o clas care realizeaz aceast interfa poate avea instane. Unei astfel de clase, i
se va putea asocia, evident, comportamentul specificat de maina de stare a interfeei.

Strile
O stare este o abstracie care descrie o situaie care poate s apar de-a lungul vieii unui
obiect, situaie n care obiectul satisface anumite condiii, execut o anumit activitate sau
ateapt producerea unui eveniment.

n principiu, o stare are urmtoarele elemente definitorii:

1. Numele acesta este un ir de caractere care ajut la descrierea strii printre alte stri
posibile; o stare poate fi i anonim;
2. Aciuni corespunztoare intrrii/ieirii n/din stare evident, sunt aciuni care
trebuie executate la intrarea n, respectiv, ieirea din starea asociat;
3. Tranziii interne acestea sunt tranziii care sunt efectuate fr a determina o
schimbare a strii gazd;
4. Substri sunt folosite pentru a evidenia o posibil structur imbricat a strii;
substrile pot fi secveniale sau concurente;
5. Evenimente amnate pot desemna o list de evenimente care nu sunt tratate n
starea gazd, fiind puse ntr-o coad de ateptare n vederea tratrii de ctre obiect,
cnd se va afla n alt stare.

Aa cum s-a vzut deja, fr o referire explicit, o stare se reprezint ca un dreptunghi cu
colurile rotunde, cum se poate vedea i n Figura 112.
















Figura 112. Exemple de stri

n Figura 112 am prezentat un exemplu de modelare a comportamentului unui sistem de
operare, la nivel nalt de abstractizare, nivel la care am reinut ca eseniale dou stri: starea de
Ateptare i starea de Activitate.

Stri iniiale i stri finale
Dup cum se poate observa i n Figura 112, pentru maina de stare a unui obiect pot fi
definite dou stri speciale. Este vorba de starea iniial, care indic punctul de start al unei
maini de stare sau al unei substri. O stare iniial se reprezint ca un cercule umplut cu negru. n
al doilea rnd, este vorba despre starea final, care marcheaz terminarea execuiei unei maini de
stare sau a unei substri. O stare final se reprezint ca un cercule umplut cu negru, nconjurat de
un cercule simplu, de raz puin mai mare. De fapt, aceste dou tipuri de stri sunt nite
pseudostri, neputnd avea, dintre trsturile obinuite ale unei stri, dect nume.

Tranziii
Suntem n msur s spunem c o tranziie este o relaie ntre dou stri, relaie care
specific faptul c un obiect, aflat n prima stare, va executa o serie de aciuni, dup care va
trece n cea de-a doua stare, ca urmare a producerii unui eveniment i a ndeplinirii unor
condiii specificate. n vorbirea curent, despre o astfel de tranziie se obinuiete s se spun c
s-a efectuat. nainte de efectuarea tranziiei, obiectul se afl n starea surs; dup efectuare obiectul
se va afla n starea int. O tranziie are, structural vorbind, cinci pri:

1. Starea surs aceasta este starea care va fi afectat de tranziie; dac un obiect se
afl n starea surs, se poate efectua o tranziie atunci cnd obiectul primete
evenimentul declanator al tranziiei i condiia de gard (dac aceasta exist) este
ndeplinit.
2. Eveniment declanator acesta este evenimentul pe care, obiectul aflat n starea
surs, primindu-l i va schimba starea, dac i condiia de gard este satisfcut
(atunci cnd exist).
3. Condiia de gard este o expresie boolean care este evaluat n momentul n
care tranziia este determinat de primirea evenimentului declanator; dac rezultatul
evalurii este True, tranziia va fi efectuat; dac rezultatul evaulrii este False,
tranziia nu va fi efectuat i dac nu exist alt tranziie care ar putea fi declanat
de acest eveniment, evenimentul este pierdut.
4. Aciunea este o prelucrare atomic, care poate aciona, direct, asupra obiectului
care deine maina de stare i, indirect, asupra obiectelor care sunt vizibile obiectului
proprietar al mainii de stare.
5. Starea int aceasta este starea care devine activ dup efectuarea tranziiei.

Dup cum s-a putut vedea, deja, n exemplele prezentate, o tranziie este redat ca o linie
continu, orientat de la starea surs spre starea int. Evident, n cazul unei auto-tranziii, starea
surs i starea int coincid.

shutDown
terminareTask
lansareTask
ncrcare
Ateptare
Activitate
stare iniial
nume stare stare final








































Figura 113. Un exemplu de main de stare

n Figura 113 se pot vedea dou cazuri deosebite de tranziii: tranziia cu mai multe surse (caz
n care sursele fac obiectul unei mbinri join n englez) precum i tranziia cu mai multe inte
(caz n care avem o bifurcare fork n englez).

Eveniment declanator
Aa cum am mai spus de mai multe ori, un eveniment nseamn producerea unui stimul care
poate declana o tranziie de stare. Evenimentele se pot referi la: semnale, apeluri de operaii,
scurgerea timpului sau o schimbare de stare. Un semnal sau un apel pot avea parametri ai cror
valori sunt disponibile tranziiei (structura condiiei de gard sau aciunea tranziiei).
Evident, putem avea i tranziii fr eveniment declanator; acestea sunt tranziiile efectuate la
terminarea activitii asociate unei stri.
Ca o scurt parantez, s remarcm posibilitatea de a avea evenimente declanatoare
polimorfice, n situaia n care am specificat o ierarhie de semnale. n acest caz, o tranziie de
eveniment declanator S poate fi declanat de S precum i de orice copil al lui S.

Condiia de gard
Redat, n structura unei tranziii, ca o expresie boolean, inclus ntre paranteze drepte, o
condiie de gard este evaluat numai dup ce evenimentul declanator al tranziiei se produce.
Aceasta nseamn c putem avea mai multe tranziii de la aceeai stare surs, cu acelai eveniment
declanator i condiii de gard dizjuncte. n sfrit, s observm c n timp ce o condiie de gard
Nu exist
post
Candidat respins
Candidat admis Exist post
Dosar complet
Sosire candidat
Ateptare
Verificare dosar
Cutare post Testare candidat
Angajare
Amnare candidat
Eliminare candidat
este evaluat o singur dat, la declanarea tranziiei, un eveniment schimbare, potenial vorbind,
este evaluat continuu.

Aciunea
Este o prelucrare atomic, care poate include apeluri de operaii ale obiectului proprietar al
mainii de stare, precum i ale altor obiecte vizibile, crearea/distrugerea altui obiect, trimiterea
unui semnal ctre un obiect. n cazul n care este vorba despre trimiterea unui semnal, se apeleaz
la prefixarea numelui semnalului cu cuvndul cheie send. Este, consider, evident faptul c o
aciune atomic nu poate fi ntrerupt de evenimente, deci, odat nceput trebuie s ateptm
terminarea ei. Prin contrast, o activitate poate fi ntrerupt de evenimente.
Pentru mai mult claritate, putem indica explicit obiectul cruia i trimitem un semnal,
folosind o dependen stereotipizat cu <<send>>, a crei surs este starea i a crei int este
obiectul.

Tranziii i stri avansate
Folosind caracteristicile de baz ale tranziiilor i strilor, n UML putem modela o palet
larg de comportamente.
Mainile de stare UML au o serie de caracteristici avansate care v pot ajuta n realizarea
modelelor comportamentale complexe. Aceste caracteristici se refer la: aciuni la intrarea ntr-o
stare, aciuni la ieirea dintr-o stare, tranziii interne, activiti i evenimente amnate, cum se
poate vedea i n Figura 114.


















Figura 114. E lemente avansate relativ la tranziii i stri

Aciuni la intrarea/ieirea n/dintr-o stare
Exist, adesea, situaii n care, la fiecare intrare ntr-o anumit stare trebuie executat o
anumit aciune, abstracie fcnd de tranziia care a determinat intrarea n starea respectiv. O
situaie asemntoare poate fi plauzibil n ceea ce privete prsirea unei stri. n Figura 114 este
prezentat un exemplu de stare n care se efectueaz interogarea global a unei tabele. Protocolul
uzual pentru rezolvarea unei astfel de probleme cere, la intrarea n stare, selectarea tabelei int
pentru interogare iar, la prsirea strii, nchiderea tabelei respective.

Tranziii interne
n practic putem ntlni i situaii n care, n interiorul unei stri se pot produce evenimente a
cror tratare s se fac fr a prsi starea respectiv. Astfel de evenimente determin aa-zisele
tranziii interne, tranziii care nu trebuie confundate cu auto-tranziiile. n cazul unei auto-tranziii,
un eveniment declaneaz tranziia, urmeaz prsirea strii, executarea unei aciuni (eventual) i
reintrarea n aceeai stare. Aceasta presupune, printre altele, i activarea aciunilor asociate cu
intrarea/ieirea n/din stare. Lucru care nu este convenabil ntotdeauna. Dac se dorete tratarea
evenimentelor fr a executa aciunile de intrare/ieire n/din stare, se apeleaz la soluia
tranziiilor interne. n Figura 114 se observ c trecerea la o nou nregistrare se face ca o tranziie
intern.

Activiti
Atunci cnd un obiect se afl ntr-o stare, n general vorbind, el ateapt producerea unui
eveniment. Exist, ns, i situaii n care dorim s modelm o activitate n curs de desfurare.
InterogareGlobal
entry / selTab()

exit / closeTab()

newRecord / TabLuc.Next()

do / Display()

verifTab / defer

Altfel spus, n vreme ce obiectul se afl ntr-o anumit stare, el va desfura o anumit activitate,
care va continua pn la terminare sau pn va fi ntrerupt de producerea unui eveniment. De
exemplu, Editorul de ecuaii folosit de Microsoft Word, atunci cnd este apelat (ca server) de MS
Word (n calitate de client), dintr-o perspectiv main de stare comut MS Word ntr-o stare
tipic pentru procesarea ecuaiilor matematice, stare care poate fi abandonat dendat ce s-a
efectuat un click de mouse n afara boxei care delimiteaz un fel de fereastr de lucru a editorului
de ecuaii.
Pentru a modela o astfel de situaie, n UML se poate apela la tranziia special do pentru a
specifica activitatea care trebuie realizat nuntrul strii, dup ce a fost executat aciunea
asociat intrrii.
Activitatea unei tranziii do poate referi alt main de stare sau o secven de aciuni. do /
Display poate fi considerat un exemplu de activitate materializat ca referin la alt main de
stare. Sunt permise i referiri de tipul: do / op1(a); op2(b).Aciunile nu pot fi ntrerupte.
Secvenele de aciuni, ns, pot fi ntrerupte, evenimentele care provoac ntreruperea fiind
gestionate de starea care include secvena de aciuni.

Evenimente amnate
n practica modelrii se ntlnete frecvent situaia n care anumite evenimente dorim s le
interpretm, altele dorim s le ignorm. Exist i situaia n care, aflndu-ne ntr-o anumit stare,
anumite evenimente nu le interpretm, nu le ignorm, pur i simplu le amnm interpretarea.
Astfel de situaii sunt absolut normale n sistemele care mizeaz pe interactivitatea cu utilizatorul.
Ca un exemplu, s considerm perechea sistem de operare-aplicaie utilizator. S presupunem c
avem o main de stare care modeleaz comportamentul sistemului de operare. Una dintre strile
importante ale acestei maini este starea n care sunt procesate evenimentele de tip click stnga de
mouse. Unele dintre aceste evenimente vor fi ignorate (dac click-ul stnga de mouse a fost
efectuat ntr-o poriune a DeskTop-ului care nu conine nici un icon). Alte evenimente vor
declana lansarea n execuie a unor aplicaii (dac click-ul stnga de mouse a fost efectuat pe un
icon valid).
n sfrit, alte astfel de evenimente vor fi transformate n mesaje care sunt puse de ctre
sistemul de operare n coada de mesaje a aplicaiei; maina virtual a aplicaiei este posibil s aib
o stare n care se va da, ntr-un trziu, rspunsul la un click de mouse n suprafaa utilizator a
aplicaiei.
Un astfel de comportament poate fi specificat utiliznd evenimente amnate. Un eveniment
amnat este o list de evenimente a cror materializare ntr-o stare este amnat pn cnd maina
de stare ajunge ntr-o stare n care evenimentele din list, nemaifiind amnate pot deveni active,
putnd declana tranziii, etc..
n Figura 114 evenimentele verifTab pot s apar n starea InterogareGlobal, dar sunt
amnate pn cnd sistemul ajunge ntr-o stare abilitat s interpreteze evenimente de tip
verifTab. Un eveniment amnat se distinge de alte evenimente prin faptul c este nsoit de
meniunea special defer.

Substri
Elementele avansate prezentate relativ la stri i tranziii ajut la rezolvarea unui numr
considerabil de probleme de modelare. Exist, totui, probleme de modelare a cror complexitate
poate fi surmontat apelnd la alt important caractersitic a mainilor de stare UML: substrile.
O substare este o stare cuibrit n alt stare. Altfel spus, unele maini de stare UML vor
putea conine i stri avnd o anumit structur intern, stri care, de fapt, abstractizeaz colecii
structurate de substri. O stare care conine substri se numete stare compus. O stare compus
poate conine att substri concurente ct i substri secveniale. O stare compus se reprezint ca
o stare simpl care, ns, n afar de nume va conine un compartiment grafic, opional, care
expune maina de stare cuibrit. Principial, substrile se pot cuibri pe oricte nivele este
necesar. Profesionitii tiu, ns, de la limbajele de programare, c acest gen de abordare a
complexitii (n fapt modularizare ierarhic) este recomandat ca uz nu ca abuz.

Substri secveniale
Pentru a introduce problematica substrilor secveniale s punem n discuie maina de stare
asociat problemei modelrii comportamentului unui bancomat. n cazul unui astfel de sistem,
putem vorbi de trei stri fundamentale: Ateptare (n vederea interaciunii cu un client), Activ
(procesarea unei tranzacii a unui client) i ntreinere (adugare de bani cash, etc.).
Analiza soluiei propus n Figura 115 ne arat faptul c, odat trecut n starea Activ, ca
urmare a evenimentului inserareCard, automatul execut aciunea de intrare n starea Activ
(readCard), dup care urmeaz secvena de substri: Validare, Selectare, Procesare, cu
posibilitatea de a itera pe ultimele dou substri, iar la terminare se tiprete o chitan n substarea
Tiprire. Se mai observ c, indiferent de substarea n care se afl bancomatul, clientul poate
apsa butonul Cancel, eveniment de competena strii Activ, care determin revenirea
bancomatului n starea Ateptare. ncercai s v imaginai ce ar fi nsemnat modelarea
comportamentului bancomatului fr a dispune de posibilitatea cuibririi substrilor.























Figura 115. Utilizarea substrilor secveniale

Stri cu istoric simplu
O main de stare descrie aspectele dinamice ale unui obiect al crui comportament curent
depinde de trecut. Dependena fa de trecut se poate manifesta n diferite moduri. Un caz aparte
de dependen de trecut n comportamentul unui obiect este caracterizat n Figura 116.















Figura 116. Stare cu istoric simplu

Exemplul generic prezentat n Figura 116 reprezint urmtorul scenariu:

1. Un anumit obiect se afl n Starea 1. Ca urmare a producerii unui eveniment are loc
tranziia n Starea 2.
2. Urmeaz parcurgerea secvenial a substrilor 1, 2, 3.
3. Indiferent de substarea n care ne aflm, poate apare o ntrerupere care comut sistemul n
Starea 1.
4. Un eveniment provoac, din nou, tranziia n Starea 2. Se dorete reluarea execuiei strii
Starea 2 de la substarea n care s-a produs ntreruperea.

Cu alte cuvinte, este necesar un mecanism care s permit (n caz de revenire n Starea 2,
dup o ntrerupere) memorarea strii n care s-a produs ultima ntrerupere.
cancel
inserareCard
operaie
Ateptare
ntreinere
Activ
Validare
Selectare
Procesare
Tiprire
[terminare]
[continuare]
entry/readCard
exit/ejectCard
ntrerupere
eveniment
Starea 1
Starea 2
H
Substare 1
Substare 2
Substare 3
stare cu istoric simplu
Modelarea, n UML, a unei stri compuse cu istoric simplu se face ca n Figura 116.
Elementul care distinge o stare compus obinuit de o stare compus cu istoric simplu este
prezena simbolului H, ncercuit, n structura strii int, el fcnd legtura ntre starea surs i
starea compus int cu istoric simplu a unei tranziii.

Substri concurente
Substrile secveniale reprezint cel mai uzual mod de imbricare a mainilor de stare. Exist,
ns, i situaii n care dorim s specificm dou sau mai multe maini de stare care sunt executate
n paralel, n contextul unui anumit obiect. De exemplu, obiectul context poate fi un fir de execuie
n interiorul cruia se creaz i se execut alte dou fire de execuie.
Reprezentarea n UML a unei astfel de situaii este ilustrat n Figura 117.
















Figura 117. Substri concurente

Semantica reprezentrii din Figura 117 este urmtoarea: din Starea 1 (simpl) se poate trece
(n anumite condiii) n Starea 2 (compus). Substrile strii Starea 2 sunt organizate n dou
fluxuri de substri, fluxuri care sunt executate concurent. Revenirea n starea Starea 1, sau n orice
alt stare (dac ar fi fost cazul) este posibil numai dup ce se termin execuia ambelor fluxuri de
substri (are loc operaia de join prin atingerea ambelor substri finale). Evident, putem avea i
mai mult de dou fluxuri de substri concurente.

5.4 Procese i fire de execuie
Introducere
Nu se ntmpl ntotdeauna ca lumea cu care ne confruntm s fie panic i ordonat. Din
contr, tendina este ca, odat cu scurgerea timpului, lumea evenimentelor care ateapt, linitite,
dreptul la replic s devin o iluzie, din ce n ce mai puternic. Dominanta lumii n care trim este
intensificarea interoperabilitii sistemelor, ceea ce nseamn i diversificarea paletei de
evenimente care ne pot influena viaa. n aceeai direcie evolueaz i lumea aplicaiilor i
sistemelor soft: creterea interoperabilitii, lucru care se poate realiza promovnd paralelismul i
necesarele strategii de sincronizare a task-urilor executate n paralel.
n UML putem modela fiecare flux de control independent ca un obiect activ, care poate
reprezenta un proces sau fir de execuie, capabil de iniierea unor activiti de control. Un proces
este considerat un flux de categorie grea, care poate fi executat n paralel cu alte procese; un fir
de execuie este considerat un flux de categorie uoar, care poate fi executat n paralel cu alte
fire de execuie, n interiorul aceluiai proces.
Realizarea aplicaiilor i a sistemelor care sunt executate n condiii de multitasking, este o
problem care solicit intens att efortul de modelare ct i abilitile de programare ale
specialitilor. Aceasta se ntmpl deoarece ntr-o lume care susine multitasking-ul (care n fond
nseamn posibilitatea ca mai multe obiecte s coopereze pentru rezolvarea aceleai probleme,
accesnd separat resursa cea mai important a unui sistem de calcul, timpul UC) apar probleme noi
de modelat i implementat, toate concentrate n sintagma sincronizare.
Procesele i firele de execuie au nevoie de diferite tipuri de mecanisme pentru a rezolva
problemele de sincronizare a accesului la diferite tipuri de resurse (altele dect timpul UC i
memoria RAM, alocate implicit proceselor i firelor de execuie). Aa cum am mai spus, fiecare
flux de control independent este modelat n UML ca un obiect activ. La fel ca n cazul oricrui
obiect, un obiect activ este instan a unei clase. n cazul obiectelor active, clasele definitoare se
numesc clase active. Obiectele active pot comunica cu alte obiecte prin schimb de mesaje, dar, n
Starea 1
Substarea 11 Substarea 12
Substarea 21 Substarea 22 Substarea 23
acest caz, schimbul de mesaje este realizat n condiii concureniale, ceea ce introduce o serie de
elemente sintactice i semantice specifice.
S mai precizm c, la ora actual, exist multe limbaje de programare care ofer suport
sintactic special pentru conceptul de obiect activ. Dintre aceste limbaje, mai cunoscute sunt Java,
Smaltak i Ada, care ofer suport nativ pentru obiecte active. Limbaje precum Object Pascal i
C++ suport multitasking-ul prin intermediul unor mecanisme de utilizarre a facilitilor
sistemului de operare n ceea ce privete mecanismele concureniale.
UML furnizeaz o reprezentare grafic a unei clase active, ca n Figura 118.

















Figura 118. O clas activ, redat ca un dreptunghi cu laturile ngroate

Exemplul din Figura 118 modeleaz un controller de clipboard, fapt care nu ne mai pune
ctui de puin pe gnduri dac ne amintim modul n care se manifest acesta n aplicaiile
Windows, de exemplu. Dup cum se poate observa, o clas activ are nume, compartiment pentru
atribute, compartiment pentru operaii i, n mod necesar, un compartiment n care se specific
semnalele recunoscute de obiectele clasei active.

Concepte utilizate n modelarea proceselor i a firelor de execuie
Am precizat, deja, faptul c un obiect activ este un obiect care deine un proces sau fir de
execuie i poate iniia activiti de control (aceste activiti de control se refer, n ultim analiz,
la relaia cu sistemul de operare, n cazul unui proces, sau la relaia cu sistemul de operare i
proprietarul, n cazul unui fir de execuie). O clas activ este o clas ale crei instane sunt
obiecte active. Se numete proces un flux de categorie grea, care poate fi executat n paralel cu
alte procese. Se numete fir de execuie un flux de categorie uoar, care poate fi executat n
paralel cu alte fire de execuie, n cadrul aceluiai proces.

Flux de control
ntr-un sistem pur secvenial exist un singur flux de control. Aceasta nseamn c, la un
moment dat, n sistem se poate ntmpla un singur lucru. Atunci cnd un program secvenial i
ncepe execuia, controlul este preluat de prima instruciune executabil a programului,
instruciunile fiind executate una dup alta. n situaia n care au loc evenimente concurente n
lumea actorilor din afara sistemului, un program secvenial va procesa un singur eveniment, la un
moment dat, punndu-le ntr-o coad de ateptare pe celelalte sau ignorndu-le, pur i simplu, pe
unele dintre ele.
n sistemele secveniale, chiar dac acestea apeleaz la ramificri, iteraii, apeluri recursive
pentru asigurarea comportamentului ateptat de utilizatori, o seciune imaginar, n orice moment,
prin fluxul de control al sistemului va evidenia prezena unui singur flux de execuie.
Spre deosebire de o astfel de situaie, n sistemele concurente vor exista mai multe fluxuri de
control al prelucrrilor, ceea ce ne va permite s observm c, la un moment dat, n sistem se pot
ntmpla lucruri diferite, n cadrul unor fluxuri simultane asociate unor procese sau fire de
execuie.
n UML utilizm clase active pentru a reprezenta un proces sau un fir de execuie care este
originea unui flux de control independent i este concurent cu alte fluxuri de control.




ClipboardController

Buffer

:

Signals
crrlC
ctrlV
:
:

nume clas activ
compartiment atribute
compartiment operaii
compartiment
semnale recunoscute
Observaie
n practic putem obine concuren n unul din urmtoarele moduri:

1. Prin distribuirea obiectelor active n noduri multiple;
2. Prin plasarea obiectelor multiple n noduri cu mai multe procesoare;
3. Prin combinarea metodelor de mai sus.

Clase i evenimente
Clasele active sunt clase n toat puterea cuvntului, dei, ntr-o ultim analiz (din
perspectiv semantic i pragmatic) clase cu proprieti deosebite. Clasele active sunt utilizate
pentru a modela fluxuri independente de control, ceea ce nu se poate spune despre clasele
obinuite care sunt socotite, implicit, clase pasive deoarece nu pot iniia activiti independente de
control. Un obiect activ emite pretenii n relaia cu procesorul i memoria RAM, prin intermediul
sistemului de operare. Un obiect pasiv dispune de resursele de care are nevoie, n contul procesului
sau firului de execuie gazd.
Folosim clase active pentru a modela familii comune de procese sau fire de execuie, n
termeni tehnici, aceasta nseamn c un obiect activ (=o instan a unei clase active) materializeaz
ideea de proces sau fir de execuie. Modelnd sistemele concurente cu obiecte active, putem
atribui cte un nume fiecrui flux independent de control. Atunci cnd este creat un obiect activ,
fluxul de control asociat este lansat n execuie. Atunci cnd un obiect activ este distrus, fluxul de
control asociat este terminat.
n alt ordine de idei, clasele active partajeaz aceleai proprieti ca toate celelalte clase: pot
avea instane, pot avea atribute i operaii, pot participa n relaii de dependen, generalizare,
asociere, pot utiliza mecanismele de extensie UML, pot realiza interfee, pot fi realizate de
colaborri i suport specificarea comportamentului cu ajutorul mainilor de stare.
Obiectele active pot apare oriunde apar obiectele pasive (n diagrame). Putem, de asemenea,
modela colaborarea unor obiecte pasive i active folosind diagrame de interaciune.
n sfrit, un obiect activ poate fi inta unui eveniment ntr-o main de stare. Relativ la
mainile de stare, s mai menionez faptul c att obiectele pasive ct i cele active pot trimite i
recepiona evenimente-semnal i evenimente-apel de operaii.

Elemente standard
Toate mecanismele de extensie ale UML-ului pot fi folosite pentru a modela proprietile
claselor active. De cele mai multe ori, folosim valori etichetate pentru a extinde proprietile
claselor active, ca de exemplu, pentru a specifica politica de localizare n noduri a claselor active.
De asemenea, UML definete dou stereotipuri standard, aplicabile claselor active:

1. <<process>> - specific un flux de categorie grea, care se poate executa concurent cu
alte procese;
2. <<thread>> - specific un flux de categorie uoar care se poate executa concurent cu
alte fluxuri de categorie uoar, n interiorul aceluiai proces.

Este momentul s adaug cteva elemente referitor la deosebirea dintre proces i fir de
execuie. n esen, deosebirea este fundamentat pe relaia celor dou tipuri de obiecte active
cu sistemul de operare al nodului n care obiectele sunt rezidente.
Spunem c un proces este de categorie grea deoarece el este un lucru cunoscut sistemului de
operare, care i asigur execuia ntr-un spaiu de adrese independent. n cele mai multe sisteme de
operare (Windows, Unix), fiecare program este executat ca un proces avnd la dispoziie propriul
spaiu de adrese. n general, toate procesele active ntr-un nod sunt egale ntre ele n ceea ce
privete competiia pentru resursele cheie ale nodului (timpul UC i memoria RAM). De
asemenea, nici un sistem de operare nu implementeaz imbricarea proceselor. Din practica
programrii, pe numeroase platforme de operare se tie c relaia proces tat proces fiu este
implementat fr a introduce vreo interferen ntre mecanismele cheie de execuie ale celor dou
fluxuri de control. De regul, nainte de a apela un proces fiu, procesul tat salveaz vectorii de
stare proprii (eseniali pentru dinamica relaiei cu procesorul) i, eventual, organizeaz RAM-ul
astfel nct procesul fiu s nu aib probleme la ncrcare i n timpul execuiei.
Dac nodul are un singur procesor, concurena este doar o iluzie, simulat de funcii speciale
ale sistemului de operare.
n sfrit, spunem c un fir de execuie este de categorie uoar deoarece, chiar dac poate fi
cunoscut de ctre sistemul de operare, implicat direct n rezolvarea problemelor de sincronizare,
execuia lui se face folosind spaiul de adrese al procesului gazd. Observaia referitoare la iluzia
concurenei n cazul nodurilor monoprocesor este valabil i n cazul firelor de execuie.

Comunicaia
Colaborarea dintre obiecte presupune interaciunea dintre ele, bazat pe schimbul de mesaje.
ntr-un sistem care conine att obiecte pasive ct i obiecte active, exist patru tipuri posibile de
interaciuni:

1. Schimb de mesaje ntre dou obiecte pasive Presupunnd c este vorba de un singur
flux de control, care opereaz asupra acestor obiecte, o astfel de interaciune nu este
nimic altceva dect o simpl invocare a unei operaii.
2. Schimb de mesaje ntre dou obiecte active Dac aa ceva se ntmpl, atunci
spunem c avem comunicaie ntre procese i exist dou stiluri posibile de comunicare.
Mai nti, un obiect activ poate apela sincron o operaie a altui obiect activ. Este
vorba de o comunicaie cu semantic rendezvous. Pe timpul rezolvrii apelului, evident,
cele dou fluxuri de control (apelantul i apelatul) sunt blocate n ateptarea terminrii
apelului. n al doilea rnd, un obiect activ poate trimite un semnal asincron altui
obiect activ sau poate apela asincron o operaie a altui obiect activ. Despre acest tip
de comunicaie se spune c are semantic mailbox, care presupune c apelantul trimite
semnalul sau apeleaz o operaie i i continu execuia independent de apelat. n UML,
un mesaj sincron este indicat ca o sgeat cu vrful plin iar un mesaj asincron este indicat
ca o sgeat simpl cu o singur aripioar,dup cum se poate observa i n Figura 119.













Figura 119. Tipuri de mesaje n comunicaia dintre obiectele active

3. Schimb de mesaje ntre un obiect activ i un obiect pasiv Este un scenariu care poate
s creeze probleme n situaia n care mai multe obiecte active vor s comunice simultan
cu acelai obiect pasiv. Sarcina sincronizrii trebuie asumat, cu mult grij, de ctre
programator, ntr-o astfel de situaie.
4. Schimb de mesaje ntre un obiect pasiv i un obiect activ Dei la prima vedere un
astfel de scenariu poate prea ilegal, de fapt el este la fel de plauzibil ca tipul al treilea de
comunicaie.

Sincronizarea
ntr-un sistem concurent, dup cum am vzut, putem avea mai multe fluxuri de control n
execuie, la un moment dat. Un flux este, n ultim analiz, un mod particular de compunere a
unor operaii atomice sau neatomice. Astfel c, odat ce a primit controlul, fluxul l va delega
operaiilor care l compun, conform schemei logice a fluxului. De asemenea, ntr-un sistem
puternic obiect orientat (cum este Java, de exemplu) majoritatea operaiilor vor raporta
controlul preluat, la o anumit instan a clasei din definiia creia face parte operaia. n acest
context putem vorbi despre posibilitatea de a avea mai multe fluxuri de control care se
mapeaz, la un moment dat, pe o operaie (deci pe un obiect); de asemenea, putem avea
fluxuri de control diferite mapate pe operaii diferite, care pot fi ale aceluiai obiect. Evident,
n ambele cazuri, prezentate mai sus (rezumate n formularea fluxuri multiple de control i un
singur obiect la un moment dat) trebuie mult atenie pentru a evita coruperea strii
obiectului partajat de fluxurile multiple. Problema n faa creia ne aflm este clasic:
excluderea mutual. O tratare necorespunztoare a acestei probleme provoac euarea
sistemelor concurente n situaii care pot fi att de puin predictibile nct se poate crea i o
senzaie de mister i conjunctur nefavorabil, ceea ce, n cazul unui sistem de calcul valid
este totalmente absurd.
n sistemele obiect orientate, cheia rezolvrii unei astfel de probleme este tratarea unui
obiect ca o regiune critic. Exist trei alternative la aceast abordare, fiecare dintre ele
implicnd ataarea unor proprieti de sincronizare operaiilor definite ntr-o clas. n UML
putem modela toate aceste trei alternative:
o:init()
r:refresh()
mesaj sincron
mesaj asincron

1. sequential apelanii trebuie s se coordoneze astfel nct, la un moment dat, un
singu flux s dein obiectul. Astfel c, n prezena unor fluxuri de control multiple,
sistemul nu garanteaz semantica i integritatea obiectului.
2. guarded semantica i integritatea obiectului este garantat n prezena unor
fluxuri de control multiple, prin secvenializarea apelurilor operaiilor, marcate ca
fiind guarded, ale obiectului. De fapt, rezultatul apelrii la alternativa guarded este
faptul c, la un moment dat, o singur operaie a obiectului poate fi apelat, ceea ce
nseamn reducerea la semantica secvenial.
3. concurent semantica i integritatea obiectului este garantat, n prezena unor
fluxuri de control multiple, prin considerarea operaiei ca fiind atomic, adic
nentreruptibil; prin urmare, un singur flux o poate apela la un moment dat.

Multe limbaje de programare ofer suport direct pentru implementarea acestor alternative. Ca
un exemplu, n Java putem declara metode prefixate cu proprietatea synchronized, ceea ce este
echivalent cu varianta concurent a UML-ului. Tot n Java putem declara clase prefixate cu
proprietatea synchronized ceea ce este echivalent cu varianta guarded a UML-ului. Limnajele de
programare pot fi nzestrate i cu alte mecanisme de sincronizare, reductibile, n esen, la oferta
UML n spe.

Perspectiva proces
Obiectele active joac un rol important n vizualizarea, construirea i documentarea
perspectivei proces a unui sistem. Perspectiva proces a unui sistem cuprinde firele de execuie i
procesele care definesc caracterul concurenial al sistemului, precum i mecanismele de
sincronizare. n UML, aspectele statice i dinamice ale acestei perspective sunt capturate n
aceleai tipuri de diagrame, folosite la modelarea perspectivei design: diagrame de clase, diagrame
de interaciune, diagrame de activitate i diagrame de hri de stare, cu meniunea c n atenia
acestor diagrame se afl clasele active care reprezint fire de execuie i procese.


Moduri de utilizare a notaiei UML pentru procese i fire
de execuie
Modelarea fluxurilor multiple de control
Realizarea unui sistem a crui funcionare se bazeaz pe fluxuri multiple de control este, de
regul, un exerciiu dificil. Dou sunt problemele care trebuie rezolvate cu ndemnare:

1. Gsirea celei mai bune formule de descompunere a activitii sistemului ntr-o
colecie bine structurat de obiecte concurente.
2. Imaginarea celor mai potrivite mecanisme de comunicare i sincronizare ntre
obiectele active i pasive ale sistemului, pentru a fi siguri de un comportament corect i
eficient n prezena unor fluxuri de control multiple.

Astfel c este ct se poate de binevenit posibilitatea oferit de UML n ceea ce privete
vizualizarea modului n care fluxurile de control interacioneaz. UML permite att capturarea
aspectelor statice ct i a celor dinamice n diagrame de clase, respectiv, de interaciune, care
conin clase i obiecte active. Paii de urmat cnd modelm fluxuri multiple de control sunt
prezentai mai jos.

Identificarea oportunitilor pentru aciuni concurente i modelarea fiecrui flux ca
o clas activ. Generalizarea obiectelor active care prezint similariti. De evitat,
sistematic, excesul de inginerie a perspectivei proces, ceea ce ar determina i un exces de
concuren.
Evaluarea distribuiei responsabilitilor ntre clasele active i examinarea altor
clase active i pasive cu care exist relaii statice. Se va urmri ca fiecare clas activ
s fie nalt coeziv i slab cuplat cu clasele vecine.
Reprezentarea relaiilor statice ntr-o diagram de clase, scond n eviden fiecare
clas activ.
Evidenierea relaiilor de colaborare dintre clase i capturarea lor n diagrame de
interaciune.
Atenie la comunicarea dintre obiecte!
Atenie la rezolvarea corect a problemelor de sincronizare!

Modelarea comunicaiei interprocese
Comunicarea ntre obiecte rezidente n fire de execuie diferite se poate realiza prin apeluri-
eveniment sau apeluri-semnal (pentru apelurile eveniment se poate recurge la una din semanticile
sincron sau asincron). Pentru comunicarea ntre procese rezidente n spaii de adrese diferite sunt
obinuite alte mecanisme de comunicare.
Problema comunicrii ntre procese capt semnificaii noi atunci cnd procesele sunt
rezidente n noduri diferite. Din perspectiv clasic, pentru astfel de situaii exist dou abordri:
schimbul de mesaje (intermediat de sistemul de operare) i apelul la distan al procedurilor
(remote procedure call). Evident, n cazul proceselor distribuite, intr n scen o serie de
tehnologii dedicate realizrii unor sisteme cu arhitecturi specifice (client-server), tehnologii
care ofer suportul necesar pentru rezolvarea tuturor problemelor de comunicare i
sincronizare care pot s apar n cazul aplicaiior distribuite (Corba, DCOM,MIDAS,
etc.).Comunicarea ntre procese poate fi, n funcie de necesiti, sincron sau asincron, cu
consecinele de rigoare n ceea ce privete sincronizarea. De analizat i exemplul prezentat n
Figura 120.

























Figura 120. Comunicare inter-procese, cu formalizm UML

5.5 Timpul i spaiul n modelarea comportamentului unui
sistem
Modelarea timpului i a spaiului este un element esenial al oricrui sistem distribuit i/sau
n timp real. UML pune la dispoziia celor interesai o serie de elemente suport, precum: marcajele
temporale, expresiile temporale, constrngerile i valorile etichetate, pentru a vizualiza, specifica,
construi i documenta sistemul n cauz. Reprezentarea UML a acestor concepte poate fi urmrit
n Figura 121.
Un marcaj temporal desemneaz momentul n care se va produce un eveniment sau va apare
un mesaj. Un marcaj temporal este o expresie care pornete de la numele unui mesaj. n Figura 121
a este un obiect de tip mesaj care permite trimiterea mesajului cu structura a:getH(region)
obiectului h, mesaj care marcheaz naterea obiectului h, fizic i temporal vorbind.
O expresie temporal este o expresie n construcia creia intervin elemente temporale (a se
vedea i exemplul din Figura 121).
O constrngere temporal este o constrngere a crei semantic este raportat esenial la
aspectele temporale ale evoluiei obiectului cruia i se aplic (a se vedea, de asemenea, Figura
121).




a2:efectuare()
a1:efectuare()
a3:afisareRezultat()
p1:planExcursie()
aplicaie client-
server Corba

Corba ACS
<<process>>
p:Planificator_Excursii

{location=client}
<<process>>
a:AgentDeRezervare

{location=reservation Server}
<<process>>
h:AgentHotel

{location=hotel server}
<<process>>
t:EliberareDocumenteTransport

{location=airline server}

























Figura 121. Constrngeri temporale i localizri

n cele din urm, n Figura 121 apar i exemple de localizare n spaiu a unor obiecte.
Localizarea obiectelor este realizat folosind mecanismul valorilor etichetate. Elemente de
localizare similare pot fi introduse i n perspectiva desfurare a sistemului.
Folosind elementele prezentate mai sus, n practic putem rezolva urmtoarele tipuri de
probleme:

Modelarea constrngerilor temporale
Modelarea distribuiei spaiale a obiectelor
Modelarea obiectelor care migreaz

Ultimul tip de problem apare n sistemele distribuite, din ce n ce mai frecvente i
importante, odat cu apariia Internet-ului i a diferitelor tipuri de aplicaii care l populeaz.

5.6 Diagrame hri de stare (DHS)
DHS sunt unul din cele cinci tipuri de diagrame folosite de UML pentru modelarea aspectelor
dinamice ale unui sistem. Dup cum se tie deja, o DHS este, de fapt, un caz particular de main
de stare. O diagram de activitate era, de asemenea, un caz particular de main de stare,
caracterizat prin faptul c toate strile (sau cea mai mare parte a lor) sunt stri de activitate i
toate tranziiile (sau cea mai mare parte a lor) sunt declanate ca urmare a terminrii activitilor
din strile surs. Dei putem spune fr a grei c att diagramele de activitate ct i DHS sunt
utile pentru a modela durata de via a unui obiect, este important s tim c DHS sunt preferate
atunci cnd modelm comportamentul obiectelor reactive. Se numete reactiv un obiect al crui
comportament este cel mai bine caracterizat specificnd rspunsurile lui la evenimentele a
cror cauz se afl n afara contextului su.
Evident, tot ceea ce am spus cnd am prezentat mainile de stare poate fi utilizat n realizarea
DHS. n Figura 122 este prezentat o diagram de stare care modeleaz un analizor lexical,
orientat pe un flux de caractere avnd sintaxa:

< string > string ;

Dup cum se vede, analizorul este modelat ca o main de stare fr stare final. Exemplul
prezentat, sper c va da cititorului o idee clar asupra situaiilor n care se apeleaz la DHS pentru
modelarea comportamentului obiectelor.


b:getH(regiune)
a:getH(regiune)
c:Client
{location=Consola}
h:ServerH
{location=Server}
e:CentruH
{location=CentruHard}
marcaje temporale
{a.execTime<10 ms} constrngere temporal
expresie temporal
localizri
































Figura 122. Modelarea obiectelor reactive utiliznd DHS
scrie(c)[c==;]
/return true
scrie(c)[c==>]
scrie(c)[c<]
/return false
scrie(c)[c==<]
Ateptare
PreluareToken
PreluareCorpMesaj
scrie(c)[c>]
/token.adaug(c);return false
scrie(c)[c;]
/corp_mesaj.adaug(c);return false




























Capitolul 6
Elemente de modelare arhitectural

...nainte de a fi un stil de interpretare, arta de a modela este un
mod de a face compoziie.
(D.Bocu, Iniiere n ingineria sistemelor soft, Editura Albastr, 2002)























6.1 Introducere
n general vorbind, un sistem este un ansamblu de elemente ntre care, n lumea cu trei
dimensiuni, exist relaii spaiale, statice i dinamice. Exist cel puin dou motive pentru care
avem nevoie de o viziune de ansamblu, integratoare, asupra acestor relaii:

1. Simplificarea nelegerii sistemului, ca o premis pentru rezolvarea eficient a unor
probleme de comunicare ntre partenerii de proiect de diferite categorii;
2. Impunerea unui anumit mod de structurare a relaiilor dintre componente, ca o
premis esenial pentru utilizarea unor abloane conceptuale de rezolvare a unei
probleme.

Nu este foarte greu de observat faptul c, nainte de a obine simplificarea nelegerii
sistemului trebuie asigurat cadrul care favorizeaz aceast nelegere.
Un astfel de cadru n procesul de dezvoltare a sistemelor soft este asigurat de o viziune
arhitectural de calitate. Un sistem soft are o arhitectur de calitate dac:
Principiile constructive eseniale pe care se bazeaz realizarea i funcionarea lui
sunt simple;
Suport, fr influene dramatice asupra costurilor implicate: modificri ale
cerinelor funcionale i nefuncionale, extinderi de natur funcional.
Aa cum am mai spus i n alt carte [3], o arhitectur de calitate atrage atenia, ntotdeauna,
prin simplitate i tipul de descentralizare promovat. Nevoia de simplitate determin necesitatea
unei abordri metodice a problemei descentralizrii. UML acord atenia cuvenit aspectelor
arhitecturale, oferind o serie de concepte, mpreun cu notaia aferent, ca i punct de plecare n
rezolvarea exigenelor arhitecturale fa de un sistem soft: componente, interfee, noduri, tabele,
fiiere, etc..

6.2 Componente
Procesul de dezvoltare a unui sistem soft are, de regul, ca rezultat o serie de produse, cu
diferite valori de ntrebuinare. Exist rezultate ale procesului de dezvoltare a cror valoare de
ntrebuinare se stabilete prin raportare la lumea conceptual. n aceast categorie intr tot ceea ce
nseamn element care definete modelarea logic. Exist, ns i rezultate ale procesului de
dezvoltare a cror valoare de ntrebuinare se stabilete prin raportare la aspectele fizice
(operaionale) ale sistemelor soft. n aceast categorie intr tot ceea ce nseamn element care are o
contribuie la modelarea fizic a formei executabile a unui sistem soft.
n UML, toate rezultatele demersului de modelare fizic sunt abstractizate de conceptul de
component.
Tot mai multe sisteme de operare i limbaje de programare ofer suport direct pentru
conceptul de component. DLL-urile, i componentele COM, DCOM, DCOM+ din Windows,
EJB-urile, componentele Delphi sunt doar cteva exemple de componente care pot fi reprezentate
n proiectele UML folosind conceptul de component.
Conceptul de component abstractizeaz i alte tipuri de produse ale efortului de dezvoltare,
produse care, ntr-un fel sau altul particip la dinamica unui sistem executabil. Astfel de produse
sunt: tabelele, fiierele, documentele.
UML furnizeaz o reprezentare grafic canonic pentru conceptul de component (Figura
123). Aceast notaie canonic permite vizualizarea unei componente, independent de mediul de
operare sau limbajul de programare folosit. Utiliznd stereotipurile, putem adapta aceast notaie
pentru a reprezenta tipuri particulare de componente.
Concepte folosite
O component este o parte fizic, nlocuibil, a unui sistem soft, gndit i dezvoltat
pentru a asigura realizarea unui anumit numr de interfee.










Figura 123. Notaia canonic pentru component

kernel32.dll
nume component
Fiecare component trebuie s aib un nume care o distinge de celelalte componente. Numele
unei componente este un ir de caractere care poate fi recunoscut ca nume simplu (n cazul n care
irul de caractere conine doar numele componentei) sau nume cu cale (n cazul n care numele
componentei este prefixat de numele sistemului de pachete n care este rezident componenta).
Prin aceasta UML nu face dect s vin n ntmpinarea unor practici, tot mai mult rspndite,
legate de organizarea proiectelor, n general i a proiectelor complexe, n special.












Figura 124. Component cu nume simplu i component cu specificarea pachetului i a
versiunii
Comparaie ntre componente i clase
n multe privine, componentele sunt asemenea claselor. Aceasta, deoarece: amndou au
nume, amndou pot realiza un anumit numr de interfee, amndou pot participa n relaii de
asociere, generalizare i dependen, amndou pot avea instane, amndou pot participa n
interaciuni. Cu toate acestea, exist i diferene semnificative ntre componente i clase.
1. Clasele sunt abstracii logice; componentele sunt pri fizice ale sistemelor soft, a
cror existen este esenial legat de lumea biilor. n alt ordine de idei, o
component (care are o existen palpabil) poate fi rezident ntr-un nod; o clas (care
este o abstracie) nu.
2. Componentele reprezint mpachetarea fizic a unor entiti logice; nivelele de
abstractizare la care se afl cele dou tipuri de componente sunt diferite.
3. Clasele pot avea atribute i operaii, expuse direct. n general, componentele au doar
operaii, care sunt accesibile numai prin intermediul interfeelor lor.
Prima diferen este cea mai important. Cnd modelm un sistem, decizia de a folosi o clas
sau o component este, n esen simpl: dac lucrul (procesul) modelat este rezident n nod,
apelm la conceptul de component; n caz contrar, apelm la conceptul de clas.
A doua diferen sugereaz o relaie ntre clase i componente. n spe, o component este
implementarea fizic a unii set de alte elemente logice, cum sunt clasele i colaborrile. Dup cum
se poate vedea n Figura 125, o astfel de relaie poate fi ilustrat ca o relaie de dependen.
n sfrit, cea de-a treia diferen evideniaz modul n care interfeele interfer cu
componentele i clasele. Practica impune observaia c att componentele ct i clasele pot realiza
o interfa, n timp ce serviciile unei componente pot fi apelate, exclusiv, prin intermediul
interfeelor expuse.


















Figura 125. O component i clasele care i implementeaz interfeele expuse

dirijarerobot.dll
Obstaco
l
Motor
Traseu
component
dependen
clase
hello.javal system::dialog.dll
{version=2.5}
nume simplu nume cu cale
Comparaie ntre componente i interfee
O interfa este o colecie de operaii care sunt folosite pentru a specifica serviciile oferite de o
clas sau o component. Relaia dintre component i interfa este important. Cele mai
importante tehnologii de dezvoltare bazate pe componente (COM+, DCOM+, CORBA, EJB)
folosesc interfeele ca un liant care ine laolalt mai multe componente. Folosirea uneia dintre
tehnologiile de mai sus nseamn descompunerea implementrii fizice prin specificarea interfeelor
care reprezint perspectivele majore asupra sistemului. Urmtorul pas nseamn furnizarea
componentelor care realizeaz aceste interfee, precum i alte componente care acceseaz
serviciile prin interfee proprii. Acesta este, n fond, mecanismul client-server, care permite
desfurarea unui sistem ale crui servicii sunt, ntr-o oarecare msur, independente de nodul n
care sunt rezidente i, n mod natural, oricnd pot fi nlocuite. Posibilitatea de a nlocui o
component cu alta, sub rezerva c interfaa este conservat, este una din trsturile cele
mai importante ale dezvoltrii orientate pe componente. Dup cum reiese i din Figura 126,
exist dou moduri de a ilustra relaia dintre o component i interfeele pe care le expune.























Figura 126. Reprezentarea relaiilor dintre componente i interfee

Prima modalitate de reprezentare se bazeaz pe forma contras (iconic) a unei interfee. Cea
de-a doa modalitatese bazeaz pe forma expandat a unei interfee. Dup cum se poate vedea,
interfaa opereaz ca un separator ntre limitele logice i fizice ale soluiei orientat pe
componente a unei probleme.
Astfel c, o component care realizeaz o interfa este conecat la interfa folosind notaia
aferent unei relaii de realizare. De asemenea, o component care acceseaz serviciile altei
componente, prin intermediul interfeei, este conectat folosind notaia pentru relaia de
dependen. Interfaa pe care o component o realizeaz se numete interfa exportat. O
component poate exporta mai multe interfee. Interfaa pe care o component o folosete se
numete interfa importat. O component poate folosi mai multe interfee. De asemenea, s
mai precizez c o component poate face, n acelai timp, import i export de interfee.


Componentele-structuri binare care pot fi mlocuite
Dezvoltarea orientat pe componente are implicaii profunde asupra unora dintre factorii cheie
ai calitii unui sistem soft: reutilizabilitatea i adaptabilitatea. n dezvoltarea orientat pe
componente se face o distincie clar ntre urmtoarele trei perspective asupra soluiei unei
probleme:

perspectiva conceptual
specificarea
implementarea

ImageHandler
image.java
component.java
dependen realizare
image.java component.java
<<interface>>
ImageHandler

error:int;
msgerr:string;
:

imageUpdate();
:
Tentaiei de a trece direct la implementare trebuie s nvm s-i opunem, cu benefici
indiscutabile, dou tipuri fundamentale de reflexie: conceptualizarea (prin care domeniul
problemei este radiografiat, organizat conceptual, fcnd, pe ct posibil, abstracie de a orice
element hard sau soft care ar putea influena perspectiva conceptual) i specificarea (prin care se
face un pas nainte n elaborarea soluiei, pas care const n identificarea i definirea proprietilor
tuturor interfeelor). Specificarea unor interfee stabile rezolv multe dintre problemele grave care
pot apare n evoluia unui proiect sau a unei soluii.
Astfel c, o component care este un produs al unui demers de tip implementaional, se
reduce, n extremis, la o structur binar (fizic) care poate oricnd s fie nlocuit de o alt
structur binar care opereaz n numele aceluiai set de interfee. Nu este doar o teorie frumoas,
ci este o modalitate din ce n ce mai rspndit de a face sistemele soft s in pasul cu evoluiile
galopante din lumea sistemelor de operare, a mediilor de dezvoltare i a echipamentelor de calcul.

Tipuri de componente
UML recunoate trei tipuri de componente:

componente - desfurare;
componente - produse de lucru secundare;
componente n execuie.

Componentele desfurare sunt componente necesare i suficiente pentru a alctui un
sistem executabil pe un calculator real (DLL-uri, i fiiere executabile n cazul platformei de
operare Windows, ca s dm un exemplu arhicunoscut). Definiia UML a componentei este
suficient de larg pentru a include modele obiect descrise deja (precum COM+, CORBA, EJB)
precum i modele obiect alternative precum paginile WEB dinamice, tabelele bazelor de date i
executabilele care folosesc mecanisme de comunicare speciale.

Componentele produse de lucru secundare
n esen, aceste componente sunt produse reziduale ale procesului de dezvoltare, constnd
din: fiiere cu cod surs i fiiere cu date, din care sunt obinute componentele desfurare.
Aceste componente nu particip direct n sistemele executabile, dar sunt produse folosite n
crearea, modificarea, dezvoltarea sistemelor executabile.

Componentele create n execuie
Aceste componente sunt create ca o consecin a activrii unui sistem executabil; de exemplu,
un obiect COM+, instaniat folosind o funcie dedicat a unui DLL, situaie obinuit n aplicaiile
care folosesc intens tehnologia COM+ a firmei Microsoft.

Organizarea componentelor
Componentele pot fi organizate prin gruparea lor n pachete, n acelai mod n care organizm
clasele. n organizarea componentelor putem apela la relaii, precum: dependena, generalizarea,
asocierea (inclusiv agregarea) i realizarea.

Elemente standard
Toate mecanismele UML de extindere pot fi aplicate componentelor. Cel mai des sunt folosite
valorile etichetate (pentru a extinde proprietile componentelor, ca de exemplu, specificarea
versiunii componentei) i stereotipurile (pentru a specifica tipuri noi de componente).
UML definete cinci stereotipuri standard care pot fi aplicate componentelor:

<<executable>> - specific o component care poate fi executat ntr-un nod;
<<library>> - specific o bibliotec obiect, static sau dinamic;
<<table>> - specific o component care reprezint o tabel a unei baze de date;
<<file>> - specific o component care reprezint un document care conine cod surs
sau date;
<<document>> - specific o component care reprezint un document.

Tehnici de modelare uzuale n lucrul cu componente
1. Cea mai rspndit utilizare a componentelor este n modelarea componentelor
desfurare care alctuiesc implementarea unui sistem soft. Dac implementarea sistemului
const doar dintr-un fiier executabil, modelarea componentelor este inutil. Dac, ns, sistemul
n curs de desfurare este alctuit din mai multe executabile i biblioteci asociate, modelarea
componentelor poate ajuta la vizualizarea, specificarea, construirea i documentarea deciziilor
referitoare la sistemul fizic.
Pentru majoritatea sistemelor, considerentele care pot influena elaborarea modelului
componentelor se refer la modul n care este imaginat implementarea fizic a sistemului
problem a crei rezolvare, la rndul ei, depinde de o serie de aspecte tehnice: facilitile oferite de
sistemul de operare n ceea ce privete lucrul cu componente, managementul sistemului dup
desfurare i inteniile de reutilizare a componentelor sistemului la realizarea altor sisteme. Un
exemplu de modelare a componentelor, ntr-un astfel de context este prezentat n Figura 127.




























Figura 127. Modelarea unui sistem bazat pe executabile i biblioteci executabile

2. Adeseori, se ntmpl s realizm sisteme care, ajunse n faza de desfurare, pe lng
executabile clasice i biblioteci sunt nsoite de o serie de alte componente, precum: fiiere de
date, fiiere de help, script-uri, fiiere de log, fiiere de iniializare sau fiiere de
instalare/dezinstalare. Dat fiind importana acestor tipuri de componente pentru corecta
funcionare a sistemelor din zilele noastre, modelarea lor este esenial pentru a asigura un control
bun al configurrii sistemului i nu numai.

3. n practica ingineriei software mai exist cel puin dou situaii n care putem
recunoate scenarii deosebite n utilizarea conceptului de component. Este vorba de
modelarea unei API (problem extrem de delicat din foarte multe puncte de vedere, care, la un
moment dat pune i problema modelrii componentelor care asigur funciile API) i de
modelarea codului surs (de la un limbaj la altul exist soluii tehnice diferite, dar din punct de
vedere semantic lucrurile se aseamn: diferitele coduri surs care compun sistemul formeaz un
sistem n care opereaz diferite tipuri de relaii, toate reprezentabile cu ajutorul notaiei UML).

6.3 Perspectiva desfurare a unui sistem soft
Nu este nevoie de prea mult efort pentru a nelege faptul c, odat realizate, componentele
trebuie desfurate pe dispozitive hard adecvate execuiei sau utillizrii lor. Pentru a modela
topologia hardului pe care este executat un anumit sistem, conceptul cheie este conceptul de nod.
Un nod desemneaz un procesor sau un dispozitiv pe care vor fi desfurate componente. Atunci
cnd reflectm la arhitectura unui sistem soft, n principiu trebuie s evalum corect att
dimensiunea logic ct i dimensiunea fizic a soluiei. Din perspectiv logic vom opera cu
modele care se pot referi la clase, interfee, colaborri, interaciuni, maini de stare. Din
perspectiv fizic vom opera cu modele care se refer la componente (care reprezint, practic,
mpachetarea fizic a elementelor care compun dimensiunea logic) i noduri (care desemneaz
server.exe foxtoacces.dll
accestofox.dll
xml.dll
{version=5.1}
hard-ul pe care componentele sunt desfurate i executate. UML furnizeaz o reprezentare grafic
simpl pentru un nod, ca n Figura 128.
n Figura 128 este prezentat notaia canonic pentru un nod, notaie care poate fi adaptat la
situaii particulare, folosind mecanismele UML de extindere.
Invit cititorul s acorde atenia cuvenit importanei pe care o are conceptul de nod pentru
reprezentarea corect i complet a elementelor eseniale, care se refer la arhitectura unui sistem
soft.











Figura 128. Notaia UML pentru conceptul de nod

Concepte folosite
Dup cum, probabil c s-a neles, un nod este un element fizic care exist n timpul execuiei
unui sistem soft i reprezint o resurs de calcul avnd, n general, cel puin memorie i, de cele
mai multe ori, capabiliti de procesare.

Numele unui nod
Fiecare nod trebuie s aib un nume care l deosebete de alte noduri. la fel ca n cazul
componentelor, numele unui nod poate fi simplu sau cu cale asociat. In cazul unui nume cu cale,
numele nodului este prefixat de sistemul de pachete n care nodul este rezident, ca i model de
reprezentare a unor proprieti ale sistemului. Astfel c, pe lng situaia din Figura 128 (cea mai
rspndit, de altfel) putem avea i situaia din Figura 129.












Figura 129. Nod al crui nume este prefixat de cale

Nu mai insist asupra gradelor de libertate care guverneaz protocolul de formare a numelui
unui nod.

Comparaie ntre noduri i componente
n multe privine, nodurile sunt asemntoare componentelor: ambele au nume, pot participa
n relaii de asociere, dependen i generalizare, pot avea instane, pot participa n interaciuni.
Exist, totui i deosebiri semnificative ntre noduri i componente:

Componentele particip la execuia unui sistem; nodurile sunt acele lucruri
(dac este ngduit exprimarea) pe care sunt executate componentele;
Componentele reprezint mpachetarea fizic a altor elemente logice; nodurile
reprezint desfurarea fizic a componentelor.

Un set de obiecte sau componente care sunt alocate unui nod, sub forma unui grup, se numete
unitate de distribuie. Se poate intui o anumit asemnare i ntre noduri i clase, dac se observ
faptul c unui nod i putem specifica att atribute ct i elemente de comportament. A se vedea
exemplul din Figura 130.

Server
nume nod
SSOFD::decan

{SSOFD=Subsistem
Optimizare Fluxuri
Decanat}




















Figura 130. Nod cu atribute i operaii

Cititorul trebuie s neleag faptul c legtura dintre noduri i componente este foarte
important pentru perspectiva arhitectural asupra unui sistem.
Nodul prezentat n Figura 130 ne atrage atenia asupra unei semantici suplimentare a
conceptului de nod. Este vorba despre faptul c un nod poate apare ntr-o diagram de desfurare
n dou ipostaze: ca tip sau ca instan a unui tip de nod.
Ne putem imagina c n sistemul informaional al unei universiti vom avea nevoie de un tip
de nod numit Decan, n care sunt concentrate o serie de resurse hard i soft cu ajutorul crora
actorul numit decan se poate informa n anumite privine. Diagramele de desfurare de nivel de
abstractizare nalt opereaz cu astfel de tipuri de noduri. O diagram de desfurare care se
mapeaz pe distribuia geografic a utilizatorilor va opera cu instane-nod, asemenea instanei
d:Decan din Figura 130.

Organizarea nodurilor
Aa cum am anticipat deja, nodurile pot fi organizate prin gruparea lor n pachete, n acelai
mod n care procedm cnd este vorba de organizarea claselor i componentelor. De asemenea,
organizarea nodurilor poate nsemna i specificarea, eventual, a relaiilor dintre noduri.

Legturi ntre noduri
Relaia uzual ntre noduri este asocierea. n acest context, o asociere abstractizeaz o legtur
fizic ntre noduri ( de exemplu, o conexiune Ethernet, o linie serial sau o magistral de
comunicaie partajat). Deoarece nodurile sunt, oarecum, asemntoare claselor, n procesul de
modelare putem apela la toate artificiile referitoare la asocieri, pe care le cunoatem de la clase (
roluri, multiplicitate, constrngeri).
















Figura 131. Asocieri ntre noduri
d:Decan

frecventaProcesor=700MHZ
memorie=256MB
:

Deploys
sitscol.xex
dateper.exe
:
<<10 T
<<10 T
<<10 T
Secretar
Decan
Server
Cancelar
n Figura 131 sugerez o parte din potenialul de modelare al asocierilor ntre noduri.
Asocierile dintre nodurile prezentate n Figura 131 sunt sterotipizate, dup cum se poate observa.

Tehnici de modelare uzuale n lucrul cu noduri
Modelarea procesoarelor i a echipamentelor periferice
Modelarea procesoarelor i a echipamentelor periferice care alctuiesc topologia unui sistem
(izolat, integrat, client-server sau distribuit n genere) este utilizarea obinuit a nodurilor.
Deoarece toate mecanismele de extindere ale UML-ului sunt aplicabile nodurilor, vom putea folosi
stereotipurile pentru a a specifica tipuri noi de noduri, utile, ulterior, n specificarea varietilor de
procesoare i echipamente periferice.
Un procesor este un nod care are capabiliti de procesare, ceea ce nseman c poate
executa o component. Un echipament periferic este un nod care nu are capabiliti de
procesare. n general, echipamentul periferic este un gen de interfa a sistemului cu lumea real.
Paii care trebuie urmai cnd modelm procesoare sau echipamente periferice sunt:

1. Identificarea dispozitivelor de calcul ale perspectivei desfurare a sistemului i
modelarea lor ca noduri.
2. Dac aceste elemente reprezint procesoare sau echipamente periferice generice,
atunci ele pot fi definite ca stereotipuri. Dac, ns, ele sunt varieti de procesoare i
echipamente periferice, care fac parte din vocabularul domeniului problemei, atunci
alegei un stereotip adecvat pentru fiecare.
3. Dac este cazul, evideniai atributele i operaiile care pot fi asociate cu fiecare nod.

Exemplificare, n Figura 132.











Figura 132. Procesor i echipamente periferice, modelate ca noduri

Modelarea distribuirii componentelor
Cnd modelm topologia unui sistem, de multe ori este util vizualizarea sau specificarea
distribuiei fizice a componentelor sistemului pe procesoare i echipamentele periferice care
alctuiesc sistemul.
Paii de urmat cnd modelm distribuirea componentelor sunt:

1. Fiecare component semnificativ a sistemului se aloc unui nod.
2. Se identific componentele care vor fi executate pe mai multe noduri (n aplicaiile
client-server este uzual ca aplicaia client s fie executat pe mai multe noduri
procesor).
3. Redai alocrile componentelor la noduri folosind una din cele trei ci posibile:

Nu indicai alocarea componentelor n diagrama de desfurare, dar rezolvai
aceast problem utiliznd alte mijloace de specificare;
Evideniai alocrile folosind relaia de dependen;
Listai componentele desfurate pe un nod ntr-un compartiment adiional al
nodului.

Cititorul trebuie s neleag, nc odat, faptul c UML ofer soluii pentru multe probleme i
situaii practice i permite, prin folosirea mecanismelor de extindere, adaptarea la probleme i
situaii neconvenionale.
Evident, lumea componentelor i a nodurilor este esenial pentru realizarea diagramelor de
componente i a diagramelor de desfurare, mpreun reprezentnd o mare parte din nsuirile
perspectivei implementare a unui sistem soft.

consol imprimant
<<processor>>

Server
sistem RAID
Expediia UML se ncheie, n aceast ediie a crii aici, autorul fiind contient de faptul c a
pus doar bazele modelrii UML, aa cum sugereaz, de altfel, titlul crii.
Documentaia pus la dispoziie n site-ul firmei Rationa, www.rational.co, numeroasele cri
aprute, ce-i drept, la diferite edituri din alte ri, lucrrile de fundamentare i popularizare a
UML-ului, risipite n tot felul de site-uri, utilizarea tools-urilor care susin modelarea UML, toate
acestea pot ajuta la transformarea procesului de modelare n UML ntr-un exerciiu firesc, care
poate aduce multe beneficii celui care l efectueaz.



















Capitolul 7
Fluxuri de lucru fundamentale pentru un
proiect dezvoltat cu suport UML.
Structura i coninutul documentaiei
realizate

...Dincolo de UML, ca limbaj, se afl procesul de utilizare efectiv a
acestuia. Aceasta este o problem att de important i complex,
nct, nici o clip nu m-am gndit c a putea s o lmuresc n
Capitolul 7.















7.1 Structura i coninutul documentaiei realizat n faza de analiz a
cerinelor

Studiul preliminar

Specificarea obiectivelor generale
Surse de informaii
Starea curent
Clarificarea cerinelor
Delimitarea ariei de probleme
Identificarea actorilor
Descrierea contextului
Identificarea contextelor de utilizare (use case)
Prioriti
Soluii alternative
Recomandri
Cerine viitoare

Analiz i proiectare rapid (opional)

Analiza proceselor organizaionale (din perspectiv informaional)

Analiza use-case-urilor

Evaluarea arhitecturii i a mediului de dezvoltare a softului

Planificare proiect, organizare, estimare costuri

Observaie
Propunerea este tributar perspectivei obiect orientate, din punct de vedere al modului de
abstractizare a soluiei i modelului RUP (Rational Unified Process) din punct de vedere al
aspectelor procesuale ale dezvoltrii unui sistem soft.

Analiza cerinelor este justificat de faptul c specialitii n IS, de regul nu sunt i specialiti
n domeniul problemei. Firete, pentru a realiza un soft de calitate trebuie colectate informaii
despre problema de rezolvat. De fapt, nsi planificarea riguroas a dezvoltrii unui soft este
posibil numai dup ce au fost nelese bine cerinele fa de sistemul soft i au fost eliminate
eventualele nenelegeri relativ la aceste cerine.
Pentru a clarifica, din start, coninutul fazei de analiz a cerinelor, din perspectiva unei
abordrii compatibil cu UML, voi pune n discuie schema din Figura 133.
Schema prezentat n Figura 133 evideniaz activitile specifice fazei de analiz a cerinelor,
documentele realizate i modul de nlnuire a acestor activii. Pentru mai mult claritate voi
prezenta n continuare, pe scurt, coninutul fiecreia dintre activitile prezentate n Figura 133.

Studiul preliminar
n ingineria softului, nainte de a rezolva o problem sunt multe lucruri de vzut i lmurit;
este evident c ar trebui, nainte de orice altceva, s se obin o serie de informaii relativ la
cerinele asumate efectiv, posibilele soluii alternative i alegerea variantei convenabil pentru
proiect .
n acest scop, practica a validat ca fiind foarte util urmtoarea procedur de urmat n
elaborarea studiului preliminar, de ctre persoana sau persoanele desemnate.

Specificarea obiectivelor generale
mpreun cu beneficiarul se stabilesc obiectivele generale ale proiectului i se stabilesc
limitrile de care trebuie s se in cont n timpul lucrului la proiect. Documente rezultate:
protocoale ale conferinelor, n care sunt fixate concluziile acestor conferine, relativ la
aspectele precizate mai sus.


































Figura 133. Coninutul fazei de analiz a cerinelor

Surse de informaii
Sunt identificate documentele de interes pentru proiect i sunt colectate ideile deja existente
relativ la rezolvarea problemei. Documentele rezultate: lista surselor de informaii i a
persoanelor de contact.

Starea curent
Utiliznd metoda chestionarelor, interviurile, etc. se pot obine date despre starea curent a
sistemului cruia dorim s-i optimizm fluxurile informaionale.

Clarificarea cerinelor
Diferitele ntlniri i discuii cu specialitii din domeniul problemei (departamentele tehnice
ale organizaiilor pentru care se realizeaz proiectul, de regul) sunt folosite pentru a
determina, cu maxim acuratee posibil, cerinele generale, de natur funcional i non-
funcional, pe care i le va asuma proiectul, odat demarat.

Delimitarea ariei de probleme
Pentru ca proiectul s aib succes, o condiie important este stabilirea frontierelor demersului
de dezvoltare: ce anume prezint interes pentru soluia problemei; care sunt aspectele
care nu vor fi luate n consideraie la elaborarea soluiei. Cerina aceasta vine din teoria
sistemelor, care pune principiul stabilirii frontiereor unui sistem la loc de frunte printre
mijloacele de stpnire a complexitii n procesul de modelare. Odat luate deciziile corecte
n materie de frontiere, vom ti care sunt interfeele utilizate de sistem pentru a comunica cu
lumea exterioar lui.

Identificarea actorilor
Cine i ce face? Aceasta este una din ntrebrile cheie n aceast etap a demersului de analiz
a cerinelor. Mai precis spus, trebuie s stabilim clar alocarea diferitelor categorii de utilizatori
ai sistemului pe task-uri, avnd competene bine specificate n domeniul problemei. Rezultate
posibile: diagrame de actori, scheme cu prezentarea competenelor utilizatorilor, etc.

Start
{Opional}
Studiul
preliminar
(P1)
Analiz i
proiectare
rapid
(P2)
Analiza
organizaion
al (P3)
Studiul
preliminar
Rezultate
Terminare
studiu
preliminar
Analiza
use-case-
urilor (A1)
Evaluare
arhitectur i
mediu de
dezvoltare a
softului (A2)
Planificare
proiect,
Organizare,
Estimare
costuri (A3)
Use case-uri
Modelul
actorilor
Glosar cu
termeni
tehnici
Glosarul de
termeni tehnici
Modelul
arhitectural
abloane i
linii de
dezvoltare
Stop
Descrierea contextului
Cum va arta mediul n care sistemul n curs de dezvoltare va trebui s fie executat? Se vor
stabili elementele directoare referitoare la modelul infrastructurii ce va fi folosit cnd
sistemul va fi pus la lucru n termeni reali: hard, soft de baz, tehnologii, etc.

Identificarea contextelor de utilizare (use case)
Care este definiia contextelor de utilizare pe care se presupune c sistemul le va suporta? O
list cu numele acestor contexte de utilizare este de mare utilitate pentru a continua cu succes
analiza cerinelor.

Prioriti
Care sunt problemele care trebuie rezolvate urgent? Care sunt problemele care mai pot
atepta? Sunt dou ntrebri importante pentru procesul de planificare a dezvoltrii
proiectului.

Soluii alternative
Mai multe soluii alternative pot fi abordate. Acestea trebuie confruntate, din perspectiva
restriciilor proiectului i a diferitelor criterii care pot avea implicaii asupra calitii,
termenului de execuie i preului. Soluiile alternative vor fi prezentate nsoide de descrieri
care pot facilita alegerea variantei care este adecvat proiectului n cauz.

Recomandri
Soluiile alternative trebuie evaluate (pe baza criteriilor mai sus stabilite). Dac este necesar se
poate face i o analiz a profitabilitii adoptrii fiecreia dintre soluii. Pe aceast baz se pot
formula recomandri cu privire la alternativa optim.

Cerine viitoare
Din perspectiva alternativei recomandate, se pot face i sugestii cu privire la cerine viitoare
de luat n consideraie, fa de sistemul soft.

Analiz i proiectare rapid
nainte de nceperea efectiv a ciclului de dezvoltare se poate organiza o activitate de tip RAD
(Rapid Analysis and Design) pentu a identifica i structura cerinele fundamentale fa de sistemul
soft.

Analiza proceselor organizaionale
Doar n situaii excepionale sistemul care urmeaz s fie dezvoltat nu are nici un fel de
precursor. De cele mai multe ori, el va fi integrat ntr-un sistem de aplicaii deja existent sau va
extinde acest sistem de aplicaii. Pentru a clarifica modul n care se va realiza integrarea sau
extinderea optimal, este necesar un exerciiu de analiz i modelare a proceselor organizaionale.

Analiza use-case-urilor
Cazurile relevante de utilizare a unui sistem soft pot fi analizate i descrise cu ajutorul
contextelor de utilizare (use case). Contextele de utilizare pot fi o soluie pentru descrierea
cerinelor fa de sistemul soft (de interes pentru diferite categorii de parteneri ai proiectului) dar i
pentru introducerea specialitilor n IS (ingineria softului) n problematica de baz a realizrii
sistemului soft (punte de legtur ntre domeniul problemei i domeniul aplicaiei).

Evaluarea arhitecturii i a mediului de dezvoltare a softului
n condiiile actuale, dezvoltarea unui sistem soft devine o problem, n mod paradoxal i
datorit nenumratelor elemente suport existente pe piaa tools-urilor, care pot fi folosite pentru a
optimiza procesul de dezvoltare.
n egal msur, dinamica sistemelor informaionale modelate de ctre sistemeloe soft este un
factor care poate influena hotrtor calitatea unei soluii. De aceea, evaluarea critic a arhitecturii
propuse pentru sistemul soft precum i a opiunilor n materie de tools-uri folosite este obligatorie
pentru a elimina posibile riscuri n procesul de dezvoltare.

Planificare proiect, organizare, estimare costuri
Pentru managementul unui proiect, rezultatele i evalurile unui studiu preliminar reprezint
baza pentru planificarea viitoare a dezvoltrii sistemului soft. Figura 133 i comentariile care au
urmat-o, pot fi luate ca repere pentru ntocmirea unui document care tezaurizeaz rezultatul unui
demers de analiz a cerinelor fa de un sistem soft.

7.2 Structura i coninutul documentaiei realizat n faza de analiz

Reamintesc, pentru nceput, structura unui document, n care se reprezint rezultatele fazei de
analiz obiect orientat. Ulterior, voi realiza o descriere succint a coninutului fiecrei seciuni
poteniale a unui astfel de document.
Analiza contextelor de utilizare (use cases)
Arhitectura aplicaiei
Dicionarul tehnic
*Prototipizarea explorativ
*Cartelele CRC (Clase+Responsabiliti+Colaboratori)
Identificarea claselor din domeniul problemei
Modelarea activitilor
Stabilirea componentelor sistemului soft

Analiza contextelor de utilizare (use cases)
Un context de utilizare descrie interaciunea dintre utilizatori i un sistem soft necesar pentru a
ndeplini anumite sarcini n cadrul activitilor specifice unei organizaii. Contextele de utilizare
apar n cadrul unor procese organizaionale. Un proces poate fi mprit n mai multe contexte de
utilizare, dac este, n mod evident, ntrerupt la un moment dat, sau dac pri, n mod clar
identificabile ale procesului, sunt gestionate de persoane diferite.
Persoane de contact n faza de analiz
Pentru a ncepe analiza domeniului problemei, trebuie s fie stabilite persoane de contact
printre experii n domeniul problemei. Adesea, dar nu ntodeauna, aceste persoane sunt viitorii
utilizatori. Pentru succesul unui proiect este important s se fac distincie ntre diferite persoane
de contact, acestea putnd fi: utilizatori novici, experi, experi n domeniul problemei sau, n cazul
membrilor colectivului de management, trebuie stabilit dac au sau nu putere de decizie, relativ la
stabilirea cerinelor i a contextelor de utilizare.
Calitatea demersului ntreprins n faza de analiz este esenial influenat de prestaia
experilor n domeniul problemei, ca persoane de contact.

Obiecte i materiale aflate n sfera de interes asociat domeniului
problemei
Analiza domeniului problemei presupune, de asemenea, colectarea i stabilirea unor obiecte i
materiale precum: formulare, rapoarte, descrierea unor procedee de prelucrare, etc.

Identificarea actorilor i a contextelor de utilizare
Acest demers presupune distincia ntre contextele de utilizare a sistemului soft(CUSS) i
contextele de utilizare asociate perspectivei organizaionale(CUAPO). Mai precis, n CUAPO
actorii pot avea atribuiile legate de toate procesele organizaionale, n timp ce n cazul CUSS
atribuiile sunt limitate la contactul direct cu sistemul soft.
Ca rezultat, se vor obine Diagrame de contexte de utilizare ale sistemului soft i, dac este
cazul, diagrame care evideniaz structura ierarhic a actorilor (generat evideniind relaiile
de motenire dintre acetia).

Descrierea contextelor de utilizare
Reprezentarea contextelor de utilizare cu ajutorul elipselor (UML) i gruparea lor n pachete,
dac este cazul, reprezint primul pas n aceast etap. Urmtorul pas l reprezint descrierea mult
mai detaliat a contextelor de utilizare, folosind scenarii textuale, care vor conine informaii
utilizate ulterior pentru a realiza diagrame de secven i diagrame de activitate.

Clarificarea cerinelor fa de sistemul soft
Tot n cadrul acestui demes, este oportun s se fac i o estimare mai realist a unora dintre
cerinele impuse viitorului sistem soft, precum: necesarului de date ce urmeaz s fie prelucrate i
pstrate pe suport extern, caracteristicile hard-ului folosit, etc.

Arhitectura aplicaiei
nainte de a ncepe primele activiti de proiectare, trebuie specificat arhitectura sistemului
soft. n ultim analiz, specificarea arhitecturii nseamn specificarea tipurilor de clase
folosite n realizarea sistemului soft i, n consecin, specificarea interfeelor care urmeaz a
fi proiectate. O arhitectur profesional asigur:

diviziune a muncii, clar, n mulimea obiectelor sistemului soft;
flexibilitate, pe termen lung, n dezvoltarea sistemului soft;
un mare grad de reutilizare a efortului de dezvoltare a sistemului soft.

Ca exemplu remarcabil de pattern, n materie de arhitectur, amintim paradigma MVC
(Model-View-Controller).

Dicionarul tehnic
Efortul de acomodare cu domeniul problemei are, ca o consecin imediat, reliefarea unor
termeni tehnici, importani pentru cristalizarea unei descrieri coerente a domeniului soluiei. Aceti
termeni sunt adunai ntr-un dicionar tehnic sau glosar de termeni, descrii cu maximum de
acuratee.
Aceste instrumente sunt necesare pentru a rezolva probleme precum:

comunicarea corect ntre diferitele categorii de parteneri de proiect;
evitarea interpretrii diferite a termenilor de ctre utilizatori i experii n domeniul
soluiei.

Prototipizarea explorativ
Prototipurile explorative sunt, n cele mai multe situaii, secvene de dialoguri proiectate care
trebuie s ilustreze contextele de utilizare anterior elaborate. Dialogurile proiectate sunt dialoguri
executabile, n care pot fi introduse date, dar care nu includ toate caracteristicile unui sistem soft
complet (precum funciile de help, tratarea sistematic a erorilor, memorarea datelor pe suport
extern de memorie, fiabilitate, etc.).
n esen, prototipizarea explorativ se folosete pentru a arta utilizatorilor i specialitilor n
IS aspectele actuale ale viitorului sistem soft.
Aceste dialoguri proiectate vor fi abstractizate, n final, ca interfee de comunicare cu sistemul
soft, asociate unui anumit tip de actor.

Cardurile CRC
Cum am mai spus, abrevierea CRC vine de la Class Responsabilities Collaborators. n
consecin, card-urile CRC sunt instrumente care permit notarea, pe un format adecvat, a claselor,
a responsabilitilor acestor clase i a colaboratorilor acestor clase.

Identificarea claselor din domeniul problemei
O clas din domeniul problemei descrie un obiect, un concept, un loc sau o persoan din
domeniul problemei, la un nivel de detaliere care poate fi neles de experi din domeniul
problemei. Clasele astfel identificate, vor constitui un sistem de clase de maxim importan
pentru viitoarea soluie detaliat, cu referire la design-ul claselor. De reinut faptul c, pentru
moment, detaliile i subtilitile tehnice, legate de specificarea complet a modelului claselor sunt,
n mod contient, omise.

Modelarea activitilor
Contextele de utilizare sunt folosite pentru a descrie cerinele fa de sistemul soft. Pentru a
detalia procesele pe care sistemul le suport n cadrul acestor contexte de utilizare, un prim pas l
reprezint elaborarea diagramelor de activitate.
Elaborarea diagramelor de activitate nseamn asigurarea unei baze importante pentru a face
tranziia de la analiz la proiectare, satisfcnd cerinele specificate fa de sistemul soft.

Stabilirea componentelor viitorului sistem soft.
Se poate spune, fr a grei c scopul fazei de analiz este stabilirea componentelor
viitorului sistem soft. La urma urmei, analiza nseamn tocmai procesul prin care realitatea
(cercetat, observat, modelat) este descompus n pri componente, articulate ntre ele astfel
nct s rezulte un ntreg cu o funcionalitate scontat.
Problema identificrii componentelor viitorului sistem soft este, n egal msur, o problem
dificil i cu implicaii mari asupra calitii soluiei. Decizii greite la acest nivel se pot transforma
uor n motive de deraiere a proiectului, la un moment dat al evoluiei lui.
UML, de exemplu, posed destul sintax pentru a captura rezultatul procesului de
identificare a componentelor care formeaz viitorul sistem soft.

7.3 Structura i coninutul documentaiei realizat n faza de design
Reamintesc, pentru nceput, structura unui document, n care se reprezint rezultatele fazei de
design obiect orientat. Ulterior, voi realiza o descriere succint a coninutului fiecrei seciuni
poteniale a unui astfel de document.
Proiectarea componentelor;
Specificarea dialogurilor;
Identificarea domeniului claselor i a relaiilor dintre clase;
Delimitarea componentelor;
Specificarea operaiilor;
Specificarea atributelor;
Modelarea strilor;
Modelarea activitilor;
Modelarea interaciunii obiectelor;

Proiectarea componentelor
Se tie c pentru identificarea i definirea componentelor, punctul de pornire l reprezint
modelarea activitilor.
Stabilirea de frontiere ntre diferite tipuri de activii nseamn necesitatea asigurrii unor
servicii de ntreinere a fluxurilor de activiti ntre componente diferite. Proiectarea
componentelor ncepe cu specificarea interfeelor componentelor, cu ajutorul crora se rezolv
problemele de asigurare a fluxurilor de activiti ntre componente diferite.
Interfeele sunt, de fapt, descrise cu ajutorul claselor. Cel mai natural este pus aceast
problem n Java sau n mediile vizuale de programare, care ofer suport pentru promovarea
tehnologiei COM, de exemplu.
Proiectarea componentelor presupune, n al doilea rnd, delimitarea componentelor din
perspectiva modelului claselor. Informaii necesare pentru specificarea interfeelor mai pot fi
obinute i din analiza componentelor care i asum responsabiliti n ceea ce privete dialogul
aplicaie-utilizator.
Aadar, materia prim pentru proiectarea componentelor este:

modelarea activiilor;
interfeele cerute de necesitile de comunicare derivate din semantica modelului
claselor.
interfeele aplicaie-utilizator.

Observaie
Analiza perspectivei arhitecturale, comunicarea dintre diferitele nivele ale sistemului,
structurat conform unei anumite arhitecturi, st la baza specificrii a unui aa zis cadrul de lucru
de baz al aplicaiei.
De regul, acest cadru de baz furnizeaz o serie de clase abstracte din care se deriveaz
clasele concrete, corespunztoare diferitelor nivele arhitecturale ale aplicaiei.

Specificarea dialogurilor
Orice aplicaie are numeroase contexte n care se utilizeaz dialogurile. Aceste contexte pot fi
indicate chiar n diagrama contextelor de utilizare. Rafinarea procesului de specificare a
dialogurilor, continu cu maparea dialogurilor peste diagramele de activitate, organizate, la rndul
lor, n componente i subsisteme ale aplicaiei.

Componentele dialogurilor
Odat specificate din punct de vedere al asocierii la componente sau subsisteme, dialogurile
trebuie descrise din punct de vedere al structurii i proprietilor elementelor care le compun. Este
vorba de a indica cu claritate:

numele elementelor care compun un dialog;
tipul elementelor;
restriciile care li se aplic.

Toate aceste informaii sunt indispensabile pentru a descrie prelucrrile asociate dialogurilor,
precum i proiecia vizual a dialogurilor, cnd este cazul.
De semnalat nsemntatea pe care o are promovarea standardelor n efortul de specificare /
rafinare economic i ergonomic a dialogurilor.

Identificarea domeniului claselor i a relaiilor dintre clase
Identificarea claselor
Dicionarul tehnic, contextele de utilizare i clasele considerate ca eseniale pentru modelarea
informaional a organizaiei, toate fiind rezultate ale fazei de analiz, constituie materia prim
pentru lansarea demersului de adugare la soluie a claselor necesare pentru a descrie toat gama
de obiecte care prezint interes pentru descrierea dinamicii sistemului soft.

Identificarea relaiilor dintre clase
Este o activitate de mare importan i care necesit experien i abilitate deosebit pentru a
evita: scprile n ceea ce privete acoperirea cerinelor, abuzul de redundan, gestiunea
defectuoas a similaritilor, dificultile de adaptare la cerine noi.

Delimitarea componentelor
Acumulrile n ceea ce privete modelul claselor, la nivelul ntregului sistem, induc o reluare,
la alt nivel de detaliere, a problemei delimitrii componentelor soluiei. Optimizarea interfeelor,
optimizarea modului de partajare a resurselor comune de ctre diferitele clase, sunt doar dou
exemple de motive de reluare a problemei delimitrii componentelor sistemului soft.

Specificarea operaiilor
Odat definit politica n ceea ce privete lumea claselor, (structurat astfel nct cele dou
cerine mari s fie satisfcute: necesitile interne + necesitile de colaborare) se poate trece, n
sfrit, la specificarea complet a operaiilor: signatur (nume, argumente, tipul returnat de
operaie), validarea strii obiectului nainte de execuia operaiei(precondiii), validarea strii
obiectului dup execuia operaiei (postcondiii), semantica asociat operaiei.

Specificarea atributelor
nceput nc din faza de analiz, procesul de specificare a atributelor claselor poate, cel puin
teoretic, s fie dus pn la capt, cunoscndu-se toate cerinele fa de clasele luate n consideraie.
Evident, vor fi adugate atribute considerate strict necesare pentrua dinamica intern a obiectelor
unei clase dar i pentru a furniza servicii de calitate diferitelor categorii de clieni.

Modelarea strilor
Diagramele de stare descriu strile eseniale prin care trec obiectele avnd o anumit
clas definitoare. Starea unui obiect este abstractizat de mulimea valorilor atributelor
obiectului i de ansamblul relaiilor poteniale ale obiectului cu alte obiecte ale aplicaiei, la
un moment dat.

Modelarea activitilor
Activitile descriu uniti individuale de prelucrare a datelor sau pot fi socotite pri
importante ale unor algoritmi. Activitile captureaz elementele de control ale unor secvene de
transformri suferite de obiecte, avnd o anumit clas definitoare. Prezena activitilor este
semnalat prima dat n diagramele de stare care ar trebuie elaborate, n mod logic, naintea
diagramelor de activitate, cu ajutorul crora se reprezint activitile evideniate ntr-o diagram de
stare a unei clase.

Modelarea interaciunii dintre obiecte
La alt nivel de abstractizare, este necesar specificarea interaciunii dintre obiectele care
coopereaz pentru rezolvarea unor task-uri comune. n acest scop se elaboreaz dou tipuri noi
de diagrame care captureaz, din perspective diferite, dar complementare, interaciunea dintre
obiectele unei aplicaii. Este vorba despre diagramele de secven, care reprezint secvene de
schimburi de mesaje efectuate ntre obiecte diferite, n contextul unei colaborri definite dintre ele,
pentru ndeplinirea unui anume scop. Dei nu am pretenia c am lmurit lucrurile, subliniez faptul
c o diagram de secven descrie o interaciune derulat ntr-o secven temporal. ntr-o astfel de
diagram, obiectele au durat de via i fac schimb de mesaje, ordonate n timp, pentru a realiza o
anumit colaborare.
n al doilea rnd, diagramele de colaborare descriu o colaborare dintre dou sau mai multe
obiecte, astfel: relaiile dintre obiecte i mesajele schimbate ntre aceste obiecte. Dimensiunea
temporal este nlocuit cu o atenie sporit fa de reprezentarea relaiilor dintre obiecte. Evident,
apar probleme noi legate de navigabilitatea ntr-o astfel de diagram.

Soluia complet a unei probleme cuprinde, aproape n mod obligatoriu, i elemente
referitoare la tezaurizarea obiectelor persistente ale unei aplicaii.
S mai precizez faptul c, informaii complete (cu privire la aspectele abordate sintetic n acest
capitol) se gsesc, din abunden, n [4]. Lucrarea [4] pune n faa cititorului toate elementele care
ajut la transformarea potenialului UML-ului ntr-un instrument, efectiv i profesional, pentru
realizarea de sisteme soft de calitate.



Teme pentru proiecte la disciplina SIPP
-semestrul II-



1. Folosind sintaxa UML, specificai cerinele fa de un sistem soft care automatizeaz
fluxurile informaionale ale unei case de schimb valutar.

2. Folosind sintaxa UML, specificai cerinele fa de un sistem soft care automatizeaz
fluxurile informaionale ale secretariatului unei coli generale.

3. Folosind sintaxa UML, specificai cerinele fa de un sistem soft care automatizeaz
fluxurile informaionale ale secretariatului unei faculti.

4. Folosind sintaxa UML, specificai cerinele fa de un sistem soft care automatizeaz
fluxurile informaionale ale unei conferine tiinifice.

5. Elaborai diagrama claselor aferent soluiei UML a problemei automatizrii fluxurilor
informaionale ale unei case de schimb valutar

6. Elaborai diagrama claselor aferent soluiei UML a problemei automatizrii fluxurilor
informaionale ale secretariatului unei faculti.

7. Elaborai diagrama claselor aferent soluiei UML a problemei automatizrii fluxurilor
informaionale ale secretariatului unei coli generale.

8. Folosind sintaxa UML, s se reprezinte aspectele statice ale aplicaiei care automatizeaz
fluxurile informaionale ale unei case de schimb valutar.

9. Folosind sintaxa UML, s se reprezinte aspectele statice ale aplicaiei care automatizeaz
fluxurile informaionale ale secretariatului unei coli generale.

10. Folosind sintaxa UML, s se reprezinte aspectele statice ale aplicaiei care automatizeaz
fluxurile informaionale ale secretariatului unei faculti.

11. Elaborai arhitectura UML a soluiei problemei informatizrii unei universiti.

12. Elaboraii arhitectura UML a soluiei problemei realizrii unei librrii virtuale care
funcioneaz pe lng o editur.

13. Elaborai arhitectura UML a soluiei problemei realizrii unui sistem de informare i
documentare care funcionez pe lng o primrie.

14. Elaborai arhitectura UML a soluiei problemei informatizrii fluxurilor informaionale
ale unui birou notarial.






BIBLIOGRAFIE SELECTIV


[1] Bennet, S.,
Mc Robb, S.,
Farmer, R.
Object Oriented Systems Analysis and Design Using
UML, McGraw Hill, 1999
[2] Booch, G.,
Rumbaugh,J.,
Jacobson, I.
The Unified Modeling Language User Guide, Addison
Wesley, 1999
[3] Bocu, D. Iniiere n ingineria sistemelor soft, Editura Albastr,
Cluj-Napoca, 2002
[4] Bocu, D. Iniiere n modelarea orientat pe obiecte a sistemelor
soft utiliznd UML, Editura Albastr, Cluj-Napoca,
2003
[5] Jacobson, I.,
Booch, G.,
Rumbaugh, J.
The Unified Software DevelopmentProcess, Addison
Wesley, 1999
[6] Fowler, M.,
Scot, K.
UML Distiled Second edition, Addison Wesley, 2000
[7] Odell,J.,J. Advanced Object Oriented Analysis & Design Using
UML, Cambridge University Press, 1998
[8] Oestereich, B. Developing Software with UML, Addison Wesley,
1999
[9] OReilly UML in a Nutshell. A DeskTop Quick Reference

[10] Quatrany, T. Visual Modeling with Rational Rose and UML,
Addison Wesley, 1998
[11] Rosenberg, D.,
Scot, K
Use case Driven Object Modeling with UML, Addison
Wesley, 1999
[12] Rumbaugh, J.,
Jacobson, I.,
Booch, G.,
The Unified Modeling LanguageReference Manual,
Addison Wesley, 1999