Universitatea TRANSILVANIA din Braşov

Facultatea de Matematică şi Informatică

Catedra de Informatică Aplicată

INGINERIA SOFTULUI

Dorin Bocu

REPROGRAFIA UNIVERSITĂŢII “TRANSILVANIA” DIN BRAŞOV

 Cuvânt înainte

Deşi relativ nouă, lumea informaticii impune respect prin problemele formulate,
conceptele şi teoriile dezvoltate pentru rezolvarea acestor probleme.
Fundamentarea teoretică a universului informaţional aflat în zona de impact cu
calculatorul este un exemplu de demers în spirală a cărui dinamică şi profunzime este greu de
egalat în alte domenii.
Permanenta schimbare a “infrastructurilor” informaţionale orientate pe calculator
menţine la cote de alertă maximă efortul de redefinire a paradigmelor teoretico-
aplicative din lumea softului.
Aproape toate tipurile de activitate umană pot fi organizate şi desfăşurate cu totul altfel în
prezenţa calculatorului. Motivul acceptării calculatorului în preajma omului sau în locul
acestuia? Operativitate, precizie, obiectivitate.
Despre consecinţele în plan estetic şi moral ale “rătăcirii” omului în sofisticata junglă a
universului informaţional planetar (în curs de configurare) este, probabil, prematur să
discutăm şi nici nu ne propunem aşa ceva în această lucrare.
Desprinderea omului de condiţiile lui naturale de viaţă a început de mult, în preistorie,
odată cu descoperirea focului. În zilele noastre această desprindere continuă cu o viteză (sau
grabă) care, uneori, ne pune pe gânduri.
Din această uriaşă epopee a desprinderii omului de natură ne propunem să analizăm unele
aspecte care se referă, în fond, la nevoia acestuia de a crea o realitate virtuală care să-l
ajute, să-l deconecteze şi, dacă se poate, să-l substitue.
Acest joc în care s-au angajat energii uriaşe are toate şansele să dureze deoarece multe
dintre abilităţile omului sunt greu de modelat şi, spre “deliciul” cercetătorilor, unele dintre ele
aproape insurmontabile.
Această lucrare încearcă un lucru destul de dificil (ţinând cont de marea diversitate a
abordărilor în literatura de specialitate) şi anume identificarea bazelor ingineriei sistemelor
soft.
Adresându-se indeosebi studenţilor de anul III de la specializarea informatică, dar şi
tuturor celor interesaţi de ştiinţa şi, în egală măsură, arta de a realiza sisteme soft, prezenta
lucrare poate fi începutul unui drum lung, uneori complicat şi, de ce nu, interesant.

Braşov
27 noiembrie 2007
1 PROBLEME A CĂROR REZOLVARE DEPINDE
ESENŢIAL DE INGINERIA SISTEMELOR SOFT
1.1 Ce este ingineria sistemelor soft?
Mai întâi, să observăm frecvenţa destul de mare cu care întâlnim sau vom întâlni sintagma ingineria
softului. Pentru comoditate o voi nota, prescurtat şi IS.
Din dorinţa de a închega repede un dialog cu cititorul, anticipez că:
Ingineria softului este o ramură a ştiinţei calculatoarelor, în permanentă evoluţie, care fundamentează
teoretic o parte din activităţile specifice realizării sistemelor soft.
Spunem “o parte” deoarece realizarea unui sistem soft are, de regulă, în spate, cunoştinţe din multe alte
ramuri ale ştiinţei calculatoarelor precum şi din alte domenii (algoritmică, programarea calculatoarelor, limbaje
formale, cercetări operaţionale, psihologie, teoria generală a sistemelor, etc.).
Tentantă şi interesantă problema definirii riguroase a sintagmei “ştiinţa calculatoarelor”.
Autorul acestei lucrări vede în spatele acestei sintagme domenii precum: algoritmica, teoria matematică a
algoritmilor (calculabilitate şi decidabilitate), bazele matematice ale sistemelor de calcul, bazele logice ale
sistemelor de calcul, teoria formală a specificării limbajelor de programare, problematica limbajelor de
programare, bazele contructive ale sistemelor de calcul (un domeniu de mare complexitate şi cu o dinamică
remarcabilă), inteligenţa artificială (un domeniu în care căutările sunt din ce în ce mai ramificate şi mai
profunde), ingineria softului, teoriile dezvoltate în jurul problematicii bazelor de date, teoriile dezvoltate în jurul
arhitecturilor de tip reţea, etc.
Este clar, sper şi pentru cei care încă mai văd în informatică “un exerciţiu de utilizare inspirată a tastaturii”,
faptul că ştiinţa calculatoarelor este variată ca preocupări, solicită intens intelectul şi, încă un amănunt
important, viteza cu care afirmaţiile din informatică devin istorie este mult mai mare decât viteza cu care
se întâmplă acelaşi lucri în fizică, sau matematică, de exemplu”.
Care sunt, totuşi, acele activităţi specifice realizării sistemelor soft care cad sub incidenţa IS?
Le putem rezuma astfel:
10 Abstractizarea soluţiei unui sistem soft, prin care desemnăm demersul conceptual în urma căruia
specialistul în IS trece de la enunţul problemei la soluţia acesteia.
20 Organizarea procesului de abstractizare (modelare) a soluţiei unui sistem soft. Îndeosebi în cazul
sistemelor soft de complexitate mare şi medie modul de organizare a efortului de modelare poate influenţa
hotărâtor calitatea unui sistem soft.
30 Reprezentarea soluţiei unui sistem soft de-a lungul întregului proces de modelare; documentarea
completă a soluţiei sistemului soft.
Este vorba, în esenţă, de rezolvarea eficientă a unor probleme de comunicare între participanţii la realizarea
unui sistem soft, precum şi de rezolvarea unor probleme de comunicare între realizatorii sistemului şi diferitele
categorii de beneficiari ai sistemului soft.
40 Optimizarea managementului procesului de realizare a unui sistem soft. Ca în orice alt tip de
industrie şi în industria softului contează enorm (pentru lansarea pe piaţă cu succes a unui sistem soft) calitatea
actului de management.
Sloganul – cheie în IS ar trebui să fie: ”Cum se poate sistematiza ,eventual automatiza, procesul de
realizare a unui sistem soft de calitate, ieftin şi obţinut în timp util?”.
IS încearcă (în diferite chipuri şi de mai mult timp) să ne înveţe cum poate deveni realitate acest slogan.
Modalitatea prin care IS rezolvă această problemă este (simplificând lucrurile) propunerea de metodologii
de dezvoltare a softului (MDS).
Istoria MDS este lungă şi destul de dificil de sintetizat fără a omite numeroase aspecte interesante. Firul
călăuzitor al acestei istorii ar putea fi, totuşi, definit astfel:

10 Fiecare metodologie doreşte să instaureze o anumită rigoare în procesul de elaborare a soluţiei unui
sistem soft.
20 Fiecare metodologie se individualizează prin accentul pe care îl pune pe un anumit element
definitor (unul sau mai multe concepte de bază, unul sau mai multe principii de bază, formalizmul de
reprezentre, etc.).
30 Fiecare metodologie doreşte să ofere suport cât mai consistent pentru realizarea de sisteme soft de
calitate.
 După unele aprecieri există, încă, o diversitate prea mare de metodologii de dezvoltare a softului, fapt care
nu stimulează neapărat productivitatea specialiştilor în IS. În jurul marilor firme producătoare de soft se
cristalizează, progresiv, elemente şi idei cu ajutorul cărora se alimentează procesul de fundamentare a unor noi
MDS. Aceste MDS primesc, de regulă, girul mediilor academice, după care se întorc la utilizatori, care le
consideră adecvate pentru rezolvarea problemelor lor.
Schematizând, avem situaţia din Figura 1.1, adică “un fel de circuit al apei în natură”. Privind mai atent,
însă, observăm că este vorba de un proces cu conexiune inversă pozitivă care, pe termen lung, are ca scop
optimizarea suportului de care au nevoie specialiştii în IS pentru a realiza sisteme soft.
Astfel se prezintă IS dacă “privim lucrurile din avion”. În realitate situaţia este mult mai complexă. Acest
fapt va ieşi la iveală în cele ce urmează, când aplicând descompunerea top-down în conjuncţie cu un permanent
efort de abstractizare, vom înţelege mai bine structura şi specificul unui demers IS.

Firme/Persoane implicate în
realizarea de sisteme soft

Idei, cerinţe, soluţii

parţiale noi

Laboratoare de cercetare

MDS nouă

Figura 1.1 Binomul cercetare-aplicaţii în evoluţia MDS

1.2 Ce este un sistem soft?

Destul de dificil un răspuns de tip definiţie la această întrebare deoarece diversitatea “creaţiior” care
concurează la calitatea de sistem soft este din ce în ce mai mare. Astfel, poate fi sistem soft un program
executabil, obţinut cu ajutorul unui compilator C++. Tot sistem soft putem considera şi un sistem de programe
executabile care cooperează pentru rezolvarea unei probleme date. De ce n-am socoti sistem soft un compilator,
un SGBD sau chiar un sistem de operare? Tot un sistem soft poate fi considerat, cu deplin temei, un control
ActiveX.
De fapt, când vine vorba de tehnologiile soft de ultimă oră (îndeosebi cele promovate de Micro soft) noţiunea
de sistem soft face faţă unor conotaţii cu totul remarcabile (DLL-urile, controalele OLE, obiectele programabile,
alţi derivaţi ai tehnologiilor COM şi DCOM, etc.).
Evident, se poate încerca, pentru a face mai multă ordine în prezentare, o clasificare a aplicaţiilor
recunoscute de platforma Microsoft/Win32. Aceste tipuri de aplicaţii sunt:
 aplicaţia de tip consolă; este aplicaţia care aduce în lumea Windows caracteristicile de bază ale unei
aplicaţii cu interfaţă orientată pe text.
 aplicaţii Win32 tradiţionale; o astfel de aplicaţie are toate elementele care sunt prezente într-o aplicaţie
Windows completă (fereastră de afişare, bară de meniuri, bară cu instrumente, bară de stare, etc.). O stfel de
aplicaţie, spre deosebire de aplicaţia de tip consolă are mari disponibilităţi de cooperare cu sistemul de
operare Windows.

 biblioteci cu legături dinamice (DLL-Dynamic Link Library); o bibliotecă DLL este, în esenţă, o colecţie
de funcţii care pot fi apelate din alte module executabile Windows. Nu discutăm aici motivele care au
generat specificarea acestei tehnologii de către specialiştii de la Microsoft(deşi acesta ar fi un foarte
interesant studiu de caz într-o lucrare pe teme IS). Important este că, realizarea unei biblioteci DLL este un
exerciţiu deosebit atât din punct de vedere al elaborării soluţiei tehnice cât şi din punct de vedere al
programării. Aceasta deoarece, mai mult decât într-o aplicaţie Windows ordinară, realizarea unei biblioteci
DLL pune la încercare abilităţile specialistului IS în ceea ce priveşte definirea de interfeţe optimale pentru
 funcţii, specificarea/scierea de cod generic, specificarea/scrierea de cod reentrant, cunoaşterea
particularităţilor programării sub Windows, etc..
 Controalele ActiveX; sunt un gen de mini-aplicaţii care pot fi încapsulate în orice obiect de tip container.
Container poate fi fereastra cadru a unei aplicaţii, sau un document HTML. Reprezentând, de fapt,
extinderea tehnologiei OLE la cerinţele universului INTERNET, ActiveX permite programatorilor să
sporească gradul de funcţionalitate al programelor fără prea mult efort. Prin utilizarea tehnologiei ActiveX,
programatorul consimte să respecte o serie de reguli, să surmonteze o serie de obstacole, dar are şi avantajul
de a beneficia de efortul de modelare al altor specialişti în IS, în caz de convergenţă de interese cu aceştia.

Am terminat, astfel, scurta trecere în revistă a tipurilor de aplicaţii suportate suportate de platforma
Windows. Evident, am pus în discuţie elemente noi care ne-ar putea ajuta la definirea noţiunii de sistem soft.
Continuând mica noastră investigaţie, ne putem întreba dacă un document HTML poate fi considerat sistem
soft? Întrebări asemănătoare ne putem pune relativ la creaţii precum: colecţiile de fonturi utilizate de editoarele
de texte, aşa zisele fişiere cu resurse promovate de mediile vizuale de programare, colecţiile de clase gen MFC
(Microsoft Foundation Class), etc.
Este clar, sper, motivul pentru care, la începutul acestui paragraf, am afirmat că este dificil de dat o definiţie
“viabilă” noţiunii de sistem soft. Nu ar fi acesta singurul caz (Biblia operează cu noţiunea de Dumnezeu fără să
ne-o definească. Cu toate acestea există oameni care consideră biblia o capodoperă atât din punct de vedere al
tipului de scriitură cât şi din punct de vedere al modului de organizare a argumentaţiei).
Contând, mai ales pe valoarea ei didactică, propun următoarea definiţie a noţiunii de sistem soft.

Se numeşte sistem soft orice produs al IS care poate fi utilizat pentru a fundamenta sau realiza protocoale
efective şi relativ autonome de prelucrare sau comunicare a datelor şi informaţiilor într-un context
informaţional dat.

Aşadar, atributele esenţiale ale unui sistem soft sunt:

10 Capacitatea de a fundamenta / realiza protocoale efective de prelucrare / comunicare a datelor /
informaţiilor.
Exemple.
-MFC poate fundamenta protocoale efective de prelucrare / comunicare date şi informaţii;
-Un sistem expert realizează un protocol efectiv de prelucrare / comunicare date / informaţii;
-Un document HTML realizează un protocol efectiv de prelucrare / comunicare date / informaţii, etc.
20 Protocolul fundamentat sau realizat are o autonomie relativă.
Ideea de bază a acestei autonomii relative constă în faptul că protocolul este capabil, în anumite împrejurări,
de iniţiativa în relaţia cu mediul de interpretare sau de execuţie a protocolului.
Ca un contraexemplu, o resursă Delphi, neintegrată într-un sistem complet de alte elemente ale unei aplicaţii
Delphi, nu poate fi considerată sistem soft. Integrată, însă, poate fi considerată parte a unui sistem soft.
30 Protocolul operează într-un context informaţional dat.
Nu prea avem motive să acceptăm ca sistem soft o creaţie IS care nu operează într-un context informaţional
specific. Chiar dacă nu este întotdeauna evident, acest context informaţional există. De exemplu, un mediu vizual
de realizare a sistemelor soft este, el însuşi, un sistem soft care operează cu un context informaţional specific,
abstractizat de conceptele şi principiile de utilizare a acestor concepte pentru a modela vizual soluţia unei
probleme date.
Cititorul, mai mult sau mai puţin avizat, întrezăreşte, probabil, faptul că noţiunea de sistem soft are un
conţinut discutabil. Mai presus de orice discuţie, însă, se află faptul că în IS denumirea generică a produselor
finite este sistem soft.
Actualmente, omenirea trăieşte un moment de cotitură din punct de vedere al modului de procesare a
informaţiilor care o interesează. Acest moment de cotitură ar putea fi numit revoluţie informaţională.
După ce o mare parte din istoria omului a fost dedicată cuceririi redutelor substanţiale şi energetice, a
sosit timpul unor modificări importante în ceea ce priveşte valorificarea dimensiunii informaţionale a tuturor
activităţilor omului.
Diversificarea pe orizontală şi pe verticală a producţiei de sisteme soft înseamnă modificarea permanentă a
ofertei de tehnologii informaţionale (TI), tot mai mult cerute de societatea informaţională în curs de
cristalizare.
Circuitul producţie TI - utilizare TI - redefinire cerinţe faţă de TI – producţie TI are o dinamică a cărei
trăsătură principală pare a fi “efectul de autoaprindere”.
Tăvălugul informatizării societăţii omeneşti pare a fi în faza în care rostogolirea lui nu mai poate fi oprită
fără a prejudicia grav progresul metodelor de investigare şi complexificare a realităţilor substanţiale şi
energetice, fără să mai vorbim de cele informaţionale.
 Nu peste mult timp, o mare parte din locuitorii planetei vor fi nevoiţi să înveţe meşteşugul utilizării şi
producerii TI.
După cum se poate observa şi în alte domenii de activitate şi în industria softului există tendinţa de a:
-extinde permanent capabilităţile interactive şi de procesare ale sistemelor soft , ţinând cont de cerinţele
concrete ale utilizatorilor dar şi formând la utilizatori obişnuinţa de a învăţa tehnologii informaţionale noi,
destinate modificării comportamentului;
-creşte sistematic calitatea sistemelor soft;
-diminua permanent costurile de producţie.
Manifestarea efectivă a acestor trei tendinţe este posibilă numai printr-un efort permanent de îmbunătăţire a
elementelor suport în procesul de realizare a sistemelor soft.
Studiul critic al elementelor suport în procesul de realizare a sistemelor soft este de competenţa disciplinei
prezentată în literatura anglo-saxonă sub denumirea “Software engineering”, care în limba română s-ar traduce
convenabil prin Ingineria softului.
După ce am încercat o scurtă incursiune în lumea preocupărilor IS, voi prezenta, în continuare, o serie de
probleme care (de la începuturile erei informaticii sau mai recent) menţin treaz interesul specialiştilor în IS
pentru regândirea permanentă a paradigmelor.

1.3 Probleme cu care se confruntă specialiştii în IS

Familiarizaţi oarecum cu încărcătura semantică de bază a noţiunilor discutate în paragrafele 1.1 şi 1.2, în
acest paragraf vom analiza unele dintre problemele care au jucat şi joacă un rol important în evoluţia IS .
De menţionat faptul că şi acesta este un subiect în care abordările abundă deoarece universul problemelor IS
poate fi analizat din mai multe puncte de vedere iar în interiorul unui punct de vedere utilizând formalizme
diferite. De exemplu, problema elaborării soluţiei unui sistem soft poate fi discutată, la un nivel de formalizm
socotit convenabil, în scopul dezvoltării abilităţilor unui specialist în IS sau în vederea informării exacte a
managerilor cu privire la particularităţile şi utilitatea unui astfel de demers.
Specialistul în IS vrea să înveţe cât mai multe detalii despre arta de a realiza sisteme soft de calitate.
Managerul care se instruieşte pe probleme de IS este interesat de cunoaşterea invarianiţilor unui astfel de
demers pentru a decide în cunoştinţă de cauză modul în care, cu minimum de resurse se pot obţine
maximum de rezultate (atât pe termen scurt cât şi, eventual, pe termen mediu sau lung) prin automatizarea
fluxurilor informaţionale ale afacerii în conducerea căreia este implicat.
Pentru a clarifica unele probleme de limbaj care ar putea să apară în continuare, să precizăm faptul că în
literatura de specialitate anglo-saxonă se consideră că trei categorii de indivizi sunt foarte importanţi pentru
succesul sau eşecul unui proiect de realizare a unui sistem soft. Aceste categorii sunt:
-utilizatorii direcţi (end-users) ai sistemelor soft;
-utilizatorii indirecţi (clients) ai sistemelor soft;
-specialiştii în IS.
Probleme datorate perspectivei “utilizator direct”
Operând la extreme, utilizatorul direct al unui sistem soft este sau un individ având afinităţi cu lumea IS sau
un individ a cărui cultură informatică este structurată, modest, în jurul abilităţilor necesare pentru utilizarea
sistemului soft.
În primul caz este vorba de un utilizator a cărui părere despre calităţile sistemului soft poate fi deosebit de
activă şi pertinentă. Al doilea tip de utilizator este, în general, sensibil la confortul oferit de utilizarea sistemului
soft. Ambele categorii de utilizatori, într-o formă sau alta, se pot considera la originea revendicării pernanente:
sporirea interactivităţii sistemului soft cu utilizatorul direct, promovând mijloace de comunicare cât mai
ergonomice.
În mod evident, interactivitatea sistem soft-utilizator direct în sensul de mai sus presupune proiectarea şi
realizarea efectivă a unor interfeţe ergonomice.
Într-o interfaţă ergonomică, utilizatorul direct găseşte funcţionalitatea dorită de o manieră care nu pune la
încercare nici înţelegerea, nici răbdarea şi nici sănătatea acestuia.
Practica a demonstrat şi demonstrează faptul că este o artă să proiectezi interfeţe inteligibile, este o
sarcină mult mai complicată să realizezi interfeţe care răspund operativ şi dau dovadă de maximă
îngăduinţă faţă de capriciile utilizatorului direct; în sfârşit, destul de pretenţioasă este şi misiunea de a realiza
interfeţe care nu numai că nu dăunează facultăţilor psihice ale utilizatorului direct, ba chiar, încearcă
reconfortarea lor.
Mulţi factori care determină calitatea unui sistem soft (problemă asupra căreia vom reveni, pe larg, în acest
capitol) îşi găsesc o formă de manifestare şi în modul în care “se exprimă” o interfaţă în relaţia cu utilizatorul.
De exemplu, robusteţea unui sistem soft, considerată un factor extern de calitate, măsoară abilitatea unui
sistem soft de a rezista la iniţiative din partea utilizatorului direct (transmise prin intermediul interfeţei)
care depăşesc cerinţele specificate ale sistemului soft.
Probleme datorate perspectivei “utilizator-indirect”
 Utilizatorul indirect (care poate fi întruchipat de orice consumator inteligent de servicii furnizate de un
anumit sistem soft) dacă se manifestă constructiv este un partener cu care specialistul în IS trebuie să coopereze
strâns deoarece soluţia multora dintre problemele care pot să apară pe timpul realizării unui sistem soft depinde
de acesta.
Utilizatorul indirect decide începerea/neînceperea finanţării proiectului de realizare a unui sistem
soft; tot el este şi cel care, în urma analizelor periodice cu privire la evoluţia proiectului, poate decide
abandonarea/continuarea proiectului. Absolut trivial este faptul că într-o economie de piaţă fără finanţare nu
se poate materializa nici o idee de proiect, oricât de generoasă şi ambiţioasă ar fi aceasta . Acesta este
motivul pentru care managementul proiectului de realizare a unui sistem soft trebuie să trateze cu maximum de
profesionalism relaţia cu utilizatorii indirecţi-variabile importante în ecuaţia finanţării unui proiect.
Utilizatorul indirect îşi asumă, în mod normal şi rolul de furnizor de date cu privire la structura
proceselor informaţionale modelate şi, ca o prelungire firească, rolul de furnizor de elemente cu privire la
cerinţele faţă de sistemul soft în curs de realizare. Dacă utilizatorul indirect nu îşi asumă aceste două roluri de
pe o poziţie corectă, specialistul în IS este în faţa unei probleme al cărei enunţ “are geometrie variabilă”:
Utilizatorul indirect nu este capabil să descrie corect procesele informaţionale modelate; cineva din echipa
de proiectare trebuie să facă acest lucru şi, evident, nota de plată a proiectului se încarcă;
Utilizatorul indirect indică cerinţele faţă de sistemul soft derivate din poziţia pe care el (utilizatorul
indirect) o are în ierarhia utilizatorilor indirecţi.
Apare, în acest fel, o problemă nouă şi importantă pentru specialiştii în IS, anume distilarea şi asamblarea
viziunilor unilaterale ale utilizatorilor indirecţi pentru a obţine o perspectivă sistemică asupra proceselor
modelate.
Utilizatorul indirect are, statistic vorbind, toate calităţile unui om obişnuit: poate face omisiuni, poate
emite judecăţi inconsistente, poate avea probleme în comunicarea datelor şi informaţiilor pe care le deţine, etc.
Această posibilitate ar trebui să sporească semnificativ încordarea cu care specialiştii în IS culeg de la utilizatorii
direcţi date şi informaţii necesare evoluţiei pozitive a proiectului.
Oricare ar fi situaţia, specialiştii în IS trebuie să acorde o atenţie deosebită utilizatorilor indirecţi; părerea lor
faţă de calităţile unui sistem soft poate determina “înmormântarea” acestuia înainte de a se naşte, sau asigurarea
condiţiilor pentru ca sistemul soft să aibă un ciclu de viaţă pozitiv.
Noţiunea de ciclu de viaţă “bate la uşă”, dar de semantica aflată în spatele ei (destul de polimorfă) vom
discuta mai multe în Capitolele 2 şi 3..
Deocamdată, ciclul de viaţă al unui sistem soft, conform unei metodologii date, descrie etapele prin care
trece un proiect de la faza de enunţ al problemei până la soluţia executabilă pe calculator ş.a.m.d dacă se pune
problema dezvoltării, întreţinerii, etc.
Probleme generate sau descoperite de specialiştii în IS
Nu este decât o confirmare a regulii faptul că IS este un univers ale cărui probleme sunt inventate,
inventariate şi rezolvate datorită dorinţei specialiştilor în IS de a optimiza procesul de realizare a sistemelor
soft.
Cele mai dificile probleme care pot apare în timpul realizării unui sistem soft sunt, totuşi, problemele care
îşi au originea în ”laboratoarele IS” sau se reflectă în activitatea acestor “laboratoare”. Vom prezenta, în
continuare, enunţul problemelor fundamentale pe care trebuie să le aibă în vedere orice specialist în IS.
Pentru nenumărate motive (dintre care, unele le vom prezenta în continuare) procesul de realizare a unui
sistem soft trebuie sistematizat.
Această nevoie de sistematizare acoperă mai multe dimensiuni:concepţie, eşalonarea în timp, reprezentarea
soluţiei, documentarea, conducerea proiectului, etc.
Sistematizarea înseamnă, în esenţă, introducerea de reguli de urmat pentru a asigura, teoretic, succesul unui
proiect. Nevoia de sistematizare intră în conflict cu tendinţa multor specialişti în IS de a se exprima ignorând
protocoalele, normele, regulile adoptate de colectivele din care fac parte.
Este din ce în ce mai greu de ţinut evidenţa tipurilor de sisteme soft cunoscute, pentru a valorifica creator
experienţa acumulată prin realizarea lor, specificând MDS infailibile şi atotcuprinzătoare. Deşi la ora actuală au
fost edificate MDS care impresionează puternic prin obiectivele propuse şi mijloacele de atingere a acestor
obiective, omul rămâne în continuare singurul în măsură să însufleţească aceste MDS sau să le adauge
capabilităţi noi în situaţii problematice deosebite (A se vedea, de exemplu, OM,T şi UML, două MDS relativ
recente, cu aspiraţii interesante pentru orice gânditor care înţelege lumea orientat pe obie cte).
Prin sistematizarea procesului de realizare a sistemelor soft se urmăreşte crearea unor condiţii
avantajoase pentu gestiunea complexităţii problemelor specifice unui proiect. Oferirea de suport pentru
gestiunea complexităţii este benefică pentru diviziunea muncii (dacă se lucrează în echipă) şi calitatea soluţiei.
Există o mare varietate de abordări care propun şi elemente suport explicite pentru gestiunea complexităţii.
Dintre aceste abordări să enumerăm şi noi câteva care au ca numitor comun modularizarea. Putem modulariza
orientat pe proceduri, putem modulariza orientat pe date, putem modulariza orientat pe obiecte. Rezultatul
trebuie să fie de fiecare dată acelaşi: “Soluţia=o colecţie de module care cooperează pentru rezolvarea unei
probleme date”.
Prin sistematizarea procesului de realizare a sistemelor soft se pun bazele reutilizării efortului de
modelare, în anumite circumstanţe. Astfel, aşa după cum vom vedea, îndeosebi în Capitolele 2 şi 4, soluţia
unei probleme poate fi elaborată pe mai multe nivele de abstractizare, fiecare nivel fiind dedicat descrierii unor
proprietăţi specifice ale soluţiei. Regulile de bază în organizarea unei soluţii pe nivele de abstractizare pare
simplă: nivelul de abstractizare al unei soluţii scade odată cu creşterea infuziei de informaţie statică şi
dinamică în soluţie.
Creşterea infuziei de informaţie statică şi dinamică înseamnă trecerea soluţiei de la o arhitectură cu o
anumită stabilitate structurală la o arhitectură cu stabilitate structurală diminuată . Este o legitate care
poate fi combătută constructiv doar prin utilizarea unei scheme de rafinare a soluţiei care să limiteze
diminuarea stabilităţii structurale a nivelului de abstractizare.
Teoretic vorbind, cu cât avem mai multe nivele de abstractizare, cu atât mai mic este efortul de
regândire a unui anumit nivel de abstractizare. Practic, însă trebuie găsit un compromis eficient între
numărul de nivele de abstractizare propuse şi efortul depus de specialişti în IS pentru obţinerea soluţiei în
acest context.
Astfel stând lucrurile, o soluţie obţinută, să spunem, pe trei nivele de abstractizare (conceptual, logic,
operaţional, a se vedea Figura 1.2) are cea mai mică stabilitate la nivel operaţional. Dacă apar modificări care
afectează acest nivel (şi ele sunt cele mai plauzibile), atunci soluţia este regândită, refăcând, în principal, nivelul
operaţional. Aceasta înseamnă că soluţia are o rezistenţă structurată la modificări şi că specialiştii în IS fac
reutilizare de efort de modelare în obţinerea unei soluţii.
Comentariu la Figura 1.2
Cele trei nivele de abstractizare au o semantică apropiată perspectivei pe care o oferă teoria managementului
asupra actului de conducere, analizat pe verticală.
Comentariu la Figura 1.3
Schema din Figura 1.3 ilustrează componentele managementului, structurat pe nivele; deşi nu sunt vizibile,
între aceste componente există relaţii foarte interesante pentru cineva care proiectează sistemul informaţional al
unei afaceri.

Nivel conceptual
(Ce face sistemul soft)

Soluţia conceptuală

Nivel logic
(Cine, când şi unde
execută prelucrările)

Soluţia logică

Nivel operaţional
(Cum se efectuează
prelucrările)

Sistem soft operaţional

Figura 1.2 Exemplu de ciclu de abstractizare a soluţiei unui sistem soft
 Figura 1.3 Piramida managementului din perspectivă sistemică.

Managementul de TOP, dacă este specificat corect trebuie să aibă cea mai mare stabilitate structurală.
Managementul TACTIC formulează politicile necesare pentru îndeplinirea obiectivelor managementului de
TOP. Dacă este necesar, stabilitatea structurală a acestor politici poate fi schimbată. În sfârşit, managementul
OPERATIV face tot ceea ce este necesar pentru a operaţionaliza politicile stabilite de managementul TACTIC.
Nivelul operativ al managementului este supus, cu prioritate, schimbărilor atunci când se pune problema
adaptării sistemului condus la condiţii de performanţă noi.
Prin sistematizarea procesului de realizare a sistemelor soft se urmăreşte creşterea permanentă a
calităţii acestora.
Este momentul să facem o scurtă incursiune în semantica deosebit de complexă a sintagmei “calitatea
sistemelor soft”.
Atât în teorie cât şi în practică se acceptă faptul că softul de calitate este rezultatul luării în consideraţie a o
serie de factori interni şi externi procesului de configurare a soluţiei finale a unui sistem soft.
În limbaj comun se vorbeşte despre necesitatea de a realiza sisteme soft fiabile, uşor de folosit, structurate,
etc. Astfel de epitete asociate unui sistem soft caracterizează două tipuri de proprietăţi ale sistemelor
soft:proprietăţi externe şi proprietăţi interne.
Calitatea sistemelor soft şi proprietăţile externe
Dintre proprietăţile externe care decid calitatea unui sistem soft, le considerăm ca fiind foarte importante pe
următoatele:
-corectitudinea;
-robusteţea;
-extensibilitatea;
-reutilizabilitatea;
-compatibilitatea;
-eficienţa;
-portabilitatea;
-uşurinţa în folosire.
Corectitudinea
Este abilitatea unui sistem soft de a executa toate sarcinile convenite cu utilizatorii şi beneficiarii în faza de
specificare
Corectitudinea este o proprietate de maximă prioritate a sistemelor soft. Un sistem soft care “face altceva
decât s-a stabilit de comun acord cu beneficiarii şi utilizatorii lui” este obligatoriu să fie corectat (dacă efortul
necesar pentru a face acest lucru este asumat de cei care au greşit) sau abandonat pentru a relua efortul de a găsi
o soluţie care să aibă, printre altele şi atributul corectitudinii.
Deşi se poate vorbi uşor şi mult despre corectitudine, este o “probă de rezistenţă şi de îndemânare
profesională” specificarea corectă a sistemelor soft.
Pentru teoreticienii IS corectitudinea, dincolo de acceptarea rutinei, este sinonimă cu rigoarea în specificare
şi proiectare, ceea ce nu este “agreat” de specialiştii în IS adepţi ai utilizării unor limbaje cu suport natural în
specificare şi proiectare.
Robusteţea
Este abilitatea unui sistem soft de a reacţiona adecvat în condiţii anormale de utilizarea.
Este evident faptul că robusteţea completează corectitudinea. În timp ce corectitudinea se referă la
comportamentul unui sistem relativ la o anumită specificare corectă, robusteţea apreciază ce se întâmplă cu
sistemul soft în situaţii care, în chiar procesul de specificare ar trebui identificate ca excepţii.
Realizarea de sisteme soft robuste este o sarcină care începe în faza de specificare şi se întinde până în faza
de programare. Pe acest traseu specialiştii în IS trebuie să înfrunte două clase mari de execpţii:
 Excepţiile externe sistemului soft;
Excepţiile interne sistemului soft.
Frontiera dintre aceste două clase de excepţii trebuie privită cu multă circumspecţie deoarece, în realitate
este oricând posibil ca, potenţial, o excepţie externă să inducă o excepţie internă şi invers.
De asemenea, să mai observăm că în timp ce excepţiile externe pot fi “înfruntate” descurajând iniţiativele
“nespecificate” ale utilizatorului, problematica excepţiilor interne este mult mai complicată.
În cazul sistemelor care gestionează relaţia cu utilizatorul prin intermediul unei interfeţe cu o semantică
deosebit de complexă, excepţiile externe, înainte de a fi inhibate trebuie identificate.
Iată, deci, încă o problemă de care specialiştii în IS se lovesc dacă doresc să “scoată pe piaţă” sisteme soft
care “rămân pe picioare” la apariţia unor excepţii. Se poate formula şi un fel de principiu relativ la odiseea
tratării excepţiilor într-un sistem soft:
În timp ce interfaţa unui sistem soft îşi sporeşte receptivitatea faţă de curiozitatea şi comoditatea utilizatorilor,
efortul de tratare complexă şi corectă a posibilelor excepţii creşte astfel încât poate deveni o problemă care nu
poate fi rezolvată decât prin metoda aproximaţiilor succesive.
Este cazul sistemelor de operare, de exemplu, a căror robusteţe este, adeseori, rezultatul unui proces de
ajustare pe banii şi pe răbdarea diferitelor categorii de utilizatori.
Extensibilitatea
Este abilitatea unui sistem soft de a se adapta uşor la modificări în faza de specificare
Problema extensibilităţii este o problemă de situare pe scala complexităţii: programele mici sunt uşor de
modificat; sistemele soft din ce în ce mai mari devin tot mai dificil de adaptat la modificări. Rămânând în sfera
afirmaţiilor valabile, dar generale, putem adăuga că două principii sunt utile în realizarea de sisteme soft
extensibile. Acest principii sunt:
Simplitatea proiectării
Ideea de bază este că o arhitectură simplă este întotdeauna mai uşor de modificat decât o arhitectură
complexă. Inevitabil, însă, vine întrebarea: când spunem că un sistem soft are o arhitectură simplă? Un
răspuns complet şi precis la această întrebare nu încape în paginile acestei cărţi. Simplitatea este un deziderat
urmărit de orice creator care se respectă. Faptul că există destule creaţii ale omului care uimesc prin dificultatea
cu care îşi transmit mesajul (inepţii literare, subproduse cinematografice, discursuri politice sterile, etc.)
dovedeşte caracterul imprevizibil al modului în care un creator ajunge să opereze cu avantajele simplităţii în
munca sa. Nu se poate algoritmiza obţinerea simplităţii pentru că, în forma ei cea mai înaltă de exprimare, este
sinonimă cu creaţia. O creaţie plăsmuită cu talent va provoca întotdeauna exclamaţii de genul:”Ce simplu era!”,
“Foarte uşor de înţeles!”, “Nici că se putea mai bine!”, “Cum de nu mi-a trecut prin cap?!”, etc.
O “creaţie” plăsmuită doar pentru a umple fizic unul din multele goluri care există în viaţa oamenilor
provoacă exclamaţii de tipul:”Doamne, ce îmbâcseală!”, Nu înţeleg mai nimic!”, Mai bine lipsă!”, “Aşa ceva
puteam şi eu să fac!”, etc.
Nu este pierdere de vreme să urmărim simplitatea şi în IS. Doar că, şi aici, obţinerea ei cere timp, pentru a
şlefui soluţia unei probleme, astfel încât să putem obţine un sistem soft care este, cel puţin:
-lizibil;
-corect modularizat;
-eficient în timpul execuţiei.
Sunt nenumărate motive, însă, pentru care în IS se sacrifică simplitatea, asigurându-se, de exemplu,
corectitudinea şi robusteţea. Enumerăm câteva dintre aceste motive: necesitatea scurtării termenelor de execuţie,
modificarea paradigmelor de modelare, modificarea limbajelor de programare, modificarea sistemelor de
operare, creşterea puterii de calcul a sistemelor hard (frecvenţă de lucru foarte mare+ dimensiuni, de vis altădată,
ale memoriei RAM).
Descentralizarea
Dacă extensibilitatea este dorită cu orice preţ şi poate că nu există suficient timp pentru a obţine un sistem
soft cu arhitectură simplă, atunci mai avem un punct de sprijin în descentralizare: cu cât autonomia modulelor
care compun sistemul soft este mai mare cu atât mai mare este probabilitatea ca o schimbare simplă să afecteze
un număr redus de module.
Reutilizabilitatea
Este abilitatea componentelor unui sistem soft de a putea fi utilizate la dezvoltarea mai multor aplicaţii
diferite.
Necesitatea reutilizării unor componente soft se întemeiază pe observaţia că, adeseori, sisteme soft diferite
pot fi construite pe baza unor soluţii-şablon similare. Promovarea sistematică a reutilizării influenţează alţi
factori de apreciere a calităţii sistemelor soft, precum corectitudinea şi fiabilitatea.
Reutilizarea este un factor cardinal în multe paradigme de programare şi modelare. Astfel, programatorii
Windows pot utiliza în procesul de realizare a propriilor aplicaţii, potenţialul MFC (Microsoft Foundation
Class). De asemenea, mediile vizuale de programare (Delphi, Visual Basic, Visual C++, CBuilder, etc.) oferă
exemple consistente de reutilizare.
 Compatibilitatea
Este o măsură a uşurinţei cu care componentele unui sistem soft se combină cu alte componente pentru a
forma aplicaţii noi.
Fireşte, compatibilitatea este importantă deoarece, în general, sistemele soft nu pot fi dezvoltate în vid; ele
vor interacţiona cu alte sisteme soft.
Secretul compatibilităţii se află în omogenitatea proiectării şi în acceptarea unor standarde de
comunicare între programe.
Aşadar, pentru a realiza sisteme soft compatibile, efortul de proiectare trebuie să ia în calcul şi cele două
cerinţe formulate mai sus. Comunitatea IS nu se poate “mândri” cu impunerea unor standarde şi principii de
detaliu în acest sens. Există “fani” Windows care promovează tehnologiile, trebuie să recunoaştem remarcabile,
ale Microsft-ului. Există, însă, şi “fani” Linux care promovează propriile lor idei şi tehnologii în ceea ce priveşte
caracteristicile mediilor de dezvoltare a sistemelor soft. Am dat două exemple de “medii” de dezvoltare a
softului. Mai sunt nenumărate altele al căror istoric nu este momentul să îl facem; raţiunea lor de a fi este
următoarea:
Lumea IS îşi datorează remarcabila dinamică unui permanent efort de inovare teoretică şi în plan
aplicativ;
Lumea IS, în marea ei varietate, are nevoie de puncte de convergenţă pentru a face posibilă
interoperabilitatea crescândă între sistemele soft.
Este destul de dificil de făcut o predicţie relativ la dezvoltarea pârghiilor de compatibilizare a sistemelor soft
în viitor. Actualmente, lumea aplicaţiilor Internet se prefigurează ca un “câmp de desfăşurare a unor
bătălii importante pentru noua faţă a universului IS”. Este nevoie de timp, răbdare şi efort susţinut pentru a
găsi noi formule de specificare a proprietăţilor fundamentale ale sistemelor soft, printre care se află şi
compatibilitatea.
Eficienţa (Performanţa)
Este abilitatea unui sistem soft de a minimiza cererile de resurse hard (timp UC, memorie RAM, memorie
externă, etc.).
Comunitatea IS are două atitudini tipice faţă de eficienţă.
Există “softişti” care fac o pasiune din optimizarea permanentă a sistemelor la care lucrează. Din
“mâinile” unor astfel de specialişti ies adevărate bijuterii din punct de vedere al performanţelor. Preţul plătit
împingând performanţa dincolo de un anumit prag logic este, în principal, diminuarea portabilităţii softului
respectiv. Într-o lume care visează la compatibilizarea sistemelor soft este greu de crezut că portabilitatea poate
fi sacrificată.
Există şi “softişti” care gândesc astfel: “Să facem sistemul soft corect înainte de a fi eficient cu orice
preţ”. Un astfel de slogan merge în aplicaţiile în care absenţa performanţei nu este critică pentru funcţionarea
softului, mizându-se pe un fapt absolut real în ultima vreme: “Eficienţa poate fi obţinută pe seama progreselor în
materie de tehnologii hard”. Ca de obieci, adevărul trebuie să fie undeva la mijloc, ceea ce înseamnă că
specialistul IS trebuie să stăpânească arta de a obţine performanţa cerută cu minimum de cheltuieli de resurse.
Portabilitatea
Este o măsură a uşurinţei cu care un sistem soft poate fi transferat pe diferite platforme hard şi medii de
operare.
Dată fiind marea diversitate de platforme hard şi medii de operare, problema este reală şi dificil de rezolvat.
Esenţa acestei probleme constă în faptul că orice sistem soft, ajuns în faza executabilă, pe un calculator real,
trebuie “să se înţeleagă cu calculatorul respectiv”. Aceasta înseamnă că un cod execuatbil are o anumită structură
şi instrucţiunile pe care le conţine sunt recunoscute de procesorul maşinii gazdă. Structura codului executabil
este importantă pentru sistemul de operare, care supervizează încărcarea codului executabil în memorie şi
execuţia acestuia, pas cu pas.
Uşurinţa în folosire
Se referă la modul în care oameni cu diferite nivele de instruire pot învăţa să folosească sistemul soft pentru
rezolvarea unor probleme reale. Se referă, de asemenea, la uşurinţa instalării şi operării sistemului soft.
Închei prezentarea proprietăţilor externe ale sistemelor soft cu precizarea că problematica proprietăţilor
interne (structurare, modularizare, obiect orientare, etc.) reprezintă un capitol la a cărui scriere încă se lucrează,
neexistând un consens deplin al specialiştilor asupra modului de articulare a acestora într-o explicaţie stabilă
structural.
2 CE ESTE O METODOLOGIE DE DEZVOLTARE A
SOFTULUI?

2.1 De ce avem nevoie de MDS?

În Capitolul 1 am prezentat o serie de consideraţii, aş zice cu pretenţii de stabilitate structurală, referitoare la
universul IS. Este, însă, prea devreme pentru a-mi închipui că “ucenicii” într-ale producerii softului sau creatorii
de soft după “reţete” proprii au devenit adepţi convinşi ai promovării “reţetelor” IS.
În acest paragraf vom inventaria o serie de probleme concrete de care, vrând-nevrând, specialistul în IS
(afiliat sau nu la o metodologie) se loveşte.
Procedând astfel legitimăm o stare de lucruri întâlnită şi în alte domenii ale cunoaşterii.
Structura discursului în IS este determinată atât de cerinţe epistemologice specifice cât şi de nevoia de
organizare a diferitelor forme de manifestare a existentului în procesul de realizare a sistemelor soft.
Evident, o parte din cerinţele epistemologice specifice le-am surprins în Capitolul 1.
În acest paragraf vom încerca să evidenţiem o parte dintre formele de manifestare a existentului în procesul
de realizare a sistemelor soft.
Trecerea de la enunţ la soluţie, în cazul problemelor de complexitate mijlocie sau mare (în care, de regulă, se
cere modelarea comportamentului unui anumit proces informaţional) este problematică. Astfel, în forma iniţială,
enunţul problemei poate sesiza nişte carenţe într-o activitate care pot fi eliminate prin utilizarea
calculatoarelor sau poate intui nişte avantaje într-o activitate dacă se apelează la suportul calculatoarelor .
În ambele cazuri, pentru a obţine enunţul complet al problemei se trece la analiza informaţională a
problemei. Scopul acestei activităţi este obţinerea unui enunţ complet al problemei care cuprinde cerinţele faţă
de sistemul soft sub forma unei soluţii cu nivel înalt de abstractizare.
Activitatea de analiză informaţională este dificilă şi este primejdios ca, din diferite motive, să nu incluzi
printre cerinţe un anumit aspect informaţional.
Dacă s-a pus punct analizei informaţionale, trebuie să se treacă la elaborarea soluţiei tehnice (un fel de
documentaţie constructivă a sistemului soft). Deşi elaborarea soluţiei tehnice înseamnă descrierea până la detaliu
a componentelor sistemului soft şi a legăturilor dintre acestea, ceea ce înseamnă infuzie treptată de elemente
concrete în soluţie, în paralel se desfăşoară şi activităţi cu pronunţat caracter de abstractizare (pentru a elimina
redundanţele, pentru a optimiza prelucrările, pentru a optimiza legăturile dintre date, pentru a spori rezistenţa
sistemului la modificări, etc.).
De foarte multe ori se poate spune că obiectul analizei informaţionale ca şi obiectul activităţii de obţinere a
soluţiei tehnice au afinităţi cu nisipurile mişcătoare. Ce-i de făcut? Trebuie multă răbdare şi abilitate pentru
a sesiza invarianţii procesului ceea ce ar permite începerea efortului de modelare.
În situaţia în care “calvarul” obţinerii soluţiei tehnice a fost depăşit începe activitatea de transpunere a
soluţiei tehnice în acord cu exigenţele de sintază, semantică şi pragmatică specifice unui limbaj de programare.
N-aş zice că nu există nisipuri mişcătoare şi în această încercare! În mod cert, numitorul comun al
problemelor de matematică cu problemele de informatică este complexitatea. În cazul matematicii predomină
complexitatea structurală; în cazul informaticii, de cele mai multe ori predomină complexitatea spaţială.
Dacă la aceste elemente se adaugă altele, precum: necesitatea reprezentării soluţiei pentru a fi înţeleasă de
diferite categorii de utilizatori, necesitatea de a partaja anumite tipuri de resurse în procesul de elaborare a
soluţiei unui sistem soft, necesitatea de a armoniza efortul de dezvoltare în cazul în care se lucrează în echipă,
etc. ne facem o imagine mai precisă asupra amănuntelor care alcătuiesc specificul unei probleme în IS.
Pentru a înfrunta toate aceste probleme şi multe altele, comunitatea specialiştilor în IS a încercat încă din
epoca de început a erei informaticii să îngrădească liberul arbitru în procesul de dezvoltare a softului, lăsând,
totuşi, loc de manifestare spiritului creator, prin iniţiative de genul:
-studiul teoretic al proprietăţilor algoritmilor: formalizare a reprezentărilor; clasificarea algoritmilor;
-studiul teoretic al unor metode generale de elaborare a algoritmilor (Backtracking, Greedy, Divide et
Impera, Programarea dinamică);
-elaborarea unor metode de programare (programarea structurată, programarea obiect-orientată);
-elaborarea unor metode de analiză a sistemelor informaţionale (procedee de investigare, mod de
reprezenatare, concepte utilizate, etc.);
-elaborarea unor metode de elaborare a soluţiei tehnice (Top-down, HIPO, Warnierr-Orr, etc.);

-dezvoltarea unor elemente suport pentru specialiştii în IS (sisteme de documentare, generatoare de

programe, medii de dezvoltare a soluţiei cu ajutorul calculatorului, etc.);
 -specificarea unor procedee de cuantificare a muncii depuse de specialiştii IS pentru realizarea
sistemelor soft;
-elaborarea unor metode de planificare a efortului de dezvoltare a sistemelor soft .
Acumulările în direcţiile semnalate mai sus sunt impresionante; evoluţia abordărilor în IS, atât teoretice cât
şi practice, seamănă, metaforic vorbind, cu evoluţia populaţiilor în sistemele genetice; călauzită de legităţi,
aparent stochastice, comunitatea specialiştilor în IS produce generaţii succesive de elemente suport în
dezvolatrea softului, le evaluează, în practică, reţine ceea ce este valoros în ele şi promovează ca parte
componentă în generaţiile următoare.
De la o perspectivă fragmentată sau incompletă asupra procesului de dezvoltare a softului s-a ajuns în
ultimii ani la elaborarea unor metodologii unitare de dezvoltare a softului, creaţii ale specialiştilor în IS puse
în slujba specialiştilor în IS, cea mai mare parte din “viaţa” unui sistem soft.

2.2 Încercare de caracterizare a unei metodologii generice de

dezvoltare a softului
În Capitolul 1, paragraful 1.1 am prezentat o listă de activităţi specifice realizării sistemelor soft.
Aceste activităţi sunt:
-abstractizarea soluţiei unui sistem soft (ASS);
-desfăşurarea în timp a (=organizarea) procesului de abstractizare a soluţiei unui sist em soft (OPA);
-reprezentarea şi documentarea evoluţiei unui sistem soft (RDS);
-optimizarea managementului procesului de realizare a unui sistem soft (OMP).
Putem să definim o metodologie generică de dezvoltare a softului astfel:
Un set finit de concepte, principii, norme, convenţii şi reguli de operaţionalizare a acestora, pentru a da
răspunsuri satisfăcătoare problemelor care apar în activităţile de tip AAS, OPA, RDS, OMP.
Să încercăm, în continuare, o serie de precizări relativ la semantica acestei definiţii. (Despre pragmatica
acestei definiţii, încă nu putem spune mare lucru. Dacă am fi vorbit despre o metodologie anume, alta era situaţia
în ceea ce priveşte pragmatica.)
Orice metodologie care “urmăreşte priza la public” trebuie să facă faţă contradic ţiilor, inerente
pentru semantica binomului MDS-specialist în IS.
Una dintre contradicţii se referă la dorinţa de a oferi un set relativ restrâns de concepte, principii şi reguli
de utilizare a acestora în opoziţie cu aspiraţia legitimă a oricărui autor de MDS de a oferi sintaxă care să
permită descrierea unei semantici, cât mai bogată posibil.
Altă contradicţie se referă la înclinaţia spre formalizm a spiritelor riguroase în opoziţie cu înclinaţia spre
intuitiv a altora.
Nu în ultimul rând (pentru că mai sunt şi alte exemple) semnalez contradicţia dintre necesitatea de a
standardiza mare parte a procesului de dezvoltare a sistemelor soft şi nevoia de exprimare liberă resimţită
de unii specialişti. În alt plan ne întâlnim cu contradicţia dintre nevoia de a creşte productivitatea muncii şi
necesitatea de a realiza sisteme soft de calitate.
Cei care specifică MDS se străduiesc să menţină echilibrul între aceste contradicţii prin diferite mijloace.
De exemplu, referitor la prima contradicţie, metodologia UML oferă o semantică foarte bogată cu ajutorul
unui set bine ales de concepte şi principii, oferind şi câteva mecanisme de extensie cu ajutorul cărora semantica
metodologiei poate fi îmbogăţită.
În ceea ce priveşte capacitatea unei MDS de a oferi suport pentru rezolvarea problemelor de tip
ASS, suntem datori cu o serie de precizări importante. Pentru o MDS recomandările pe care aceasta le face
pentru a transforma enunţul unei probleme de informatică în soluţie executabilă pe un calculator real, practic
definesc însăşi substanţa metodologiei. Aceste recomandări desemnează, conform literaturii de specialitate,
ciclul de abstractizare al unei MDS.
Pentru un specialist în IS prima întrebare pe care şi-o pune în faţa unei probleme noi este destul de lungă.
“Cum să derivez din datele problemei o soluţie, respectând termenele de execuţie, fără să dezamăgesc
utilizatorul direct, întâmpinând exigenţele curente şi de perspectivă ale utilizatorului indirect şi, chiar
dacă pare un pic utopie, fără să mă stresez peste măsură?”.
Fără îndoială, o astfel de întrebare poate avea o serie de conotaţii etice, filozofice, etc. dar nu acestea îl
preocupă pe specialistul în IS.
Evidenţiind doar ingredientele esenţiale ale unei probleme de IS, avem:
-Date
-Prelucrări
-Interfeţe

Toate aceste ingrediente există în domeniul problemei în format utilizator.

În domeniul problemei, pentru descrierea soluţiei se folosesc concepte pe care le înţeleg, probabil, oricare
dintre participanţii la un proiect, dar, în orice caz, ar trebui să le înţeleagă participanţii din sfera utilizatorilor
şi clienţilor.La celălalt capăt al balanţei se află domeniul soluţiei în care se vehiculează concepte pe care le
înţelesc specialiştii în IS.
În format utilizator datele sunt organizate supralicitând redundanţa, prelucrările, fiind aplicate unor date în
care “musteşte” redundanţa, nu sunt automat cea mai fericită alegere.
Tot atât de delicată este şi problema “organizării” interfeţelor deoarece în elaborarea acestora trebuie
gestionată optim contradicţia dintre dorinţa de a oferi utilizatorului confort şi pornirea naturală a
specialistului în IS de a raţionaliza interfaţa cu utilizatorul.
Acestea sunt o parte din motivele pentru care o MDS trebuie să ofere suport pentru elaborarea treptată (pe
mai multe nivele de abstractizare) a soluţiei pentru probleme de genul:
-organizarea optimă a datelor utilizate de un sistem soft;
-organizarea optimă a prelucrărilor specifice unui sistem soft;
-organizarea pe principii ergonomice şi de eficienţă a interfeţelor unui sistem soft.
Suportul oferit pentru rezolvarea problemelor semnalate mai sus depinde de metodologie. Rămânând la
ideea de metodologie generică, ar trebui să spunem că acest suport poate reprezenta un set de concepte,
principii şi reguli de operaţionalizare a acestora cu ajutorul cărora se reprezintă proprietăţile de un
anumit tip ale procesului în curs de modelare.
De exemplu, proprietăţile informaţionale ale procesului modelat, odată ce au fost identificate, caracterizate
şi clasificate ne pot da o descriere a aspectelor statice ale procesului; în acest scop metodologiile oferă modele de
organizare a datelor, eventual pe mai multe nivele de abstractizare.
Proprietăţile comportamentale ale procesului pot fi descrise utilizând modele capabile să surprindă diferite
“nuanţe” ale dinamicii unui sistem.
Pare simplu, dar nu este aşa. Pentru a obţine o reprezentare cât mai exactă a proprietăţilor informaţionale şi
comportamentale ale unui proces, trebuie să elaborăm:
-modele care reprezintă statica unui sistem;
-modele care reprezintă dinamica unui sistem;
-modele care reprezintă fluxurile informaţionale într-un sistem
ş.a.m.d.
Altfel spus, sistemul modelat este privit din mai multe perspective, fiecare perspectivă permiţând descrierea
unui anumit tip de proprietăţi; laolaltă, putem spune, fortând puţin lucrurile, perspectivele ne ajută să obţinem o
“imagine holografică” asupra sistemului modelat. Până unde merge acurateţea acestei imagini?! Iată o întrebare
cu mai mult de două tăişuri pentru cei care dezvoltă softuri dar mai ales pentru cei care specifică noi MDS.
În ceea ce priveşte capacitatea unei MDS de a oferi suport pentru rezolvarea problemelor de tip
OPA.
Oferta MDS privind rezolvarea problemelor de tip OPA este desemnată în literatura de specialitate prin
sintagma ciclul de viaţă al sistemelor soft.
Ciclul de viaţă al sistemelor soft este, alături de ciclul de abstractizare, o caracteristică fundamentală a MDS.
Este evident faptul că, la detaliu, fiecare MDS are propria propunere de ciclu de viaţă. Făcând abstracţie de
metodologie, o primă perspectivă asupra semanticii noţiunii de ciclu de viaţă o obţinem în Figura 2.1.
Diagrama din Figura 2.1 surprinde elementele esenţiale pe baza cărora începe să aibă sens noţiunea de ciclu
de viaţă.
Adevărul este că, pentru sisteme soft de complexitate mare sau medie, ciclul de viaţă al unei MDS trebuie să
propună reguli de etapizare/organizare a efortului de realizare a unui sistem soft reunite sub denumirea
“Dezvoltare”. Tot din ciclul de viaţă face parte şi utilzarea sistemului soft, de la care putem avea feed-back-uri
care pot genera modificări.

Analiza Proiectarea Implementarea Testarea

Etape de dezvoltare
Figura 2.1. Conţinutul generic al etapei de dezvoltare a unui sistem soft

Având ca pretext diagrama prezentată în Figura 2.1., pot prezenta comentariile de mai jos.

Analiza
Este etapa în care se constată că este necesar un sistem soft şi se iau decizii în consecinţă.
 Fie că se constată existenţa unei pieţe pentru un produs de uz general, fie că o anumită organizaţie are
nevoie de un soft specializat, în mare măsură această primă etapă presupune mai degrabă luarea unor decizii de
management şi marketing decât abordarea unor probleme legate de studiul algoritmilor, de exemplu.
După luarea deciziei de dezvoltare a sistemului soft începe analiza propriu-zisă, al cărei scop principal este
identificarea necesităţilor utilizatorului potenţial al sistemului soft. De exemplu, în cazul unui produs de uz
general, care urmează a fi vândut pe o piaţă concurenţială, trebuie stabilit un public ţintă. Dacă se construieşte un
sistem soft de gestiune a stocurilor ce urmează a fi folosit în departamentul de aprovizionare al unei firme
constructoare de maşini, atunci trebuiesc identificate necesităţile şi aşteptările celor care lucrează în cadrul
acestui departament.
Unul dintre rezultatele formale ale etapei de analiză îl reprezintă un set de cerinţe pe care noul sistem soft ar
trebui să le satisfacă. Acestea trebuiesc formulate din punctul de vedere al utilizatorului (direct sau indirect), sau
în limbajul de specialitate al IS.
După ce au fost identificate cerinţele, acestea sunt transformate în specificaţii tehnice. Ca un exemplu,
cerinţa ca accesul la datele sistemului să fie permis doar persoanelor autorizate se poate transforma în
specificaţia că sistemul nu trebuie să răspundă decât după introducerea unei parole de exact unsprezece
caractere, confirmată de sistem.
Fireşte, se pot pune întrebările:
“Care sunt regulile care guvernează procesul de identificare şi reprezentare a cerinţelor faţă de sistemul
soft?”
şi
“Care sunt regulile care guvernează domeniul de elaborare şi reprezentare a specificaţiilor tehnice?”.
Răspunsul este simplu: metodologia oferă suport de tip ASS şi suport de tip RDS care se foloseşte în această
etapă a ciclului de viaţă cât mai eficient cu putinţă.
Proiectarea
Este etapa în care soluţia sistemului soft este specificată în detaliu.
În termeni generali vorbind, sistemul soft imaginat în etapa de analiză este descompus, progresiv, în
componente mai uşor de modelat, numite, generic, module. Implementarea sistemelor complexe devine posibilă
tocmai prin această descompunere modulară. Astfel, mulţimea detaliilor tehnice care trebuie luată în considerare
ar fi imposibil de stăpânit. Proiectarea modulară creează, totodată condiţii pentru lucrul în echipă şi vine în
întâmpinarea efortului de întreţinere, dacă acesta este reclamat.
Una dintre concluziile greu de combătut ale generaţiilor de MDS poate fi formulată astfel:
“O structură modulară, chibzuit proiectată este benefică atât pentru implementarea sistemului cât şi
pentru modificarea sa ulterioară.”
Probabil, acesta este unul dintre principalele motive pentru care modelarea orientată spre obiecte câştigă tot
mai mult teren.
În faza de proiectare, ca şi în cea de analiză suportul de tip ASS şi RDS este esenţial pentru a obţine o
soluţie tehnică de calitate.
Implementarea
Este etapa în care are loc scrierea efectivă a programelor, crearea fişierelor şi, în consecinţă, dezvoltarea
bazei de date a sistemului soft astfel obţinut.
Testarea
Este etapa strâns legată de etapa anterioară deoarece, în mod normal, fiecare modul al sistemului este testat
în timpul implementării.
Într-un sistem bine proiectat (ceea ce ar face trimitere directă la o serie de posibili factori interni ai calităţii
precum: decompozabilitatea modulară, compozabilitatea modulară, înţelegerea modulară, continuitatea modulară
şi protecţia modulară) fiecare modul poate fi testat în mod independent, utilizând versiuni simplificate ale
celorlalte module pentru a simula interacţiunea modulului ţintă al testării cu restul sistemului. Evident, pe măsură
ce diferite module sunt finalizate şi combinate, testarea individuală face loc treptat testării generale a întregului
sistem.
Practica dovedeşte că testarea şi complementara acestei activităţi, care este depanarea, sunt, îndeosebi în
cazul sistemelor mari activităţi greu de finalizat. Sistemele de mari dimensiuni pot conţine foarte multe erori
chiar şi după efectuarea celor mai complexe teste. Multe erori pot rămâne neobservate pe toată durata vieţii
sistemului soft. Punerea la punct a unor strategii de eliminare a acestor erori este un obiectiv major al IS. Practica
ne arată că în această direcţie mai sunt încă multe probleme de rezolvat.



În ceea ce priveşte capacitatea unei MDS de a oferi suport pentru rezolvarea problemelor de tip
RDS, putem, de asemenea, să facem o serie de consideraţii cu caracter general.
Pe tot parcursul elaborării soluţiei unei probleme, aceasta trebuie documentată şi reprezentată.
 Soluţia trebuie documentată deoarece există mai multe categorii de persoane interesate în utilizarea acestei
documentaţii (operatorii sistemului soft, cei care distribuie şi instalează sistemul soft, programatorii care se
ocupă de întreţinerea sistemului soft, partenerii proiectului de realizare a sistemului soft, etc.).
Documentaţia de utilizare poate fi realizată sub forma unor ghiduri de utilizare tipărite sau poate fi
încorporată în structura sistemului soft sub formă de help interactiv. Spre binele autorilor sistemelor soft sau spre
binele celor care ar trebui să modifice sistemul soft este bine ca însuşi codul sursă al sistemului soft să fie
generos documentat.
Deoarece, de calitatea documentaţiei depinde în mare măsură şi priza sistemului soft la segmentul de
piaţă căruia i se adresează, marile firme producătoare de soft au transformat documentarea unui sistem soft
într-o activitate supusă în mare măsură standardelor, automatizării, legilor pieţei.
Se cunosc exemplele remarcabile oferite în această privinţă de firme precum Microsoft sau Borland.
Soluţia trebuie reprezentată în fiecare etapă a ciclului de viaţă deoarece:
-permite schimbul de informaţii de natură tehnică între partenerii de proiect;
-serveşte ca sursă de documentare strict necesară celor care vor să aducă modificări sau dezvoltări
acestei soluţii.
Atât pentru documentarea cât şi pentru reprezentarea soluţiei se folosesc limbaje sau sisteme adecvate.
Astfel, pentru documentare se foloseşte, în esenţă, limbajul natural, manifestându-se o grijă deosebită pentru
rigoarea, claritatea, sugestivitatea şi uşurinţa în utilizare a diferitelor tipuri sau sisteme de documentare.
Programatorii, îndeosebi, sunt deja obişnuiţi cu încorporarea în mediile de programare sau în funcţionalitatea
diferitelor sisteme soft a unor help-uri interactive de mare complexitate sau a tutorialelor care asistă învăţarea
operării sistemelor soft. Ultima “găselniţă” în materie de documentare a sistemelor soft o reprezintă capabilităţile
de tip “wizards” care scutesc utilizatorii de grija de a memora anumite protocoale de utilizare a sistemelor soft,
lăsându-le însă întotdeauna libertatea de a gândi care este cea mai bună alegere într-un anumit moment al
utilizării softului în cauză.
În ceea ce priveşte reprezentarea soluţiei, aducem la cunoştinţa cititorului faptul că lucrurile sunt mai puţin
aşezate decât în cazul documentării.
Limbajele alese pentru reprezentarea soluţiei unui sistem soft pot fi:
-tributare cerinţei de a fi intuitive, caz în care textul este combinat cu grafica conform unor reguli
specificate riguros din punct de vedere sintactic (a se vedea notaţia utilizată în UML!);
-tributare excesului de formalizm, indispensabil, spun teoreticienii pentru a asigura un spor de
corectitudine în specificare, analiză, proiectare. Formalizmul excesiv este cerut şi de, încă ipotetica, nă zuinţă a IS
de a implica sisteme soft specializate în generarea automată a codului executabil pornind de la soluţia tehnică (a
se vedea Z, Z++, VDM, VDM++, sisteme formale de reprezentare a soluţiei unui sistem soft care au reuşit
câteva străpungeri experimentale în lumea practică a IS şi atât deocamdată).
Referitor la notaţie (cum se mai numeşte limbajul de reprezentare a soluţiei) să precizăm că aceasta în
manualele de prezentare a MDS este strâns dependentă de semantica metodologiei, adică limbajul de
reprezentare a soluţiei “respiră acelaşi aer” cu limbajul de abstractizare a soluţiei.
În ceea ce priveşte capacitatea unei MDS de a oferi suport pentru rezolvarea problemelor de tip
OMP
Din cele expuse până în acest punct al lucrării s-a înţeles, presupun, faptul că lucrul în cadrul unui proiect de
dezvoltare a unui sistem soft ridică probleme deosebite din punctul de vedere al managementului. Deja, practica
lucrului în cadrul proiectelor de realizare a unor sisteme soft serioase a confirmat valabilitatea afirmaţiei potrivit
căreia:
Un management slab poate compromite uşor şansele de reuşită ale unei echipe de proiectare redutabilă
profesional; un management bun poate gestiona eventualele probleme datorate nivelului profesional
necorespunzător al unora dintre membrii echipei de proiectare.
Lumea în care trăim este, fără să exagerăm deloc, opera diferitelor tipuri de management.
Specialişti sau nu în probleme de management, este bine să ştim că există discipline care studiază
problemele fundamentale ale managementului, dar, complexitatea activităţilor imaginate de om depăşind de mult
capabilităţile explicative şi operaţionale ale unui tratat de bazele managementului, asistăm la apariţia unor
varietăţi noi de management cu obişnuinţa cu care la un anumit timp după apusul soarelui ne vine din ce în ce
mai greu să rezistăm tentaţiei de a ne culca. Printre aceste varietăţi de management se află şi managementul
proiectelor de realizare a sistemelor soft (MPRSS). Multe dintre principiile fundamentale ale teoriei
managementului operează şi în cadrul MPRSS. Mai mult, putem afirma că, cel puţin în cazul etapei de analiză
din ciclul de viaţă al unui sistem soft cunoştinţele de management sunt de mare utilitate (dacă sistemul soft este
realizat la cererea conducerii unei organizaţii cu sau fără profit).
Multe din întrebările care se pun în etapa de analiză (ce obiective are de îndeplinit sistemul soft?, care sunt
mijloacele de îndeplinire a acestor obiective?, cum îşi mapează sistemul soft funcţiile pe domeniul activităţilor
deservite?, etc.) primesc răspunsuri mult mai clare dacă analistul are şi cunoştinţe de management. Sperând că v-
am convins, oarecum, de utilizarea unui management adecvat al procesului de dezvoltare a unui sistem soft, să
anticipăm că în atenţia MPRSS se află trei tipuri fundamentale de activităţi:
-gestiunea resurselor angajate în realizarea sistemului soft;
-asigurarea calităţii sistemului soft;
-gestiunea riscurilor asociate procesului de realizare a sistemului soft.
Toate aceste trei tipuri de activităţi se desfăşoară după o planificare riguroasă care presupune, în esenţă
stabilirea cadrului optim din punct de vedere organizatoric şi logistic care permite valorificarea suportului
oferit de MDS pentru rezolvarea problemelor de tip ASS, OPA, RDS.
Nu ne va surprinde, aşadar, să constatăm că specialiştii care depun eforturi pentru dezvoltarea suportului
metodologic de tip OMP propun o serie de modele calitative şi cantitative cu ajutorul cărora se încearcă
măsurarea sau evaluarea rezultatelor activităţilor mai sus precizate.
Date fiind particularităţile acestor activităţi în cazul proiectelor de realizare a unor sisteme soft, este de
aşteptat ca multe direcţii de acţiune ale managementului să se supună unor legităţi specifice.
Orice patron de firmă soft va scăpa de multe probleme în ziua în care din laboratorul de cercetare va ieşi pe
piaţă o metodologie care:
articulează atât de bine contradicţiile, certitudinile şi incertitudinile din munca unui specialist în IS, încât
toate merg ca într-o linie de fabricaţie a unor echipamente necesare pentru dotarea unor capsule spaţiale.
Fericire sau ghinion, cert este că mai avem cale lungă până acolo. Nu cred că este cazul să vă spun explicit
de ce. Doar atât mai adaug: de vină este complexitatea unora dintre activităţile specifice gândirii omeneşti.
Nu ne rămâne decât să alegem dintre nenumăratele rele pe care le avem în faţă pe cea mai puţin costisitoare
din toate punctele de vedere.
3 CICLUL DE VIAŢĂ AL UNUI SISTEM SOFT
3.1 Ciclul de viaţă al sistemelor soft. Încă o introducere
Să ne reamintim, la acest început de capitol, ideea de bază a capitolelor 1 şi 2: nevoia de sistematizare a
procesului de dezvoltare a sistemelor soft.
Nimeni nu contestă faptul că se pot întâlni abordări de genul celor reprezentate în Figura 3.1 şi în Figura 3.2.

Specificarea Implementare
cerinţelor

Figura 3.1 Un model primitiv de dezvoltare a softului

Specificarea Diagrama de
cerinţelor structură

Implementare

Figura 3.2 Un model îmbunătăţit de dezvoltare a softului

Tot ceea ce se poate spune despre modelele de dezvoltare sugerate de figurile de mai sus este faptul că
abstractizează frumos, dar ineficient procesul de dezvoltare a sistemelor soft de mare şi medie complexitate.
Conform Figurii 3.1, specialistul în IS trebuie să aibă abilităţi remarcabile care să-i permită să facă un salt
uriaş de la cerinţe la codul care descrie, practic, în detaliu, soluţia executabilă a sistemului soft.
Există oameni care pot face acest lucru. Diferitele nivele de abstractizare şi faze de dezvoltare a softului se
înfiripă în creierele acestora şi capătă contururi suficient de clare pentru a permite alimentarea cu “materie primă
de calitate” a procesului de codificare. Chiar şi în cazul unor astfel de oameni, saltul de la cerinţe la cod este plin
de riscuri.
Îmbunătăţirea sugerată de Figura 3.2 este reală dar insuficientă. Ani la rând, în laboratoarele de cercetare ale
IS s-au făcut eforturi extrem de diverse şi uneori foarte originale, pentru găsirea celei mai bune formule de
desfăşurare în timp a procesului de abstractizare a soluţiei unui sistem soft.
Toate aceste formule se concretizează într-o listă lungă de propuneri de cicluri de viaţă, din care vom
analiza în continuare câteva exemple reprezentative.
Deşi ciclul de viaţă propus de o MDS funcţionează optim în conjuncţie cu o anumită strategie de
abstractizare a soluţiei, specifică MDS, în analiza pe care o fac în paragraful 3.2 voi insista doar pe elementele
care definesc particularităţile unei MDS din punct de vedere al ciclului de viaţă.

3.2 Ciclul de viaţă al sistemelor soft. Câteva exemple.

Schimbările care s-au produs, în timp, în ceea ce priveşte tehnologiile informaţionale şi MDS s-au reflectat
şi în ciclul de viaţă al sistemelor soft, fie prin schimbarea etapelor acestuia, fie prin modificarea strategiei de
parcurgere a acestor etape.
Un studiu comparativ al diferitelor exemple de MDS evidenţiază o serie de elemente interesante.
Numărul fazelor ciclului de viaţă specific unei MDS poate varia de la trei (analiză, proiectare,
implementare) până la douăzeci sau mai multe.
Este evident faptul că, şi în acest domeniu, concurenţa, beţia teoretică şi ruperea contactului cu realitatea
zămislesc, din când în când, adevăraţi monştri metodologici. Pentru a trece cu brio examenul practicii, o MDS
trebuie să manifeste o preocupare deosebită pentru două dintre trăsăturile ciclului de viaţă asociat:

-numărul de faze să fie justificat atât de o analiză punctuală cât şi de consideraţii de ansamblu în ceea
ce priveşte versatilitatea operaţionalizării ciclului de viaţă;
-fiecare fază a ciclului de viaţă să fie “acoperită” satisfăcător de elemente supor t pentru rezolvarea
problemelor de tip ASS, RDS, OMP.
 Având în vedere aceste două exigenţe, voi trece la descrierea unor modele ale ciclului de viaţă al sistemelor
soft reprezentative, urmând să degajez o serie de concluzii generale după prezentarea acestor modele.

3.2.1 Modelul cascadă( MC)

Numit şi water-fall, este un exemplu de ciclu de viaţă care a făcut istorie. El afost “lansat la apă” la
începutul deceniului 7 de către W. W. Royce şi constă într-o descompunere a ciclului de viaţă al unui sistem soft
în faze secvenţiale. Fazele sunt descompuse în activităţi. Trecerea de la o fază la alta se realizează după ce
precedenta a fost parcursă integral.
Să mai reţinem şi faptul că MC se aplică la nivel de sistem. Alte informaţii cu privire la model în Figura 3.3.

Definirea
cerinţelor

Analiza

Proiectarea

Implementarea

Testarea

Utilizarea
şi instruirea

Figura 3.3. Modelul cascadă

Avantaje recunoscute ale modelului cascadă

Oferă un control total asupra fazelor, în sensul că acestea fiind ordonate devin previzibile, evidenţiindu-se
clar “întinderea” lor ca o colecţie de activităţi şi subactivităţi specifice;
Este uşor de însuşit de către partenerii unui proiect, inclusiv de cei cu experienţă redusă;
Fiecare fază este “acompaniată” de o documentaţie destul de bine structurată.
Dezavantaje ale modelului cascadă
Aplicându-se la nivel de sistem, evident că nu oferă suport prea consistent pentru controlul complexităţii
în cazul sistemelor mari;
Deşi, după cum reiese şi din Figura 3.3, nu este descurajată abordarea iterativă a unor faze sau
componente ale lor, restricţiile de timp impuse de programarea calendaristică a fazelor limitează ofertele
benefice ale posibilităţii de revenire la o etapă anterioară.
Acest fapt nu este tocmai convenabil dacă ţinem cont de faptul că, în practică, nu numai că sunt necesare
reluări ale fazelor, mai mult se simte nevoia lucrului în paralel la o scară mai mare decât o permite modelul
cascadă;

Evident, sistemul se predă doar după parcurgerea etapelor anterioare, ceea ce înseamnă o lungă perioadă
de timp până când utilizatorul vede sistemul la lucru, ceea ce nu este convenabil pentru nici una din faze
(utilizatorul are destul timp să emită alte pretenţii faţă de sistemul soft);
MC nu oferă suport adecvat pentru abordarea dinamică a proceselor de modelat;
MC nu are protecţie explicită faţă de modificările care pot interveni pe parcursul dezvoltării sistemului
soft.
 Nu am considerat necesar să mai insist asupra conţinutului fazelor prezentate în Figura 3.3. Paragraful 2.2 al
acestei lucrări conţine suficiente informaţii lămuritoare în acest sens.
Cu toate că are destui critici, modelul cascadă a fost şi este folosit, integral sau parţial, ori de câte ori se
doreşte un ciclu de viaţă cu o structură echilibrată.

3.2.2 Modelul V (MV)

Acest model preia ideile de bază ale modelului cascadă, integrându-le într-o concepţie ierarhică de
controlare a modului în care sunt parcurse fazele de dezvoltare. (A se vedea Figura 3.4)
Modelul, prezentat în Figura 3.4, descrie o strategie de organizare a procesului de abstractizare în care se
propune o perspectivă mai clară asupra elementelor de feed-back ale procesului, o abordare mai modernă
a relaţiei sistem-componente, o delimitare mai precisă a interferenţelor procesului cu utilizatorul
sistemului soft rezultat.
Adevărul este că marile mutaţii produse în lumea tehnologiilor informaţionale orientează eforturile
specialiştilor în IS către posibilitatea abordării unui sistem orientat pe componente, de o manieră iterativ-
incrementală (ceea ce înseamnă mai mult decât oferta modelului V) cu o atenţie deosebită faţă de utilizator.
În actuala etapă de dezvoltare a IS utilizatorul a devenit un partener ale cărui opinii trebuie luate în seamă
pentru ca sistemul soft să poată trece cu bine “examenul pieţei”.
Aş mai sublinia faptul că în cadrul MV se face o distinţie clară între verificare şi validare, ca activităţi
specifice laturii din dreapta a V-ului modelului.
Verificarea se referă la testarea sistemului, în diverse faze de dezvoltare, din punct de vedere al
corectitudinii logice. În schimb, validarea permite verificarea corectitudinii specificării cerinţelor iniţiale faţă de
sistemul soft. Figura 3.4 ne arată că validarea stabileşte dacă sistemul, în forma lui finală, corespunde sau nu
cerinţelor. Faptul că validarea este posibilă doar când sistemul ajunge în forma finală este un punct slab al
modelului, îndeosebi în situaţia în care procesul de modelat are afinităţi structurale sau conjuncturale cu
“nisipurile mişcătoare”.
Menţionăm faptul că MV, în forma consacrată aparţine lui Ould, care l-a adus în faţa comunităţii
specialiştilor în IS în 1990.

Definirea
cerinţelor Validare

Proiectare Testare
sistem sistem

Proiectare Testare
subsisteme subsisteme
(componente) (componente)

Codificare/
asamblare
componente

Figura 3.4. Modelul V

3.2.3 Modelul prototipizării (MP)

Multe modele de dezvoltare se bazează pe utilizarea, în anumite momente, a abordărilor iterative (de
exemplu, analiza poate implica o serie de sarcini care sunt iterativ repetate până când modelele analizei sunt
considerate complete).
Deşi promite un cadru mai realist de dezvoltare a softului o astfel de abordare poate fi uşor “descumpănită”
de constatarea că, în zilele noastre utilizatorul final sau indirect ştie să folosească sistemul odată ce acesta a
fost livrat, ceea ce creează foarte repede împrejurările necesare pentru ca acesta (utilizatorul) să observe
eventualele neconcordanţe între cerinţele lui faţă de sistem şi cele implementate efectiv .
MP oferă o abordare care, potenţial, poate contribui la eliminarea omisiunilor şi ambiguităţilor care pot
exista în cerinţe.
În IS se numeşte prototip un sistem sau un sistem parţial finisat care este construit rapid pentru a explora
anumite aspecte ale cerinţelor faţă de sistem şi care nu este considerat sistem gata de livrarea finală la
utilizator.
Un sistem soft aflat în faza de prototip se deosebeşte de un sistem soft gata de livrare prin o serie de
omisiuni asumate sau strecurate involuntar în faza de codificare (implementare).
Astfel că un prototip are, în mod obişnuit, o funcţionalitate incompletă (capacitate limitată de procesare a
datelor, performanţe reduse în timpul execuţiei, siguranţă în funcţionare problematică, etc.).
Dezvoltarea prototipului este posibilă efectiv doar utilizând instrumente pentru dezvoltarea rapidă a
sistemelor soft (medii vizuale de proiectare, medii vizuale de programare, etc.).
Când realizăm un prototip putem avea diferite obiective în minte.
Putem construi un prototip pentru a investiga cerinţele utilizator; în acest scop ne putem focaliza efortul de
dezvoltare pe realizarea interfeţei cu utilizatorul pentru a stabili ce date aşteaptă utilizatorul de la sistem şi ce
date furnizează utilizatorul sistemului.
Prototipul poate fi folosit pentru a determina cel mai adecvat gen de interfaţă.
Putem construi un prototip pentru a stabili dacă o platformă de implementare anume poate suporta anumite
cerinţe de prelucrare.
În sfârşit, un prototip ar putea să urmărească determinarea eficienţei unui limbaj particular, a unui SGBD
sau a unei infrastructuri de comunicaţie.
O perspectivă mai clară asupra proprietăţilor modelului MP putem obţine şi din Figura 3.5.

Analiza Definire
iniţială obiective
prototip

Specificare
prototip

Evaluare prototip Construire

şi stabilire protoip
schimbări

Prototip
complet

Figura 3.5. Dezvoltarea rapidă a softului

utilizând prototipizarea
Aşadar, fazele principale necesare pentru a pregăti un prototip sunt:

Efectuarea unei analize iniţiale;

Definirea obiectivelor prototipului ;
Specificarea prototipului;
Construirea prototipului;
Evaluarea prototipului şi stabilirea schimbărilor de efectuat.
 Efectuarea unei analize iniţiale
Întreaga activitate de dezvoltare a softului foloseşte resurse valoroase. Începerea unui exerciţiu de
prototipizare fără o analiză iniţială este posibil să conducă la o activitate nestructurată şi greşit focalizată care va
produce un soft proiectat nesatisfăcător.

Definirea obiectivelor prototipului

Prototipizarea este de dorit să aibă obiective clar stabilite. Un exerciţiu de prototipizare poate implica multe
iteraţii, fiecare iteraţie având drept rezultat o anumită îmbunătăţire a prototipului. Pentru participanţii la un
exerciţiu de prototipizare, la un moment dat poate fi dificil de stabilit dacă prototipizarea trebuie sau nu să
continue. Pentru evitarea unei astfel de posibilităţi definirea clară a obiectivelor de îndeplinit poate fi de mare
folos.

Specificarea prototipului
Deşi prototipul nu este realizat în perspectiva unor operaţii de extindere este, evident, important să aibă un
comportament scontat. De aceea, este absolut firesc să luăm în calcul posibilitatea unor modificări care să
apropie prototipul cât mai mult de comportamentul scontat.
Aceste modificări sunt mult mai uşor de făcut dacă softul este realizat potrivit unor principii de proiectare
profunde.

Construirea prototipului
Deoarece este important ca prototipul să fie realizat rapid este firesc ca în această fază să se apeleze la un
mediu de dezvoltare rapidă a plicaţiilor (Delphi, Visual Basic, Visual C, C-Builder, etc.).

Evaluarea prototipului şi stabilirea schimbărilor de efectuat

Motivul principal pentru care realizăm un prototip este testarea şi explorarea anumitor aspecte ale sistemului
soft de realizat. Prototipul trebuie evaluat în conformitate cu obiectivele identificate la începerea exerciţiului de
prototipizare. Dacă obiectivele nu au fost îndeplinite, evaluarea are drept consecinţă o serie de modificări care
urmăresc apropierea prototipului de obiectivele asumate.
După cum se vede şi din Figura 3.10, ultimele trei faze sunt parcurse ciclic, până când toate obiectivele
asumate de exerciţiul de prototipizare sunt îndeplinite.
În cele ce urmează putem prezenta avantajele acestui model dar şi o serie de aspecte de care ar trebui să
ţinem cont înainte de a ne “aventura” în prototipizare.

Avantaje:
Ilustrarea timpurie a funcţionalităţii sistemului ajută la identificarea tuturor dezacordurilor dintre
specialistul IS şi client;
Cerinţele client omise au şanse să fie identificate;
Dificultăţile legate de proiectarea interfeţei pot fi conştientizate şi rezolvate;
Realizabilitatea şi utilitatea sistemului soft pot fi testate chiar dacă, prin natura lui, prototipul este
incomplet.

Probleme:
Clientul poate percepe prototipul ca parte a sistemului final dar nu poate înţelege amploarea efortului
cerut, uneori, de realizarea formei finale a sistemului, motiv pentru care are senzaţia că acesta (sistemul final)
trebuie livrat mai curând decât este posibil în realitate;
Prototipul poate distrage atenţia de la aspectele funcţionale (uneori critice pentru sistem) către problemele
de interfaţă (fetişizate oarecum de nevoia de a da permanent satisfacţie clientului/utilizatorului);
Prototipizarea se bazează pe o implicare semnificativă a utilizatorului;
Managementul care se bazează pe modelul MP are de luat decizii dificile de-a lungul întregului ciclu de
viaţă.

3.2.4 Concluzii
Deşi din motive didactice am încercat să focalizez atenţia cititorului pe noţiunea de ciclu de viaţă, acesta va
înţelege, probabil, legătura indisolubilă dintre ciclul de viaţă şi celelalte componente ale unei MDS. Îndeosebi
binomul ciclu de viaţă – ciclu de abstractizare trebuie înţeles profund de către practicanţii IS care vor să
valorifice la maximum potenţialul unei MDS.
Exemplele prezentate arată, pe de o parte, dificultăţile întâmpinate de-a lungul timpului de specialişti IS în
încercarea lor de a spori randamentul metodologiilor de dezvoltare a softului, pe de altă parte tendinţa
permanentă a MDS de a oferi o perspectivă cât mai realistă asupra procesului de dezvoltare a sistemelor soft.
 Aşa cum se vede şi din exemplele prezentate nu lipsesc nici exagerările, multe din modelele specificate de-a
lungul timpului funcţionând frumos doar în închipuirea creatorilor lor.
Ca o concluzie de bun simţ, am putea spune că un model de dezvoltare este bun dacă este agreat de un
număr mare de specialişti.
Acest lucru se poate întâmpla dacă:
modelul este uşor de învăţat şi operaţionalizat;
modelul este bine ancorat în realitatea procesului de dezvoltare;
modelul oferă suport consistent de-a lungul întregului proces de dezvoltare a sistemelor soft.
Cititorul începe, probabil, să fie de acord cu mine atunci când spun că în IS "nisipurile sunt mişcătoare",
multe probleme nerezolvate stau la vedere, deci cei care se simt cu muşchii tari pot să iasă la "interval".
Expediţia noastră continuă pentru că mai avem şi alte necunoscute de scos la iveală în capitolele care
urmează.
4 ABSTRACTIZAREA SOLUŢIEI UNUI SISTEM SOFT
4.1 Modelarea. Limbaje de modelare
După Capitolul 3, în care libertatea de mişcare a gândirii a fost oarecum îngrădită de exigenţele subiectului
abordat, iată-ne din nou pe un teritoriu vast, complex şi în continuă prefacere: universul modelării.
Activitatea de elaborare a modelelor se bazează, prin definiţie, pe un mare consum de energie intelectuală.
Cu atât mai mare este efortul de modelare cu cât orizontul epistemologic al celui implicat în efort este
nestructurat sau structurat neconcludent.
Ori de câte ori este vorba despre activităţi care se bazează pe “muşchii” gândirii, trebuie să ne asumăm
deopotrivă riscurile, frumuseţea şi noutatea pe care o presupune rezolvarea unei probleme. Chiar şi atunci când
“drumul este, pe alocuri, bătătorit” pentru a reuşi avem nevoie de două tipuri de abilităţi:
abilităţi de elaborare sistematică a realităţii,
metodă de modelare în domeniul de care aparţine problema.
Pentru a fi “meseriaşi” adevăraţi ne mai trebuie doar atâta îndoială în ceea ce ştim la un moment dat cât să
ne fie permanent trează dorinţa de a şti mai multe în fiecare clipă.
Ce este un model?
Un model este reprezentarea într-un anumit mediu a unui obiect, proces sau fenomen din acelaşi mediu sau
dintr-un mediu diferit. Vom numi sistem real (SR) obiectul, procesul sau fenomenul supus procesului de
modelare.
Modelul surprinde aspectele considerate importante ale unui SR, dintr-un anumit punct de vedere,
simplificând sau omiţând celelalte aspecte ale SR. Ingineria, arhitectura, astronomia, fizica şi, de ce nu, IS
folosesc intens modele.
Odată realizate, modelele pot fi fizice (în construcţii, în muzeologie, etc.) sau pot lua forma unor
reprezentări adecvate pe un suport de memorie externă (hârtie, floppy-disk, hard-disk, etc.).
În IS proprietăţile modelelor sunt reprezentate cu ajutorul limbajelor.
Făcând abstracţie de cele fizice, modelele se impun atenţiei celor care le studiază prin semantica şi notaţia
lor. Mai pe înţelesul unui specialist IS, înţelegerea unui model este o problemă de sintaxă, semantică şi,
pentru a fi toate bune, trebuie să fie şi o problemă de pragmatică .
Dacă singurul merit al unui model s-ar rezuma la faptul că generează problemele mai sus menţionate,
probabil că, îndeosebi în zilele noastre, ne-am lepăda de ele.
Realitatea este că avem nenumărate motive pentru care acest lucru nu se întâmplă.
Modelarea poate fi utilizată pentru reprezentarea unor sisteme de cunoştinţe în vederea simplificării
înţelegerii acestora de către persoanele interesate.
În lumea IS se folosesc frecvent astfel de modele pentru a capacita utilizatorii în procesul de specificare a
cerinţelor faţă de un sistem soft, de exemplu.
Elaborarea de modele pare a stimula creativitatea celor care proiectează un anumit sistem.
Înainte de a fi ceea ce este în forma finală, un sistem este descris dintr-o serie de perspective care prilejuiesc
realizarea a o serie de modele preliminare.
Sistemul final este aproximarea unui SR, obţinută prin agregarea sintaxei şi semanticii tuturor modelelor
preliminare asociate.
Dacă ar fi să dăm un exemplu din lumea IS, atunci sintaxa şi semantica unui sistem soft ar putea fi rezultatul
agregării a trei tipuri fundamentale de modele:
-modele care descriu aspectele statice ale SR modelat;
-modele care descriu aspectele dinamice ale SR modelat;
-modele care descriu aspectele funcţionale ale SR modelat.
Un model poate fundamenta realizarea unui sistem de organizare, clasificare, vizualizare şi editare a
informaţilor despre sistemele mari.
Altfel spus, nu ne putem imagina procedee de simplificare a efortului de modelare într-un anumit domeniu
dacă nu rezolvăm problema paradigmei-cadru de modelare.
Sistemele dinamice pot fi modelate utilizând, să zicem, paradigma UML.
Cu ajutorul modelelor putem simplifica procesul de alegere a unei soluţii alternative .
Numeroase sunt situaţiile în care factorii care condiţionează la un moment dat procesul de realizare a unui
sistem soft complică peste măsură decizia de continuare a procesului. O modalitate de a ieşi din impas într-o
astfel de situaţie o reprezintă elaborarea de modele alternative şi alegerea celui mai bun pe baza evaluării
avantajelor şi riscurilor asociate acestora.

Modelele au fost dintotdeauna şi elemente suport pentru stăpânirea sistemelor complexe .

 Este, probabil, una dintre virtuţile cel mai mult încercată în IS. Sistemele soft mari (large software system)
pot fi abstractizate pe diferite nivele cu ajutorul modelelor, ceea ce simplifică procesul de înţelegere a SR
modelat (evident, este vorba de un exemplu de sistem informaţional), evidenţiază mai uşor structura sistemului
sau permite anticiparea impactului pe care eventuale schimbări le pot produce asupra SR.
Oprim aici o analiză care ar putea fi continuată la alt nivel de abstractizare pentru a spune mai multe în
favoarea utilităţii modelelor.
Convingerea mea, probată şi de practică, este că merită să înveţi să modelezi oricât de dificil pare, la început,
universul paradigmei folosite.
Ce este un limbaj de modelare?
Cititorul bănuieşte, probabil, că nu ajunge să vorbim frumos despre modele. Trebuie să spunem câte ceva şi
despre “climatul” în care sunt elaborate aceste modele. Prima afirmaţie pe care am mai făcut-o undeva şi în
Capitolul 1, este că putem elabora modelel folosind un “arsenal”propriu de elemente-suport. Teoretic, însă,
avem de înfruntat, cel puţin trei probleme:
vom avea, precis, dificultăţi în a ne face modelele înţelese de alţi specialişti;
probabilitatea de a eşua în ceea ce priveşte calitatea modelului poate fi destul de mare;
este extrem de redusă şansa de a beneficia de toate avantajele pe care le oferă un mediu de dezvoltare.
Dacă “limbajul de modelare propriu” este extrem de valoros, mai avem o şansă în recunoaşterea lui de o
comunitate cât mai largă de specialişti. Şi, astfel, se face trecerea la al doilea tip de “climat” propriu elaborării
modelelor: cel în care se folosesc limbaje de modelare, recunoscute ca atare de comunitatea utilizatorilor,
purtând, eventual, girul mediilor academice, beneficiind, în cel mai fericit caz şi de recunoaşterea ca
standard.
Într-o lume a IS un limbaj de modelare care nu este un standard este condamnat la supliciul anonimatului
ceea ce echivalează cu “moartea clinică” a ideilor lansate de acel limbaj. Din fericire, chiar şi aflat în moarte
clinică, un limbaj de modelare propus la un moment dat poate dăinui, prin ideile lui valoroase, dacă acestea au
fost fixate convingător într-o lucrare de specialitate care a ajuns într-o bibliotecă adevărată.
Abandonând aceste consideraţii care riscă să provoace un veritabil derapaj tematic, voi încerca să explic
cititorului ce este un limbaj de modelare în general şi ce este un limbaj de modelare în IS.
În general vorbind, un limbaj de modelare poate fi definit ca o ierarhie de concepte, principii şi procedee de
operaţionalizare a acestora în vederea abstractizării soluţiilor problemelor care fac parte dintr-o anumită
clasă tipologică.
Această definiţie poate fi considerată satisfăcătoare pentru utilizatorii limbajelor de modelare. În fond,
aceştia trebuie să fie buni “mânuitori” ai conceptelor, principiilor şi procedeelor de operaţionalizare a
acestora pentru a realiza modele cărora li se poate aplica sintagma “profesionale”.
Pentru cei care specifică limbaje de modelare sau pentru cei care realizează sisteme soft suport în procesul
de modelare orientate pe un anumit limbaj de modelare, definiţia de mai sus este insuficientă.
Utilizatorul unui limbaj de modelare este asemenea muncitorului care trebuie să ştie să mânuiască o trusă
de scule, într-un context anume.
Persoana care specifică un limbaj de modelare este asemenea inginerului care a proiectat trusa de scule,
abstractizând o familie de contexte în care poate fi utilizată trusa.
“Scoaterea pe piaţă” a unui limbaj de modelare înseamnă rezolvarea “cu brio” a două probleme majore:
- Specificarea universului conceptual al limbajului
-Identificarea formalizmului de prezentare a universului conceptual
Amândouă problemele sunt dificil de rezolvat astfel încât beneficiarii potenţiali ai limbajului de modelare să
devină beneficiari efectivi în număr cât mai mare. Semnalez, în continuare, câteva dintre dificultăţile şi
antagonismele cu care se confruntă un specificator de limbaje de modelare (SLM).
Primul obstacol pe care trebuie să-l depăşească un SLM este reprezentat de problema delimitării
tipologice a sistemelor care urmează a fi modelate cu ajutorul limbajului . Demersul pentru rezolvarea
acestei probleme poate eşua graţios dacă SLM implicat nu reuşeşte să oprească la timp elanul generalizării sau
dacă, din contră, nu găseşte suficiente resurse pentru a extinde rezonabil oferta de aplicabilitate a limbajului.
A doua problemă cu care se confruntă un SLM este, evident, specificarea universului conceptual. Este,
se poate spune, cea mai dificilă dintre numeroasele probleme cu care se confruntă un SLM. Aceasta deoarce,
universul conceptual trebuie structurat astfel încât să poată fi utilizat, indiferent de complexitatea sistemului
modelat. În cazul problemelor de complexitate mică, amploarea efortului de abstractizare este redusă; relativ
redusă este, în general, şi semantica pe care trebuie să o codificăm cu ajutorul limbajului.
Aşa cum, probabil, cititorul a dedus deja, confruntat cu exigenţele unei probleme, adecvată tipologic,
limbajul de modelare trebuie să facă faţă la două “comandamente” esenţiale:
-asigurarea de suport pentru cel care modelează în vederea rafinării treptate a soluţiei;
-asigurarea de suport pentru cel care modelează în vederea captării semanticii sistemului modelat.
 Amândouă comandamentele “apasă” greu pe umerii celor care vor să specifice limbaje de modelare. Pentru
mai multă rigoare în exprimare, de fapt, trebuie să spun cititorului că problema rafinării treptate a soluţiei
unei probleme arbitrare este greu de algoritmizat.
Acest fapt ar putea fi motivat, oarecum, de includerea aptitudinii de a rafina soluţia unei probleme printre
abilităţile de bază ale unei persoane inteligente.
Astfel că, nu avem algoritmi de rafinare treptată a soluţiei unei probleme, indiferent ce limbaj de modelare
discutăm; în schimb, orice limbaj de modelare încearcă să propună un "background" pentru alegerea celei mai
bune variante de rafinare.
“Răutatea” unei probleme de rafinare a soluţiei unui enunţ dat este dublă:
algoritmizarea schemei de rafinare agreată de un limbaj nu poate fi realizată decât în linii mari ; pe
această bază apare al doilea factor de răutate: găsirea schemei de rafinare este o problemă de alegere
dintr-o mulţime, uneori inepuizabilă, de variante.
Ca exemple de elemente suport pentru rafinarea treptată a soluţiei unui sistem soft putem indica:
Descompunerea sistemelor în subsisteme şi agregarea subsistemelor în sisteme (două procedee de
abstractizare din teoria generală a sistemelor care operează cu înţelesul originar la nivele înalte de abstractizare).
Utilizarea modularizării pentru obţinerea soluţiei unui sistem soft; este un procedeu care extinde
utilitatea principiului descompunerii din teoria generală a sistemelor la specificul problemelor de modelare din
IS. La fel cum descompunerea sistemelor în subsisteme este consecinţa unui anumit mod de a înţelege sistemul
modelat, modularizarea se poate baza pe abordarea top -down sau bottom-up. Indiferent de alegere avem nevoie
de criterii. Ca un exemplu, în cazul abordării top-down putem avea descompunere bazată pe:
-criterii funcţionale;
-criterii de organizare a datelor;
-abstractizarea fluxurilor de date;
-tipuri abstracte de date.
Fiecare dintre cerinţele de mai sus propune, de fapt, o anumită manieră de trecere de la domeniul problemei
către domeniul soluţiei.
A treia problemă în atenţia unui SLM se referă la notaţia prin intermediul căreia se face transfer de
semantică dinspre limbajul de modelare către utilizatorul limbajului de modelare.
Este o problemă care, rezolvată nesatisfăcător, poate compromite intenţiile conceptuale ale limbajului.
De regulă, o notaţie inspirată permite:
-vizualizarea procesului de modelare;
-specificarea soluţiei unei probleme;
-realizarea soluţiei;
-documentarea soluţiei.
Vizualizarea procesului de modelare
Este o calitate care contribuie hotărâtor la rezolvarea a două probleme importante:
- sporirea semnificativă a accesibilităţii limbajului de modelare; în opoziţie totală cu limbajele de
modelare vizuale se află limbajele de modelare care se bazează pe o sintaxă exclusiv formală.
- asigurarea unui cadru sistematic pentru realizarea de medii CASE pentru promovarea modelării vizuale
asistată de calculator.
Impactul pe care îl are caracterul vizual al modelării asupra productivităţii muncii este uriaş, dacă adăugăm
precizarea că mediile de dezvoltare asistată iau asupra lor mare parte din sarcinile de rutină sau susceptibile de a
fi automatizate.
Există specialişti care pun în “cârca” vizualizării o anumită tendinţă de depreciere a specificării soluţiei unei
probleme (datorită oportunităţii pe care o reprezintă un mediu CASE pentru a prototipiza, de exemplu).
Chestiunea este discutabilă deoarece, dacă se lucrează sub presiunea timpului, un mediu de dezvoltare nu
poate decât să ne ajute să scurtăm termenele de execuţie realizând componente cu înalt grad de standardizare. De
asemenea, dacă timpul “nu presează”, atunci ţine oricum de liberul arbitru dacă înainte de a ne repezi la tastatură
am reflectat suficient la problemele etapei în care ne aflăm.
Specificarea soluţiei unei probleme
Orice limbaj de modelare trebuie să posede în cel mai înalt grad însuşirea de a permite specificarea corectă
şi completă a soluţiei unei probleme.
Cititorul care s-a confruntat, ca specialist IS, cu efectele devastatoare (asupra existenţei unui sistem soft) ale
unei specificări incorecte şi/sau incomplete înţelege pe deplin “greutatea” acestei cerinţe. Raza de acţiune a
calităţii procesului de specificare a soulţiei unui sistem soft aduce atingere atât factorilor interni cât şi factorilor
externi ai calităţii unui sistem soft.
Privind această cerinţă şi din perspectiva exigenţelor unui potenţial mediu de dezvoltare, asociat limbajului,
adăugăm o nouă dimensiune înţelegerii capabilităţilor unui limbaj de specificare a soluţiei unui sistem soft.
Atrag atenţia cititorului asupra utilităţii unei dezbateri mai ample pe teme de corectitudine şi completitudine.
Astfel, un specialist IS poate opera cu cel puţin două sensuri ale conceptului de corectitudine:
 -corectitudinea de mapare
-corectitudinea formală.
Corectitudinea de mapare caracterizează modul în care cerinţele beneficiarului sunt specificate în soluţie.
Orice diferenţă între mesajul corespunzător unei cerinţe din domeniul problemei şi mesajul aceleiaşi cerinţe în
domeniul soluţiei trebuie interpretată ca un exemplu de specificare incorectă.
Corectitudinea formală răspunde de acurateţea formală a specificării. Mesajul de bază al specificării poate
fi prezent, deci avem corectitudine de mapare, dar acurateţea specificării din punct de vedere formal poate fi un
obstacol în comunicare sau în generarea automată corectă a unor piese ale sistemului soft de către mediul de
dezvoltare.
În materie de specificare corectă este cunoscut “duelul” dintre sistemele formale de specificare (Z, Z++,
VDM, VDM++) şi sistemele intuitive de specificare.
În timp ce sistemele formale de specificare sunt puternic matematizate, ceea ce restrânge serios numărul
celor interesaţi de această abordare, sistemele intuitive încearcă să cultive rigoarea utilizând masiv semantici
exprimate cu ajutorul limbajelor naturale.
Valenţele semantice ale noţiunii de completitudine a specificării sunt, de asemenea, variate.
Analog corectitudinii, putem vorbi de completitudine de mapare, prin care înţelegem prezenţa în sistemul
de cerinţe a tuturor elementelor vitale în momentul dezvoltării softului, precum şi a unor elemente-cadru care să
permită redefinirea, la nevoie, a sistemului de cerinţe.
Putem vorbi, de asemenea, de o completitudine structurală, prin care desemnăm finalizarea corectă a
tuturor intenţiilor de specificare ale proiectului.
Evident, efortul de specificare corectă şi completă are determinări adânci în structura ciclului de viaţă şi a
ciclului de abstractizare. Acest lucru va fi mai clar pentru cititor în momentul în care va trece de la înţelegerea
“pe bucăţi” a unei MDS la o viziune sistemică asupra utilităţii ei.
Realizarea softului
O notaţie chibzuit aleasă trebuie să aibă calitatea de a permite relativ uşor transpunerea soluţiei tehnice în
limbajul de programare ales. Ceea ce, probabil, pare simplu ca teorie este însă o sarcină dificilă pentru SLM.
Pentru ca notaţia unei MDS să faciliteze realizarea softului, la specificarea limbajului de modelare trebuie
depuse eforturi de unificare, pe cât posibil, a lumii conceptelor din domeniul soluţiei tehnice cu lumea
conceptelor din domeniul programării.
Această unificare este extrem de dificilă cât timp în lumea limbajelor de programare se menţin încă
deosebirile de abordări în ceea ce priveşte structura soluţiei unei probleme.
Într-o oarecare măsură este chiar scuzabilă o astfel de stare de lucruri. Să ne gândim că în programare există
nu doar variaţiuni pe o anumită temă ci chiar teme diferite.
Programatorii cu experienţă ştiu că într-un fel este să programezi într-un limbaj procedural, alta este optica
într-un limbaj de esenţă funcţională, aproape cu totul alta este abordarea într -un limbaj suport pentru
programarea logică. De asemenea, este o lume principial nouă şi programarea obiect-orientată; plină de
surprize este şi lumea limbajelor paralele.
Deosebirile de natură conceptuală dintre limbajele prezentate mai sus (care nu au epuizat lista tipurilor de
limbaje existente!) sunt suficient de pregnante pentru a provoca derută, la primul contact, unui programator
crescut într-o altă paradigmă.
De ce ne-am aştepta să fie mai uşoară soarta SLM în ceea ce priveşte încercarea lor de unificare a
semanticilor diferitelor limbaje de programare într-o notaţie cât mai robustă.
Pentru a da un exemplu concret de încercare în această direcţie recomand atenţiei cititorului notaţia UML
care reuşeşte un lucru demn de toată lauda: aducerea la numitor comun a numeroaselor MDS autoproclamate
obiect-orientate prin propunerea unei notaţii în care îşi fac loc concepte fundamentale ale modelării obiect-
orientate (clasă, obiect, asociere, agregare, generalizare, moştenire, mesaj, metaclasă, metodă, signatură, pachet,
şablon, stereotip, etc.), precum şi o serie de concepte care ţin de reprezentarea diferitelor tipuri de arhitecturi ale
unui sistem soft în genere, modelarea în mediile de calcul paralele, etc.
Deşi ambiţia oricărui SLM în IS este de a vedea modelele obţinute independente de limbajul în care va fi
transcris modelul, nu înseamnă neaparat că are şi susţinere efectivă.
Revenind la cazul UML-ului, autorii lui clamează independenţa faţă de limbaje de programare, dar, în sinea
lor ştiu că maparea soluţiei tehnice pe soluţia programată este perfectă doar dacă principiile fundamentale ale
limbajelor de modelare şi programare sunt în rezonanţă.
Pentru ca lucrurile să progreseze mai sunt de înfăptuit numeroase reforme în ceea ce priveşte:
-impunerea de standarde tehnologice în domeniul sistemelor de operare;
-definirea şi implementarea unor standarde în ceea ce priveşte structura sistemelor soft.
Mediile vizuale de programare (de genul DELPHI, VISUAL C++, C-Builder, etc.) sunt exemple grăitoare
de abordări compatibile cu o paradigmă de modelare importantă cum este UML.
Documentarea soluţiei
Notaţia unui limbaj de modelare trebuie să dispună de resursele necesare pentru a permite:
 -reprezentarea şi documentarea arhitecturii sistemului;
-reprezentarea şi documentarea cerinţelor faţă de sistemul soft;
-reprezentarea şi documentarea soluţiei tehnice la diferite nivele de abstractizare;
-reprezentarea şi documentarea activităţilor specifice managementului dezvoltării sistemelor soft.
Sistemele soft adevărate (în sensul că au complexitate medie sau mare) trebuie să adauge lângă codul sursă
(izomorf, practic, cu codul executabil al sistemului soft) o serie de alte produse tipice ingineriei softului care,
laolaltă, alcătuiesc documentaţia constructivă şi de prezentare a sistemului soft.
Documantarea completă a unui sistem soft este o probă de profesionalism pe care firmele de soft mari au
transformat-o într-un veritabil bussines pe seama cererii de documantaţie, în creştere, din partea utilizatorilor
diverselor tehnologii informaţionale lansate pe piaţă.
A patra problemă în atenţia unui SLM se referă la stabilirea limbajului cu care este definit limbajul de
modelare.
Cărţile care popularizează limbajele de modelare apelează, de regulă, la o combinaţie între limbajul natural
şi elemente de descriere formală pentru a realiza compromisul optim între rigoare şi accesibilitate. Documentaţia
de referinţă a unui limbaj de modelare poate apela la un limbaj special pentru descrierea proprietăţilor limbajului
de modelare.
Situaţia este similară cu cea întâlnită în domeniul limbajelor de programare, unde se cunosc formalizme de
descriere a anumitor proprietăţi ale limbajelor de tipul:
-diagrame de sintaxă
-sintaxa BNF
Evident, există şi excepţii interesante în ceea ce priveşte alegerea limbajului cu ajutorul căruia se specifică
un limbaj de modelare. Este vorba de sistemele formale de specificare a softului (Z, Z++, VDM, VDM++) care
apelează, esenţial, la un formalizm matematic care poate veni dinspre teoria mulţimilor, logică, calculul lambda,
etc. Poate fi, de asemenea, vorba despre limbajele de modelare, gen UML, care conţin în ele însele resursele
pentru specificarea semanticii lor.

4.2 Arhitectura unui limbaj de modelare

Un limbaj de modelare care se respectă îşi propune (cel puţin din cauza cerinţelor formulate în paragraful
4.1.) să se prezinte în faţa utilizatorilor cu o concepţie arhitecturală clară.
Înţelegerea arhitecturii unui limbaj de modelare este benefică atât pentru utilizatorii limbajului cât şi pentru
cei care îi studiază fundamentele.
Efectul cunoaşterii arhitecturii unui limbaj de modelare asupra unui utilizator al acestui limbaj este similar
efectului pe care îl are, în general vorbind, structurarea asupra unui demers de cunoaştere a unui sistem.
Arhitectura unui sistem este datoare să explice tuturor celor interesaţi:
-care sunt subsistemele fundamentale ale sistemului; ce semantică încapsulează aceste subsisteme?
-care sunt dependenţele fundamentale între subsistemele evidenţiate mai sus; care este semantica
esenţială a acestor dependenţe?
-care este formalizmul utilizat pentru descrierea şi reprezentarea elementelor prezentate mai sus?
Este evident faptul că, prin clarificarea aspectelor arhitecturale ale unui limbaj de modelare, SLM
defineşte orizontul strategic al posibilităţiilor de operare cu capabilităţile de modelare ale limba jului.
Este posibil ca, pentru mulţi utilizatori, cunoaşterea acestui orizont să nu fie deloc o prioritate. Aceasta
deoarece alţii decid pentru ei ce limbaj de modelare trebuie să folosească iar utilizarea efectivă a limbajului nu
trebuie să treacă neaparat prin înţelegerea subtilităţilor asociate perspectivei arhitecturale. Pentru a ne forma o
idee asupra utilităţii cunoaşterii arhitecturii unui limbaj de modelare ne putem inspira din obişnuinţa pe care şi-
au făcut-o unii producători de soft de a scoate pe piaţă manuale de utilizare şi manuale de referinţă pentru
sistemele soft pe care le produc.
Manualele de referinţă manifestă o atenţie sporită faţă de elementele arhitecturale şi faţă de, să-i spunem,
evoluţia universului conceptual al obiectului descris.
Manualele de utilizare încearcă, mai degrabă, să prezinte utilizatorului scenarii pe baza cărora se poate
utiliza semantica obiectului respectiv.
Specialiştii în IS, interesaţi de utilizarea intensă a limbajelor de modelare preferă să înlocuiască abordarea
arhitecturală cu o abordare pragmatică. Pentru un utilizator de limbaj de modelare scenariul cel mai plauzibil
este următorul:
1. Dintr-un motiv anume, în atenţia specialistului IS, ajunge o anumită realitate informaţională, cu veleităţi
sistemice şi structurale obiective.
2. Specialistul IS stabileşte determinarea obiectivă şi subiectivă a realităţii informaţionale respective.
În determinarea obiectivă includem acele aspecte ale realităţii informaţionale care există şi se manifestă
independent de atitudinea specialistului IS.
În determinarea subiectivă intră în joc exact atitudinea specialistului IS faţă de aspectele obiective ale
realităţii informaţionale.
 Din momentul în care atitudinea specialistului faţă de realitatea informaţională începe să se structureze,
practic, începe procesul de modelare a realităţii informaţionale. Acest proces presupune:
permanente şi obligatorii procese de abstractizare.
Se face abstractizare atunci când schiţăm elementele arhitecturale ale modelului, ceea ce înseamnă
generalizare.
Se face abstractizare atunci când optăm pentru o soluţie alternativă în procesul de rafinare a modelului, ceea
ce înseamnă specializare.
permanente şi obligatorii eforturi de reprezentare a diferitelor nivele de abstractizare , scopurile
urmărite fiind:
-rezolvarea problemelor de comunicare;
-obţinerea specificaţiilor complete ale modelului.
5 MODELAREA OBIECT ORIENTATĂ CU UML
5.1 Ce este UML(fără a intra în detalii)?
Cititorul bănuieşte, deja, că UML este rezultatul unor acumulări cu un istoric destul de zbuciumat, în
materie de modelare a soluţiilor sistemelor soft.
Aşadar, să remarcăm faptul că UML este un limbaj de modelare, nu o metodologie. Ca limbaj de
modelare, UML oferă o notaţie, în spatele căreia se află o semantică adecvată. Notaţia este în mare parte
grafică, astfel că este cât se poate de nimerit să reproducem caracterizarea de ansamblu a UML-ului, făcută în
documentaţia pusă la dispoziţie î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 organizaţională şi a altor sisteme, nu
neapărat din lumea IS.”
Cele mai puternice şi recente rădăcini 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 abordări remarcabile, în spatele cărora 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. Reacţia 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
îmbunătăţiri 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 către membrii OMG, în noiembrie 1997. OMG este actualmente
implicat, cu responsabilităţi precise, în dezvoltarea viitoare a standardului UML. Versiunea 1.3 a fost făcută
publică în 1999 şi prin contribuţia grupului RTF (Revision Task Force), etc.
Să încercăm acum o explicaţie a sintagmei “unified” din denumirea UML.
Aşadar, pentru UML, atributul “unified” poate fi înţeles în raport cu următoarele topici IS.
 Metodologiile şi notaţiile asociate lor privite din punct de vedere
istoric
UML combină conceptele, folosite intens şi cu acelaşi înţeles, în mai multe metodologii obiect orientate, impunând definiţii clare pentru
fiecare concept şi o notaţie adecvată. Ca urmare, UML este capabil să reprezinte cele mai multe dintre modelele exi stente, la fel de bine
sau chiar mai bine decât metodologiile originale.

 Ciclul de viaţă al dezvoltării sistemelor soft

UML operează cu aceleaşi concepte şi notaţii în diferite etape ale procesului de abstractizare a soluţiei. Prin
urmare, nu este necesar un efort de translatare semantică şi sintactică a soluţiei, de la un nivel de abstractizare la
altul. Această situaţie este absolut convenabilă din perspectiva modelului iterativ şi incremental de dezvoltare,
cu care UML se potriveşte cel mai bine.
 Tipuri de aplicaţii
UML este pregătit să ofere suport pentru modelarea unui număr mare de tipuri de aplicaţii, incluzând
sisteme cu volum mare de date şi prelucrări, 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 aşteptat să fie la fel de bun sau chiar mai bun decât orice alt limbaj de interes general,
în multe tipuri de aplicaţii.
 Limbaje şi platforme de implementare
UML este gândit să fie util pentru sisteme soft implementate pe diferite platforme, incluzând limbaje de
programare, SGBD-uri, 4GLs, documente organizaţionale, medii firmware, etc. Modul de lucru este acelaşi sau
prezintă multe similarităţi în toate tipurile de aplicaţii, rezultatul fiind dependent de mediul în care se lucrează.
 Procesul de dezvoltare
Aşa cum am mai spus, UML este un limbaj de modelare, nu o descriere a unui proces de dezvoltare detaliat.
UML este gândit să fie utilizat independent de proces, dar oferă suport complet pentru procesele de dezvoltare
iterative şi incrementale (a se vedea. Rational Unified Process - RUP).
Să precizăm, în sfârşit, 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ă, specialiştii obişnuiesc să spună că UML are o arhitectură de metamodelare pe 4
nivele, cum rezultă şi din Figura 5.1.
 Nivel Descriere Exemple
Meta-metamodel Desemnează infrastructura MetaClase,
conceptuală, necesară pentru o MetaAtribute,
arhitectură de metamodelare. MetaOperaţii
Defineşte limbajul pentru
specificarea metamodelelor.
Metamodel Desemnează o instanţă a unui Clasă, Atribut,
meta-metamodel. Operaţie,
Defineşte limbajul necesar Componentă
pentru specificarea unui model.
Model Desemnează o instanţă a unui CodProdus,
metamodel. Defineşte un limbaj DenumireProdus,
pentru descrierea domeniilor Cantitate, etc.
informaţionale.
Obiecte(dată) Desemnează o instanţă a unui <1111>, <Ţeavă
utilizator model. Defineşte un domeniu PVC>, 30
informaţional concret.

Figura 5.1. Arhitectura UML

Pe bună dreptate, cititorul se va intreba: “La ce îmi foloseşte să ştiu atâtea despre arhitectura UML?”.
Un răspuns moderat la această întrebare, mai jos.
Aşa cum se prezintă la ora actuală, UML oferă utilizatorilor o notaţie şi un meta-model.
Notaţia desemnează acele elemente de sintaxă (preponderent grafice) cu ajutorul cărora se specifică soluţia
UML a unui sistem soft. De exemplu, pentru a reprezenta soluţia UML a unei probleme, în mod normal ne vom
folosi de notaţia aferentă diagramelor de clase, în care se operează cu concepte precum: clase, asocieri,
generalizări, multiplicitate, etc. Utilizatorul “grăbit” prinde din zbor semantica unor astfel de concepte.
Utilizatorul care are obsesia rigorii, vrea un răspuns precis la întrebări de genul: “Ce este o clasă?”.
Producătorii de tools-uri de dezvoltare pentru specialiştii IS sunt chiar interesaţi, în mod obiectiv, de
clarificarea răspunsurilor la astfel de întrebări. Ideea unor limbaje de specificare şi proiectare riguroase este bine
reprezentată în lumea metodelor formale (în care singurele enunţuri acceptate sunt în spiritul calculului
propoziţional sau al calculului predicatelor).
Metodele formale reprezintă cea mai bună armă cu care putem stăvili insinuarea ambiguităţilor în
enunţurile noastre.
Din păcate, “omul în genere ”, nu a fost “proiectat” spre a fi un adorator al limbajelor formale .
Pentru a comunica, “omul în genere” foloseşte cel mai bine limbajul natural sau derivaţi simplificaţi ai
acestuia. La urma urmei, această înclinaţie naturală are o explicaţie destul de profundă:
Capacitatea lilmbajelor naturale de a opera cu semnificaţii noi este mult mai mare decât a limbajelor
formale.
Pentru a împăca pe toată lumea, UML oferă utilizatorilor un meta-model, cu ajutorul căruia se dau
răspunsuri riguroase la întrebări de genul: “Ce este o clasă?”. Această caracteristică face din UML un limbaj
interesant, deoarece resursele pentru specificarea conceptelor lui se găsesc în el însuşi (limbajele de programare,
de exemplu, folosesc metalimbaje de tip notaţie BNF sau diagrame de sintaxă, pentru specificare).

5.2 Date esenţiale pentru înţelegerea UML

În acest paragraf voi trece în revistă coordonatele esenţiale pentru înţelegerea UML.
 Aşadar, UML este un limbaj pentru: vizualizarea, specificarea, construirea şi documentarea
componentelor unui sistem soft.
UML – limbaj pentru vizualizare
UML pune accent pe vizualizarea soluţiei unui sistem soft pentru a elimina cea mai mare parte a
problemelor de comunicare care pot să apară între diferitele categorii de participanţi la dezvoltarea unui sistem
soft. Evident, fără a renunţa în totalitate la text, UML propune o manieră preponderent grafică de reprezenta re şi
documentare a unui sistem soft.
UML – limbaj pentru specificare
În ingineria softului, specificarea înseamnă elaborarea de modele precise, complete şi fără ambiguităţi. O
specificare vizuală, cum este specificarea UML, este expusă riscului de a genera ambiguităţi în procesul de
comunicare, într-un grad mai mare decât în cazul specificării formale. Şi totuşi, o specificare vizuală a soluţiei în
toate fazele de dezvoltare a unui sistem soft, este de preferat, dată fiind importanţa unei comunicări cât mai
ample între specialiştii IS, utilizatori şi beneficiari, ca parteneri în cadrul aceluiaşi proiect.
 UML – limbaj pentru construire
Probabil, a fost înţeles faptul că UML nu este un limbaj de programare vizuală, dar, ceea ce trebuie reţinut
este faptul că modelele elaborate în UML pot fi uşor “translatate” în numeroase limbaje de programare. Această
stare de fapt ne sugerează posibilitatea mapării naturale a unui model UML în limbaje precum Java, C++, Vizual
Basic, Ada, etc.
Posibilitatea efectivă a acestei mapări stă la baza generării automate a codului asociat unui model UML, în
conformitate cu o anumită opţiune de limbaj. Generarea automată a codului, pornind de la modelul UML, sau
invers, regăsirea modelului UML asociat unei implementări date, sunt posibile utilizând instrumente CASE,
precum Rational Rose, ObjectiF, etc.
UML – limbaj pentru documentare
O firmă de soft adevărată produce toate genurile de componente adiţionale obţinerii codului executabil al
unui sistem soft, precum:
 Cerinţele faţă de sistemul soft;
 Descrierea arhitecturii sistemului;
 Specificaţiile de proiectare;
 Codul sursă;
 Planurile de dezvoltare, etc.
UML posedă resurse adecvate pentru specificarea cerinţelor faţă de un sistem soft, reprezentarea arhitecturii
unui sistem şi a tuturor detaliilor de proiectare, modelarea activităţilor de management al proiectului, etc.
 Unde putem folosi UML?
Înainte de orice, UML a fost gândit să fie utilizat în dezvoltarea de sisteme soft în domenii precum:
- Sistemele informaţionale ale întreprinderilor;
- Servicii financiare şi bancare;
- Telecomunicaţii;
- Transporturi;
- Electronica medicală;
- Servicii distribuite bazate pe WEB, etc.
Să mai adăugăm faptul că UML este suficient de expresiv pentru a permite şi modelarea sistemelor de altă
natură decât soft (fluxuri de lucru în sistemul justiţiei şi sănătate, etc.).
 Arhitectura sistemelor soft din perspectivă UML
Un specialist în IS cunoaşte bine faptul că, sistemele de mare complexitate, nu pot fi modelate satisfăcător
dacă paleta criteriilor de observare şi analiză nu este adecvat structurată. Învăţând din greşelile altor limbaje de
modelare, UML propune o formulă de arhitectură comprimată în sintagma “perspectiva arhitecturală 4+1”.
Această formulă este binevenită, atât pentru lucrul în echipă la un proiect (deci în sprijinul managementului)
cât şi pentru procesul de obţinere a unei soluţii de calitate şi cât mai complete. Perspectiva arhitecturală 4+1 este
reprezentată, în sinteză grafică, în Figura 6.2, care ne sugerează faptul că identificarea arhitecturii unui sistem
soft este o activitate pentadimensională, dacă mi se îngăduie exprimarea. Fiecare perspectivă focalizează atenţia
echipei de dezvoltare asupra unui gen de probleme, a căror rezolvare influenţează în mod specific calitatea
soluţiei, în ansamblu. Atrag atenţia 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 cerinţele funcţionale ale acestuia. Altfel spus,
ce servicii asigură sistemul soft pentru utilizatorii lui? Arhitectura logică este încapsulată în diagramele
claselor, care conţin clasele şi relaţiile dintre ele (socotite abstracţii fundamentale ale sistemului în curs de
dezvoltare). Mare parte din notaţia UML este dedicată reprezentării arhitecturii logice (clase, asocieri,
generalizări, agregări, pachete, etc.).
Elementele care definesc arhitectura logică încep să fie precizate încă de la începutul fazei de elaborare (a se
vedea RUP), când se stabilesc clasele şi pachetele socotite abstracţii majore ale domeniului problemei. În timp,
alte şi alte clase şi pachete sunt adăugate modelului UML al soluţiei 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 abilităţii echipei de
dezvoltare, de a armoniza gestiunea abstracţiilor majore ale sistemului soft cu gestiunea mecanismelor
cheie ale sistemului soft.
Această abilitate este transpunerea, într-un context particular, a relaţiei dintre strategie (=abstracţiile
majore) şi tactică (=mecanismele cheie). Deciziile tactice greşite, în timpul proiectării, pot compromite uşor
o arhitectură logică robustă. Pentru a implementa, cu succes, deciziile referitoare la mecanismele cheie ale
unui sistem soft, în IS a apărut o ramură de cercetare nouă, cea care se referă la proiectarea şi utilizarea
soluţiilor-şablon (patterns, în literatura anglo-saxonă).
 Perspectiva Perspectiva
logică sistem componenete sistem
(structurală) (implementaţională)
 Funcţionalitate Managementul softului
Reutilizare
Portabilitate

Perspectiva
contexte de
utilizare
(utilizator)
Mod de folosire
Înţelegere
sistem

Perspectiva Perspectiva
procese sistem topologie sistem
(comportamentală) (desfăşurare în mediul
Performanţă de execuţie)
Utilitate Performanţă
Toleranţă la erori Utilitate
Toleranţă la erori
Livrare şi instalare
Accesibilitate
Figura 5. 2 Perspectiva arhitecturii 4+1

Perspectiva componente sistem (Implementation view)

Această perspectivă asupra unui sistem soft trebuie să precizeze diferitele componente ale unui sistem soft,
împreună, eventual, cu relaţiile dintre acestea.
Prin componentă a unui sistem soft vom înţelege, 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ă
diferenţa î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 nenumărate componente ale unei aplicaţii Java.
Să mai atragem atenţia cititorului şi asupra faptului că între componente pot exista dependenţe (care, în
terminologia UML, arată cum pot influenţa schimbările 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 implementaţională a unui sistem.
Perspectiva procese sistem (Behavioral view)
Această perspectivă are în vizor structura executabilelor sistemului soft (procese, fire de execuţie,
mecanisme de concurenţă şi sincronizare, etc.)
Specificarea acestui tip de arhitectură ia în calcul cerinţe precum: performanţa, fiabilitatea, utilitatea, etc.
Perspectiva componente sistem şi perspectiva procese sistem folosesc pentru reprezentare diagrame de
componente care indică componentele (procesele), interfeţele acestora şi dependenţele 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ă execuţia
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, purtând etichete care sugerează
repartizarea, pe tipuri de activităţi şi informaţii despre procesele executate în aceste noduri. Evident, o bună
topologie hard trebuie să asigure viteze de execuţie 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, aşa cum este acesta văzut de diferite categorii de utilizatori şi, prin intermediul acestora, de
diferiţi 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 interacţiune,
diagrame de stare, diagrame de activitate.
Scurta trecere în revistă a modelului “4+1” ne atenţionează, încă o dată, asupra complexităţii abordării
propuse de UML, precum şi asupra necesităţii de a începe explorarea notaţiei UML care permite materializarea
abordării “4+1”.

5.3 Scurtă incursiune în universul conceptual al UML

Dupǎ ce am fǎcut atâtea promisiuni relativ la utilitatea UML în diferite contexte, este cazul sǎ facem o
primǎ încercare de ridicare a vǎlului care mai acoperǎ încǎ, în acest punct al demersului nostru, universul
conceptelor utilizate în modelarea UML. Procedând top-down (aşa cum se întâmplǎ de multe ori în IS) sǎ
precizǎm, pentru început, cǎ vocabularul UML opereazǎ cu trei tipuri de elemente constitutive:
 Entitǎţi;
 Relaţii;
 Diagrame.
 Observaţie
Entitǎţile desemneazǎ o serie de abstracţii care pot fi socotite “cetǎţeni de prim rang” într -un model UML.
Relaţiile abstractizeazǎ diferitele tipuri de legǎturi care pot exista între entitǎţi.
Diagramele sunt folosite pentru a grupa colecţiile de entitǎţi, cu scopul de a evidenţia mai bine diferitele
nivele de abstractizare ale soluţiei unui sistem soft.

Tipuri de entitǎţi în UML

UML opereazǎ cu patru tipuri de entitǎţi:
 Entitǎţi cu funcţii structurale;
 Entitǎţi cu funcţii comportamentale;
 Entitǎţi cu funcţii de grupare;
 Entitǎţi cu funcţii de documentare.
Aceste tipuri de entitǎţi reprezintǎ fundamentul oricǎrei soluţii obiect orientate, în UML. Ele sunt utilizate
intens pentru a realiza modele corect specificate (corectitudinea specificǎrii, în UML, acoperǎ atât aspectele de
sintaxǎ ale modelelor, cât şi cerinţa de a încapsula semantica eficient în aceste metode).

Entitǎţile cu funcţii structurale (EFS)

Foarte sintetic, EFS sunt substantivele modelelor UML. De cele mai multe ori, EFS reprezintǎ pǎrţi statice
ale unui model, reprezentând 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 mulţimi de obiecte care partajeazǎ aceleaşi atribute
informaţionale, acelaşi comportament, aceleaşi relaţii şi aceeaşi semanticǎ .
O clasǎ implementeazǎ una sau mai multe interfeţe. 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 operaţiile ei, ca în Figura 6.
2. interfaţa - abstractizeazǎ o colecţie de operaţii care specificǎ serviciile furnizate de o clasǎ sau
componentǎ.
Î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 operaţii, nicidecum prin lista implementǎrilor acestor operaţii. Este o chestiune de nuanţǎ prin
care în modelarea softului se face distincţia necesarǎ între interfaţǎ şi implementarea acesteia .

Pacient Nume clasǎ

CNP
Nume_I_Prenume Atribute informaţionale
…

creare()
eliberare() Operaţii
adaugare()
…
Figura 5.3. Reprezentarea unei clase în UML
 Ca şi notaţie vizualǎ, o interfaţǎ este redatǎ printr-un cerc cǎruia i se ataşeazǎ numele interfeţei (Figura
5.4).

IPacient

Figura 5.4. Reprezentarea unei interfeţe în UML

3. colaborare - abstractizeazǎ o familie de clase, interfeţe şi alte elemente care, prin cooperare,
reuşesc sǎ asigure un comportament care înseamnǎ mai mult decât “suma mecanicǎ” a
comportamentelor pǎrţilor.
De remarcat faptul cǎ, o colaborare are atât dimensiune structuralǎ cât şi dimensiune comportamentalǎ.
Dintr-o perspectivǎ ceva mai largǎ privind, o colaborare reprezintǎ implementarea unui şablon care
abstractizeazǎ o anumitǎ funcţie a unui sistem soft. Notaţia pentru colaborare este o elipsǎ al cǎrei contur este
realizat cu o linie întreruptǎ, în interiorul cǎreia se trece numele colaborǎrii.

Programare
pacient

Figura 5.5. Reprezentarea unei colaborǎri în UML

4. Un context de utilizare (use case, în limba englezǎ) - abstractizeazǎ o colecţie de secvenţe de

acţiuni 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 entitǎţile comportamentale într-un model UML.
Sǎ mai precizǎm cititorului faptul cǎ un context de utilizare este realizat de cǎtre o colaborare.
Semantica realizǎrii va fi discutatǎ tot în acest paragraf. Notaţia pentru context de utilizare este o elipsǎ
al cǎrei contur este o linie continuǎ, în interiorul cǎreia se trece numele contextului de utilizare (Figura 5.6).

Planifica
re
pacient
Figura 5.6. Reprezentarea unui context de utilizare în UML

Urmǎtoarele trei tipuri de EFS (clasele active, componentele şi nodurile) sunt, într-o oarecare mǎsurǎ,
asemǎnǎtoare claselor, în sensul cǎ sunt descrise ca mulţimi de obiecte care partajeazǎ aceleaşi atribute, operaţii,
relaţii şi semantici. Şi totuşi, existǎ suficiente elemente care deosebesc aceste trei tipuri de EFS de tipul clasǎ, şi
între ele însele, motiv pentru care sunt tratate distinct de cǎtre notaţia UML.
5. clasǎ activǎ - este o clasǎ ale cǎrei obiecte posedǎ unul sau mai multe procese sau fire de execuţie,
ceea ce înseamnǎ cǎ obiectele pot iniţia activitǎţi de control.
Aşadar, o clasǎ activǎ este întocmai ca o clasǎ obişnuitǎ, exceptând faptul cǎ obiectele sale reprezintǎ
elemente al cǎror comportament este concurent cu comportamentul altor elemente.
Notaţia UML pentru o clasǎ activǎ se deosebeşte de notaţia pentru clasǎ prin linia îngroşatǎ a
conturului. De observat, Figura 5.7.
Cititorul bǎnuieşte, probabil, faptul cǎ avem nevoie de clase active pentru a modela soluţiile problemelor în
care se apeleazǎ la multitasking şi, în consecinţǎ, apar probleme noi legate de sincronizarea proceselor sau firelor
de execuţie.

Supervizor pacient

CNP
…

Iniţiere()
Suspendare()
…
Figura 5.7. 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, realizǎrii uneia sau mai multor interfeţe.
Exemple de componente: unit-uri Pascal, ierahii de clase C++ specializate în lucrul cu octeţii de şiruri,
DLL-uri din lumea Windows, pachetele din Java etc.
Notaţia UML pentru o componentǎ este ilustratǎ în Figura 6.8.

Evid_Pacient.java nume componentă

Figura 5.8. Notaţia UML pentru o componentǎ

7. Un nod - este un element fizic, care existǎ la un moment dat şi reprezintǎ o resursǎ de calcul (cel
puţin memorie, şi adesea capabilitǎţi de prelucrare).
Una sau mai multe componente pot fi rezidente într-un nod sau pot migra de la un nod la altul. Notaţia
UML, simplificatǎ, pentru un nod este prezentatǎ în Figura 5.9.

Server

Figura 5.9. Notaţia UML, minimalǎ pentru un nod

Acestea au fost cele şapte tipuri de entitǎţi cu funcţii structurale, care formeazǎ fundamentul structural
al oricǎrui model UML autentic. Prezentarea pe care am fǎcut-o a avut ca scop introducerea notaţiei pentru cele
şapte EFS, semantica completǎ a conceptelor prezentate şi a notaţiilor asociate fiind o problemǎ ce urmeazǎ a fi
pusǎ în discuţie, ulterior, în aceastǎ carte sau, de ce nu, în altă carte, care prezintă procesul de utilizare efectivǎ a
notaţiei UML pentru rezolvarea unor probleme date.

Entitǎţile cu funcţii comportamentale (EFC)

EFC abstractizeazǎ aspectele dinamice ale unui sistem în cadrul modelelor UML. Prin urmare, EFC
sunt verbe ale modelelor UML (având şi o reprezentare graficǎ sugestivǎ) care încearcǎ reprezentarea
comportamentului unui sistem, în timp şi în spaţiu. UML opereazǎ cu douǎ tipuri fundamentale de EFC.
1. interacţiune - abstractizeazǎ un comportament care cuprinde o mulţime 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 operaţii
individuale poate fi specificat ca o interacţiune. O interacţiune implicǎ o serie de alte elemente, precum mesaje,
secvenţe de actiuni (comportamentul invocat de mesaje) şi legǎturi între obiecte.
Notaţia UML pentru mesaj este prezentatǎ în Figura 5.10.
afişeazǎ()
Figura 5.10. Notaţia UML pentru mesaj

Dupǎ cum se vede din notaţia prezentatǎ în Figura 5.10, sǎgeata care indicǎ un mesaj între douǎ obiecte
are asociat şi numele operaţiei invocate.
2. maşină de stare (în engleza americanǎ, state machine) abstractizeazǎ, de data aceasta ,
comportamentul unui singur obiect sau al unei interacţiuni dintre obiecte, pe timpul vieţii
acestora, ca succesiune de acţiuni-rǎspuns la anumite evenimente.
Aşadar, comportamentul unei clase sau al unei colaborǎri între clase (cadrul natural de reprezentare al
interacţiunilor) poate fi specificat cu ajutorul unei maşini de stare. O maşină de stare implicǎ o serie de alte
elemente, precum: stǎri, tranziţii, evenimente (fapte ce pot declanşa o tranziţie) şi activitǎţi (rǎspunsuri la
tranziţii). Notaţia UML pentru o stare este prezentatǎ în Figura 5.11 (dreptunghi cu colţurile rotunde, în interiorul
cǎruia se aflǎ numele stǎrii şi, eventual, substǎrile asociate.

Aşteptare
Figura 5.11. Notaţia UML pentru stare
 Interacţiunile şi maşinile 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, colaborǎrile şi obiectele.

Entitǎţi cu funcţii de grupare (EFG)

EFG reprezintǎ elemente utile în organizarea modelelor UML, reprezentate ca nişte casete în care un
anumit model poate fi descompus în ceea ce se considerǎ a fi pǎrţile 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 execuţiei unui sistem soft), EFG au
o valoare de întrebuinţare pur conceptualǎ (în timpul procesului de dezvoltare a sistemului). Notaţia UML pentru
un pachet este ilustratǎ în Figura 5.12. Problematica EFG necesitǎ o discuţie mai amplǎ pentru a înţelege
întreaga semanticǎ a subiectului.

Entitǎţi cu funcţie de documentare (EFD)

EFD reprezintǎ pǎrţile explicative ale modelelor UML. De fapt, acestea sunt comentarii pe care le puteţi
folosi în descrierea modelelor UML pentru a lǎmuri anumite aspecte neclare ale acestora sau pentru a adǎuga
informaţii suplimentare despre proprietǎţile acestor modele. EFD sunt reprezentate în UML ca note.
Reprezentarea aferentǎ notelor în UML este ilustratǎ în Figura 5.13.

Gestiune pacienţi

Figura 5.12. Notaţia UML pentru conceptul de pachet

Funcţia calculeazǎ
vârsta pacientului
Figura 5.13. Notaţia UML pentru conceptul de notǎ
Relaţii în UML
UML utilizeazǎ patru tipuri de relaţii pentru a descrie aspectele de naturǎ relaţionalǎ ale modelelor:
 Dependenţele;
 Asocierile;
 Generalizǎrile;
 Realizǎrile.
Aceste tipuri de relaţii reprezintǎ nucleul conceptelor de bazǎ propuse de UML pentru descrierea relaţiilor
dintre diferitele tipuri de entitǎţi ale modelelor UML.
1. dependenţa - abstractizeazǎ o relaţie semanticǎ între douǎ entitǎţi, caracterizatǎ prin faptul cǎ o
schimbare în una dintre ele poate afecta semantic cealaltǎ entitate.
Într-o astfel de relaţie, 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 relaţie se întâlneşte foarte des,
în diferite ipostaze. Notaţia UML pentru relaţia de dependenţǎ este reprezentatǎ în Figura 6.14.

Figura 5.14. Notaţia UML pentru relaţia de dependenţǎ

2. asocierea - abstractizeazǎ o relaţie structuralǎ prin care se descriu legǎturile dintre obiecte, de
tipuri diferite sau de acelaşi tip.
Asocierea (şi diferitele variaţiuni pe tema asocierii) sunt esenţiale pentru descrierea relaţiilor statice
dintre obiectele unei aplicaţii. Notaţia UML pentru asociere înseamnǎ, în mod necesar, o linie continuǎ (vezi
Figura 6.15), un nume şi, eventual, restricţii de cardinalitate şi nume de roluri, direcţionate sau nu.

0..1 Asistǎ *
Medic Pacient
Figura 5.15. Notaţia UML pentru asociere
 3. generalizarea - este abstractizarea unei relaţii dintre două concepte UML, compatibile, a cărei
semantică este exprimată astfel:
 Unul dintre concepte este concept tată, celălalt 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 moşteneşte structura şi
comportamentul elementului părinte asociat.

Notaţia UML pentru generalizare este prezentată în Figura 5.16.

Figura 5.16. Notaţia UML pentru relaţia de generalizare

4. realizarea - este abstractizarea unei relaţii semantice între clasificatori, exprimată astfel: un
clasificator specifică nişte capabilităţi pentru care alt clasificator fur nizează suportul necesar.

Ca un exemplu uzual, o interfaţă pentru a fi utilizată efectiv, trebuie să fie realizată de una sau mai multe
clase. Aşadar, o anumită clasă realizează o anumită interfaţă. Notaţia UML pentru realizare este prezentată în
Figura 5.17.

Figura 5.17. Notaţia UML pentru realizare

Diagrame în UML
În UML, diagramele sunt reprezentări grafice ale unor colecţii de elemente (entităţi şi relaţii).
Diagramele UML sunt grafuri ale căror noduri sunt entităţi şi ale căror arce sunt relaţii. Permiţând asamblarea
diferitelor tipuri de entităţi şi relaţii pentru a obţine descrieri ale sistemelor modelate din diferite perspective,
diagramele UML sunt elemente suport puternice pentru abstractizarea şi vizualizarea soluţiei unui sistem soft.
Deşi în teorie se susţine că o diagramă poate conţine orice combinaţie de entităţi şi relaţii, în practică se
recomandă utilizarea unui set restrâns de tipuri de diagrame, care încearcă să acopere toate cerinţele legate de
acceptarea pentru sistemele soft a arhitecturii “4+1”.
De aceea, cei care popularizează UML-ul recomandă următoarele nouă tipuri de diagrame:
 Diagrame de clase;
 Diagrame de obiecte;
 Diagrame de contexte de utilizare;
 Diagrame de secvenţă;
 Diagrame de colaborare;
 Diagrame hărţi de stare;
 Diagrame de activitate;
 Diagrame de componente;
 Diagrame de desfăşurare.
Descrierea şi exemplificarea modului de utilizare a acestor diagrame, sarcină de care urmează să ne ocupăm
în continuare, va lămuri problemele esenţiale care apar într-un exerciţiu 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 relaţie.
Regulile UML care susţin elaborarea de modele corecte se referă la:
 Numele entităţilor – cum putem denumi entităţile, relaţiile şi diagramele;
 Domeniul – contextul care dă înţeles specific unui nume;
 Vizibilitatea – cum poate un nume să fie văzut şi folosit de alte nume;
 Integritatea – cum interacţionează entităţile complet şi consistent cu alte entităţi;
 Execuţie – ce se înţelege prin execuţia sau simularea unui model dinamic.
Modelele elaborate pe timpul dezvoltării unui sistem soft fiind în atenţia mai multor categorii de participanţi,
apar situaţii în care modelele sunt afectate de:
 Omisiuni - anumite aspecte sunt ascunse pentru a simplifica procesul de înţelegere al modulului;
 Incomplete - anumite elemente pot lipsi cu desăvârşire;
  Inconsistente - nu este garantată integritatea unui model.
Obţinem 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 obţine modele perfectibile în timp.
Mecanisme comune în modelarea UML
O construcţie, de orice natură, este realizată mai simplu şi mai armonios dacă sunt respectate anumite
şabloane în ceea ce priveşte modelarea aşa-ziselor însuşiri comune.
De exemplu, dacă atunci când vrem să construim o casă, optăm pentru un anumit stil (bucovinean,
maramureşean etc.), putem spune că am rezolvat o problemă importantă, în ceea ce priveşte arhitectura casei.
Această situaţie se întâlneşte şi în modelarea UML, care propune patru mecanisme comune pentru utilizarea
lui consistentă:
 Specificaţiile;
 Ornamentele;
 Separările comune;
 Mecanismele de extindere.
Specificaţiile
Probabil, a fost înţeles faptul că UML este mai mult decât o notaţie vizuală. În spatele fiecărui tip de notaţie
vizuală există întotdeauna o specificaţie care furnizează, sub forma unui enunţ textual, sintaxa şi semantica
blocului constructiv asociat notaţiei.
În practică, elementele grafice ale notaţiei UML sunt folosite pentru a vizualiza sistemul. Specificaţiile
UML sunt folosite pentru a exprima detaliile sistemului.
Ornamentele
Cele mai multe entităţi au, în UML, o notaţie grafică directă şi unică, care asigură o reprezentare
vizuală a celor mai importante aspecte ale elementelor. De exemplu, notaţia grafică pentru o clasă este, în mod
deliberat, uşor de realizat, dat fiind faptul că la temelia oricărei soluţii obiect-orientate se află modelul claselor.
Notaţia UML pentru o clasă ocazionează, de asemenea, descrierea celor mai importante aspecte: numele clasei,
atributele şi operaţiile ei. Specificarea unei clase poate, însă, include şi alte detalii, precum: caracterul abstract al
clasei, vizibilitatea atributelor şi operaţiilor, etc. Astfel că, fiecare element al notaţiei UML începe cu un simbol
de bază, la care se pot adăuga o serie de ornamente, specifice acelui simbol. Se va reveni asupra problemei
ornamentelor chiar în acest capitol.
Separările comune
În modelarea sistemelor obiect-orientate este uzuală împărţirea (separarea) produselor efortului de
modelare în perechi de abordare.
Mai întâi, este foarte importantă separarea de tipul clasă – obiect. Situaţia caracterizată de această separare
este: în timp ce clasa este o abstractizare, un obiect este o manifestare concretă a acestei abstractizări .
Astfel, în UML putem întâlni tandemul clase – obiecte, ca în Figura 5.18.

Student Ion : Student

matricol
: Student
…

Maria

<<instance Of>>
Maria Student

Figura 5.18. Clasă şi obiecte

În Figura 6.18 este prezentată clasa Student, împreună cu trei obiecte având 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 dependenţa
stereotip <<instance Of>>.
Aproape fiecare bloc constructiv UML suportă genul de abordare prezentat pe relaţia clas ă / obiect. Astfel,
putem vorbi de contexte de utilizare, componente şi instanţe ale componentelor, noduri şi instanţe ale nodurilor
etc. În Figura 6.18 s-a putut observa şi modul în care se obţin numele obiectelor într-un model UML. În al doilea
rând, este extrem de importantă separarea dintre interfaţă şi implementare.
O interfaţă declară “un contract” de furnizare a unor servicii iar o implementare a unei interfeţe reprezintă o
realizare concretă a contractului asumat de interfaţă. Un exemplu de utilizare a acestei separări, în Figura 5.19.
 ISecretar DatePersStud.dll

IDecan
Figura 5.19. Interfeţele şi implementarea lor
Aşa cum, probabil că aţi ghicit, în Figura 5.19 sunt prezentate două interfeţe implementate de o componentă
DLL. Multe dintre blocurile constructive UML suportă genul de abordare prezentat pe relaţia interfaţă /
implementare. De exemplu, colaborările realizează contextele de utilizare, metodele implementează operaţiile.
Mecanismele de extindere UML
Un limbaj de modelare, închis din punct de vedere al notaţiei, poate ajunge uşor în situaţia de a nu putea
exprima, cu mijloace recunoscute de toţi utilizatorii lui, o anumită semantică din domeniul problemei sau din
domeniul soluţiei.
Pentru acest motiv, UML a fost gândit ca un limbaj de modelare deschis-închis (open-closed), prin
specificarea unor mecanisme de extindere care includ:
 Stereotipurile (stereotypes);
 Valorile etichetate (tagged values);
 Constrângerile (constraints).
Un stereotip extinde vocabularul UML, permiţând specialiştilor să creeze noi genuri de blocuri constructive,
pornind de la unele existente deja.
O valoare etichetată extinde proprietăţile unui bloc constructiv UML, permiţând specialiştilor să adauge
informaţii noi în procesul de specificare a blocului constructiv.
O constrângere extinde semantica unui bloc constructiv UML, permiţând specialiştilor să adauge reguli noi
sau să le modifice pe cele existente.
EventQueue
<<exception>> { version=3.2
Overflow author=ma}

add() {ordered}
remove()
flush()

Figura 5.20. Mecanismele UML de extindere, pe un exemplu

În figura 5.20 este prezentat un exemplu de clasă – stereotip (Overflow), aflată în relaţie de dependenţă cu
clasa EventQueue, căreia i-au fost adăugate informaţii 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 constrângerii {ordered}.
6 MODELAREA ASPECTELOR STRUCTURALE.
ELEMENTE-SUPORT FUNDAMENTALE
6.1 Clase
Clasele sunt elementele constructive cele mai importante ale unui sistem obiect orientat. În general vorbind,
o clasă este abstractizarea unei colecţii de obiecte care partajează aceleaşi atribute, aceleaşi operaţii,
aceleaşi relaţii şi aceeaşi semantică. UML oferă un formalizm grafic pentru reprezentarea unei clase,
asemănător celui din Figura 6.1.

Poligon nume clasă

coordonate atribute
perimetru()
aria()
afisare() operaţii

Figura 6.1. Notaţia UML pentru clasă.

După cum se poate vedea, notaţia propusă în Figura 6.1 permite vizualizarea unei abstractizări, independent
de limbajul de programare şi de o manieră care permite evidenţierea celor mai importante părţi ale abstractizării:
numele, atributele şi operaţiile 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 6.2a. Un nume cu cale, asociat unei clase, se poate observa în Figura 6.2b, el
indicând, ca un prefix la numele clasei, pachetul în care este rezidentă clasa.

Client java::awt::Rectangle

(a) (b)

Figura 6.2. Specificarea numelui unei clae în UML

Un nume de clasă poate fi un şir de caractere de orice lungime, care conţine litere, cifre şi semne de
punctuaţie, cu excepţia simbolului ”::”, utilizat pentru a separa numele clasei de pachetul sau lanţul 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 obţine prin juxtapunerea mai multor cuvinte care pot dezvălui semantica clasei
respective. De exemple, PoligonAbstract, TriunghiEchilateral, FereastraDeDialog, etc. Se observă cum,
pentru mai multă lizibilitate, fiecare cuvânt din structura numelui începe cu literă mare.
Atributele unei clase
Un atribut este numele unei proprietăţi ( a unei clase) care abstractizează un domeniu de valori pe care
instanţele proprietăţii le pot lua.
O clasă poate avea orice număr de atribute sau, la limită, nici un atribut.
Un atribut desemnează, astfel, o anumită proprietate a realităţii modelate, proprietate partajată de toate
instanţele realităţii respective. Ca formalizm de reprezentare, atributele sunt listate în compartimentul situat
imediat sub numele clasei, ca în Figura 6.3.
În funcţie 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 iniţială. ca în
Figura 6.4.
 Student

natricol Lista atributelor

numePrenume
adresa
dataNasterii

Figura 6.3. Atributele unei clase

Aşa cum sugerează exemplele prezentate în Figurile 6.3 şi 6.4, numele unui atribut poate începe cu literă
mică, celelalte cuvinte care formează numele atributului începând cu literă mare.

Student

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

Figura 6.4. Atribute, complet caracterizate

Operaţiile unei clase

O operaţie este abstractizarea unui serviciu, care poate fi solicitat oricărui obiect al unei clase. Este
clară, sper, sugestia că o operaţie a unei clase este partajată de toate obiectele clasei respective. O clasă poate
avea oricâte operaţii sau, la limită, nici o operaţie. Operaţiile unei clase sunt listate în compartimentul situat
imediat sub lista atributelor, ca în Figura 6.5.

Student

adaugs()
stergs()
modifics() Lista operaţiilor
afisez()

Figura 6.5. Operaţiile unei clase

În practică, regulile de formare şi reprezentare a numelor operaţiilor sunt asemănătoare celor folosite în
cazul atributelor. O operaţie 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 6.6. În Figura 6.6 am folosit secvenţa “...”
pentru a indica faptul că lista operaţiilor este, în mod conştient, incompletă. Această secvenţă, împreună cu
posibilitatea de a organiza listele de atribute sau operaţii, prea lungi, în categorii descriptive, folosind
stereotipurile, contribuie la o mai bună mapare a potenţialului de descriere al unei clase peste nevoile de
reprezentare specifice unui punct de vedere al specialistului în IS.
 Student

...
modificMatricol(m:string[4])
consultNume():string[40]
modificAdresa(a:TAdresa=””) Lista operaţiilor
...

Figura 6.6. Operaţii descrise la nivel de signatură

Utilizarea stereotipurilor pentru clasificarea însuşirilor unei clase este exemplificată în Figura 6.7.

Student

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

Se cuvine să reamintim faptul că stereotipul este unul dintre mecanismele de extensie, de bază, ale
UML-ului, cu ajutorul căruia putem îmbogăţi, progresiv, însăşi semantica limbajului. Asupra acestui
mecanism de extensie vom mai reveni.
Responsabilităţile unei clase
O responsabilitate este abstractizarea textuală a unui serviciu furnizat de o clasă. Este deja lămurit
faptul că, la definirea unei clase, este foarte importantă supoziţia că toate obiectele acestei clase au acelaşi
comportament.
Această afirmaţie, la un nivel de abstractizare mai înalt, înseamnă că atributele şi operaţiile sunt doar
nişte elemente-suport pentru îndeplinirea responsabilităţilor clasei. Responsabilităţile unei clase, în cazul în care
sunt definite, sunt listate într-un compartiment situat la baza simbolului grafic al clasei, ca în Figura 6.8
În practică, elaborarea modelului claselor poate începe prin specificarea responsabilităţilor entităţilor
candidate, înregistrate în vocabularul realizat în faza de analiză a cerinţelor. În acest scop se pot folosi tehnici
precum card-urile CRC1 sau analiza bazată pe contexte de utilizare. În procesul de rafinare a modelului claselor,
responsabilităţile sunt traduse într-un set de atribute şi operaţii care asigură îndeplinirea optimă a
responsabilităţilor.

1
CRC – prescurtare de la Class – Responsabilities – Collaborators, o tehnică efectivă de explorare şi identificare a responsabilitătilor unei
clase
 Student

Responsabilities

 creare studenţi
 actualizare date personale studenţi
 validare date personale studenţi
...

Figura 6.8. Responsabilităţile unei clase

6.2 Relaţii
În modelarea obiect-orientată există trei tipuri de relaţii care sunt considerate foarte importante:
dependenţele, care abstractizează relaţiile de utilizare existente între clase (rafinarea, versionarea, legarea);
generalizările, care leagă clasele generalizate de specializările lor şi asocierile, care reprezintă relaţiile
structurale dintre obiecte. Formalizmul UML pentru reprezentarea acestor trei tipuri de relaţii, precum şi maniera
de utilizare, pot fi urmărite, pentru început, în Figura 6.9.

Window dependenţă

open()
Event
close()
move()
display()
handleEvent()
generalizări

asociere

ConsoleWindow DialogBox
Control

Figura 6.9. Reprezentarea relaţiilor în UML

Relaţia de dependenţă
Aşa cum am mai precizat, o dependenţă este o relaţie de utilizare care exprimă faptul că o schimbare în
specificarea unei entităţi (de exemplu, clasa Event) poate afecta altă entitate care o foloseşte ( de exemplu, clasa
Window). După cum vom vedea în Capitolul 3, există un număr semnificativ de stereotipuri, aplicabile relaţiilor
de dependenţă dintre entităţile unui model UML.
Dacă se consideră necesar, relaţia de dependenţă poate avea un nume, care ajută la discriminarea ei într -
un context în care mai sunt şi alte dependenţe, ceea ce ajută la referirea mai uşoară a dependenţei, în caz de
nevoie.
Relaţia de generalizare
O generalizare este o relaţie între o entitate generală (numită superclasă sau clasă părinte) şi o varietate
specifică a acelei entităţi (numită subclasă sau clasă copil)). În literatura de specialitate, generalizarea mai este
desemnată şi prin sintagma „relaţie is a kind of”. Generalizarea înseamnă că obiectele copil pot fi folosite
oriunde pot apare obiecte părinte. Altfel spus, generalizarea ne asigură de faptul că un copil poate fi un substitut
al părintelui său, nu şi invers. Trivial, dar trebuie să reamintim (pentru cei care nu sunt documentaţi suficient
asupra paradigmei obiect-orientate) faptul că un copil moşteneşte toate proprietăţile părintelui (în mod esenţial,
atributele şi operaţiile). Adesea, dar nu întotdeauna, copilul are atribute şi/sau operaţii adiţionale. O operaţie a
unui copil care are aceeaşi signatură cu o operaţie a părintelui se spune că suprascrie (redefineşte) operaţia
părintelui, procedeu prin care se pun bazele polimorfismului.
Relaţia de asociere
O asociere este o relaţie structurală care specifică faptul că instanţele unei clase sunt conectate la
instanţele altei clase. Conectarea de care am vorbit mai sus, trebuie înţeleasă astfel: dată o instanţă a a clasei A,
în clasa B poate fi găsită cel puţin o instanţă b, astfel încât 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 către un
obiect al altei clase şi invers, dacă cele două clase sunt în relaţie de asociere. O asociere la care participă exact
două clase se numeşte asociere binară. Deşi nu este o situaţie 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 analizând Figura 6.10.
În practică, numele unei asocieri nu este obligatoriu, fiind folosit pentru a spori claritatea modelului.

nume asociere sensul navigării

Persoana Lucrează pentru Firma

asociere
Figura 6.10. Numele unei asocieri
Relaţia de agregare
O asociere obişnuită între două clase reprezintă, aşa cum am spus, o relaţie structurală între egali,
ceea ce înseamnă că ambele clase sunt considerate, conceptual, la acelaşi nivel de importanţă în relaţie.
Făcând puţină literatură, o asociere obişnuită este abstractizarea unei relaţii de parteneriat. În realitate, există
nenumărate situaţii, în care suntem nevoiţi să acordăm un statut special unor asocieri în care ideea de parteneriat
nu mai operează. O astfel de situaţie este cea în care trebuie să modelăm o relaţie „întreg/parte”, în care una
dintre clase desemnează o entitate mai largă (întregul) care constă din entităţi mai mici (părţile). Acest tip de
relaţie se numeşte agregare şi în literatura de specialitate mai este recunoscută şi ca relaţie „has-a”, spre
deosebire de „is-a-kind of” (generalizarea”). Formalizmul grafic folosit pentru specificarea unei agregări este
prezentat în Figura 6.11.

Companie întregul
1
agregarea
multiplicităţi

*
Departament partea

Figura 6.11. Exemplu de agregare

După cum sugerează şi Figura 6.11, agregarea este o relaţie care, în esenţă, înseamnă că un obiect al
clasei întreg constă din unul sau mai multe obiecte ale clasei parte în relaţia de agregare. Evident că, putem
întâlni şi situaţii î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 decât o potenţială relaţie întreg -parte,
neprecizând nimic în ceea ce priveşte competenţele instanţelor întreg relativ la crearea şi distrugerea
instanţelor parte.

6.3 Mecanisme comune

Anunţată în Capitolul 1, reluăm în acest paragraf problema mecanismelor comune. Să ne amintim,
aşadar, faptul că UML este mai uşor de înţeles şi aplicat dacă înţelegem importanţa celor patru mecanisme
comune: specificaţiile, ornamentele, separările 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.
 Ornamentele
Forţând puţin exprimarea, dată fiind şi lipsa unui cuvânt nou pentru o semantică parţial nouă, pentru a
conţine cât mai multă semantică şi pentru a transmite, diferitelor persoane interesate, cât mai mult din această
semantică, modelele UML sunt „împodobite” cu o serie de elemente adiţionale formalizmului de bază.
Ornamentele asociate modelelor UML sunt de două tipuri: note şi ornamente pentru vizualizarea şi detalierea
specificării.
Ne amintim că o notă este un simbol grafic folosit pentru redarea constrângerilor sau comentariilor ataşate
unui element sau unei colecţii de elemente. Formalizmul pentru o notă UML poate fi revăzut în Figura 6.12.

text simplu încapsulare URL

Această componentă A se vedea

va fi livrată cel mai http://www.rational.com
târziu în 13/02/04

legătură la document

A se vedea Heap.doc
pentru detalii asupra
acestui algoritm

Figura 6.12. Moduri de utilizare a notelor

Notele prezentate în Figura 6.12 pot fi ataşate 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
specificării. De exemplu, se ştie că notaţia de bază pentru asociere este o linie; atunci când situaţia o cere,
această linie poate fi ornamentată cu detalii, cum sunt rolurile şi multiplicităţile ataşate fiecărui capăt al asocierii.
În utilizarea UML, regula generală de urmat este: „ Se porneşte cu notaţia de bază pentru fiecare element şi
se adaugă alte ornamente numai dacă acestea sunt necesare pentru a furniza informaţii importante
pentru înţelegera modelului”. Majoritatea ornamentelor sunt redate prin plasarea textului în apropierea
elementului vizat sau prin adăugarea unui simbol grafic notaţiei de bază. Este posibil ca, uneori, să doriţi să
adăugaţi unui element detalii mai multe, ceea ce poate fi destul de dificil folosind textul simplu sau simbolurile
grafice. În astfel de situaţii, unor entităţi precum clasele, componentele şi nodurile le putem adăuga un nou
compartiment, situat imediat sub compartimentele uzuale, pentru a furniza alte informaţii.

Mecanismele UML de extindere

Stereotipurile
După cum am văzut, UML furnizează un limbaj pentru capturarea şi reprezentarea semanticii următoarelor
tipuri de entităţi; entităţi cu funcţii structurale, entităţi cu funcţii comportamentale, entităţi cu funcţii de grupare
şi entităţi cu funcţii de documentare. Aceste patru tipuri de entităţi sunt suficiente pentru majoritatea sistemelor
pe care le modelăm. Există, însă şi situaţii în care, în domeniul problemei apar aspecte care reclamă introducerea
unor semantici noi, folosind în acest scop formalizme asemănătoare celor utilizate în cazul blocurilor
constructive primitive. Pentru a reglementa modul în care se procedează în astfel de situaţii, în UML au fost
specificate mecanismele de extindere. Acestea sunt: stereotipurile, valorile etichetate şi constrângerile.

Stereotipurile
Referindu-ne la aria claselor, un stereotip nu este similar cu o clasă părinte într-o relaţie de generalizare
părinte-copil. Mai degrabă, putem gândi stereotipul ca un metatip, ale cărui instanţe sunt clase noi, în sintaxa
UML. Ca un exemplu, dacă suntem familiarizaţi cu modelul de dezvoltare RUP, vom vedea că acesta conţine
recomandări precise în ceea ec priveşte modelarea claselor, existând stereotipuri pantru trei tipuri fundamentale
de clase: clasele de frontieră, clasele cu funcţii de prelucrare şi clasele cu funcţii de control. Fiecare din cele
trei tipuri de clase poate fi considerat un stereotip, care extinde posibilităţile de modelare ale UML -ului, ca în
Figura 6.13.

<<Boundary>> <<Entity>>

PreluareDateStudent PrelucrareDateStudent

<<Control>>

SupervizareBE

Figura 6.13. Exemple de stereotipuri utile în modelarea claselor

După cum reiese din Figura 6.13, un stereotip este recunoscut după numele lui, situat între simbolurile
<<...>>, dedesubtul căruia se află numele concret al modelului.

Valorile etichetate
Fiecare entitate UML are propriul set de proprietăţi: clasele au nume, atribute şi operaţii; asocierile au
nume şi două sau mai multe capete cu propriile lor proprietăţi, etc. După cum am văzut, folosim stereotipurile
pentru a adăuga soluţiei noastre entităţi noi. Pentru a adăuga proprietăţi noi entităţilor, folosim valorile
etichetate. În practică, valorile etichetate pot fi folosite pentru a păstra diferite informaţii despre proprietăţile
entităţilor. Astfel, informaţii de interes pentru managementul unui proiect (data creării unui model, starea
dezvoltării lui, autorul, etc.) sau informaţii de interes în procesul de instalare a unei aplicaţii (memoria internă
necesară, memoria externă necesară, limita inferioară a frecvenţei procesorului, etc.) sunt două exemple uzuale
de utilizare a valorilor etichetate. Formalizmul de prezentare a valorilor etichetate este , transparent prezentat în
Figura 6.14.
După cum se poate observa în Figura 6.14, valorile etichetate apar între acolade ca secvenţe de tipul:

{<etichetă>=<valoare>}

dacă informaţiile sunt adăugate direct pe entitatea vizată, sau, folosind ca suport nota ataşată, urmând aceeaşi
sintaxă, dacă este vorba de informaţii care se referă la mai multe entităţi, de exemplu.
Constrângerile
Este de domeniul evidenţei, probabil, faptul că orice construcţie sintactică în UML are propria ei
semantică. De exemple, într-o relaţie de generalizare operează principiul substituţiei care afirmă că un obiect al
clasei copil poate substitui un obiect al clasei părinte, dar nu şi invers. Acest „dar nu şi invers” este o
constrângere, de care trebuie să fim conştienţi când lucrăm cu o ierarhie de clase.
Utilizând constrângerile, putem, de asemenea, să adăugăm semantici noi modelelor sau să modificăm
regulile fundamentale după care operează modelele. În ultimă analiză, o constrângere specifică o serie de
condiţii care trebuie îndeplinite pentru ca modelul să fie corect. Formalizmul după care adăugăm
constrângeri modelelor este deductibil din Figura 6.15.

În general, specificarea constrângerilor poate fi realizată folosind un limbaj textual, liber în expresie.
Dacă se doreşte mai multă rigoare în specificarea constrângerilor se poate apela la OCL (Object
Constraint Language), un standard care însoţeşte specificarea completă a UML-ului. Acest standard poate
fi găsit în documentaţia pusă la dispoziţie de firma Rational pe site-ul www.rational.com.
 autor=Tudor Stelian
Server terminat=12/10/2001
{procesoare=2}
{aplicatie=serv.exe}

serv.exe
{doarPeServer,
RamSize=600K}

Figura 6.14. Utilizarea valorilor etichetate

Cont * ContFirma 1 Firma

* ContPersonal {XOR}

* Persoana

lucrator
angajat angajator
Persoana Firma
* 0..1

Şef

{Persoana.angajator=
Persoana.Şef.angajator}

Figura 6.15. Exemple de constrângeri

6.4 Diagrame
Introducere
În paragraful 5.3 am precizat deja rolul diagramelor (ca entităţi cu funcţii 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ă înţelegere, atât a soluţiei cât şi a sistemului modelat. Necesitatea
diagramelor în modelarea UML are o justificare mult mai profundă decât cea prezentată mai sus. Una dintre
provocările importante în procesul de modelare a comportamentului unui sistem se numeşte stăpânirea
complexităţii. 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. Aşa se face că, la anumite
nivele de abstractizare a soluţiei 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 întâlnite în
arhitectura soluţiei UML a unui sistem soft. Aşa cum am mai spus, în UML există nouă tipuri de diagrame,
utilizate pentru gruparea modelelor care descriu aspectele statice sau dinamice ale unui sistem.
Pentru descrierea aspectelor statice avem:

1. Diagrame ale claselor

2. Diagrame ale obiectelor
3. Diagrame ale componentelor
4. Diagrame de desfăşurare

Pentru descrierea aspectelor dinamice avem:

1. Diagrame ale contextelor de utilizare

2. Diagrame de secvenţă
3. Diagrame de colaborare
4. Diagrame de hărţi 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
doreşte, în ultimă instanţă, un specialist în IS, în relaţia cu UML. Fără această abilitate, mânuirea, cu randament,
a tool-urilo precum Rational Rose, ObjectiF, etc. este un vis imposibil.

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 înţelegem relaţiile
invariante dintre componentele sistemului. Referindu-ne la ingineria softului, din perspectivă UML, aspecte
statice ale soluţiei unui sistem soft sunt: relaţiile dintre clase, interfeţele, colaborările, ansamblul structurat
al componentelor, topologia hard care susţine execuţia sistemului. Odată definite relaţiile dintre clase,
introducem un element de stabilitate, necesară pentru a putea continua efortul de realizare a soluţiei. Odată
specificate interfeţele, clienţii lor se pot ocupa, în linişte, de aspectele legate de utilizarea lor, etc..

Diagrame ale claselor

O diagramă a claselor expune un ansamblu de clase, interfeţe şi colaborări, împreună cu relaţiile dintre
ele. Diagramele claselor reprezintă tipul de diagramă cel mai des întâlnit în modelarea sistemelor obiect
orientate. Folosim diagramele claselor pentru a evidenţia perspectiva design (structurală) a sistemului . De
asemenea, putem observa faptul că diagramele claselor care includ clase active sunt utile pentru a evidenţia
aspectele statice ale perspectivei proces a unui sistem.

Diagrame ale obiectelor

O diagramă a obiectelor expune un ansamblu de obiecte, împreună cu relaţiile dintre ele. Folosim
diagramele obiectelor pentru a ilustra structuri de date, instantanee statice ale instanţelor entităţilor din
diagramele claselor. Într-o oarecare măsură, se subânţelege faptul că diagramele obiectelor sunt destinate
evidenţierii perspectivei design (statică) sau perspectivei proces (statică) a unui sistem, cum se întâmplă şi în
cazul diagramelor claselor, dar luând în obiectiv instanţe 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 relaţiile dintre ele.
Folosim acest tip de diagramă pentru a ilustra aspectele statice ale perspectivei implementaţionale a unui
sistem. Diagramele componentelor se află în legătură cu diagramele claselor, datorită faptului că, în mod normal,
o componentă se mapează pe una sau maai multe clase, interfeţe sau colaborări.

Diagrame de desfăşurare
O diagramă de desfăşurare expune un ansamblu de noduri, împreună cu relaţiile dintre ele. Folosim
acest tip de diagramă pentru a ilustra aspectele statice ale perspectivei desfăşurare a hard-ului care susţine
execuţia unui sistem soft. Diagramele de desfăşurare se află în legatură cu diagramele componentelor, datorită
faptului că, în mod uzual, un nod conţine una sau mai multe componente.
Diagrame comportamentale
După cum am văzut, 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 hărţi de stare (statechart diagram)
Acestea sunt diagrame care se focalizează pe schimbările 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
socotiţi un gen special de clasă), împreună cu relaţiile eferente. Putem folosi diagramele context de utilizare
pentru a ilustra aspecte statice ale contextelor de utilizare a unui sistem (diferite tipuri de relaţii între
contextele de utilizare) dar, mai ales, pentru a prefigura organizarea şi modelarea comportamentului unui
sistem.

Diagrame de secvenţă
O diagramă de secvenţă este o diagramă de interacţiune, care evidenţiază ordonarea în timp a mesajelor
care rezolvă problemele de comunicare dintre obiectele unei aplicaţii. Astfel că, o diagramă de secvenţă expune
un ansamblu de obiecte şi distribuţia temporală a mesajelor, trimise şi primite, de către aceste obiecte. Obiectele,
în mod uzual au nume, pot fi şi instanţe anonime ale claselor, dar pot reprezenta şi instanţe ale altor tipuri de
entităţi precum: colaborări, componente sau / şi noduri. Evident, utilizăm o diagramă de secvenţă pentru a
reprezenta perspectiva dinamică a unui sistem.

Diagrame de colaborare
O diagramă de colaborare este o diagramă de interacţiune care pune accent pe organizarea structurală a
obiectelor care trimit sau primesc mesaje. O diagramă de colaborare expune un ansamblu de obiecte, legăturile
dintre aceste obiecte şi mesajele trimise sau primite de aceste obiecte. În mod uzual, obiectele au un nume, pot fi
instanţe anonime ale claselor, dar pot fi şi instanţe ale altor tipuri de entităţi, precum colaborări, componente
sau/şi noduri. O diagramă de colaborare este, de asemenea, utilă pentru a reprezenta perspectiva dinamică a unui
sistem.

Diagrame hărţi de stare (DHS)

O DHS este o maşină de stare în structura căreia intră elemente precum: stările obiectelor, tranziţiile,
evenimentele şi activităţile 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 activităţilor din interiorul unui sistem (flux care poate fi
secvenţial sau ramificat) precum şi obiectele asupra cărora acţionează, sau de care sunt demarate aceste activităţi.
Diagramele de activitate sunt importante pentru modelarea funcţiei unui sistem, ca flux de control, în dinamica
activităţilor unui obiect sau a unui ansamblu de obiecte-partenere la rezolvarea unei probleme.

Diagrame ale claselor

Diagrama claselor este tipul de diagramă care nu poate lipsi din soluţia obiect orientată a unui sistem
soft. Cum am mai spus, o diagramă a claselor este o diagramă care expune un ansamblu de clase, interfeţe şi
colaborări precum şi relaţiile dintre acestea. Formalizmul grafic de reprezentare al unei diagrame a claselor se
exprimă sintetic în formula „colecţie 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 entităţilor conţinute:
clase (prezenţă obligatorie şi esenţială în orice diagramă a claselor);
interfeţe (prezenţă strict necesară când se modelează în spiritul obiectelor (componentelor)
programabile, care separă net interfeţele de implementarea lor;
colaborări (este vorba de colaborări din perspectivă structurală, care pot fi numite „piesele mari” ale
unei diagrame a claselor);
dependenţe, generalizări, relaţii de asociere.

Asemenea altor tipuri de diagrame, diagramele claselor pot conţine note şi constrângeri. Dacă necesităţile de
abstractizare o impun, diagramele claselor pot conţine pachete sau subsisteme, fiecare dintre acestea fiind
utilizate pentru a grupa elemente ale modelului în curs de elaborare, obţinându-se blocuri constructive cu o
semantică specifică, accesibilă unui anumit tip de „beneficiar”. Uneori, diagramele claselor pot conţine şi
instanţe.
Încercând un răspuns la întrebarea „Pentru ce elaborăm diagramele claselor?”, reamintesc faptul că
intenţia lor declarată este de a modela aspectele statice ale perspectivei design (structurale). Mergând ceva mai
departe, trebuie să subliniez faptul că cerinţele funcţionale ale unui sistem soft trebuie să se mapeze
convenabil peste ansamblul modelelor care compun perspectiva design. De aceea se obişnuieşte să se afirme
că stabilitatea structurală a design-ului static este esenţială pentru longevitatea şi calitatea unei soluţii .
Din punctul de vedere al practicii, utilizăm diagramele claselor în una din situaţiile următoare:

 Suntem preocupaţi de modelarea vocabularului sistemului

 Dorim să modelăm o colaborare
 Dorim să modelăm schema logică a unei baze de date

Modelarea vocabularului unui sistem

Această activitate implică o serie de decizii relativ la abstracţiile care sunt părţi componente ale sistemului
în curs de modelare şi care vor rămâne în afara frontierei sistemului. Folosim diagrame de clase pentru a
vizualiza şi specifica aceste abstracţii şi responsabilităţile lor în cadrul sistemului.

Modelarea unei colaborări

O colaborare este o comuniune de clase, interfeţe şi alte elemente care lucrează împreună pentru a asigura
un comportament, care înseamnă mai mult decât suma mecanică a comportamentelor elementelor care participă
la colaborare (putem vorbi, astfel, despre necesitatea valenţelor sinergetice ale unei colaborări). Folosim
diagrame de clase pentru a vizualiza şi specifica astfel de colaborări. Un exemplu de colaborare, simplă, poate fi
urmărit în Figura 6.16. Figura 6.16 prezintă un set de clase, considerate esenţiale 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 36 se concentrează asupra abstracţiilor care sunt direct implicate în deplasarea robotului. Ne putem,
lesne, imagina că există şi abstracţii preocupate, de exemplu, de gestiunea conflictelor care pot apare în timpul
deplasării robotului, în anumite condiţii de mediu. Vor exista, prin urmare, şi alte colaborări în mulţimea claselor
care descriu, din punct de vedere static, comportamentul unui robot autonom. Pentru a simplifica procesul de
înţelegere a sistemului, este recomandabil procedeul separării mai multor colaborări, 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 înţelegem rezultatul proiectării conceptuale a bazei de date (De
exemplu, modelul relaţional al unei baze de date, adus la o formă normală convenabilă). Sunt numeroase
aplicaţiile în care
avem nevoie de asigurarea persistenţei informaţiilor, utilizând baze de date relaţionale sau baze de date obiect
orientate. Schema logică a unei baze de date poate fi modelată folosind diagrame de clase, ca în Figura 6.17.
În Figura 6.17 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 operaţiilor utile în manipularea obiectelor unei clase, în clasa de nivel de persistenţă
imediat superioară (cum este cazul în relaţia dintre clasa Facultate şi clasa Catedra).
 AgentTraseu SenzorColiziuni

Responsabilities
 căutare traseu Driver
 evitare obstacole

Motor de Cârmă MotorPrincipal

Motor

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

Figura 6.16. Modelarea unei colaborări simple între clase, în UML

Facultate Catedră
{persistent} {persistent}
Ar
nume:TNume e nume:TNume
1
adresa:string adaugProf()
1..*
Angaja stergProf()
adaugstud() t la
stergstud()
citestestud()
… () Profesor
{persistent}
1..
nume:TNume
*

Înmatric
ulat Pred
ă
*
Student Curs
{persistent} {persistent}
Frecvent
nume:TNume ează nume:TNume
matricol:integer codCurs:integer

Figura 6.17. Modelarea schemei logice a unei baze de date

Câteva observaţii de luat în seamă când elaborăm o diagramă a claselor

O diagramă a claselor bine structurată va ţine cont de următoarele cerinţe:
 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 esenţiale pentru a înţelege respectivul aspect;
 Furnizarea de detalii, conforme nivelului de abstractizare şi ataşarea doar a ornamentelor strict
necesare;
 Nu va avea niciodată atâtea omisiuni încât să rişte informarea greşită a cititorului asupta semanticii
importante a clasei.
Complementar cerinţelor de mai sus putem accepta următoarele reguli de stil:

 Asocierea unei diagramei de clase cu un nume sugestiv (care să deconspire semantica diagramei);
 Expunerea elementelor diagramei astfel încât să reducem la minimum liniile care se intersectează;
 Folosirea notelor şi a culorilor, ca pârghii vizuale de dirijare a atenţiei asupra aspectelor importante ale
diagramei.
7 MODELAREA ASPECTELOR
COMPORTAMENTALE. ELEMENTE-SUPORT
FUNDAMENTALE
7.1 Interacţiuni
Într-un sistem, interesant din punct de vedere comportamental, obiectele interacţionează între ele utilizând ca
tehnică de bază transmiterea de mesaje.
Se numeşte interacţiune 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 modelării vom folosi interacţiunile pentru a modela aspecte dinamice ale colaborărilor, care
reprezintă uniuni de obiecte jucând roluri specfice, cooperând pentru realizarea unui anumit comportament,
despre care putem spune, cu rezerva de rigoare, că este mai mare decât suma mecanică a elementelor.
Aceste roluri reprezintă instanţe prototipice ale claselor, interfeţe, componente, noduri şi contexte de
utilizare. Aspectele lor dinamice sunt vizualizate, specificate, construite şi documentate ca fluxuri de control care
pot cuprinde fire de execuţie secvenţiale, precum şi fluxuri mai complexe, care implică ramificări, iteraţii,
recursii sau concurenţă.
Putem modela o interacţiune în două moduri: prin accentuarea ordonării în timp a mesajelor (obţinând
modele numite diagrame de secvenţă) sau prin accentuarea secvenţării mesajelor în contextul unor colecţii
structurate de obiecte (obţinând modele numite diagrame de colaborare).
Este evident faptul că interacţiunile bine structurate sunt asemenea algoritmilor bine structuraţi: eficiente,
simple, adaptabile şi inteligibile.
Să mai subliniem faptul că putem folosi interacţiunile pentru a modela fluxuri de control în interiorul unor
operaţii, clase, componente, contexte de utilizare sau la nivelul sistemului ca întreg. Utilizând diagramele de
interacţiune, putem reflecta asupra acestor fluxuri în două moduri. Mai întâi, ne putem focaliza atenţia asupra
modului în care sunt expediate mesajele în timp. În al doilea rând, ne putem concentra atenţia asupra relaţiilor
structurate dintre obiectele aflate într-o interacţiune şi, pe acest temei, să considerăm modul în care mesajele
circulă între componentele contextului structurat.
UML furnizează o reprezentare grafică a mesajului, aşa cum se poate vedea în Figura 7.1.

7.2 Concepte vehiculate în modelarea interacţiunilor

7.2.1 Contextul în care se manifestă interacţiunile
Există o interacţiune în orice situaţie în care obiectele sunt legate între ele. Mai exact spus, vom descoperi
interacţiuni în colaborarea dintre obiectele care există în contextul sistemului sau subsistemului modelat. Mai
putem descoperi interacţiuni şi în contextul unei operaţii. În sfârşit, putem identifica interacţiuni şi în contextul
unei clase.
Cel mai adesea, descoperim interacţiuni în colaborarea obiectelor care există în contextul sistemului sau
subsistemului modelat.

număr de secvenţă mesaj CitesteUrmNote()

1:PrelNotMat(n)
f:Foaia_Matricola n:Note
{ordered}

obiect legătură obiect

Figura 7.1. Mesaje, legaturi şi secvenţierea mesajelor

De exemplu, subsistemul Planificarea activităţii didactice din cadrul sistemului informaţional al unei
facultăţi este contextul în care instanţe ale unor clase, precum StatDeFuncţii, PlanDeÎnvăţământ,
FormaţieDeLucru vor interacţiona pentru a „contribui” la rezolvarea problemei orarului semestrial al grupelor
de la fiecare specializare şi, de ce nu, al fiecărui profesor în parte.
Interacţiuni între obiecte descoperim şi în procesul de implementare a unei operaţii. Parametrii unei operaţii,
orice variabilă obiect locală operaţiei şi orice obiecte globale (dar încă vizibile operaţiei) pot interacţiona pentru
a materializa algoritmul corespunzător implementării operaţiei.
 Astfel, invocarea operaţiei suma() care simulează adunarea a două numere mari, fiecare număr fiind o
instanţă a clasei NumarMare, este evident că poate fi implementată astfel încât invocarea să aibă sintaxa:
nr1.suma(nr2)
ceea ce inseamnă interacţiune între obiectul global nr1, obiectul transmis prin lista de parametrii ( nr2 ) şi
un obiect local operaţiei, folosit pentru a genera obiectul sumă pe care îl va returna operaţia suma().
În al treilea şi ultimul rând, descoperim interacţiuni în contextul unei clase. Altfel spus, putem folosi
interacţiunile pentru a vizualiza, specifica, construi şi documenta semantica unei clase. Revenind la exemplul
clasei NumarMare, pentru a ilustra comportamentul obiectelor acestei clase, putem imagina interacţiuni care
arată cum colaborează atributele acestei clase pentru a permite îndeplinirea responsabilităţilor asumate de clasă,
la specificare.

Obiecte şi roluri
Obiectele care participă într-o interacţiune 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.

Legături
O legătură este o conexiune semantică între obiecte. În general, o legătură este o instanţă a unei asocieri.
Aşa cum rezultă şi din Figura 68, în momentul în care o clasă are o asociere cu altă clasă, putem avea şi o
legătură între instanţele celor două clase; odată ce există o legătură între două obiecte, unul dintre ele poate
trimite un mesaj celuilalt.
O legătură specifică o cale de-a lungul căreia un obiect poate trimite un mesaj altui obiect sau chiar lui
însuşi.
De cele mai multe ori, este suficient să specificăm faptul că o astfel de cale există. Dacă este nevoie de mai
multă precizie în ceea ce priveşte această cale, putem ornamenta capătul potrivit al legăturii cu unul din
următoarele stereotipuri standard:
 <<association>> - specifică faptul că obiectul corespunzător este vizibil prin asociere;
 <<self>> - specifică faptul că obiectul corespunzător este vizibil deoarece el este executantul operaţiei;
 <<global>> - specifică faptul că obiectul corespunzător este vizibil deoarece aparţine unui domeniu
acoperitor;
 <<local>> - specifică faptul că obiectul corespunzător este vizibil deoarece aparţine unui domeniu
local;
 <<parameter>> - specifică faptul că obiectul corespunzător este vizibil în calitate de parametru.

Persoana
1..* * Firma
afectare (d:Departament) angajat angajator

afectare(financiar)
p:Persoana :Firma

Figura 7.2 Asociere şi legătură

Mesaje
Presupunem că avem o colecţie de obiecte şi un set de legături 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 colecţiei de obiecte, la un moment dat şi sunt folositoare atunci când dorim să vizualizăm, să specificăm,
să construim sau să documentăm o structură statică de obiecte.Să presupunem, acum, că dorim să modelăm
schimbarea stării unei colecţii de obiecte de-a lungul unei perioade de timp.
Dacă, prin absurd, am putea imagina un procedeu de „fotografiere” a colecţiei de obiecte, la intervale succesive
de timp, atunci ar trebui să observăm: obiecte care schimbă mesaje între ele, provoacă evenimente şi invocă
operaţii. În plus faţă de perspectiva asociată scenariului de mai sus, ne putem propune vizualizarea explicită a
stării curente şi a rolului instanţelor individuale.
 Un mesaj este specificarea unei comunicări între obiecte, care transmite informaţia necesară pentru
producerea unei activităţi. Primirea unei instanţe mesaj poate fi considerată o instanţă a unui eveniment. Ca
urmare a formulării unui mesaj, o acţiune răspuns va fi declanşată. O astfel de acţiune poate produce o schimbare
de stare.
În UML pot fi modelate următoarele tipuri de acţiuni:
 Call – invocarea unei operaţii a unui obiect; un obiect îşi poate transmite lui însuşi un mesaj, ceea ce
este interpretat ca invocare locală a unei operaţii;
 Return – întoarcerea unei valori la apelant;
 Send – expedierea unui semnal către un obiect;
 Create – crearea unui obiect;
 Destroy – distrugerea unui obiect; un obiect se poate, la nevoie, autodistruge.
UML oferă o notaţie care permite deosebirea, sub aspect vizual, a acestor tipuri de acţiuni, care pot fi
asociate unui mesaj. O primă prespectivă asupra acestei notaţii poate fi observată în Figura 7.3, care este,
anticipând, o diagramă de secvenţă.

c:Client p:AsistentPlanificare

<<create>> :AgentBilete
create

setItinerar(i)
calculRuta()
call

ruta call (invocare

locală)
return <<destroy>>

notificare()
destroy

send
Figura 7.3. Mesaje şi tipuri de acţiuni asociate

Figura 7.3, deşi ipotetică conţine elementele fundamentale pentru a înţelege importanţa noţiunii de mesaj în
reprezentarea interacţiunilor dintre obiecte. Obiectul c (de tip Client) creează un obiect anonim de tip
AgentBilete (folosind un mesaj asociat cu o acţiune stereotipizată create); obiectul c apelează metoda
setItinerar() a obiectului anonim de tip AgentBilete (care primeşte ca parametru, un obiect i de tip
Itinerar); obiectul anonim apelează propria metodă calculRuta() pentru a determina elementele
caracteristice ale rutei. Următorul mesaj este asociat cu o acţiune de tip return, după care urmează distrugerea
obiectului anonim de către obiectul i. În sfârşit, 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 cărora va trebui să revenim în continuare.

Secvenţare
În practica descrierii interacţiunilor dintre obiecte, un obiect trimite un mesaj altui obiect; receptorul, la
rândul lui, trimite un mesaj altui obiect ş.a.m.d. Acest potenţial flux de mesaje formează o secvenţă. Orice
secvenţă are un început, care este localizat într-un proces sau fir de execuţie. Secvenţa poate să fie activă, cel
mult cât timp este activ procesul sau firul de execuţie.
Fiecare proces şi fir de execuţie din interiorul unui sistem defineşte un flux de control distinct şi în interiorul
fiecărui flux mesajele sunt ordonate în secvenţe care ţin cont de succesiunea lor în timp. Pentru o mai bună
vizualizare a scevenţelor de mesaje, în UML putem modela explicit „ordinea de intrare” a mesajului, relativ la
începutul secvenţei din care face parte, prin prefixarea mesajului cu un număr de secvenţă, separat cu simbolul
„:” de mesaj. De domeniul uzualului este să specificăm fluxuri de control procedurale, redate folosind o
săgeată de tipul celei din Figura 7.4.
 2:selectN(S) 2.2:Insert(m)
s:Student n:Note 2.2 f:FoaieMa-
ricola

2.1:m=CalcMed()

Figura 7.4. Secvenţă procedurală

Mai puţin uzuale, dar, evident posibile sunt fluxurile de control plate, care se redau folosind o săgeată
asemănătoare celei din Figura 7.5.

1:procesare(p)
p:Persoana o:OreLucrate

2:generare(o)

f:Fluturas

Figura 7.5. Secvenţă plata

În practica modelării UML distincţia dintre secvenţa plată şi cea procedurală este subtilă. De exemplu,
modelarea interacţiunilor din perspectiva contexte de utilizare se pretează la utilizarea secvenţelor plate. Odată
cu adâncirea procesului de rafinare a soluţiei vom fi nevoiţi să folosim şi secvenţele procedurale, omniprezente
în oferta limbajelor de programare pentru organizarea fluxurilor de prelucrare.

Crearea, modificarea şi distrugerea obiectelor

În majoritatea cazurilor, obiectele care participă într-o interacţiune există atâta timp cât există şi
interacţiunea. Totuşi, în anumite interacţiuni, obiectele pot fi create şi/sau distruse în intervale de timp cuprinse
strict între începutul şi terminarea interacţiunii. La fel stau lucrurile şi în cazul legăturilor dintre obiecte. Pentru a
indica faptul că un obiect sau o legătură intră într-o interacţiune şi/sau părăseşte interacţiunea, putem ataşa
elementului vizat una din următoarele constrângeri:
 new - specifică faptul că instanţa sau legătura este creată pe timpul execuţiei inetracţiunii care o
include;
 destroyed - specifică faptul că instanţa sau legătura este distrusă înainte de terminarea execuţiei
interacţiunii care o include;
 transient - specifică faptul că instanţa sau legătura este creată pe timpul execuţiei interacţiunii care o
include, dar este distrusă înainte de terminarea execuţiei.
În sfârşit, dacă într-o interacţiune, un obiect suportă modificări ale valorilor atributelor lui, modificări de
stare sau de rol, fiecare variantă a obiectului poate apare pe aceeaşi linie a vieţii, variantele diferite putând fi,
eventual, conectate cu mesaje marcate de stereotipul become.

Reprezentarea unei interacţiuni

Am vazut deja faptul că o interacţiune pune probleme de semantică şi de notaţie. Din punct de vedere
semantic, o interacţiune poate pune accent pe ordonarea în timp a mesajelor (ceea ce ne conduce la realizarea de
diagrame de secvenţă) sau pe accentuarea organizării structurale în interiorul interacţiunii, 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 făcându-se fără
pierdere de informaţie.
Din punct de vedere al notaţiei este important să semnalăm prezenţa şi semnificaţia liniei vieţii unui obiect
într-o diagramă de secvenţă, element care oferă suport pentru reprezentarea în timp a existenţei unui obiect.
De asemenea, diagramele de colaborare permit modelarea legăturilor structurale care există între obiecte.
7.3 Contexte de utilizare
7.3.1 Elemente introductive
Deşi nu au explicitat întotdeauna acest lucru, specialiştii în ingineria softului au acţionat conform
principiului: „Înainte de a realiza un lucru nou, trebui să hotărăşti cum îl vei folosi (= care este valoarea lui
de întrebuiţare)”?
Pare de neconceput, dar adevărul este că multă vreme nu s-a sesizat importanţa covărşitoare a
problematizării şi formalizării temeinice a principiului mai sus formulat. Specificare de cerinţe s-a făcut, într-o
formă sau alta, dintotdeauna în industria softului. Ceea ce separă optica UML, în ceea ce priveşte specificarea
cerinţelor, de alte limbaje de modelare este „unghiul din care se face specificarea cerinţelor”. UML spune
răspicat: „înainte de a gândi la soluţia unui sistem soft, determină, cu maximum de acurateţe, tipul
utilizatorului acestui sistem soft”.
Încerc să sugerez faptul că tipul utilizatorului este o abstracţie în care se reflectă o serie de cerinţe
funcţionale specifice dar şi o serie de cerinţe aşa zis nefuncţionale. Un sistem soft „burduşit” cu cerinţe
funcţionale, expuse ignorând cele mai elementare reguli de proiectare a unor interfeţe ergonomice, nu va putea
înfrunta niciodată un sistem echivalent funcţional dar cu interfaţa ergonomică.
După cum sugerează şi perspectiva UML asupra arhitecturii unui sistem soft, în centrul efortului de
dezvoltare a soluţiei unui sistem soft, utilizând UML, se află perspectiva context de utilizare (use case).
Perspectiva context de utilizare va descrie comportamentul unui sistem soft aşa cum este el văzut de către „end-
user-i”, analişti şi „tester-i”.
Un element cheie în crearea contextelor de utilizare este abilitatea de a spune ce face contextul de utilizare
fără a specifica nimic despre implementarea lui. Astfel că putem concluziona faptul că un context de utilizare
specifică un comportament dorit (de end-user-i), fără a impune nimic relativ la modul în care va fi implementat
acest comportament. Marele câştig al unui astfel de demers constă în faptul că un context de utilizare permite, în
egală masură utilizatorilor finali şi experţilor în domeniu, să comunice cu specialiştii în ingineria softului, care
lucrează la soluţia sistemului soft, în cadrul căreia a fost specificat contextul de utilizare.
Pentru moment, un context de utilizare descrie un set de secvenţe, în care fiecare secvenţă reprezintă
interacţiunea entităţilor din afara sistemului (actorii lui) cu sistemul însuşi (şi abstracţiile lui eseţiale) . De
fapt, comportamentele astfel specificate sunt funcţii de nivel sistem, utilizate pentru a vizualiza, specifica,
construi şi documenta comportamentul scontat al sistemului în timpul fazei de identificare şi analiză a cerinţelor.
Un context de utilizare reprezintă o cerinţă funcţională a sistemului ca întreg. Ca un exemplu, un
context de utilizare important într-o firmă care produce automobile este Gestiunea vânzărilor.
Un context de utilizare implică interacţiunea dintre actori şi sistem. Un actor reprezintă un set coerent de
roluri, pe care utilizatorii contextului de utilizare le joacă în timp ce interacţionează cu acesta. Poate fi
actor o fiinţă umană, un alt sistem soft sau un anumit tip de sistem automat, capabil de interacţiune.
În majoritatea proceselor de dezvoltare a unor sisteme soft găsim contexte de utilizare care sunt versiuni
specializate ale altor contexte de utilizare, contexte de utilizare care sunt considerate ca părţi 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 reutilizării, apelăm la cele trei tipuri de relaţii, mai sus precizate:
generalizarea, includerea şi extinderea.
Un context de utilizare îndeplineşte, în mod normal, o sarcină concretă. Din perspectiva unui actor dat, un
context de utilizare poate efectua nişte calcule, poate furniza nişte rezultate, poate prelua nişte date de intrare,
etc.
Contextele de utilizare pot fi identificate la nivelul întregului sistem, dar şi la nivelul componentelor
sistemului (subsisteme, clase, interfeţe).
În fiecare caz este important să reţinem următoarea idee: „Contextele de utilizare reprezintă comportamentul
scontat al sistemului sau al componentelor acestuia, furnizând, în acelaşi timp, elemente fundamentale pentru
testarea acestor componente în timpul procesului de dezvoltare. Contextele de utilizare aplicate la nivelul
subsistemelor sunt surse ideale pentru testele desfăşurate asupra soluţiei î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ă notaţie
permite vizualizarea unui context de utilizare separat de realizarea lui şi în comuniune cu alte contexte de
utilizare. Fundamentele notaţiei aferente contextelor de utilizare sunt prezentate în Figura 7.6.
 actor context de
utilizare

Consultare
planuri de
invatamant

Decan
nume actor
nume context de utilizare

Figura 7.6. Notaţia UML pentru actori şi contexte de utilizare

7.3.2 Concepte UML din sfera contextelor de utilizare

După cum am menţionat deja, un context de utilizare este o descriere a unui set de secvenţe de acţiuni,
incluzând variante, pe care sistemul le execută pentru a produce un rezultat observabil, aşteptat 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 7.7.

nume simplu nume cu cale

Validare Financiar::PreluarePontaj
utilizator

Figura 7.7. 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ă când
interacţionează cu acesta. În mod obişnuit, un actor reprezintă un rol pe care o fiinţă umană, un dispozitiv
periferic sau chiar alt sistem îl joacă în relaţia cu sistemul căruia îi este asociat contextul de utilizare cu care
comunică actorul. De exemplu, un lucrător la o bancă ar putea, abstractizat ca actor, să joace rolul de Agent-de-
Împrumuturi; dacă, pe de altă parte, suntem interesaţi să abstractizăm rolul unui client în relaţia cu banca,
putem reflecta asupra unui actor numit Client. O instanţă a unui actor reprezintă o interacţiune individuală
specifică cu sistemul în cauză. Deşi în modelele UML apar actori, aceştia nu sunt consideraţi părţi ale sistemului,
fiind rezidenţi în afara sistemului. Reprezentaţi grafic sub forma unor omuleţi stilizaţi, actorii suportă, atunci
când este cazul relaţia de generalizare, ca în Figura 7.8.
Actorii pot fi conectaţi la un context de utilizare numai prin asociere. O asociere între un actor şi un context
de utilizare precizează faptul că între aceste entităţi există o relaţie de comunicare, în sensul că fiecare poate
trimite sau primi mesaje.
Să mai subliniem faptul că, apelând la mecanismele UML de extensie putem stereotipiza un actor pentru a
introduce o notaţie 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 făcut. În
general, în procesul de modelare a soluţiei unei probleme, este foarte importantă abilitatea de a distinge interfaţa
unui sistem ( ce face? ) de implementarea lui (cum face?).
 actor

Client
generalizare

actor

ClientPersoanaFizi ClientPersoanaJuridica
ca

Figura 7.8. Actorii în UML

Putem specifica comportamentul unui context de utilizare prin descrierea textuală a unui flux de
evenimente, suficient de clar pentru ca un neiniţiat să îl poată înţelege uşor. Când se redactează acest flux de
evenimente, trebuie să specificăm cum şi când începe şi se termină contextul de utilizare, când interacţionează
contextul de utilizare cu actorii şi ce obiecte sunt schimbate, fluxul principal de evenimente, precum şi fluxurile
alternative de evenimente.
Exemplificăm cu un scenariu asociat contextului de utilizare ValidareUtilizator, din cadrul unui sistem soft
care gestionează o reţea de bancomate.

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 apăsarea 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 excepţional de evenimente: Clientul poate anula o tranzacţie în

orice moment prin apăsarea butonului Cancel, fapt care restartează
contextul de utilizare. Într-o astfel de situaţie nu se efectuează nici o
modificare asupra contului Clientului.

Flux excepţional de evenimente: Clientul poate şterge codul PIN, în

orice moment care precede terminarea introducerii prin apăsarea tastei
Enter având astfel posibilitatea să reia introducerea codului PIN.

Flux excepţional de evenimente: Dacă Clientul introduce un cod PIN

invalid, contextul de utilizare este restartat. Dacă acest lucru se
întamplă de trei ori la rând, sistemul anulează întreaga tranzacţie,
împiedicând Clientul să mai interacţioneze cu bancomatul timp de 60 secunde .

Contextele de utilizare şi scenariile

În practică există obişnuinţa de a descrie, la început, textual, fluxul de evenimente asociat unui context de
utilizare. Pe măsură ce înţelegerea cerinţelor faţă de sistem se rafinează (=intră în detalii), se pot utiliza
diagrame de interacţiune pentru a specifica vizual acest flux de evenimente. De regulă, se poate apela la
diagrame de secvenţă pentru specificarea fluxurilor principale de evenimente şi variaţiuni ale acestor diagrame
pentru a specifica fluxurile excepţionale de evenimente ale unui context de utilizare.
Este de dorit să separăm fluxurile principale de fluxurile alternative deoarece un context de utilizare descrie
un set de secvenţe, 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 informaţional al unei instituţii de învăţământ superior poate include contextul de
utilizare ÎnmatriculareStudenţi. În practică, însă, se ştie că operaţia de înmatriculare se poate derula în mai
multe ipostaze:

1. Candidaţii admişi, în urma unei sesiuni de admitere, pot fi înmatriculaţi, la o anumită

specializare;
 2. Studenţii admişi la aceeaşi specializare în alte universităţi, pot fi înmatriculaţi, în anumite
condiţii;
3. Studenţii admişi la specializări înrudite ca profil, în aceeaşi universitate, pot fi înmatriculaţi, în
anumite condiţii, etc.
Este evident faptul că descrierea contextului de utilizare ÎnmatriculareStudenţi trebuie să ia în consideraţie
mai multe variante, fiecare variantă având asociată propria secvenţă de acţiuni. În acest caz, fiecare secvenţă se
numeşte scenariu. Vom numi scenariu o secvenţă specifică de acţiuni care ilustrează o variantă de
comportament a unui context de utilizare. Din altă perspectivă privind lucrurile, un scenariu este, în relaţia cu
contextul de utilizare gazdă, ceea ce este un obiect în relaţia cu clasa lui definitoare.

Contextele de utilizare şi colaborările

Aşa cum am menţionat deja, un context de utilizare reprezintă comportamentul unui sistem (al unui
subsistem, al unei clase sau interfeţe) în curs de dezvoltare, fără a specifica modul de implementare a
comportamentului. Există o explicaţie plauzibilă a acestui mod de a privi lucrurile: analiza sistemului, printre
ale cărui rezultate se află şi specificarea comportamentului acestuia, trebuie să facă abstracţie, cu bună
ştiinţă, de aspectele implementaţionale, pentru a feri astfel soluţia de efectele, previzibile, ale schimbărilor
la nivel implementaţional. La momentul potrivit, contextul, de utilizare va trebui, totuşi, să beneficieze de o
implementare şi în acest scop va trebui identificată familia de clase şi alte entităţi care, lucrând împreună,
implementează contxtul de utilizare. Această familie de elemente, incluzând atât structura statică, cât şi
structura dinamică este modelată în UML sub forma unei colaborări.
La nivel înalt de abstractizare , putem specifica explicit realizarea unui context de utilizare de către o
colaborare ca în Figura 7.9.

Gestiune Consultare
planuri planuri de
învăţământ

colaborare realizare context de utilizare

Figura 7.9. 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 inspiraţiei.

Organizarea contextelor de utilizare

Contextele de utilizare pot fi organizate prin gruparea lor în pachete, în acelaşi mod în care procedăm cu
clasele.
Organizarea contextelor de utilizare poate fi realizată şi apelând la relaţiile de generalizare, includere şi
extindere.
În esenţă, toate aceste tipuri de relaţii sunt utilizate pentru a partaja comportamente comune.

Relaţia de generalizare
Generalizarea între contexte de utilizare este asemănătoare generalizării dintre clase. Mai exact, aceasta
înseamnă că orice context de utilizare copil moşteneşte comportamentul şi semantica contextului de
utilizare părinte; copilul poate adăuga elemente de comportament noi sau poate suprascrie
comportamentul părintelui. De asemenea, părintele poate fi substituit de oricare dintre copii lui (dacă ne
exprimăm în termeni de instanţe).
De exemplu, în sistemul informaţional al unei bănci putem avea un context de utilizare Validare utilizator
(responsabil de verificarea identităţii unui utilizator). Putem, de asemenea, avea doi copii specializaţi ai acestui
context de utilizare (Verificare parolă şi Scanare retină). Fiecare dintre aceste două contexte se comportă la fel
ca Validare utilizator, putând fi aplicate oriunde apare Validare utilizator, în plus, fiecare putând adăuga
propriul comportament (primul, prin verificarea unei parole textuale, al doilea prin verificarea şablonului retiniar
unic al utilizatorului).
Notaţia pentru relaţia de generalizare este cunoscută de la generalizarea între clase.
Relaţia de includere
O relaţie 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 locaţie specificată în bază .
Contextul de utilizare inclus nu poate opera singur niciodată, ci doar instanţiat ca parte a unui context de utilizare
de bază, care îl include.
Folosim relaţia de includere pentru a evita descrierea aceluiaşi 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ă. O relaţie de includere se reprezintă ca o relaţie de dependenţă marcată cu
stereotipul include. În descrierea asociată contextului de utilizare de bază, includerea este marcată ca în
exemplul de mai jos.

Fluxul principal de evenimente:

Preluare nume utilizator şi parolă. include
(Validare parolă).
Configurare sesiune.
Start sesiune.

Relaţia de extindere
O relaţie 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 locaţie specificată indirect de
contextul de utilizare care realizează extinderea.
Folosim relaţia de extindere pentru a modela o parte a unui context de utilizare pe care utilizatorul o percepe
ca fiind un comportament opţional al sistemului. În acest mod, separăm comportamentul opţional de
comportamentul imperativ.
O relaţie de extindere este redată ca o relaţie 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 obişnuit 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.

7.4 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 hărţi de stare, diagramele de activitate). Diagramele de contexte de utilizare sunt
esenţiale 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 asociaţi lor, precum şi relaţiile
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 afişează proprietăţi comune altor tipuri de
diagrame: asocierea cu un nume şi un conţinut grafic care realizează un anumit tip de proiecţie într-un model.
Conţinutul grafic deosebeşte diagramele de contexte de utilizare de alte tipuri de diagrame.

Conţinutul unei diagrame de contexte de utilizare

În mod uzual, diagramele de contexte de utilizare conţin:
 Contexte de utilizare
 Actori
 Relaţii de dependenţă, generalizare şi/sau asociere.

Ca oricare alt tip de diagramă, ele mai pot conţine note şi constrângeri.
 În sfârşit, diagramele de contexte de utilizare mai pot conţine pachete, folosite pentru a grupa elementele
modelului în unităţi mai mari, cu scopul de a mări lizibilitatea modelului.
Uneori, diagramele de contexte de utilizare pot conţine şi instanţe ale contextelor de utilizare, îndeosebi
când dorim să vizualizăm un sistem specific de execuţie.

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 către un „tools” care „înţelege” modelarea UML.
Ingineria inversă este operaţia prin care, pornind de la cod, putem obţine modelul UML asociat.
Ambele operaţii urmăresc asigurarea unei mapări benefice a soluţiei UML a unei probleme, peste soluţia-
limbaj de implementare ţintă şi invers. Avantajele sunt evidente, atât în cazul ingineriei directe cât şi în cazul
ingineriei inverse.
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ă, având
corespondenţe la nivelul sistemului executabil), diagramele de contexte de utilizare sunt puţin diferite, în sensul
că ele mai mult reflectă decât 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 operaţii de inginerie directă sau inversă.

7.5 Diagrame de interacţiune

Diagramele de secvenţă şi diagramele de colaborare – numite, împreună, diagrame de interacţiune, sunt,
după cum am mai spus, două din cele cinci tipuri de diagrame folosite de UML pentru modelarea aspectelor
dinamice ale sistemelor.
Diagramele de interacţiune sunt importante nu doar pentru modelarea aspectelor dinamice ale unui sistem ci
şi pentru obţinerea codului executabil, atât prin inginerie directă cât şi prin ingineria inversă.

Conceptele vehiculate în procesul de elaborare şi

înţelegere a diagramelor de interacţiune
O diagramă de interacţiune expune o interacţiune, determinată de o mulţime de obiecte, împreună cu
relaţiile dintre ele, inlcuzând şi mesajele care pot fi schimbate între aceste obiecte.
O diagramă de secvenţă este o diagramă de interacţiune 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ă evoluţia în timp de-a lungul axei ordonatelor.
O diagramă de colaborare este o diagramă de interacţiune care pune accent pe organizarea structurală a
obiectelor care trimit sau recepţionează mesaje. Ca formalism de reprezentare, o diagramă de colaborare este o
colecţie de noduri şi arce.
Să mai precizez, în această fază a prezentării, faptul că, asemenea tuturor tipurilor de diagrame, diagramele de
interacţiune au un nume şi un conţinut grafic, care, de altfel, face distincţia între diagramele de interacţiune şi
alte tipuri de diagrame.

Conţinutul unei diagrame de interacţiune

În mod uzual, o diagramă de interacţiune conţine:

 obiecte
 legături
 mesaje

Atunci când este cazul, o diagramă de interacţiune mai poate conţine note şi constrângeri.

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 7.10, realizarea unei diagrame de secvenţă presupune, plasarea, pentru început, a obiectelor
care participă la interacţiune, în partea de sus a diagramei, de-a lungul axei absciselor, figurată simbolic.
 Obiecte

s:Student m:FoaieMatricola n:Note f:FluxFoiMatricole

<<create>>
Timpul return
setDatePer() prelNote(m)

insert(m)

<<destroy>>

linia vieţii

Figura 7.10. Diagramă de secvenţă

În mod normal, obiectul cel mai din stânga va fi obiectul care declanşează interacţiunea, urmat, spre dreapta,
de celelalte obiecte, în ordinea participării la interacţiune. 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 crescătoare a timpului în care sunt emise, obţinându-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 întâi, este vorba despre linia vieţii obiectului. O linie a vieţii unui obiect este o linie verticală
întreruptă, care reprezintă existenţa unui obiect de-a lungul unei perioade de timp. Majoritatea obiectelor care
apar într-o diagramă de interacţiune vor avea durata de viaţă cât timp există interacţiunea, prin urmare, aceste
obiecte vor fi aliniate în partea de sus a diagramei; pentru aceste obiecte linia vieţii acoperă toată verticala
diagramei, începând de la obiect în jos. Pot exista şi obiecte care sunt create pe timpul interacţiunii, la primirea
unui mesaj purtând marca stereotipului create. Pentru aceste obiecte linia vieţii începe din momentul
receptării mesajului (a se observa linia vieţii pentru obiectul m, în Figura 76). Obiectele pot fi distruse pe timpul
interacţiunii. Linia vieţii pentru un astfel de obiect se termină odată cu primirea mesajului purtând marca
stereotipului destroy, moment marcat prin prezenţa unui X lărgit, care punctează terminarea liniei vieţii (a
se observa linia vieţii pentru obiectul m, în Figura 7.10).
În al doilea rând, este vorba despre focalizarea controlului pe un obiect. Focalizarea controlului pe un obiect
este indicată printr-un dreptunghi înalt şi de lăţime mică, prin care se figurează perioada de timp în care un
obiect execută o acţiune, directă sau dintr-o procedură subordonată. Partea de sus a dreptunghiului coincide cu
startul acţiunii; partea de jos este asociată cu terminarea acţiunii şi poate fi însoţită de un mesaj de tip return
(cum se întâmplă în Figura 7.10, la terminarea acţiunii obiectului n; de observat şi forma particulară a săgeţii în
cazul unui mesaj de tip return).
Imbricarea focalizării controlului (datorită apelurilor recursive, apelului unei self-operaţii, etc.) poate fi
redată cu ajutorul unor dreptunghiuri desenate uşor la dreapta focus-ului părinte, ca în Figura 7.11.

print()

Figura 7.11. Imbricarea focalizării controlului

 În sfârşit, monopolizarea controlului de către o acţiune (în sensul că aceasta nu poate pasa controlul acţiunii
altui obiect) se indică, dacă se consideră necesar, ca un dreptunghi al cărui interior poate suporta efectul de
umbrire.

Diagrame de colaborare
O diagramă de colaborare pune accent pe organizarea obiectelor care participă la o interacţiune. După cum
se poate vedea şi în Figura 7.12, realizarea unei diagrame de colaborare poate începe prin reprezentarea
obiectelor care participă la interacţiune, în calitate de vârfuri ale unui graf. În al doilea rând, se adaugă legăturile
dintre obiecte, în calitate de arce ale grafului. În sfârşit, legăturile în cauză sunt îmbogăţite semantic prin ataşarea
de mesaje pe care obiectele le trimit sau le primesc.
În acest fel, persoana care urmăreşte o diagramă de colaborare beneficiază de indicaţii vizuale clare relativ
la fluxul de control al interacţiunii, fără a pierde din vedere organizarea structurală a obiectelor care colaborează.

s:Student

1:<<create>>
2:setDatePers()

2.3:insert(m) <<global>>
m:FoaieMatricola f:FluxFoiMatricole

2.3.1:<<destroy>>

2.1:prelNote(m)
2.2
<<global>
n:Note >

Figura 7.12. Diagramă de colaborare

Diagramele de colaborare au două caracteristici care le deosebesc de diagramele de secvenţă. Mai întâi, este
vorba de indicarea modului în care un obiect este legat de altul (=calea de acces la obiect).
În acest scop, putem ataşa legăturii un stereotip de cale la capătul unei legături, indicând natura vizibilităţii
obiectului vizat, pentru obiectul care expediază mesajul. În Figura 7.12, f este global pentru m, de exemplu.
În al doilea rând, este vorba de sistemul de secvenţare prin ataşare de numere de secvenţă explicite. Pentru a
specifica ordonarea în timp a mesajelor, mesajul este prefixat cu un număr (începând cu mesajul numărul 1),
incrementând cu o unitate prefixul fiecărui mesaj nou (2,3,...).
În situaţia î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 oricâte nivele dorim. După cum se vede şi în
Figura 7.12, de-a lungul aceleeaşi legături putem reprezenta mai multe mesaje (eventual cu direcţii de expediere
diferite) dar având numere de secvenţă unice.
De cele mai multe ori, în practică modelăm fluxuri de control secvenţiale. Atunci când este cazul , putem
modela şi fluxuri de control mai complexe (iteraţii sau ramificări). O iteraţie înseamnă o secvenţă repetată de
mesaje. Pentru a modela o iteraţie, trebuie să prefixăm numărul de secvenţă al mesajului cu o expresie iteraţie de
tipul [i:=1..n] sau, pur şi simplu * dacă dorim să semnalăm prezenţa iteraţiei fără a specifica alte detalii.
O iteraţie indică faptul că mesajul vizat şi orice mesaj imbricat vor fi repetate în conformitate cu expresia
asociată iteraţiei.
Pentru a indica mesaje cu execuţie condiţionată, mesajele în cauză pot avea numărul de secvenţă prefixat cu
o clauză de condiţie, de tipul [x0]. Un mesaj alternativ va avea acelaşi număr de secvenţă, dar prefixat de o
condiţie în relaţia de SAU EXCLUSIV cu celelalte mesaje având acelaşi număr de secvenţă.
UML nu impune o anumită sintaxă pentru expresiile din interiorul parantezelor drepte. Putem folosi
convenţii pseudocod sau sintaxă specifică unui anumit limbaj de programare.
 Scurtă notă relativ la ingineria directă şi inversă a diagramelor de interacţiune.
Ingineria directa (=obţinerea codului pornind de la model) este posibilă pentru ambele tipuri de diagrame
de interacţiune, îndeosebi, atunci când contextul diagramei este o operaţie. Cantitatea şi acurateţea codului
generat depinde atât de „inteligenţa” softului care procesează modelul (în cazul nostru diagrama de interacţiune)
cât şi de cantitatea şi acurateţea informaţiei conţinută de model.
Este previzibil faptul că ne aflăm într-un stadiu de abstractizare în care mai sunt încă mulţi paşi de făcut
pentru a mapa eficient modelul pe codul care îl implementează.
Ingineria inversă (=crearea modelului pornind de la cod) este, de asemenea, posibilă, pentru ambele tipur i
de diagrame de interacţiune, îndeosebi atunci când codul în cauză este implementarea unei operaţii.

7.6 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 situaţii, aceasta înseamnă modelarea paşilor secvenţiali (uneori concurenţiali) 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 societăţi de obiecte sau pentru a modela fluxul de control specific unei operaţii. În vreme
ce diagramele de interacţiune 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 urmăreşte trecerea, într-o
anumită ordine, de la o activitate la alta. Prin activitate desemnăm o prelucrare neatomică, în curs de
desfăşurare în interiorul unei maşini cu stări. Calculatoarele reale sunt exemple remarcabile de maşini cu
stări, privite, de exemplu, din punct de vedere al modului în care funcţionează procesorul. Ideea de neatomic
subliniază faptul că din punct de vedere al maşinii cu stări pe care se mapează activitatea, aceasta poate fi
descompusă. În ultimă analiză, activităţile sunt secvenţe de acţiuni atomice (neîntreruptibile din punct de vedere
al modului în care funcţionează maşina cu stări) care au ca rezultat schimbări î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
activităţi. Am menţionat deja ce se înţelege prin activitate şi prin acţiune.
Din punct de vedere al reprezentării, o diagramă de activitate poate fi privită ca o colecţie de noduri şi arce.
Pentru conformitate, să menţionăm şi faptul că o diagramă de activitate, asemenea celorlaltor tipuri de
diagrame, are un nume şi un conţinut grafic specific.

Conţinutul unei diagrame de activitate

În mod vizual, o diagramă de activitate conţine:
 stări de activitate şi stări de acţiune;
 tranziţii;
 obiecte.
În esenţă, o diagramă de activitate este o proiecţie a elementelor care pot fi găsite într-un graf de activitate, care este un caz particular
de maşină de stare, în care toate tranziţiile sunt declanşate de terminarea activităţiilor în starea sursă.

Deoarece o diagramă de activitate este un gen de maşină de stare, va avea toate caracteristicile unei maşini
de stare. Aceasta înseamnă că diagramele de activitate pot conţine stări simple şi compuse, ramificări (specifice
unor prelucrări secvenţiale sau paralele), etc.
Evident, asemenea tutror celorlaltor diagrame, diagramele de activitate mai pot conţine şi constrângeri.

Stări de acţiune şi stări de activitate

În fluxul de control modelat de o diagramă de activitate, se întâmplă diferite lucruri. Se pot evalua expresii
pentru a seta valorile unor atribute sau pentru a returna o valoare. Se poate apela o operaţie a unui obiect, se
poate trimite un semnal unui obiect, se poate crea sau distruge un obiect.
Aceste operaţii atomice, executabile pe un calculator real, se numesc stări de acţiune deoarece sunt
stări ale sistemului, fiecare dintre ele reprezentând execuţia unei acţiuni.
O stare de acţiune se reprezintă ca în Figura 7.13.
Stările de acţiune nu pot fi descompuse. Mai mult chiar, stările de acţiune sunt atomice, ceea ce, la modul
consistent, înseamnă că chiar dacă apar evenimente, ele nu pot fi întrerupte.
 Selectare etaj I:=I+1

acţiuni simple Expresii

Start V[I]:=I+10

Figura 7.13. Stări de acţiune

Pe de alta parte, stările de activitate pot fi, ulterior descompuse, activitatea lor putând fi reprezentată de alte
diagrame de activitate. Stările de activitate nu sunt atomice, ceea ce înseamnă că pot fi întrerupte şi execuţia lor
are durată în timp.
După cum se vede în Figura 80, nu există deosebire de notaţie esenţială între stările de acţiune şi activitate,
cu excepţia faptului că starea de activitate poate conţine elemente adiţionale, precum: acţiunile iniţiale şi finale
sau specificările de submaşini.

Tranziţiile
În momentul în care o acţiune sau o activitate este terminată fluxul de control este preluat de următoarea
acţiune sau activitate. Trecerea de la o stare la alta se numeşte tranziţie şi se reprezintă ca o linie simplă
orientată (a se vedea Figura 7.14).
Semantic vorbind, acest gen de tranziţii, se numesc tranziţii fără declanşator sau de terminare, deoarece
controlul trece de la starea sursă la starea destinaţie de îndată ce acţiunea/activitatea din starea sursă este
terminată.

starea de start

tranziţii
stări de acţiune

starea finală

Figura 7.14. Reprezentarea tranziţiilor în UML

În momentul în care acţiunea unei stări sursă date este terminată, se va executa acţiunea specifică ieşirii,
dacă există vreuna. După care, necondiţionat, are loc tranziţia către următoarea acţiune sau activitate. Urmează
executarea acţiunii specifice intrării în noua stare (dacă există) şi executarea acţiunii/activitaţii asociate noii stări,
etc. Există situaţii în care fluxul de control evoluează nedefinit, dar există şi foarte multe situaţii în care acesta
încetează la întâlnirea unei stări finale.
Notaţiile pentru starea iniţială şi starea finală pot fi observate în Figura 7.14.
Ramificarea (branching) şi unirea (merge)
Tranziţiile secvenţiale, simple, sunt destul de obişnuite, dar nu sunt singurele întâlnite în procesul de
modelare a fluxurilor de control. La fel ca în cazul schemelor logice (hărţile de fluxuri – flowchart-uri), putem
apela la ramificări pentru a specifica tranziţii alternative, ghidate de o anumită expresie booleană. O ramificare,
se introduce, din punct de vedere al notaţiei, ca un romb; poate avea o singură tranziţie la intrare şi două sau mai
multe tranziţii la ieşire. Pe fiecare tranziţie de ieşire se indică o expresie booleană, evaluată la intrarea în
ramificare. Evident, expresiile boolene asociate tranziţiilor care ies dintr-o ramificare (numite şi expresii de
gardă) trebuie să fie mutual exclusive. Un exemplu, în Figura 7.15.
Se mai adaugă şi faptul că simularea unei iteraţii este destul de simplă, folosind ramificarea.
Diagrama din Figura 7.15 poate fi completată, ca semantică şi din punct de vedere al notaţiei, ca în Figura
7.16.
 Do verificareCont(s)

ramificarea [else]
(branch, în engleză) Do afisareStareCont()

[există suma]
expresii de gardă

Do tranzactie(s)

Figura 7.15. Ramificarea într-o diagramă de activitate

unire (merge, în engleză)

Do verificareCont(s)

[else] [exista suma]

Do afisareStareCont() Do tranzactie(s)

Figura 7.16. Un exemplu complet de ramificare

Bifurcare (fork) şi imbricare (join)

Tranziţiile secvenţiale şi ramificările sunt elementele cel mai frecvent întâlnite în diagramele de activitate.
Cu toate acestea, atât în modelarea fluxurilor de lucru dintr-o organizaţie, cât şi în anumite tipuri de aplicaţii,
care mizează pe multitasking, apare problema fluxurilor de activităţi 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ă, îngroşată, după cum se vede şi în Figura 7.17, în care prezint un
exemplu dintr-o lucrare de licenţă a unui fost student.
Diagrama din Figura 7.17 ne indică posibilitatea ca activităţiile GătirePizza, PreparareSos şi
DestupareSticlăVin să se desfăşoare în paralel, deci sunt introduse folosind bifurcaţia. Dintre aceste trei
activităţi, care pot avea fire de execuţie paralele (ca să mai colorăm puţin expunerea), două dintre ele
(GătirePizza şi PreparareSos) trebuie să fie terminate înainte de a se trece la combinare (de aici necesitatea
primei îmbinări).
Tot în Figura 7.17 se mai observă şi posibilitatea, naturală, de altfel, de a introduce fire de execuţie
condiţionate.
Participarea la ospăţ poate să aibă succes şi cu sau fără vin, conform diagramei din Figura 7.17.
 bifurcaţia

GătirePizza PreparareSos [se doreşte vin]

DestupareSticlăVin
Combinare

îmbinări

Figura 7.17. Diagrama de activitate în cazul unui ospăţ bazat pe pizza

Teme pentru proiecte la disciplina Ingineria softului
1. Folosind sintaxa UML, specificaţi cerinţele faţă de un sistem soft care automatizează fluxurile
informaţionale ale unei case de schimb valutar.

2. Folosind sintaxa UML, specificaţi cerinţele faţă de un sistem soft care automatizează fluxurile
informaţionale ale secretariatului unei şcoli generale.

3. Folosind sintaxa UML, specificaţi cerinţele faţă de un sistem soft care automatizează fluxurile
informaţionale ale secretariatului unei facultăţi.

4. Folosind sintaxa UML, specificaţi cerinţele faţă de un sistem soft care automatizează fluxurile
informaţionale ale unei conferinţe ştiinţifice.

5. Elaboraţi diagrama claselor aferentă soluţiei UML a problemei automatizării fluxurilor informaţionale
ale unei case de schimb valutar

6. Elaboraţi diagrama claselor aferentă soluţiei UML a problemei automatizării fluxurilor informaţionale
ale secretariatului unei facultăţi.

7. Elaboraţi diagrama claselor aferentă soluţiei UML a problemei automatizării fluxurilor informaţionale
ale secretariatului unei şcoli generale.

8. Folosind sintaxa UML, să se reprezinte aspectele statice ale aplicaţiei care automatizează fluxurile
informaţionale ale unei case de schimb valutar.

9. Folosind sintaxa UML, să se reprezinte aspectele statice ale aplicaţiei care automatizează fluxurile
informaţionale ale secretariatului unei şcoli generale.

10. Folosind sintaxa UML, să se reprezinte aspectele statice ale aplicaţiei care automatizează fluxurile
informaţionale ale secretariatului unei facultăţi.

11. Elaboraţi arhitectura UML a soluţiei problemei informatizării unei universităţi.

12. Elaboraţii arhitectura UML a soluţiei problemei realizării unei librării virtuale care funcţionează pe
lângă o editură.

13. Elaboraţi arhitectura UML a soluţiei problemei realizării unui sistem de informare şi documentare care
funcţioneză pe lângă o primărie.

14. Elaboraţi arhitectura UML a soluţiei problemei informatizării fluxurilor informaţionale ale unui birou
notarial.
BIBLIOGRAFIE SELECTIVĂ
[1] Bennet, S., McRobb, S., Farmer, R., Object Oriented Systems Analysis and Design using UML, McGraw-
Hill Publishing Company, 1999

[2] Booch, G., Rumbaugh, J., Jacobson, I., The Unified Modeling Language User Guide, Addison-Wesley,
1999

[3] Booch, G., Object Oriented Design with Applications, The Benjamin/ Cummings Publishing Company,
Inc., 1991

[4] Fowler, M., UML Distiled, Second Edition, Addison Wesley, 2000

[5] Meyer, B., Object Oriented Software Construction, Prentice-Hall, 1997

[6] Priestley, M., Practical Object Oriented Design, McGraw-Hill, 1997

[7] Quatrany, T., Visual Modeling with Rationale Rose and UML,
Addison-Wesley, 1998

[8] Rumbaugh, J., Jacobson, I., Booch, G., The Unified Modeling Language Reference Manual, Addison-
Wesley, 1999
CUPRINS
1 Probleme a căror rezolvare depinde esenţial de ingineria sistemelor soft ....................................................... 3
1.1 Ce este ingineria sistemelor soft? .............................................................................................................. 3
1.2 Ce este un sistem soft? .............................................................................................................................. 4
1.3 Probleme cu care se confruntă specialiştii în IS ........................................................................................ 6
2 Ce este o metodologie de dezvoltare a softului? ............................................................................................ 12
2.1 De ce avem nevoie de MDS? .................................................................................................................. 12
2.2 Încercare de caracterizare a unei metodologii generice de dezvoltare a softului.....................................13
3 Ciclul de viaţă al unui sistem soft .................................................................................................................. 18
3.1 Ciclul de viaţă al sistemelor soft. Încă o introducere............................................................................... 18
3.2 Ciclul de viaţă al sistemelor soft. Câteva exemple. ................................................................................. 18
3.2.1 Modelul cascadă( MC)................................................................................................................... 19
3.2.2 Modelul V (MV)............................................................................................................................ 20
3.2.3 Modelul prototipizării (MP)........................................................................................................... 20
3.2.4 Concluzii........................................................................................................................................ 22
4 Abstractizarea soluţiei unui sistem soft ......................................................................................................... 24
4.1 Modelarea. Limbaje de modelare ............................................................................................................ 24
4.2 Arhitectura unui limbaj de modelare ....................................................................................................... 28
5 Modelarea obiect orientatĂ cu UML ............................................................................................................. 30
5.1 Ce este UML(fără a intra în detalii)?....................................................................................................... 30
5.2 Date esenţiale pentru înţelegerea UML ...................................................................................................31
5.3 Scurtă incursiune în universul conceptual al UML ................................................................................. 34
6 Modelarea aspectelor structurale. Elemente-suport fundamentale ................................................................ 41
6.1 Clase........................................................................................................................................................ 41
6.2 Relaţii ...................................................................................................................................................... 44
6.3 Mecanisme comune.................................................................................................................................45
6.4 Diagrame ................................................................................................................................................. 48
Introducere..................................................................................................................................................... 48
Diagrame structurale...................................................................................................................................... 49
Diagrame comportamentale........................................................................................................................... 50
Diagrame ale claselor ....................................................................................................................................50
7 Modelarea aspectelor comportamentale. Elemente-suport fundamentale...................................................... 54
7.1 Interacţiuni .............................................................................................................................................. 54
7.2 Concepte vehiculate în modelarea interacţiunilor ................................................................................... 54
7.2.1 Contextul în care se manifestă interacţiunile ................................................................................. 54
Obiecte şi roluri ............................................................................................................................................. 55
Legături.......................................................................................................................................................... 55
Secvenţare...................................................................................................................................................... 56
Crearea, modificarea şi distrugerea obiectelor............................................................................................... 57
Reprezentarea unei interacţiuni ..................................................................................................................... 57
7.3 Contexte de utilizare................................................................................................................................ 58
7.3.1 Elemente introductive .................................................................................................................... 58
7.3.2 Concepte UML din sfera contextelor de utilizare .......................................................................... 59
Numele contextelor de utilizare ..................................................................................................................... 59
Contextele de utilizare şi actorii .................................................................................................................... 59
Contextele de utilizare şi fluxurile de evenimente ......................................................................................... 59
Contextele de utilizare şi scenariile ............................................................................................................... 60
Contextele de utilizare şi colaborările............................................................................................................ 61
Organizarea contextelor de utilizare .............................................................................................................. 61
Relaţia de generalizare...................................................................................................................................61
Relaţia de includere ....................................................................................................................................... 62
Relaţia de extindere ....................................................................................................................................... 62
7.4 Diagrame de contexte de utilizare ........................................................................................................... 62
Concepte UML utilizate în sfera diagramelor de contexte de utilizare.......................................................... 62
Conţinutul unei diagrame de contexte de utilizare......................................................................................... 62
Scurtă notă, relativ la ingineria directă şi inversă a diagramelor UML ......................................................... 63
7.5 Diagrame de interacţiune......................................................................................................................... 63
Conţinutul unei diagrame de interacţiune ...................................................................................................... 63
Diagrame de secvenţă ....................................................................................................................................63
Diagrame de colaborare .................................................................................................................................65
 7.6 Diagrame de activitate............................................................................................................................. 66
Conţinutul unei diagrame de activitate .......................................................................................................... 66
Stări de acţiune şi stări de activitate............................................................................................................... 66
Tranziţiile ...................................................................................................................................................... 67
Teme pentru proiecte la disciplina Ingineria softului....................................................................................... 70
BIBLIOGRAFIE SELECTIVĂ ......................................................................................................................... 71
CUPRINS ............................................................................................................................................................ 72