Universitatea TRANSILVANIA din Braov

Facultatea de Matematic i Informatic

Catedra de Informatic Aplicat

INGINERIA SOFTULUI

Dorin Bocu

REPROGRAFIA UNIVERSITII TRANSILVANIA DIN BRAOV

Cuvnt nainte
Dei relativ nou, lumea informaticii impune respect prin problemele formulate,
conceptele i teoriile dezvoltate pentru rezolvarea acestor probleme.
Fundamentarea teoretic a universului informaional aflat n zona de impact cu
calculatorul este un exemplu de demers n spiral a crui dinamic i profunzime este greu de
egalat n alte domenii.
Permanenta schimbare a infrastructurilor informaionale orientate pe calculator
menine la cote de alert maxim efortul de redefinire a paradigmelor teoreticoaplicative din lumea softului.
Aproape toate tipurile de activitate uman pot fi organizate i desfurate cu totul altfel n
prezena calculatorului. Motivul acceptrii calculatorului n preajma omului sau n locul
acestuia? Operativitate, precizie, obiectivitate.
Despre consecinele n plan estetic i moral ale rtcirii omului n sofisticata jungl a
universului informaional planetar (n curs de configurare) este, probabil, prematur s
discutm i nici nu ne propunem aa ceva n aceast lucrare.
Desprinderea omului de condiiile 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 gnduri.
Din aceast uria epopee a desprinderii omului de natur ne propunem s analizm 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 uriae are toate ansele s dureze deoarece multe
dintre abilitile omului sunt greu de modelat i, spre deliciul cercettorilor, unele dintre ele
aproape insurmontabile.
Aceast lucrare ncearc un lucru destul de dificil (innd cont de marea diversitate a
abordrilor n literatura de specialitate) i anume identificarea bazelor ingineriei sistemelor
soft.
Adresndu-se indeosebi studenilor de anul III de la specializarea informatic, dar i
tuturor celor interesai de tiina i, n egal msur, arta de a realiza sisteme soft, prezenta
lucrare poate fi nceputul unui drum lung, uneori complicat i, de ce nu, interesant.

Braov
27 noiembrie 2007

1 PROBLEME A CROR REZOLVARE DEPINDE

ESENIAL DE INGINERIA SISTEMELOR SOFT
1.1 Ce este ingineria sistemelor soft?
Mai nti, s observm frecvena destul de mare cu care ntlnim sau vom ntlni sintagma ingineria
softului. Pentru comoditate o voi nota, prescurtat i IS.
Din dorina de a nchega repede un dialog cu cititorul, anticipez c:
Ingineria softului este o ramur a tiinei calculatoarelor, n permanent evoluie, care fundamenteaz
teoretic o parte din activitile specifice realizrii sistemelor soft.
Spunem o parte deoarece realizarea unui sistem soft are, de regul, n spate, cunotine din multe alte
ramuri ale tiinei calculatoarelor precum i din alte domenii (algoritmic, programarea calculatoarelor, limbaje
formale, cercetri operaionale, psihologie, teoria general a sistemelor, etc.).
Tentant i interesant problema definirii riguroase a sintagmei tiina calculatoarelor.
Autorul acestei lucrri 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 specificrii limbajelor de programare, problematica limbajelor de
programare, bazele contructive ale sistemelor de calcul (un domeniu de mare complexitate i cu o dinamic
remarcabil), inteligena artificial (un domeniu n care cutrile 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 reea, etc.
Este clar, sper i pentru cei care nc mai vd n informatic un exerciiu de utilizare inspirat a tastaturii,
faptul c tiina calculatoarelor este variat ca preocupri, solicit intens intelectul i, nc un amnunt
important, viteza cu care afirmaiile din informatic devin istorie este mult mai mare dect viteza cu care
se ntmpl acelai lucri n fizic, sau matematic, de exemplu.
Care sunt, totui, acele activiti specifice realizrii sistemelor soft care cad sub incidena IS?
Le putem rezuma astfel:
10 Abstractizarea soluiei unui sistem soft, prin care desemnm demersul conceptual n urma cruia
specialistul n IS trece de la enunul problemei la soluia acesteia.
20 Organizarea procesului de abstractizare (modelare) a soluiei unui sistem soft. ndeosebi n cazul
sistemelor soft de complexitate mare i medie modul de organizare a efortului de modelare poate influena
hotrtor calitatea unui sistem soft.
30 Reprezentarea soluiei unui sistem soft de-a lungul ntregului proces de modelare; documentarea
complet a soluiei sistemului soft.
Este vorba, n esen, de rezolvarea eficient a unor probleme de comunicare ntre participanii 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 obinut n timp util?.
IS ncearc (n diferite chipuri i de mai mult timp) s ne nvee cum poate deveni realitate acest slogan.
Modalitatea prin care IS rezolv aceast problem este (simplificnd lucrurile) propunerea de metodologii
de dezvoltare a softului (MDS).
Istoria MDS este lung i destul de dificil de sintetizat fr a omite numeroase aspecte interesante. Firul
cluzitor al acestei istorii ar putea fi, totui, definit astfel:
10 Fiecare metodologie dorete s instaureze o anumit rigoare n procesul de elaborare a soluiei 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 dorete s ofere suport ct 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 neaprat productivitatea specialitilor n IS. n jurul marilor firme productoare de soft se
cristalizeaz, progresiv, elemente i idei cu ajutorul crora 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.
Schematiznd, avem situaia din Figura 1.1, adic un fel de circuit al apei n natur. Privind mai atent,
ns, observm c este vorba de un proces cu conexiune invers pozitiv care, pe termen lung, are ca scop
optimizarea suportului de care au nevoie specialitii n IS pentru a realiza sisteme soft.
Astfel se prezint IS dac privim lucrurile din avion. n realitate situaia este mult mai complex. Acest
fapt va iei la iveal n cele ce urmeaz, cnd aplicnd descompunerea top-down n conjuncie cu un permanent
efort de abstractizare, vom nelege mai bine structura i specificul unui demers IS.
Firme/Persoane implicate n
realizarea de sisteme soft

Idei, cerine, soluii

pariale noi

Laboratoare de cercetare
MDS nou

Figura 1.1 Binomul cercetare-aplicaii n evoluia MDS

1.2 Ce este un sistem soft?

Destul de dificil un rspuns de tip definiie la aceast ntrebare deoarece diversitatea creaiior care
concureaz la calitatea de sistem soft este din ce n ce mai mare. Astfel, poate fi sistem soft un program
executabil, obinut 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, cnd vine vorba de tehnologiile soft de ultim or (ndeosebi cele promovate de Micro soft) noiunea
de sistem soft face fa unor conotaii cu totul remarcabile (DLL-urile, controalele OLE, obiectele programabile,
ali derivai ai tehnologiilor COM i DCOM, etc.).
Evident, se poate ncerca, pentru a face mai mult ordine n prezentare, o clasificare a aplicaiilor
recunoscute de platforma Microsoft/Win32. Aceste tipuri de aplicaii sunt:
aplicaia de tip consol; este aplicaia care aduce n lumea Windows caracteristicile de baz ale unei
aplicaii cu interfa orientat pe text.
aplicaii Win32 tradiionale; o astfel de aplicaie are toate elementele care sunt prezente ntr-o aplicaie
Windows complet (fereastr de afiare, bar de meniuri, bar cu instrumente, bar de stare, etc.). O stfel de
aplicaie, spre deosebire de aplicaia de tip consol are mari disponibiliti de cooperare cu sistemul de
operare Windows.

biblioteci cu legturi dinamice (DLL-Dynamic Link Library); o bibliotec DLL este, n esen, o colecie
de funcii care pot fi apelate din alte module executabile Windows. Nu discutm aici motivele care au
generat specificarea acestei tehnologii de ctre specialitii de la Microsoft(dei acesta ar fi un foarte
interesant studiu de caz ntr-o lucrare pe teme IS). Important este c, realizarea unei biblioteci DLL este un
exerciiu deosebit att din punct de vedere al elaborrii soluiei tehnice ct i din punct de vedere al
programrii. Aceasta deoarece, mai mult dect ntr-o aplicaie Windows ordinar, realizarea unei biblioteci
DLL pune la ncercare abilitile specialistului IS n ceea ce privete definirea de interfee optimale pentru

funcii, specificarea/scierea de cod generic, specificarea/scrierea de cod reentrant, cunoaterea

particularitilor programrii sub Windows, etc..
Controalele ActiveX; sunt un gen de mini-aplicaii care pot fi ncapsulate n orice obiect de tip container.
Container poate fi fereastra cadru a unei aplicaii, sau un document HTML. Reprezentnd, de fapt,
extinderea tehnologiei OLE la cerinele universului INTERNET, ActiveX permite programatorilor s
sporeasc gradul de funcionalitate al programelor fr 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 specialiti n IS, n caz de convergen de interese cu acetia.

Am terminat, astfel, scurta trecere n revist a tipurilor de aplicaii suportate suportate de platforma
Windows. Evident, am pus n discuie elemente noi care ne-ar putea ajuta la definirea noiunii de sistem soft.
Continund mica noastr investigaie, ne putem ntreba dac un document HTML poate fi considerat sistem
soft? ntrebri asemntoare ne putem pune relativ la creaii precum: coleciile de fonturi utilizate de editoarele
de texte, aa zisele fiiere cu resurse promovate de mediile vizuale de programare, coleciile 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 definiie
viabil noiunii de sistem soft. Nu ar fi acesta singurul caz (Biblia opereaz cu noiunea de Dumnezeu fr s
ne-o defineasc. Cu toate acestea exist oameni care consider biblia o capodoper att din punct de vedere al
tipului de scriitur ct i din punct de vedere al modului de organizare a argumentaiei).
Contnd, mai ales pe valoarea ei didactic, propun urmtoarea definiie a noiunii de sistem soft.
Se numete 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 informaiilor ntr-un context
informaional dat.
Aadar, atributele eseniale ale unui sistem soft sunt:
10 Capacitatea de a fundamenta / realiza protocoale efective de prelucrare / comunicare a datelor /
informaiilor.
Exemple.
-MFC poate fundamenta protocoale efective de prelucrare / comunicare date i informaii;
-Un sistem expert realizeaz un protocol efectiv de prelucrare / comunicare date / informaii;
-Un document HTML realizeaz un protocol efectiv de prelucrare / comunicare date / informaii, 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 mprejurri,
de iniiativa n relaia cu mediul de interpretare sau de execuie a protocolului.
Ca un contraexemplu, o resurs Delphi, neintegrat ntr-un sistem complet de alte elemente ale unei aplicaii
Delphi, nu poate fi considerat sistem soft. Integrat, ns, poate fi considerat parte a unui sistem soft.
30 Protocolul opereaz ntr-un context informaional dat.
Nu prea avem motive s acceptm ca sistem soft o creaie IS care nu opereaz ntr-un context informaional
specific. Chiar dac nu este ntotdeauna evident, acest context informaional exist. De exemplu, un mediu vizual
de realizare a sistemelor soft este, el nsui, un sistem soft care opereaz cu un context informaional specific,
abstractizat de conceptele i principiile de utilizare a acestor concepte pentru a modela vizual soluia unei
probleme date.
Cititorul, mai mult sau mai puin avizat, ntrezrete, probabil, faptul c noiunea de sistem soft are un
coninut discutabil. Mai presus de orice discuie, ns, se afl faptul c n IS denumirea generic a produselor
finite este sistem soft.
Actualmente, omenirea triete un moment de cotitur din punct de vedere al modului de procesare a
informaiilor care o intereseaz. Acest moment de cotitur ar putea fi numit revoluie informaional.
Dup ce o mare parte din istoria omului a fost dedicat cuceririi redutelor substaniale i energetice, a
sosit timpul unor modificri importante n ceea ce privete valorificarea dimensiunii informaionale a tuturor
activitilor omului.
Diversificarea pe orizontal i pe vertical a produciei de sisteme soft nseamn modificarea permanent a
ofertei de tehnologii informaionale (TI), tot mai mult cerute de societatea informaional n curs de
cristalizare.
Circuitul producie TI - utilizare TI - redefinire cerine fa de TI producie TI are o dinamic a crei
trstur principal pare a fi efectul de autoaprindere.
Tvlugul informatizrii societii omeneti pare a fi n faza n care rostogolirea lui nu mai poate fi oprit
fr a prejudicia grav progresul metodelor de investigare i complexificare a realitilor substaniale i
energetice, fr s mai vorbim de cele informaionale.

Nu peste mult timp, o mare parte din locuitorii planetei vor fi nevoii s nvee meteugul utilizrii i
producerii TI.
Dup cum se poate observa i n alte domenii de activitate i n industria softului exist tendina de a:
-extinde permanent capabilitile interactive i de procesare ale sistemelor soft , innd cont de cerinele
concrete ale utilizatorilor dar i formnd la utilizatori obinuina de a nva tehnologii informaionale noi,
destinate modificrii comportamentului;
-crete sistematic calitatea sistemelor soft;
-diminua permanent costurile de producie.
Manifestarea efectiv a acestor trei tendine este posibil numai printr-un efort permanent de mbuntire a
elementelor suport n procesul de realizare a sistemelor soft.
Studiul critic al elementelor suport n procesul de realizare a sistemelor soft este de competena disciplinei
prezentat n literatura anglo-saxon sub denumirea Software engineering, care n limba romn s-ar traduce
convenabil prin Ingineria softului.
Dup ce am ncercat o scurt incursiune n lumea preocuprilor IS, voi prezenta, n continuare, o serie de
probleme care (de la nceputurile erei informaticii sau mai recent) menin treaz interesul specialitilor n IS
pentru regndirea permanent a paradigmelor.

1.3 Probleme cu care se confrunt specialitii n IS

Familiarizai oarecum cu ncrctura semantic de baz a noiunilor 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 evoluia IS .
De menionat faptul c i acesta este un subiect n care abordrile abund deoarece universul problemelor IS
poate fi analizat din mai multe puncte de vedere iar n interiorul unui punct de vedere utiliznd formalizme
diferite. De exemplu, problema elaborrii soluiei unui sistem soft poate fi discutat, la un nivel de formalizm
socotit convenabil, n scopul dezvoltrii abilitilor unui specialist n IS sau n vederea informrii exacte a
managerilor cu privire la particularitile i utilitatea unui astfel de demers.
Specialistul n IS vrea s nvee ct mai multe detalii despre arta de a realiza sisteme soft de calitate.
Managerul care se instruiete pe probleme de IS este interesat de cunoaterea invarianiilor unui astfel de
demers pentru a decide n cunotin de cauz modul n care, cu minimum de resurse se pot obine
maximum de rezultate (att pe termen scurt ct i, eventual, pe termen mediu sau lung) prin automatizarea
fluxurilor informaionale ale afacerii n conducerea creia este implicat.
Pentru a clarifica unele probleme de limbaj care ar putea s apar n continuare, s precizm faptul c n
literatura de specialitate anglo-saxon se consider c trei categorii de indivizi sunt foarte importani pentru
succesul sau eecul unui proiect de realizare a unui sistem soft. Aceste categorii sunt:
-utilizatorii direci (end-users) ai sistemelor soft;
-utilizatorii indireci (clients) ai sistemelor soft;
-specialitii n IS.
Probleme datorate perspectivei utilizator direct
Opernd la extreme, utilizatorul direct al unui sistem soft este sau un individ avnd afiniti cu lumea IS sau
un individ a crui cultur informatic este structurat, modest, n jurul abilitilor necesare pentru utilizarea
sistemului soft.
n primul caz este vorba de un utilizator a crui prere despre calitile 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 revendicrii pernanente:
sporirea interactivitii sistemului soft cu utilizatorul direct, promovnd mijloace de comunicare ct mai
ergonomice.
n mod evident, interactivitatea sistem soft-utilizator direct n sensul de mai sus presupune proiectarea i
realizarea efectiv a unor interfee ergonomice.
ntr-o interfa ergonomic, utilizatorul direct gsete funcionalitatea dorit de o manier care nu pune la
ncercare nici nelegerea, nici rbdarea i nici sntatea acestuia.
Practica a demonstrat i demonstreaz faptul c este o art s proiectezi interfee inteligibile, este o
sarcin mult mai complicat s realizezi interfee care rspund operativ i dau dovad de maxim
ngduin fa de capriciile utilizatorului direct; n sfrit, destul de pretenioas este i misiunea de a realiza
interfee care nu numai c nu duneaz facultilor psihice ale utilizatorului direct, ba chiar, ncearc
reconfortarea lor.
Muli factori care determin calitatea unui sistem soft (problem asupra creia vom reveni, pe larg, n acest
capitol) i gsesc o form de manifestare i n modul n care se exprim o interfa n relaia cu utilizatorul.
De exemplu, robusteea unui sistem soft, considerat un factor extern de calitate, msoar abilitatea unui
sistem soft de a rezista la iniiative din partea utilizatorului direct (transmise prin intermediul interfeei)
care depesc cerinele 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
strns deoarece soluia multora dintre problemele care pot s apar pe timpul realizrii unui sistem soft depinde
de acesta.
Utilizatorul indirect decide nceperea/nenceperea finanrii proiectului de realizare a unui sistem
soft; tot el este i cel care, n urma analizelor periodice cu privire la evoluia proiectului, poate decide
abandonarea/continuarea proiectului. Absolut trivial este faptul c ntr-o economie de pia fr finanare nu
se poate materializa nici o idee de proiect, orict de generoas i ambiioas ar fi aceasta . Acesta este
motivul pentru care managementul proiectului de realizare a unui sistem soft trebuie s trateze cu maximum de
profesionalism relaia cu utilizatorii indireci-variabile importante n ecuaia finanrii unui proiect.
Utilizatorul indirect i asum, n mod normal i rolul de furnizor de date cu privire la structura
proceselor informaionale modelate i, ca o prelungire fireasc, rolul de furnizor de elemente cu privire la
cerinele fa de sistemul soft n curs de realizare. Dac utilizatorul indirect nu i asum aceste dou roluri de
pe o poziie corect, specialistul n IS este n faa unei probleme al crei enun are geometrie variabil:
Utilizatorul indirect nu este capabil s descrie corect procesele informaionale modelate; cineva din echipa
de proiectare trebuie s fac acest lucru i, evident, nota de plat a proiectului se ncarc;
Utilizatorul indirect indic cerinele fa de sistemul soft derivate din poziia pe care el (utilizatorul
indirect) o are n ierarhia utilizatorilor indireci.
Apare, n acest fel, o problem nou i important pentru specialitii n IS, anume distilarea i asamblarea
viziunilor unilaterale ale utilizatorilor indireci pentru a obine o perspectiv sistemic asupra proceselor
modelate.
Utilizatorul indirect are, statistic vorbind, toate calitile unui om obinuit: poate face omisiuni, poate
emite judeci inconsistente, poate avea probleme n comunicarea datelor i informaiilor pe care le deine, etc.
Aceast posibilitate ar trebui s sporeasc semnificativ ncordarea cu care specialitii n IS culeg de la utilizatorii
direci date i informaii necesare evoluiei pozitive a proiectului.
Oricare ar fi situaia, specialitii n IS trebuie s acorde o atenie deosebit utilizatorilor indireci; prerea lor
fa de calitile unui sistem soft poate determina nmormntarea acestuia nainte de a se nate, sau asigurarea
condiiilor pentru ca sistemul soft s aib un ciclu de via pozitiv.
Noiunea 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 pn la soluia executabil pe calculator .a.m.d dac se pune
problema dezvoltrii, ntreinerii, etc.
Probleme generate sau descoperite de specialitii n IS
Nu este dect o confirmare a regulii faptul c IS este un univers ale crui probleme sunt inventate,
inventariate i rezolvate datorit dorinei specialitilor n IS de a optimiza procesul de realizare a sistemelor
soft.
Cele mai dificile probleme care pot apare n timpul realizrii unui sistem soft sunt, totui, problemele care
i au originea n laboratoarele IS sau se reflect n activitatea acestor laboratoare. Vom prezenta, n
continuare, enunul problemelor fundamentale pe care trebuie s le aib n vedere orice specialist n IS.
Pentru nenumrate 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:concepie, ealonarea n timp, reprezentarea
soluiei, 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 tendina multor specialiti n IS de a se exprima ignornd
protocoalele, normele, regulile adoptate de colectivele din care fac parte.
Este din ce n ce mai greu de inut evidena tipurilor de sisteme soft cunoscute, pentru a valorifica creator
experiena acumulat prin realizarea lor, specificnd MDS infailibile i atotcuprinztoare. Dei la ora actual au
fost edificate MDS care impresioneaz puternic prin obiectivele propuse i mijloacele de atingere a acestor
obiective, omul rmne n continuare singurul n msur s nsufleeasc aceste MDS sau s le adauge
capabiliti noi n situaii problematice deosebite (A se vedea, de exemplu, OM,T i UML, dou MDS relativ
recente, cu aspiraii interesante pentru orice gnditor care nelege lumea orientat pe obie cte).
Prin sistematizarea procesului de realizare a sistemelor soft se urmrete crearea unor condiii
avantajoase pentu gestiunea complexitii problemelor specifice unui proiect. Oferirea de suport pentru
gestiunea complexitii este benefic pentru diviziunea muncii (dac se lucreaz n echip) i calitatea soluiei.
Exist o mare varietate de abordri care propun i elemente suport explicite pentru gestiunea complexitii.
Dintre aceste abordri s enumerm i noi cteva 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 acelai: Soluia=o colecie de module care coopereaz pentru rezolvarea unei
probleme date.
Prin sistematizarea procesului de realizare a sistemelor soft se pun bazele reutilizrii efortului de
modelare, n anumite circumstane. Astfel, aa dup cum vom vedea, ndeosebi n Capitolele 2 i 4, soluia
unei probleme poate fi elaborat pe mai multe nivele de abstractizare, fiecare nivel fiind dedicat descrierii unor
proprieti specifice ale soluiei. Regulile de baz n organizarea unei soluii pe nivele de abstractizare pare
simpl: nivelul de abstractizare al unei soluii scade odat cu creterea infuziei de informaie static i
dinamic n soluie.
Creterea infuziei de informaie static i dinamic nseamn trecerea soluiei de la o arhitectur cu o
anumit stabilitate structural la o arhitectur cu stabilitate structural diminuat . Este o legitate care
poate fi combtut constructiv doar prin utilizarea unei scheme de rafinare a soluiei care s limiteze
diminuarea stabilitii structurale a nivelului de abstractizare.
Teoretic vorbind, cu ct avem mai multe nivele de abstractizare, cu att mai mic este efortul de
regndire a unui anumit nivel de abstractizare. Practic, ns trebuie gsit un compromis eficient ntre
numrul de nivele de abstractizare propuse i efortul depus de specialiti n IS pentru obinerea soluiei n
acest context.
Astfel stnd lucrurile, o soluie obinut, s spunem, pe trei nivele de abstractizare (conceptual, logic,
operaional, a se vedea Figura 1.2) are cea mai mic stabilitate la nivel operaional. Dac apar modificri care
afecteaz acest nivel (i ele sunt cele mai plauzibile), atunci soluia este regndit, refcnd, n principal, nivelul
operaional. Aceasta nseamn c soluia are o rezisten structurat la modificri i c specialitii n IS fac
reutilizare de efort de modelare n obinerea unei soluii.
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; dei nu sunt vizibile,
ntre aceste componente exist relaii foarte interesante pentru cineva care proiecteaz sistemul informaional al
unei afaceri.
Nivel conceptual
(Ce face sistemul soft)

Soluia conceptual

Nivel logic
(Cine, cnd i unde
execut prelucrrile)

Soluia logic

Nivel operaional
(Cum se efectueaz
prelucrrile)
Sistem soft operaional
Figura 1.2 Exemplu de ciclu de abstractizare a soluiei 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 sfrit, managementul
OPERATIV face tot ceea ce este necesar pentru a operaionaliza politicile stabilite de managementul TACTIC.
Nivelul operativ al managementului este supus, cu prioritate, schimbrilor atunci cnd se pune problema
adaptrii sistemului condus la condiii de performan noi.
Prin sistematizarea procesului de realizare a sistemelor soft se urmrete creterea permanent a
calitii acestora.
Este momentul s facem o scurt incursiune n semantica deosebit de complex a sintagmei calitatea
sistemelor soft.
Att n teorie ct i n practic se accept faptul c softul de calitate este rezultatul lurii n consideraie a o
serie de factori interni i externi procesului de configurare a soluiei finale a unui sistem soft.
n limbaj comun se vorbete despre necesitatea de a realiza sisteme soft fiabile, uor de folosit, structurate,
etc. Astfel de epitete asociate unui sistem soft caracterizeaz dou tipuri de proprieti ale sistemelor
soft:proprieti externe i proprieti interne.
Calitatea sistemelor soft i proprietile externe
Dintre proprietile externe care decid calitatea unui sistem soft, le considerm ca fiind foarte importante pe
urmtoatele:
-corectitudinea;
-robusteea;
-extensibilitatea;
-reutilizabilitatea;
-compatibilitatea;
-eficiena;
-portabilitatea;
-uurina 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
dect 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 greit) sau abandonat pentru a relua efortul de a gsi
o soluie care s aib, printre altele i atributul corectitudinii.
Dei se poate vorbi uor i mult despre corectitudine, este o prob de rezisten i de ndemnare
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 specialitii n IS adepi ai utilizrii unor limbaje cu suport natural n
specificare i proiectare.
Robusteea
Este abilitatea unui sistem soft de a reaciona adecvat n condiii anormale de utilizarea.
Este evident faptul c robusteea completeaz corectitudinea. n timp ce corectitudinea se refer la
comportamentul unui sistem relativ la o anumit specificare corect, robusteea apreciaz ce se ntmpl cu
sistemul soft n situaii care, n chiar procesul de specificare ar trebui identificate ca excepii.
Realizarea de sisteme soft robuste este o sarcin care ncepe n faza de specificare i se ntinde pn n faza
de programare. Pe acest traseu specialitii n IS trebuie s nfrunte dou clase mari de execpii:

Excepiile externe sistemului soft;

Excepiile interne sistemului soft.
Frontiera dintre aceste dou clase de excepii trebuie privit cu mult circumspecie deoarece, n realitate
este oricnd posibil ca, potenial, o excepie extern s induc o excepie intern i invers.
De asemenea, s mai observm c n timp ce excepiile externe pot fi nfruntate descurajnd iniiativele
nespecificate ale utilizatorului, problematica excepiilor interne este mult mai complicat.
n cazul sistemelor care gestioneaz relaia cu utilizatorul prin intermediul unei interfee cu o semantic
deosebit de complex, excepiile externe, nainte de a fi inhibate trebuie identificate.
Iat, deci, nc o problem de care specialitii n IS se lovesc dac doresc s scoat pe pia sisteme soft
care rmn pe picioare la apariia unor excepii. Se poate formula i un fel de principiu relativ la odiseea
tratrii excepiilor ntr-un sistem soft:
n timp ce interfaa unui sistem soft i sporete receptivitatea fa de curiozitatea i comoditatea utilizatorilor,
efortul de tratare complex i corect a posibilelor excepii crete astfel nct poate deveni o problem care nu
poate fi rezolvat dect prin metoda aproximaiilor succesive.
Este cazul sistemelor de operare, de exemplu, a cror robustee este, adeseori, rezultatul unui proces de
ajustare pe banii i pe rbdarea diferitelor categorii de utilizatori.
Extensibilitatea
Este abilitatea unui sistem soft de a se adapta uor la modificri n faza de specificare
Problema extensibilitii este o problem de situare pe scala complexitii: programele mici sunt uor de
modificat; sistemele soft din ce n ce mai mari devin tot mai dificil de adaptat la modificri. Rmnnd n sfera
afirmaiilor valabile, dar generale, putem aduga c dou principii sunt utile n realizarea de sisteme soft
extensibile. Acest principii sunt:
Simplitatea proiectrii
Ideea de baz este c o arhitectur simpl este ntotdeauna mai uor de modificat dect o arhitectur
complex. Inevitabil, ns, vine ntrebarea: cnd spunem c un sistem soft are o arhitectur simpl? Un
rspuns complet i precis la aceast ntrebare nu ncape n paginile acestei cri. Simplitatea este un deziderat
urmrit de orice creator care se respect. Faptul c exist destule creaii ale omului care uimesc prin dificultatea
cu care i transmit mesajul (inepii literare, subproduse cinematografice, discursuri politice sterile, etc.)
dovedete caracterul imprevizibil al modului n care un creator ajunge s opereze cu avantajele simplitii n
munca sa. Nu se poate algoritmiza obinerea simplitii pentru c, n forma ei cea mai nalt de exprimare, este
sinonim cu creaia. O creaie plsmuit cu talent va provoca ntotdeauna exclamaii de genul:Ce simplu era!,
Foarte uor de neles!, Nici c se putea mai bine!, Cum de nu mi-a trecut prin cap?!, etc.
O creaie plsmuit doar pentru a umple fizic unul din multele goluri care exist n viaa oamenilor
provoac exclamaii de tipul:Doamne, ce mbcseal!, Nu neleg mai nimic!, Mai bine lips!, Aa ceva
puteam i eu s fac!, etc.
Nu este pierdere de vreme s urmrim simplitatea i n IS. Doar c, i aici, obinerea ei cere timp, pentru a
lefui soluia unei probleme, astfel nct s putem obine un sistem soft care este, cel puin:
-lizibil;
-corect modularizat;
-eficient n timpul execuiei.
Sunt nenumrate motive, ns, pentru care n IS se sacrific simplitatea, asigurndu-se, de exemplu,
corectitudinea i robusteea. Enumerm cteva dintre aceste motive: necesitatea scurtrii termenelor de execuie,
modificarea paradigmelor de modelare, modificarea limbajelor de programare, modificarea sistemelor de
operare, creterea puterii de calcul a sistemelor hard (frecven de lucru foarte mare+ dimensiuni, de vis altdat,
ale memoriei RAM).
Descentralizarea
Dac extensibilitatea este dorit cu orice pre i poate c nu exist suficient timp pentru a obine un sistem
soft cu arhitectur simpl, atunci mai avem un punct de sprijin n descentralizare: cu ct autonomia modulelor
care compun sistemul soft este mai mare cu att mai mare este probabilitatea ca o schimbare simpl s afecteze
un numr redus de module.
Reutilizabilitatea
Este abilitatea componentelor unui sistem soft de a putea fi utilizate la dezvoltarea mai multor aplicaii
diferite.
Necesitatea reutilizrii unor componente soft se ntemeiaz pe observaia c, adeseori, sisteme soft diferite
pot fi construite pe baza unor soluii-ablon similare. Promovarea sistematic a reutilizrii influeneaz ali
factori de apreciere a calitii 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 aplicaii, potenialul 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 msur a uurinei cu care componentele unui sistem soft se combin cu alte componente pentru a
forma aplicaii noi.
Firete, compatibilitatea este important deoarece, n general, sistemele soft nu pot fi dezvoltate n vid; ele
vor interaciona cu alte sisteme soft.
Secretul compatibilitii se afl n omogenitatea proiectrii i n acceptarea unor standarde de
comunicare ntre programe.
Aadar, pentru a realiza sisteme soft compatibile, efortul de proiectare trebuie s ia n calcul i cele dou
cerine formulate mai sus. Comunitatea IS nu se poate mndri cu impunerea unor standarde i principii de
detaliu n acest sens. Exist fani Windows care promoveaz tehnologiile, trebuie s recunoatem remarcabile,
ale Microsft-ului. Exist, ns, i fani Linux care promoveaz propriile lor idei i tehnologii n ceea ce privete
caracteristicile mediilor de dezvoltare a sistemelor soft. Am dat dou exemple de medii de dezvoltare a
softului. Mai sunt nenumrate altele al cror istoric nu este momentul s l facem; raiunea lor de a fi este
urmtoarea:
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 crescnd ntre sistemele soft.
Este destul de dificil de fcut o predicie relativ la dezvoltarea prghiilor de compatibilizare a sistemelor soft
n viitor. Actualmente, lumea aplicaiilor Internet se prefigureaz ca un cmp de desfurare a unor
btlii importante pentru noua fa a universului IS. Este nevoie de timp, rbdare i efort susinut pentru a
gsi noi formule de specificare a proprietilor fundamentale ale sistemelor soft, printre care se afl i
compatibilitatea.
Eficiena (Performana)
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 softiti care fac o pasiune din optimizarea permanent a sistemelor la care lucreaz. Din
minile unor astfel de specialiti ies adevrate bijuterii din punct de vedere al performanelor. Preul pltit
mpingnd performana dincolo de un anumit prag logic este, n principal, diminuarea portabilitii softului
respectiv. ntr-o lume care viseaz la compatibilizarea sistemelor soft este greu de crezut c portabilitatea poate
fi sacrificat.
Exist i softiti care gndesc astfel: S facem sistemul soft corect nainte de a fi eficient cu orice
pre. Un astfel de slogan merge n aplicaiile n care absena performanei nu este critic pentru funcionarea
softului, mizndu-se pe un fapt absolut real n ultima vreme: Eficiena poate fi obinut pe seama progreselor n
materie de tehnologii hard. Ca de obieci, adevrul trebuie s fie undeva la mijloc, ceea ce nseamn c
specialistul IS trebuie s stpneasc arta de a obine performana cerut cu minimum de cheltuieli de resurse.
Portabilitatea
Este o msur a uurinei 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.
Esena acestei probleme const n faptul c orice sistem soft, ajuns n faza executabil, pe un calculator real,
trebuie s se neleag cu calculatorul respectiv. Aceasta nseamn c un cod execuatbil are o anumit structur
i instruciunile pe care le conine sunt recunoscute de procesorul mainii gazd. Structura codului executabil
este important pentru sistemul de operare, care supervizeaz ncrcarea codului executabil n memorie i
execuia acestuia, pas cu pas.
Uurina n folosire
Se refer la modul n care oameni cu diferite nivele de instruire pot nva s foloseasc sistemul soft pentru
rezolvarea unor probleme reale. Se refer, de asemenea, la uurina instalrii i operrii sistemului soft.
nchei prezentarea proprietilor externe ale sistemelor soft cu precizarea c problematica proprietilor
interne (structurare, modularizare, obiect orientare, etc.) reprezint un capitol la a crui scriere nc se lucreaz,
neexistnd un consens deplin al specialitilor asupra modului de articulare a acestora ntr-o explicaie 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 consideraii, a zice cu pretenii 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 reete proprii au devenit adepi convini ai promovrii reetelor IS.
n acest paragraf vom inventaria o serie de probleme concrete de care, vrnd-nevrnd, specialistul n IS
(afiliat sau nu la o metodologie) se lovete.
Procednd astfel legitimm o stare de lucruri ntlnit i n alte domenii ale cunoaterii.
Structura discursului n IS este determinat att de cerine epistemologice specifice ct i de nevoia de
organizare a diferitelor forme de manifestare a existentului n procesul de realizare a sistemelor soft.
Evident, o parte din cerinele epistemologice specifice le-am surprins n Capitolul 1.
n acest paragraf vom ncerca s evideniem o parte dintre formele de manifestare a existentului n procesul
de realizare a sistemelor soft.
Trecerea de la enun la soluie, n cazul problemelor de complexitate mijlocie sau mare (n care, de regul, se
cere modelarea comportamentului unui anumit proces informaional) este problematic. Astfel, n forma iniial,
enunul problemei poate sesiza nite carene ntr-o activitate care pot fi eliminate prin utilizarea
calculatoarelor sau poate intui nite avantaje ntr-o activitate dac se apeleaz la suportul calculatoarelor .
n ambele cazuri, pentru a obine enunul complet al problemei se trece la analiza informaional a
problemei. Scopul acestei activiti este obinerea unui enun complet al problemei care cuprinde cerinele fa
de sistemul soft sub forma unei soluii cu nivel nalt de abstractizare.
Activitatea de analiz informaional este dificil i este primejdios ca, din diferite motive, s nu incluzi
printre cerine un anumit aspect informaional.
Dac s-a pus punct analizei informaionale, trebuie s se treac la elaborarea soluiei tehnice (un fel de
documentaie constructiv a sistemului soft). Dei elaborarea soluiei tehnice nseamn descrierea pn la detaliu
a componentelor sistemului soft i a legturilor dintre acestea, ceea ce nseamn infuzie treptat de elemente
concrete n soluie, n paralel se desfoar i activiti cu pronunat caracter de abstractizare (pentru a elimina
redundanele, pentru a optimiza prelucrrile, pentru a optimiza legturile dintre date, pentru a spori rezistena
sistemului la modificri, etc.).
De foarte multe ori se poate spune c obiectul analizei informaionale ca i obiectul activitii de obinere a
soluiei tehnice au afiniti cu nisipurile mictoare. Ce-i de fcut? Trebuie mult rbdare i abilitate pentru
a sesiza invarianii procesului ceea ce ar permite nceperea efortului de modelare.
n situaia n care calvarul obinerii soluiei tehnice a fost depit ncepe activitatea de transpunere a
soluiei tehnice n acord cu exigenele de sintaz, semantic i pragmatic specifice unui limbaj de programare.
N-a zice c nu exist nisipuri mictoare 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 spaial.
Dac la aceste elemente se adaug altele, precum: necesitatea reprezentrii soluiei pentru a fi neleas de
diferite categorii de utilizatori, necesitatea de a partaja anumite tipuri de resurse n procesul de elaborare a
soluiei 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 amnuntelor care alctuiesc specificul unei probleme n IS.
Pentru a nfrunta toate aceste probleme i multe altele, comunitatea specialitilor n IS a ncercat nc din
epoca de nceput a erei informaticii s ngrdeasc liberul arbitru n procesul de dezvoltare a softului, lsnd,
totui, loc de manifestare spiritului creator, prin iniiative de genul:
-studiul teoretic al proprietilor algoritmilor: formalizare a reprezentrilor; 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 informaionale (procedee de investigare, mod de
reprezenatare, concepte utilizate, etc.);
-elaborarea unor metode de elaborare a soluiei tehnice (Top-down, HIPO, Warnierr-Orr, etc.);
-dezvoltarea unor elemente suport pentru specialitii n IS (sisteme de documentare, generatoare de
programe, medii de dezvoltare a soluiei cu ajutorul calculatorului, etc.);

-specificarea unor procedee de cuantificare a muncii depuse de specialitii IS pentru realizarea

sistemelor soft;
-elaborarea unor metode de planificare a efortului de dezvoltare a sistemelor soft .
Acumulrile n direciile semnalate mai sus sunt impresionante; evoluia abordrilor n IS, att teoretice ct
i practice, seamn, metaforic vorbind, cu evoluia populaiilor n sistemele genetice; clauzit de legiti,
aparent stochastice, comunitatea specialitilor n IS produce generaii succesive de elemente suport n
dezvolatrea softului, le evalueaz, n practic, reine ceea ce este valoros n ele i promoveaz ca parte
component n generaiile urmtoare.
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, creaii ale specialitilor n IS puse
n slujba specialitilor n IS, cea mai mare parte din viaa 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 activiti specifice realizrii sistemelor soft.
Aceste activiti sunt:
-abstractizarea soluiei unui sistem soft (ASS);
-desfurarea n timp a (=organizarea) procesului de abstractizare a soluiei unui sist em soft (OPA);
-reprezentarea i documentarea evoluiei 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, convenii i reguli de operaionalizare a acestora, pentru a da
rspunsuri satisfctoare problemelor care apar n activitile de tip AAS, OPA, RDS, OMP.
S ncercm, n continuare, o serie de precizri relativ la semantica acestei definiii. (Despre pragmatica
acestei definiii, nc nu putem spune mare lucru. Dac am fi vorbit despre o metodologie anume, alta era situaia
n ceea ce privete pragmatica.)
Orice metodologie care urmrete priza la public trebuie s fac fa contradic iilor, inerente
pentru semantica binomului MDS-specialist n IS.
Una dintre contradicii se refer la dorina de a oferi un set relativ restrns de concepte, principii i reguli
de utilizare a acestora n opoziie cu aspiraia legitim a oricrui autor de MDS de a oferi sintax care s
permit descrierea unei semantici, ct mai bogat posibil.
Alt contradicie se refer la nclinaia spre formalizm a spiritelor riguroase n opoziie cu nclinaia spre
intuitiv a altora.
Nu n ultimul rnd (pentru c mai sunt i alte exemple) semnalez contradicia dintre necesitatea de a
standardiza mare parte a procesului de dezvoltare a sistemelor soft i nevoia de exprimare liber resimit
de unii specialiti. n alt plan ne ntlnim cu contradicia dintre nevoia de a crete productivitatea muncii i
necesitatea de a realiza sisteme soft de calitate.
Cei care specific MDS se strduiesc s menin echilibrul ntre aceste contradicii prin diferite mijloace.
De exemplu, referitor la prima contradicie, metodologia UML ofer o semantic foarte bogat cu ajutorul
unui set bine ales de concepte i principii, oferind i cteva mecanisme de extensie cu ajutorul crora semantica
metodologiei poate fi mbogit.
n ceea ce privete capacitatea unei MDS de a oferi suport pentru rezolvarea problemelor de tip
ASS, suntem datori cu o serie de precizri importante. Pentru o MDS recomandrile pe care aceasta le face
pentru a transforma enunul unei probleme de informatic n soluie executabil pe un calculator real, practic
definesc nsi substana metodologiei. Aceste recomandri desemneaz, conform literaturii de specialitate,
ciclul de abstractizare al unei MDS.
Pentru un specialist n IS prima ntrebare pe care i-o pune n faa unei probleme noi este destul de lung.
Cum s derivez din datele problemei o soluie, respectnd termenele de execuie, fr s dezamgesc
utilizatorul direct, ntmpinnd exigenele curente i de perspectiv ale utilizatorului indirect i, chiar
dac pare un pic utopie, fr s m stresez peste msur?.
Fr ndoial, o astfel de ntrebare poate avea o serie de conotaii etice, filozofice, etc. dar nu acestea l
preocup pe specialistul n IS.
Evideniind doar ingredientele eseniale ale unei probleme de IS, avem:
-Date
-Prelucrri
-Interfee
Toate aceste ingrediente exist n domeniul problemei n format utilizator.
n domeniul problemei, pentru descrierea soluiei se folosesc concepte pe care le neleg, probabil, oricare
dintre participanii la un proiect, dar, n orice caz, ar trebui s le neleag participanii din sfera utilizatorilor

i clienilor.La cellalt capt al balanei se afl domeniul soluiei n care se vehiculeaz concepte pe care le
nelesc specialitii n IS.
n format utilizator datele sunt organizate supralicitnd redundana, prelucrrile, fiind aplicate unor date n
care mustete redundana, nu sunt automat cea mai fericit alegere.
Tot att de delicat este i problema organizrii interfeelor deoarece n elaborarea acestora trebuie
gestionat optim contradicia dintre dorina de a oferi utilizatorului confort i pornirea natural a
specialistului n IS de a raionaliza interfaa 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 soluiei pentru probleme de genul:
-organizarea optim a datelor utilizate de un sistem soft;
-organizarea optim a prelucrrilor specifice unui sistem soft;
-organizarea pe principii ergonomice i de eficien a interfeelor unui sistem soft.
Suportul oferit pentru rezolvarea problemelor semnalate mai sus depinde de metodologie. Rmnnd la
ideea de metodologie generic, ar trebui s spunem c acest suport poate reprezenta un set de concepte,
principii i reguli de operaionalizare a acestora cu ajutorul crora se reprezint proprietile de un
anumit tip ale procesului n curs de modelare.
De exemplu, proprietile informaionale 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.
Proprietile comportamentale ale procesului pot fi descrise utiliznd modele capabile s surprind diferite
nuane ale dinamicii unui sistem.
Pare simplu, dar nu este aa. Pentru a obine o reprezentare ct mai exact a proprietilor informaionale i
comportamentale ale unui proces, trebuie s elaborm:
-modele care reprezint statica unui sistem;
-modele care reprezint dinamica unui sistem;
-modele care reprezint fluxurile informaionale ntr-un sistem
.a.m.d.
Altfel spus, sistemul modelat este privit din mai multe perspective, fiecare perspectiv permind descrierea
unui anumit tip de proprieti; laolalt, putem spune, fortnd puin lucrurile, perspectivele ne ajut s obinem o
imagine holografic asupra sistemului modelat. Pn unde merge acurateea acestei imagini?! Iat o ntrebare
cu mai mult de dou tiuri pentru cei care dezvolt softuri dar mai ales pentru cei care specific noi MDS.
n ceea ce privete 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, alturi de ciclul de abstractizare, o caracteristic fundamental a MDS.
Este evident faptul c, la detaliu, fiecare MDS are propria propunere de ciclu de via. Fcnd abstracie de
metodologie, o prim perspectiv asupra semanticii noiunii de ciclu de via o obinem n Figura 2.1.
Diagrama din Figura 2.1 surprinde elementele eseniale pe baza crora ncepe s aib sens noiunea de ciclu
de via.
Adevrul 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 modificri.

Analiza

Proiectarea

Implementarea

Testarea

Etape de dezvoltare
Figura 2.1. Coninutul generic al etapei de dezvoltare a unui sistem soft

Avnd 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 existena unei piee pentru un produs de uz general, fie c o anumit organizaie are
nevoie de un soft specializat, n mare msur aceast prim etap presupune mai degrab luarea unor decizii de
management i marketing dect abordarea unor probleme legate de studiul algoritmilor, de exemplu.
Dup luarea deciziei de dezvoltare a sistemului soft ncepe analiza propriu-zis, al crei scop principal este
identificarea necesitilor utilizatorului potenial al sistemului soft. De exemplu, n cazul unui produs de uz
general, care urmeaz a fi vndut pe o pia concurenial, trebuie stabilit un public int. Dac se construiete un
sistem soft de gestiune a stocurilor ce urmeaz a fi folosit n departamentul de aprovizionare al unei firme
constructoare de maini, atunci trebuiesc identificate necesitile i ateptrile celor care lucreaz n cadrul
acestui departament.
Unul dintre rezultatele formale ale etapei de analiz l reprezint un set de cerine 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 cerinele, acestea sunt transformate n specificaii tehnice. Ca un exemplu,
cerina ca accesul la datele sistemului s fie permis doar persoanelor autorizate se poate transforma n
specificaia c sistemul nu trebuie s rspund dect dup introducerea unei parole de exact unsprezece
caractere, confirmat de sistem.
Firete, se pot pune ntrebrile:
Care sunt regulile care guverneaz procesul de identificare i reprezentare a cerinelor fa de sistemul
soft?
i
Care sunt regulile care guverneaz domeniul de elaborare i reprezentare a specificaiilor tehnice?.
Rspunsul este simplu: metodologia ofer suport de tip ASS i suport de tip RDS care se folosete n aceast
etap a ciclului de via ct mai eficient cu putin.
Proiectarea
Este etapa n care soluia sistemului soft este specificat n detaliu.
n termeni generali vorbind, sistemul soft imaginat n etapa de analiz este descompus, progresiv, n
componente mai uor de modelat, numite, generic, module. Implementarea sistemelor complexe devine posibil
tocmai prin aceast descompunere modular. Astfel, mulimea detaliilor tehnice care trebuie luat n considerare
ar fi imposibil de stpnit. Proiectarea modular creeaz, totodat condiii pentru lucrul n echip i vine n
ntmpinarea efortului de ntreinere, dac acesta este reclamat.
Una dintre concluziile greu de combtut ale generaiilor de MDS poate fi formulat astfel:
O structur modular, chibzuit proiectat este benefic att pentru implementarea sistemului ct i
pentru modificarea sa ulterioar.
Probabil, acesta este unul dintre principalele motive pentru care modelarea orientat spre obiecte ctig tot
mai mult teren.
n faza de proiectare, ca i n cea de analiz suportul de tip ASS i RDS este esenial pentru a obine o
soluie tehnic de calitate.
Implementarea
Este etapa n care are loc scrierea efectiv a programelor, crearea fiierelor i, n consecin, dezvoltarea
bazei de date a sistemului soft astfel obinut.
Testarea
Este etapa strns legat de etapa anterioar deoarece, n mod normal, fiecare modul al sistemului este testat
n timpul implementrii.
ntr-un sistem bine proiectat (ceea ce ar face trimitere direct la o serie de posibili factori interni ai calitii
precum: decompozabilitatea modular, compozabilitatea modular, nelegerea modular, continuitatea modular
i protecia modular) fiecare modul poate fi testat n mod independent, utiliznd versiuni simplificate ale
celorlalte module pentru a simula interaciunea modulului int al testrii cu restul sistemului. Evident, pe msur
ce diferite module sunt finalizate i combinate, testarea individual face loc treptat testrii generale a ntregului
sistem.
Practica dovedete c testarea i complementara acestei activiti, care este depanarea, sunt, ndeosebi n
cazul sistemelor mari activiti greu de finalizat. Sistemele de mari dimensiuni pot conine foarte multe erori
chiar i dup efectuarea celor mai complexe teste. Multe erori pot rmne neobservate pe toat durata vieii
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 direcie mai sunt nc multe probleme de rezolvat.

n ceea ce privete capacitatea unei MDS de a oferi suport pentru rezolvarea problemelor de tip
RDS, putem, de asemenea, s facem o serie de consideraii cu caracter general.
Pe tot parcursul elaborrii soluiei unei probleme, aceasta trebuie documentat i reprezentat.

Soluia trebuie documentat deoarece exist mai multe categorii de persoane interesate n utilizarea acestei
documentaii (operatorii sistemului soft, cei care distribuie i instaleaz sistemul soft, programatorii care se
ocup de ntreinerea sistemului soft, partenerii proiectului de realizare a sistemului soft, etc.).
Documentaia de utilizare poate fi realizat sub forma unor ghiduri de utilizare tiprite 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 nsui codul surs al sistemului soft s fie
generos documentat.
Deoarece, de calitatea documentaiei depinde n mare msur i priza sistemului soft la segmentul de
pia cruia i se adreseaz, marile firme productoare de soft au transformat documentarea unui sistem soft
ntr-o activitate supus n mare msur standardelor, automatizrii, legilor pieei.
Se cunosc exemplele remarcabile oferite n aceast privin de firme precum Microsoft sau Borland.
Soluia trebuie reprezentat n fiecare etap a ciclului de via deoarece:
-permite schimbul de informaii de natur tehnic ntre partenerii de proiect;
-servete ca surs de documentare strict necesar celor care vor s aduc modificri sau dezvoltri
acestei soluii.
Att pentru documentarea ct i pentru reprezentarea soluiei se folosesc limbaje sau sisteme adecvate.
Astfel, pentru documentare se folosete, n esen, limbajul natural, manifestndu-se o grij deosebit pentru
rigoarea, claritatea, sugestivitatea i uurina n utilizare a diferitelor tipuri sau sisteme de documentare.
Programatorii, ndeosebi, sunt deja obinuii cu ncorporarea n mediile de programare sau n funcionalitatea
diferitelor sisteme soft a unor help-uri interactive de mare complexitate sau a tutorialelor care asist nvarea
operrii sistemelor soft. Ultima gselni n materie de documentare a sistemelor soft o reprezint capabilitile
de tip wizards care scutesc utilizatorii de grija de a memora anumite protocoale de utilizare a sistemelor soft,
lsndu-le ns ntotdeauna libertatea de a gndi care este cea mai bun alegere ntr-un anumit moment al
utilizrii softului n cauz.
n ceea ce privete reprezentarea soluiei, aducem la cunotina cititorului faptul c lucrurile sunt mai puin
aezate dect n cazul documentrii.
Limbajele alese pentru reprezentarea soluiei unui sistem soft pot fi:
-tributare cerinei 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 notaia 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 soluia tehnic (a
se vedea Z, Z++, VDM, VDM++, sisteme formale de reprezentare a soluiei unui sistem soft care au reuit
cteva strpungeri experimentale n lumea practic a IS i att deocamdat).
Referitor la notaie (cum se mai numete limbajul de reprezentare a soluiei) s precizm c aceasta n
manualele de prezentare a MDS este strns dependent de semantica metodologiei, adic limbajul de
reprezentare a soluiei respir acelai aer cu limbajul de abstractizare a soluiei.
n ceea ce privete capacitatea unei MDS de a oferi suport pentru rezolvarea problemelor de tip
OMP
Din cele expuse pn n acest punct al lucrrii s-a neles, 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 afirmaiei potrivit
creia:
Un management slab poate compromite uor ansele de reuit ale unei echipe de proiectare redutabil
profesional; un management bun poate gestiona eventualele probleme datorate nivelului profesional
necorespunztor al unora dintre membrii echipei de proiectare.
Lumea n care trim este, fr s exagerm deloc, opera diferitelor tipuri de management.
Specialiti sau nu n probleme de management, este bine s tim c exist discipline care studiaz
problemele fundamentale ale managementului, dar, complexitatea activitilor imaginate de om depind de mult
capabilitile explicative i operaionale ale unui tratat de bazele managementului, asistm la apariia unor
varieti noi de management cu obinuina cu care la un anumit timp dup apusul soarelui ne vine din ce n ce
mai greu s rezistm tentaiei de a ne culca. Printre aceste varieti 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 puin n cazul etapei de analiz
din ciclul de via al unui sistem soft cunotinele de management sunt de mare utilitate (dac sistemul soft este
realizat la cererea conducerii unei organizaii cu sau fr profit).
Multe din ntrebrile 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 funciile pe domeniul activitilor
deservite?, etc.) primesc rspunsuri mult mai clare dac analistul are i cunotine de management. Spernd c v-

am convins, oarecum, de utilizarea unui management adecvat al procesului de dezvoltare a unui sistem soft, s
anticipm c n atenia MPRSS se afl trei tipuri fundamentale de activiti:
-gestiunea resurselor angajate n realizarea sistemului soft;
-asigurarea calitii sistemului soft;
-gestiunea riscurilor asociate procesului de realizare a sistemului soft.
Toate aceste trei tipuri de activiti se desfoar 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, aadar, s constatm c specialitii care depun eforturi pentru dezvoltarea suportului
metodologic de tip OMP propun o serie de modele calitative i cantitative cu ajutorul crora se ncearc
msurarea sau evaluarea rezultatelor activitilor mai sus precizate.
Date fiind particularitile acestor activiti n cazul proiectelor de realizare a unor sisteme soft, este de
ateptat ca multe direcii de aciune ale managementului s se supun unor legiti specifice.
Orice patron de firm soft va scpa de multe probleme n ziua n care din laboratorul de cercetare va iei pe
pia o metodologie care:
articuleaz att de bine contradiciile, certitudinile i incertitudinile din munca unui specialist n IS, nct
toate merg ca ntr-o linie de fabricaie a unor echipamente necesare pentru dotarea unor capsule spaiale.
Fericire sau ghinion, cert este c mai avem cale lung pn acolo. Nu cred c este cazul s v spun explicit
de ce. Doar att mai adaug: de vin este complexitatea unora dintre activitile specifice gndirii omeneti.
Nu ne rmne dect s alegem dintre nenumratele rele pe care le avem n fa pe cea mai puin 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 ntlni abordri de genul celor reprezentate n Figura 3.1 i n Figura 3.2.

Specificarea
cerinelor

Implementare
Figura 3.1 Un model primitiv de dezvoltare a softului

Specificarea
cerinelor

Diagrama de
structur

Implementare
Figura 3.2 Un model mbuntit 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 abiliti remarcabile care s-i permit s fac un salt
uria de la cerine la codul care descrie, practic, n detaliu, soluia 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 capt 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 cerine la cod este plin
de riscuri.
mbuntirea sugerat de Figura 3.2 este real dar insuficient. Ani la rnd, n laboratoarele de cercetare ale
IS s-au fcut eforturi extrem de diverse i uneori foarte originale, pentru gsirea celei mai bune formule de
desfurare n timp a procesului de abstractizare a soluiei unui sistem soft.
Toate aceste formule se concretizeaz ntr-o list lung de propuneri de cicluri de via, din care vom
analiza n continuare cteva exemple reprezentative.
Dei ciclul de via propus de o MDS funcioneaz optim n conjuncie cu o anumit strategie de
abstractizare a soluiei, specific MDS, n analiza pe care o fac n paragraful 3.2 voi insista doar pe elementele
care definesc particularitile unei MDS din punct de vedere al ciclului de via.

3.2 Ciclul de via al sistemelor soft. Cteva exemple.

Schimbrile care s-au produs, n timp, n ceea ce privete tehnologiile informaionale 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 evideniaz o serie de elemente interesante.
Numrul fazelor ciclului de via specific unei MDS poate varia de la trei (analiz, proiectare,
implementare) pn la douzeci sau mai multe.
Este evident faptul c, i n acest domeniu, concurena, beia teoretic i ruperea contactului cu realitatea
zmislesc, din cnd n cnd, adevrai montri metodologici. Pentru a trece cu brio examenul practicii, o MDS
trebuie s manifeste o preocupare deosebit pentru dou dintre trsturile ciclului de via asociat:
-numrul de faze s fie justificat att de o analiz punctual ct i de consideraii de ansamblu n ceea
ce privete versatilitatea operaionalizrii ciclului de via;
-fiecare faz a ciclului de via s fie acoperit satisfctor de elemente supor t pentru rezolvarea
problemelor de tip ASS, RDS, OMP.

Avnd n vedere aceste dou exigene, voi trece la descrierea unor modele ale ciclului de via al sistemelor
soft reprezentative, urmnd 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 fcut istorie. El afost lansat la ap la
nceputul deceniului 7 de ctre W. W. Royce i const ntr-o descompunere a ciclului de via al unui sistem soft
n faze secveniale. Fazele sunt descompuse n activiti. Trecerea de la o faz la alta se realizeaz dup ce
precedenta a fost parcurs integral.
S mai reinem i faptul c MC se aplic la nivel de sistem. Alte informaii cu privire la model n Figura 3.3.
Definirea
cerinelor

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, evideniindu-se
clar ntinderea lor ca o colecie de activiti i subactiviti specifice;
Este uor de nsuit de ctre partenerii unui proiect, inclusiv de cei cu experien redus;
Fiecare faz este acompaniat de o documentaie destul de bine structurat.
Dezavantaje ale modelului cascad
Aplicndu-se la nivel de sistem, evident c nu ofer suport prea consistent pentru controlul complexitii
n cazul sistemelor mari;
Dei, dup cum reiese i din Figura 3.3, nu este descurajat abordarea iterativ a unor faze sau
componente ale lor, restriciile de timp impuse de programarea calendaristic a fazelor limiteaz ofertele
benefice ale posibilitii 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
reluri ale fazelor, mai mult se simte nevoia lucrului n paralel la o scar mai mare dect o permite modelul
cascad;
Evident, sistemul se pred doar dup parcurgerea etapelor anterioare, ceea ce nseamn o lung perioad
de timp pn cnd utilizatorul vede sistemul la lucru, ceea ce nu este convenabil pentru nici una din faze
(utilizatorul are destul timp s emit alte pretenii fa de sistemul soft);
MC nu ofer suport adecvat pentru abordarea dinamic a proceselor de modelat;
MC nu are protecie explicit fa de modificrile care pot interveni pe parcursul dezvoltrii sistemului
soft.

Nu am considerat necesar s mai insist asupra coninutului fazelor prezentate n Figura 3.3. Paragraful 2.2 al
acestei lucrri conine suficiente informaii lmuritoare n acest sens.
Cu toate c are destui critici, modelul cascad a fost i este folosit, integral sau parial, ori de cte ori se
dorete un ciclu de via cu o structur echilibrat.

3.2.2 Modelul V (MV)

Acest model preia ideile de baz ale modelului cascad, integrndu-le ntr-o concepie 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 relaiei sistem-componente, o delimitare mai precis a interferenelor procesului cu utilizatorul
sistemului soft rezultat.
Adevrul este c marile mutaii produse n lumea tehnologiilor informaionale orienteaz eforturile
specialitilor n IS ctre posibilitatea abordrii unui sistem orientat pe componente, de o manier iterativincremental (ceea ce nseamn mai mult dect oferta modelului V) cu o atenie deosebit fa de utilizator.
n actuala etap de dezvoltare a IS utilizatorul a devenit un partener ale crui opinii trebuie luate n seam
pentru ca sistemul soft s poat trece cu bine examenul pieei.
A mai sublinia faptul c n cadrul MV se face o distinie clar ntre verificare i validare, ca activiti
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 specificrii cerinelor iniiale fa de
sistemul soft. Figura 3.4 ne arat c validarea stabilete dac sistemul, n forma lui final, corespunde sau nu
cerinelor. Faptul c validarea este posibil doar cnd sistemul ajunge n forma final este un punct slab al
modelului, ndeosebi n situaia n care procesul de modelat are afiniti structurale sau conjuncturale cu
nisipurile mictoare.
Menionm faptul c MV, n forma consacrat aparine lui Ould, care l-a adus n faa comunitii
specialitilor n IS n 1990.
Definirea
cerinelor

Validare

Proiectare
sistem

Testare
sistem

Proiectare
subsisteme
(componente)

Testare
subsisteme
(componente)

Codificare/
asamblare
componente

Figura 3.4. Modelul V

3.2.3 Modelul prototipizrii (MP)

Multe modele de dezvoltare se bazeaz pe utilizarea, n anumite momente, a abordrilor iterative (de
exemplu, analiza poate implica o serie de sarcini care sunt iterativ repetate pn cnd modelele analizei sunt
considerate complete).
Dei promite un cadru mai realist de dezvoltare a softului o astfel de abordare poate fi uor descumpnit
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 mprejurrile necesare pentru ca acesta (utilizatorul) s observe
eventualele neconcordane ntre cerinele lui fa de sistem i cele implementate efectiv .
MP ofer o abordare care, potenial, poate contribui la eliminarea omisiunilor i ambiguitilor care pot
exista n cerine.
n IS se numete prototip un sistem sau un sistem parial finisat care este construit rapid pentru a explora
anumite aspecte ale cerinelor fa de sistem i care nu este considerat sistem gata de livrarea final la
utilizator.
Un sistem soft aflat n faza de prototip se deosebete 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 obinuit, o funcionalitate incomplet (capacitate limitat de procesare a
datelor, performane reduse n timpul execuiei, siguran n funcionare problematic, etc.).
Dezvoltarea prototipului este posibil efectiv doar utiliznd instrumente pentru dezvoltarea rapid a
sistemelor soft (medii vizuale de proiectare, medii vizuale de programare, etc.).
Cnd realizm un prototip putem avea diferite obiective n minte.
Putem construi un prototip pentru a investiga cerinele utilizator; n acest scop ne putem focaliza efortul de
dezvoltare pe realizarea interfeei cu utilizatorul pentru a stabili ce date ateapt 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
cerine de prelucrare.
n sfrit, un prototip ar putea s urmreasc determinarea eficienei unui limbaj particular, a unui SGBD
sau a unei infrastructuri de comunicaie.
O perspectiv mai clar asupra proprietilor modelului MP putem obine i din Figura 3.5.
Definire
obiective
prototip

Analiza
iniial

Specificare
prototip

Evaluare prototip
i stabilire
schimbri

Construire
protoip

Prototip
complet
Figura 3.5. Dezvoltarea rapid a softului
utiliznd prototipizarea
Aadar, fazele principale necesare pentru a pregti un prototip sunt:
Efectuarea unei analize iniiale;
Definirea obiectivelor prototipului ;
Specificarea prototipului;
Construirea prototipului;
Evaluarea prototipului i stabilirea schimbrilor de efectuat.

Efectuarea unei analize iniiale

ntreaga activitate de dezvoltare a softului folosete resurse valoroase. nceperea unui exerciiu de
prototipizare fr o analiz iniial este posibil s conduc la o activitate nestructurat i greit focalizat care va
produce un soft proiectat nesatisfctor.
Definirea obiectivelor prototipului
Prototipizarea este de dorit s aib obiective clar stabilite. Un exerciiu de prototipizare poate implica multe
iteraii, fiecare iteraie avnd drept rezultat o anumit mbuntire a prototipului. Pentru participanii la un
exerciiu de prototipizare, la un moment dat poate fi dificil de stabilit dac prototipizarea trebuie sau nu s
continue. Pentru evitarea unei astfel de posibiliti definirea clar a obiectivelor de ndeplinit poate fi de mare
folos.
Specificarea prototipului
Dei prototipul nu este realizat n perspectiva unor operaii de extindere este, evident, important s aib un
comportament scontat. De aceea, este absolut firesc s lum n calcul posibilitatea unor modificri care s
apropie prototipul ct mai mult de comportamentul scontat.
Aceste modificri sunt mult mai uor de fcut 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 plicaiilor (Delphi, Visual Basic, Visual C, C-Builder, etc.).
Evaluarea prototipului i stabilirea schimbrilor de efectuat
Motivul principal pentru care realizm un prototip este testarea i explorarea anumitor aspecte ale sistemului
soft de realizat. Prototipul trebuie evaluat n conformitate cu obiectivele identificate la nceperea exerciiului de
prototipizare. Dac obiectivele nu au fost ndeplinite, evaluarea are drept consecin o serie de modificri care
urmresc apropierea prototipului de obiectivele asumate.
Dup cum se vede i din Figura 3.10, ultimele trei faze sunt parcurse ciclic, pn cnd toate obiectivele
asumate de exerciiul 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 funcionalitii sistemului ajut la identificarea tuturor dezacordurilor dintre
specialistul IS i client;
Cerinele client omise au anse s fie identificate;
Dificultile legate de proiectarea interfeei pot fi contientizate 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 nelege amploarea efortului
cerut, uneori, de realizarea formei finale a sistemului, motiv pentru care are senzaia c acesta (sistemul final)
trebuie livrat mai curnd dect este posibil n realitate;
Prototipul poate distrage atenia de la aspectele funcionale (uneori critice pentru sistem) ctre problemele
de interfa (fetiizate oarecum de nevoia de a da permanent satisfacie 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
Dei din motive didactice am ncercat s focalizez atenia cititorului pe noiunea de ciclu de via, acesta va
nelege, probabil, legtura indisolubil dintre ciclul de via i celelalte componente ale unei MDS. ndeosebi
binomul ciclu de via ciclu de abstractizare trebuie neles profund de ctre practicanii IS care vor s
valorifice la maximum potenialul unei MDS.
Exemplele prezentate arat, pe de o parte, dificultile ntmpinate de-a lungul timpului de specialiti IS n
ncercarea lor de a spori randamentul metodologiilor de dezvoltare a softului, pe de alt parte tendina
permanent a MDS de a oferi o perspectiv ct mai realist asupra procesului de dezvoltare a sistemelor soft.

Aa cum se vede i din exemplele prezentate nu lipsesc nici exagerrile, multe din modelele specificate de-a
lungul timpului funcionnd 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
numr mare de specialiti.
Acest lucru se poate ntmpla dac:
modelul este uor de nvat i operaionalizat;
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 cnd spun c n IS "nisipurile sunt mictoare",
multe probleme nerezolvate stau la vedere, deci cei care se simt cu muchii tari pot s ias la "interval".
Expediia noastr continu pentru c mai avem i alte necunoscute de scos la iveal n capitolele care
urmeaz.

4 ABSTRACTIZAREA SOLUIEI UNUI SISTEM SOFT

4.1 Modelarea. Limbaje de modelare
Dup Capitolul 3, n care libertatea de micare a gndirii a fost oarecum ngrdit de exigenele subiectului
abordat, iat-ne din nou pe un teritoriu vast, complex i n continu prefacere: universul modelrii.
Activitatea de elaborare a modelelor se bazeaz, prin definiie, pe un mare consum de energie intelectual.
Cu att mai mare este efortul de modelare cu ct orizontul epistemologic al celui implicat n efort este
nestructurat sau structurat neconcludent.
Ori de cte ori este vorba despre activiti care se bazeaz pe muchii gndirii, trebuie s ne asumm
deopotriv riscurile, frumuseea i noutatea pe care o presupune rezolvarea unei probleme. Chiar i atunci cnd
drumul este, pe alocuri, bttorit pentru a reui avem nevoie de dou tipuri de abiliti:
abiliti de elaborare sistematic a realitii,
metod de modelare n domeniul de care aparine problema.
Pentru a fi meseriai adevrai ne mai trebuie doar atta ndoial n ceea ce tim la un moment dat ct s
ne fie permanent treaz dorina 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 acelai 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,
simplificnd sau omind celelalte aspecte ale SR. Ingineria, arhitectura, astronomia, fizica i, de ce nu, IS
folosesc intens modele.
Odat realizate, modelele pot fi fizice (n construcii, n muzeologie, etc.) sau pot lua forma unor
reprezentri adecvate pe un suport de memorie extern (hrtie, floppy-disk, hard-disk, etc.).
n IS proprietile modelelor sunt reprezentate cu ajutorul limbajelor.
Fcnd abstracie de cele fizice, modelele se impun ateniei celor care le studiaz prin semantica i notaia
lor. Mai pe nelesul unui specialist IS, nelegerea 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 menionate,
probabil c, ndeosebi n zilele noastre, ne-am lepda de ele.
Realitatea este c avem nenumrate motive pentru care acest lucru nu se ntmpl.
Modelarea poate fi utilizat pentru reprezentarea unor sisteme de cunotine n vederea simplificrii
nelegerii acestora de ctre persoanele interesate.
n lumea IS se folosesc frecvent astfel de modele pentru a capacita utilizatorii n procesul de specificare a
cerinelor 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, obinut prin agregarea sintaxei i semanticii tuturor modelelor
preliminare asociate.
Dac ar fi s dm un exemplu din lumea IS, atunci sintaxa i semantica unui sistem soft ar putea fi rezultatul
agregrii 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 funcionale ale SR modelat.
Un model poate fundamenta realizarea unui sistem de organizare, clasificare, vizualizare i editare a
informailor despre sistemele mari.
Altfel spus, nu ne putem imagina procedee de simplificare a efortului de modelare ntr-un anumit domeniu
dac nu rezolvm problema
paradigmei-cadru de modelare.
Sistemele dinamice pot fi modelate utiliznd, s zicem, paradigma UML.
Cu ajutorul modelelor putem simplifica procesul de alegere a unei soluii alternative .
Numeroase sunt situaiile n care factorii care condiioneaz la un moment dat procesul de realizare a unui
sistem soft complic peste msur decizia de continuare a procesului. O modalitate de a iei din impas ntr-o
astfel de situaie o reprezint elaborarea de modele alternative i alegerea celui mai bun pe baza evalurii
avantajelor i riscurilor asociate acestora.
Modelele au fost dintotdeauna i elemente suport pentru stpnirea sistemelor complexe .

Este, probabil, una dintre virtuile 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 nelegere a SR
modelat (evident, este vorba de un exemplu de sistem informaional), evideniaz mai uor structura sistemului
sau permite anticiparea impactului pe care eventuale schimbri 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 utilitii modelelor.
Convingerea mea, probat i de practic, este c merit s nvei s modelezi orict de dificil pare, la nceput,
universul paradigmei folosite.
Ce este un limbaj de modelare?
Cititorul bnuiete, probabil, c nu ajunge s vorbim frumos despre modele. Trebuie s spunem cte ceva i
despre climatul n care sunt elaborate aceste modele. Prima afirmaie pe care am mai fcut-o undeva i n
Capitolul 1, este c putem elabora modelel folosind un arsenalpropriu de elemente-suport. Teoretic, ns,
avem de nfruntat, cel puin trei probleme:
vom avea, precis, dificulti n a ne face modelele nelese de ali specialiti;
probabilitatea de a eua n ceea ce privete 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 recunoaterea lui de o
comunitate ct mai larg de specialiti. i, astfel, se face trecerea la al doilea tip de climat propriu elaborrii
modelelor: cel n care se folosesc limbaje de modelare, recunoscute ca atare de comunitatea utilizatorilor,
purtnd, eventual, girul mediilor academice, beneficiind, n cel mai fericit caz i de recunoaterea 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 dinui, prin ideile lui valoroase, dac acestea au
fost fixate convingtor ntr-o lucrare de specialitate care a ajuns ntr-o bibliotec adevrat.
Abandonnd aceste consideraii 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
operaionalizare a acestora n vederea abstractizrii soluiilor problemelor care fac parte dintr-o anumit
clas tipologic.
Aceast definiie poate fi considerat satisfctoare pentru utilizatorii limbajelor de modelare. n fond,
acetia trebuie s fie buni mnuitori ai conceptelor, principiilor i procedeelor de operaionalizare a
acestora pentru a realiza modele crora 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, definiia de mai sus este insuficient.
Utilizatorul unui limbaj de modelare este asemenea muncitorului care trebuie s tie s mnuiasc o trus
de scule, ntr-un context anume.
Persoana care specific un limbaj de modelare este asemenea inginerului care a proiectat trusa de scule,
abstractiznd 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
Amndou problemele sunt dificil de rezolvat astfel nct beneficiarii poteniali ai limbajului de modelare s
devin beneficiari efectivi n numr ct mai mare. Semnalez, n continuare, cteva dintre dificultile i
antagonismele cu care se confrunt un specificator de limbaje de modelare (SLM).
Primul obstacol pe care trebuie s-l depeasc un SLM este reprezentat de problema delimitrii
tipologice a sistemelor care urmeaz a fi modelate cu ajutorul limbajului . Demersul pentru rezolvarea
acestei probleme poate eua graios dac SLM implicat nu reuete s opreasc la timp elanul generalizrii sau
dac, din contr, nu gsete 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 nct 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 codificm cu ajutorul limbajului.
Aa cum, probabil, cititorul a dedus deja, confruntat cu exigenele unei probleme, adecvat tipologic,
limbajul de modelare trebuie s fac fa la dou comandamente eseniale:
-asigurarea de suport pentru cel care modeleaz n vederea rafinrii treptate a soluiei;
-asigurarea de suport pentru cel care modeleaz n vederea captrii semanticii sistemului modelat.

Amndou 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 rafinrii treptate a soluiei
unei probleme arbitrare este greu de algoritmizat.
Acest fapt ar putea fi motivat, oarecum, de includerea aptitudinii de a rafina soluia unei probleme printre
abilitile de baz ale unei persoane inteligente.
Astfel c, nu avem algoritmi de rafinare treptat a soluiei unei probleme, indiferent ce limbaj de modelare
discutm; n schimb, orice limbaj de modelare ncearc s propun un "background" pentru alegerea celei mai
bune variante de rafinare.
Rutatea unei probleme de rafinare a soluiei unui enun dat este dubl:
algoritmizarea schemei de rafinare agreat de un limbaj nu poate fi realizat dect n linii mari ; pe
aceast baz apare al doilea factor de rutate: gsirea schemei de rafinare este o problem de alegere
dintr-o mulime, uneori inepuizabil, de variante.
Ca exemple de elemente suport pentru rafinarea treptat a soluiei 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 nelesul originar la nivele nalte de abstractizare).
Utilizarea modularizrii pentru obinerea soluiei 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 consecina unui anumit mod de a nelege 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 abordrii top-down putem avea descompunere bazat pe:
-criterii funcionale;
-criterii de organizare a datelor;
-abstractizarea fluxurilor de date;
-tipuri abstracte de date.
Fiecare dintre cerinele de mai sus propune, de fapt, o anumit manier de trecere de la domeniul problemei
ctre domeniul soluiei.
A treia problem n atenia unui SLM se refer la notaia prin intermediul creia se face transfer de
semantic dinspre limbajul de modelare ctre utilizatorul limbajului de modelare.
Este o problem care, rezolvat nesatisfctor, poate compromite inteniile conceptuale ale limbajului.
De regul, o notaie inspirat permite:
-vizualizarea procesului de modelare;
-specificarea soluiei unei probleme;
-realizarea soluiei;
-documentarea soluiei.
Vizualizarea procesului de modelare
Este o calitate care contribuie hotrtor la rezolvarea a dou probleme importante:
- sporirea semnificativ a accesibilitii limbajului de modelare; n opoziie 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 modelrii vizuale
asistat de calculator.
Impactul pe care l are caracterul vizual al modelrii asupra productivitii muncii este uria, dac adugm
precizarea c mediile de dezvoltare asistat iau asupra lor mare parte din sarcinile de rutin sau susceptibile de a
fi automatizate.
Exist specialiti care pun n crca vizualizrii o anumit tendin de depreciere a specificrii soluiei unei
probleme (datorit oportunitii 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 dect s ne ajute s scurtm termenele de execuie realiznd 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 aflm.
Specificarea soluiei unei probleme
Orice limbaj de modelare trebuie s posede n cel mai nalt grad nsuirea de a permite specificarea corect
i complet a soluiei unei probleme.
Cititorul care s-a confruntat, ca specialist IS, cu efectele devastatoare (asupra existenei unui sistem soft) ale
unei specificri incorecte i/sau incomplete nelege pe deplin greutatea acestei cerine. Raza de aciune a
calitii procesului de specificare a souliei unui sistem soft aduce atingere att factorilor interni ct i factorilor
externi ai calitii unui sistem soft.
Privind aceast cerin i din perspectiva exigenelor unui potenial mediu de dezvoltare, asociat limbajului,
adugm o nou dimensiune nelegerii capabilitilor unui limbaj de specificare a soluiei unui sistem soft.
Atrag atenia cititorului asupra utilitii unei dezbateri mai ample pe teme de corectitudine i completitudine.
Astfel, un specialist IS poate opera cu cel puin dou sensuri ale conceptului de corectitudine:

-corectitudinea de mapare
-corectitudinea formal.
Corectitudinea de mapare caracterizeaz modul n care cerinele beneficiarului sunt specificate n soluie.
Orice diferen ntre mesajul corespunztor unei cerine din domeniul problemei i mesajul aceleiai cerine n
domeniul soluiei trebuie interpretat ca un exemplu de specificare incorect.
Corectitudinea formal rspunde de acurateea formal a specificrii. Mesajul de baz al specificrii poate
fi prezent, deci avem corectitudine de mapare, dar acurateea specificrii din punct de vedere formal poate fi un
obstacol n comunicare sau n generarea automat corect a unor piese ale sistemului soft de ctre 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 restrnge serios numrul
celor interesai de aceast abordare, sistemele intuitive ncearc s cultive rigoarea utiliznd masiv semantici
exprimate cu ajutorul limbajelor naturale.
Valenele semantice ale noiunii de completitudine a specificrii sunt, de asemenea, variate.
Analog corectitudinii, putem vorbi de completitudine de mapare, prin care nelegem prezena n sistemul
de cerine a tuturor elementelor vitale n momentul dezvoltrii softului, precum i a unor elemente-cadru care s
permit redefinirea, la nevoie, a sistemului de cerine.
Putem vorbi, de asemenea, de o completitudine structural, prin care desemnm finalizarea corect a
tuturor inteniilor de specificare ale proiectului.
Evident, efortul de specificare corect i complet are determinri adnci 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 nelegerea
pe buci a unei MDS la o viziune sistemic asupra utilitii ei.
Realizarea softului
O notaie chibzuit aleas trebuie s aib calitatea de a permite relativ uor transpunerea soluiei tehnice n
limbajul de programare ales. Ceea ce, probabil, pare simplu ca teorie este ns o sarcin dificil pentru SLM.
Pentru ca notaia unei MDS s faciliteze realizarea softului, la specificarea limbajului de modelare trebuie
depuse eforturi de unificare, pe ct posibil, a lumii conceptelor din domeniul soluiei tehnice cu lumea
conceptelor din domeniul programrii.
Aceast unificare este extrem de dificil ct timp n lumea limbajelor de programare se menin nc
deosebirile de abordri n ceea ce privete structura soluiei unei probleme.
ntr-o oarecare msur este chiar scuzabil o astfel de stare de lucruri. S ne gndim c n programare exist
nu doar variaiuni 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 funcional, 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 atepta s fie mai uoar soarta SLM n ceea ce privete ncercarea lor de unificare a
semanticilor diferitelor limbaje de programare ntr-o notaie ct mai robust.
Pentru a da un exemplu concret de ncercare n aceast direcie recomand ateniei cititorului notaia UML
care reuete un lucru demn de toat lauda: aducerea la numitor comun a numeroaselor MDS autoproclamate
obiect-orientate prin propunerea unei notaii n care i fac loc concepte fundamentale ale modelrii obiectorientate (clas, obiect, asociere, agregare, generalizare, motenire, 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.
Dei ambiia oricrui SLM n IS este de a vedea modelele obinute independente de limbajul n care va fi
transcris modelul, nu nseamn neaparat c are i susinere efectiv.
Revenind la cazul UML-ului, autorii lui clameaz independena fa de limbaje de programare, dar, n sinea
lor tiu c maparea soluiei tehnice pe soluia programat este perfect doar dac principiile fundamentale ale
limbajelor de modelare i programare sunt n rezonan.
Pentru ca lucrurile s progreseze mai sunt de nfptuit numeroase reforme n ceea ce privete:
-impunerea de standarde tehnologice n domeniul sistemelor de operare;
-definirea i implementarea unor standarde n ceea ce privete structura sistemelor soft.
Mediile vizuale de programare (de genul DELPHI, VISUAL C++, C-Builder, etc.) sunt exemple gritoare
de abordri compatibile cu o paradigm de modelare important cum este UML.
Documentarea soluiei
Notaia unui limbaj de modelare trebuie s dispun de resursele necesare pentru a permite:

-reprezentarea i documentarea arhitecturii sistemului;

-reprezentarea i documentarea cerinelor fa de sistemul soft;
-reprezentarea i documentarea soluiei tehnice la diferite nivele de abstractizare;
-reprezentarea i documentarea activitilor specifice managementului dezvoltrii sistemelor soft.
Sistemele soft adevrate (n sensul c au complexitate medie sau mare) trebuie s adauge lng codul surs
(izomorf, practic, cu codul executabil al sistemului soft) o serie de alte produse tipice ingineriei softului care,
laolalt, alctuiesc documentaia 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 documantaie, n cretere, din partea utilizatorilor
diverselor tehnologii informaionale lansate pe pia.
A patra problem n atenia unui SLM se refer la stabilirea limbajului cu care este definit limbajul de
modelare.
Crile care popularizeaz limbajele de modelare apeleaz, de regul, la o combinaie ntre limbajul natural
i elemente de descriere formal pentru a realiza compromisul optim ntre rigoare i accesibilitate. Documentaia
de referin a unui limbaj de modelare poate apela la un limbaj special pentru descrierea proprietilor limbajului
de modelare.
Situaia este similar cu cea ntlnit n domeniul limbajelor de programare, unde se cunosc formalizme de
descriere a anumitor proprieti ale limbajelor de tipul:
-diagrame de sintax
-sintaxa BNF
Evident, exist i excepii interesante n ceea ce privete alegerea limbajului cu ajutorul cruia se specific
un limbaj de modelare. Este vorba de sistemele formale de specificare a softului (Z, Z++, VDM, VDM++) care
apeleaz, esenial, la un formalizm matematic care poate veni dinspre teoria mulimilor, logic, calculul lambda,
etc. Poate fi, de asemenea, vorba despre limbajele de modelare, gen UML, care conin 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 puin din cauza cerinelor formulate n paragraful
4.1.) s se prezinte n faa utilizatorilor cu o concepie arhitectural clar.
nelegerea arhitecturii unui limbaj de modelare este benefic att pentru utilizatorii limbajului ct i pentru
cei care i studiaz fundamentele.
Efectul cunoaterii 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 cunoatere a unui sistem.
Arhitectura unui sistem este datoare s explice tuturor celor interesai:
-care sunt subsistemele fundamentale ale sistemului; ce semantic ncapsuleaz aceste subsisteme?
-care sunt dependenele fundamentale ntre subsistemele evideniate mai sus; care este semantica
esenial a acestor dependene?
-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
definete orizontul strategic al posibilitiilor de operare cu capabilitile de modelare ale limba jului.
Este posibil ca, pentru muli utilizatori, cunoaterea acestui orizont s nu fie deloc o prioritate. Aceasta
deoarece alii decid pentru ei ce limbaj de modelare trebuie s foloseasc iar utilizarea efectiv a limbajului nu
trebuie s treac neaparat prin nelegerea subtilitilor asociate perspectivei arhitecturale. Pentru a ne forma o
idee asupra utilitii cunoaterii arhitecturii unui limbaj de modelare ne putem inspira din obinuina pe care iau fcut-o unii productori 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 atenie sporit fa de elementele arhitecturale i fa de, s-i spunem,
evoluia universului conceptual al obiectului descris.
Manualele de utilizare ncearc, mai degrab, s prezinte utilizatorului scenarii pe baza crora se poate
utiliza semantica obiectului respectiv.
Specialitii n IS, interesai 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 urmtorul:
1. Dintr-un motiv anume, n atenia specialistului IS, ajunge o anumit realitate informaional, cu veleiti
sistemice i structurale obiective.
2. Specialistul IS stabilete determinarea obiectiv i subiectiv a realitii informaionale respective.
n determinarea obiectiv includem acele aspecte ale realitii informaionale 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
realitii informaionale.

Din momentul n care atitudinea specialistului fa de realitatea informaional ncepe s se structureze,

practic, ncepe procesul de modelare a realitii informaionale. Acest proces presupune:
permanente i obligatorii procese de abstractizare.
Se face abstractizare atunci cnd schim elementele arhitecturale ale modelului, ceea ce nseamn
generalizare.
Se face abstractizare atunci cnd optm pentru o soluie alternativ n procesul de rafinare a modelului, ceea
ce nseamn specializare.
permanente i obligatorii eforturi de reprezentare a diferitelor nivele de abstractizare , scopurile
urmrite fiind:
-rezolvarea problemelor de comunicare;
-obinerea specificaiilor complete ale modelului.

5 MODELAREA OBIECT ORIENTAT CU UML

5.1 Ce este UML(fr a intra n detalii)?
Cititorul bnuiete, deja, c UML este rezultatul unor acumulri cu un istoric destul de zbuciumat, n
materie de modelare a soluiilor sistemelor soft.
Aadar, s remarcm faptul c UML este un limbaj de modelare, nu o metodologie. Ca limbaj de
modelare, UML ofer o notaie, n spatele creia se afl o semantic adecvat. Notaia este n mare parte
grafic, astfel c este ct se poate de nimerit s reproducem caracterizarea de ansamblu a UML-ului, fcut n
documentaia pus la dispoziie n site-ul www.rational.com:
UML este un limbaj pentru specificarea, vizualizarea, construirea i documentarea componentelor
(artifacts) unui sistem soft sau, la fel de bine, pentru modelarea organizaional i a altor sisteme, nu
neaprat din lumea IS.
Cele mai puternice i recente rdcini ale limbajului UML se afl n metodologiile, patronate spiritual de
Grady Booch, James Rumbaugh i Ivar Jacobson.
UML a unificat i standardizat oferta metodologiilor Booch, OMT i OOSE, precum i a altor metodologii
cu abordri remarcabile, n spatele crora se afl autori precum Odell, Shaeler-Mellor, Meyer, Wirfs-Brock etc.
Prima versiune public a UML a fost lansat n octombrie 1995 sub forma versiunii 0.8. Reacia marelui
public a fost evaluat i inclus n versiunea 0.9, n iulie 1996 i n versiunea 0.91, n octombrie 1996. Versiunea
1.0 a fost prezentat pentru standardizare membrilor OMG (Object Management Group) n iulie 1997. O serie de
mbuntiri aduse UML au fost incluse n versiunea 1.1, care a fost prezentat OMG n septembrie 1997. UML
a fost adoptat ca standard, n unanimitate, de ctre membrii OMG, n noiembrie 1997. OMG este actualmente
implicat, cu responsabiliti precise, n dezvoltarea viitoare a standardului UML. Versiunea 1.3 a fost fcut
public n 1999 i prin contribuia grupului RTF (Revision Task Force), etc.
S ncercm acum o explicaie a sintagmei unified din denumirea UML.
Aadar, pentru UML, atributul unified poate fi neles n raport cu urmtoarele topici IS.
Metodologiile i notaiile asociate lor privite din punct de vedere
istoric
UML combin conceptele, folosite intens i cu acelai neles, n mai multe metodologii obiect orientate, impunnd definiii clare pentru
fiecare concept i o notaie adecvat. Ca urmare, UML este capabil s reprezinte cele mai multe dintre modelele exi stente, la fel de bine
sau chiar mai bine dect metodologiile originale.

Ciclul de via al dezvoltrii sistemelor soft

UML opereaz cu aceleai concepte i notaii n diferite etape ale procesului de abstractizare a soluiei. Prin
urmare, nu este necesar un efort de translatare semantic i sintactic a soluiei, de la un nivel de abstractizare la
altul. Aceast situaie este absolut convenabil din perspectiva modelului iterativ i incremental de dezvoltare,
cu care UML se potrivete cel mai bine.
Tipuri de aplicaii
UML este pregtit s ofere suport pentru modelarea unui numr mare de tipuri de aplicaii, incluznd
sisteme cu volum mare de date i prelucrri, sisteme de mare complexitate, sisteme de timp real, sisteme
distribuite, etc. Este posibil s existe tipuri de probleme n care un limbaj de modelare specializat este mai
folositor, dar UML este de ateptat s fie la fel de bun sau chiar mai bun dect orice alt limbaj de interes general,
n multe tipuri de aplicaii.
Limbaje i platforme de implementare
UML este gndit s fie util pentru sisteme soft implementate pe diferite platforme, incluznd limbaje de
programare, SGBD-uri, 4GLs, documente organizaionale, medii firmware, etc. Modul de lucru este acelai sau
prezint multe similariti n toate tipurile de aplicaii, rezultatul fiind dependent de mediul n care se lucreaz.
Procesul de dezvoltare
Aa cum am mai spus, UML este un limbaj de modelare, nu o descriere a unui proces de dezvoltare detaliat.
UML este gndit s fie utilizat independent de proces, dar ofer suport complet pentru procesele de dezvoltare
iterative i incrementale (a se vedea. Rational Unified Process - RUP).
S precizm, n sfrit, faptul c UML a fost dezvoltat de Rational Software Corporation i partenerii ei,
precum: OMG, Digital Equipment Corporation, HP, i-Logix, IntelliCorp, IBM, Microsoft, Oracle, etc.
Cititorului amator de elemente de referin referitoare la UML s-i mai spunem c, din perspectiv formal,
UML are o arhitectur structurat pe patru nivele de abstractizare: obiecte utilizator, model, meta-model i
meta-metamodel. Astfel c, specialitii obinuiesc s spun c UML are o arhitectur de metamodelare pe 4
nivele, cum rezult i din Figura 5.1.

Nivel
Meta-metamodel

Metamodel

Model

Obiecte(dat)
utilizator

Descriere
Desemneaz
infrastructura
conceptual, necesar pentru o
arhitectur de metamodelare.
Definete
limbajul
pentru
specificarea metamodelelor.
Desemneaz o instan a unui
meta-metamodel.
Definete limbajul necesar
pentru specificarea unui model.
Desemneaz o instan a unui
metamodel. Definete un limbaj
pentru descrierea domeniilor
informaionale.
Desemneaz o instan a unui
model. Definete un domeniu
informaional concret.

Exemple
MetaClase,
MetaAtribute,
MetaOperaii

Clas,
Atribut,
Operaie,
Component
CodProdus,
DenumireProdus,
Cantitate, etc.
<1111>, <eav
PVC>, 30

Figura 5.1. Arhitectura UML

Pe bun dreptate, cititorul se va intreba: La ce mi folosete s tiu attea despre arhitectura UML?.
Un rspuns moderat la aceast ntrebare, mai jos.
Aa cum se prezint la ora actual, UML ofer utilizatorilor o notaie i un meta-model.
Notaia desemneaz acele elemente de sintax (preponderent grafice) cu ajutorul crora se specific soluia
UML a unui sistem soft. De exemplu, pentru a reprezenta soluia UML a unei probleme, n mod normal ne vom
folosi de notaia aferent diagramelor de clase, n care se opereaz cu concepte precum: clase, asocieri,
generalizri, multiplicitate, etc. Utilizatorul grbit prinde din zbor semantica unor astfel de concepte.
Utilizatorul care are obsesia rigorii, vrea un rspuns precis la ntrebri de genul: Ce este o clas?.
Productorii de tools-uri de dezvoltare pentru specialitii IS sunt chiar interesai, n mod obiectiv, de
clarificarea rspunsurilor la astfel de ntrebri. Ideea unor limbaje de specificare i proiectare riguroase este bine
reprezentat n lumea metodelor formale (n care singurele enunuri acceptate sunt n spiritul calculului
propoziional sau al calculului predicatelor).
Metodele formale reprezint cea mai bun arm cu care putem stvili insinuarea ambiguitilor n
enunurile noastre.
Din pcate, omul n genere , nu a fost proiectat spre a fi un adorator al limbajelor formale .
Pentru a comunica, omul n genere folosete cel mai bine limbajul natural sau derivai simplificai ai
acestuia. La urma urmei, aceast nclinaie natural are o explicaie destul de profund:
Capacitatea lilmbajelor naturale de a opera cu semnificaii noi este mult mai mare dect a limbajelor
formale.
Pentru a mpca pe toat lumea, UML ofer utilizatorilor un meta-model, cu ajutorul cruia se dau
rspunsuri riguroase la ntrebri de genul: Ce este o clas?. Aceast caracteristic face din UML un limbaj
interesant, deoarece resursele pentru specificarea conceptelor lui se gsesc n el nsui (limbajele de programare,
de exemplu, folosesc metalimbaje de tip notaie BNF sau diagrame de sintax, pentru specificare).

5.2 Date eseniale pentru nelegerea UML

n acest paragraf voi trece n revist coordonatele eseniale pentru nelegerea UML.
Aadar, UML este un limbaj pentru: vizualizarea, specificarea, construirea i documentarea
componentelor unui sistem soft.
UML limbaj pentru vizualizare
UML pune accent pe vizualizarea soluiei unui sistem soft pentru a elimina cea mai mare parte a
problemelor de comunicare care pot s apar ntre diferitele categorii de participani la dezvoltarea unui sistem
soft. Evident, fr a renuna n totalitate la text, UML propune o manier preponderent grafic de reprezenta re i
documentare a unui sistem soft.
UML limbaj pentru specificare
n ingineria softului, specificarea nseamn elaborarea de modele precise, complete i fr ambiguiti. O
specificare vizual, cum este specificarea UML, este expus riscului de a genera ambiguiti n procesul de
comunicare, ntr-un grad mai mare dect n cazul specificrii formale. i totui, o specificare vizual a soluiei n
toate fazele de dezvoltare a unui sistem soft, este de preferat, dat fiind importana unei comunicri ct mai
ample ntre specialitii IS, utilizatori i beneficiari, ca parteneri n cadrul aceluiai proiect.

UML limbaj pentru construire

Probabil, a fost neles faptul c UML nu este un limbaj de programare vizual, dar, ceea ce trebuie reinut
este faptul c modelele elaborate n UML pot fi uor translatate n numeroase limbaje de programare. Aceast
stare de fapt ne sugereaz posibilitatea maprii naturale a unui model UML n limbaje precum Java, C++, Vizual
Basic, Ada, etc.
Posibilitatea efectiv a acestei mapri st la baza generrii automate a codului asociat unui model UML, n
conformitate cu o anumit opiune de limbaj. Generarea automat a codului, pornind de la modelul UML, sau
invers, regsirea modelului UML asociat unei implementri date, sunt posibile utiliznd instrumente CASE,
precum Rational Rose, ObjectiF, etc.
UML limbaj pentru documentare
O firm de soft adevrat produce toate genurile de componente adiionale obinerii codului executabil al
unui sistem soft, precum:
Cerinele fa de sistemul soft;
Descrierea arhitecturii sistemului;
Specificaiile de proiectare;
Codul surs;
Planurile de dezvoltare, etc.
UML posed resurse adecvate pentru specificarea cerinelor fa de un sistem soft, reprezentarea arhitecturii
unui sistem i a tuturor detaliilor de proiectare, modelarea activitilor de management al proiectului, etc.
Unde putem folosi UML?
nainte de orice, UML a fost gndit s fie utilizat n dezvoltarea de sisteme soft n domenii precum:
- Sistemele informaionale ale ntreprinderilor;
- Servicii financiare i bancare;
- Telecomunicaii;
- Transporturi;
- Electronica medical;
- Servicii distribuite bazate pe WEB, etc.
S mai adugm faptul c UML este suficient de expresiv pentru a permite i modelarea sistemelor de alt
natur dect soft (fluxuri de lucru n sistemul justiiei i sntate, etc.).
Arhitectura sistemelor soft din perspectiv UML
Un specialist n IS cunoate bine faptul c, sistemele de mare complexitate, nu pot fi modelate satisfctor
dac paleta criteriilor de observare i analiz nu este adecvat structurat. nvnd din greelile altor limbaje de
modelare, UML propune o formul de arhitectur comprimat n sintagma perspectiva arhitectural 4+1.
Aceast formul este binevenit, att pentru lucrul n echip la un proiect (deci n sprijinul managementului)
ct i pentru procesul de obinere a unei soluii de calitate i ct mai complete. Perspectiva arhitectural 4+1 este
reprezentat, n sintez grafic, n Figura 6.2, care ne sugereaz faptul c identificarea arhitecturii unui sistem
soft este o activitate pentadimensional, dac mi se ngduie exprimarea. Fiecare perspectiv focalizeaz atenia
echipei de dezvoltare asupra unui gen de probleme, a cror rezolvare influeneaz n mod specific calitatea
soluiei, n ansamblu. Atrag atenia asupra rolului pe care l joac perspectiva context de utilizare n
contextul celorlaltor 4 perspective.
Perspectiva logic sistem (Structural view)
Aceast perspectiv a arhitecturii uni sistem soft se refer la cerinele funcionale ale acestuia. Altfel spus,
ce servicii asigur sistemul soft pentru utilizatorii lui? Arhitectura logic este ncapsulat n diagramele
claselor, care conin clasele i relaiile dintre ele (socotite abstracii fundamentale ale sistemului n curs de
dezvoltare). Mare parte din notaia UML este dedicat reprezentrii arhitecturii logice (clase, asocieri,
generalizri, agregri, pachete, etc.).
Elementele care definesc arhitectura logic ncep s fie precizate nc de la nceputul fazei de elaborare (a se
vedea RUP), cnd se stabilesc clasele i pachetele socotite abstracii majore ale domeniului problemei. n timp,
alte i alte clase i pachete sunt adugate modelului UML al soluiei pentru a reflecta deciziile luate privitor la
mecanismele cheie ale sistemului soft.
Prin urmare, putem spune c arhitectura logic a unui sistem soft poart amprenta abilitii echipei de
dezvoltare, de a armoniza gestiunea abstraciilor majore ale sistemului soft cu gestiunea mecanismelor
cheie ale sistemului soft.
Aceast abilitate este transpunerea, ntr-un context particular, a relaiei dintre strategie (=abstraciile
majore) i tactic (=mecanismele cheie). Deciziile tactice greite, n timpul proiectrii, pot compromite uor
o arhitectur logic robust. Pentru a implementa, cu succes, deciziile referitoare la mecanismele cheie ale
unui sistem soft, n IS a aprut o ramur de cercetare nou, cea care se refer la proiectarea i utilizarea
soluiilor-ablon (patterns, n literatura anglo-saxon).

Perspectiva
logic sistem
(structural)
Funcionalitate

Perspectiva
componenete sistem
(implementaional)
Managementul softului
Reutilizare
Portabilitate

Perspectiva
contexte de
utilizare
(utilizator)
Mod de folosire
nelegere
sistem

Perspectiva
procese sistem
(comportamental)
Performan
Utilitate
Toleran la erori

Perspectiva
topologie sistem
(desfurare n mediul
de execuie)
Performan
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 relaiile dintre acestea.
Prin component a unui sistem soft vom nelege, cel mai adesea, un modul fizic de cod.
O component poate coincide cu un pachet, dar cel mai adesea poate diferi. Ca un exemplu, care subliniaz
diferena ntre pachet i component putem observa faptul c n Java clasa String este parte a pachetului
java.lang.package, dar poate s fie utilizat n nenumrate componente ale unei aplicaii Java.
S mai atragem atenia cititorului i asupra faptului c ntre componente pot exista dependene (care, n
terminologia UML, arat cum pot influena schimbrile de stare ale unei componente starea alteia sau a mai
multor componente). Este evident faptul c perspectiva componente sistem a arhitecturii unui sistem soft este
important pentru rezolvarea corect a problemelor de reutilizare a codului, portabilitate a codului i de
management eficient al pieselor fizice ale unui sistem soft.
Evident, exist o anumit mapare a perspectivei structurale pe perspectiva implementaional a unui sistem.
Perspectiva procese sistem (Behavioral view)
Aceast perspectiv are n vizor structura executabilelor sistemului soft (procese, fire de execuie,
mecanisme de concuren i sincronizare, etc.)
Specificarea acestui tip de arhitectur ia n calcul cerine precum: performana, fiabilitatea, utilitatea, etc.
Perspectiva componente sistem i perspectiva procese sistem folosesc pentru reprezentare diagrame de
componente care indic componentele (procesele), interfeele acestora i dependenele dintre acestea.
Diagramele de componente asociate perspectivei proces indic, de fapt, modul de mapare a claselor pe
bibliotecile run-time, gen applet-uri Java, DLL-uri, componente ActiveX.
Perspectiva topologie-hard (Enviromental view)
O astfel de perspectiv va trebui s precizeze nodurile care formeaz topologia hard care asigur execuia
sistemului soft. n aceste noduri se vor executa diferitele procese, indicate n perspectiva procese sistem.
Topologia hard este reprezentat cu ajutorul unor diagrame de noduri, purtnd etichete care sugereaz
repartizarea, pe tipuri de activiti i informaii despre procesele executate n aceste noduri. Evident, o bun
topologie hard trebuie s asigure viteze de execuie rezonabile, resurse suficiente n noduri, fiabilitate, etc.
Perspectiva contexte de utilizare (User view)
Aceast perspectiv demonstreaz i valideaz oarecum celelalte patru perspective. De fapt, perspectiva
contexte de utilizare se bazeaz pe folosirea contextelor de utilizare (use case) pentru a descrie comportamentul

sistemului soft, aa cum este acesta vzut de diferite categorii de utilizatori i, prin intermediul acestora, de
diferii membri ai echipei de proiectare. Aspectele statice ale acestui tip de perspectiv sunt reprezentate cu
ajutorul diagramelor de contexte de utilizare. Aspectele dinamice sunt ncapsulate n diagrame de interaciune,
diagrame de stare, diagrame de activitate.
Scurta trecere n revist a modelului 4+1 ne atenioneaz, nc o dat, asupra complexitii abordrii
propuse de UML, precum i asupra necesitii de a ncepe explorarea notaiei UML care permite materializarea
abordrii 4+1.

5.3 Scurt incursiune n universul conceptual al UML

Dup ce am fcut attea promisiuni relativ la utilitatea UML n diferite contexte, este cazul s facem o
prim ncercare de ridicare a vlului care mai acoper nc, n acest punct al demersului nostru, universul
conceptelor utilizate n modelarea UML. Procednd top-down (aa cum se ntmpl de multe ori n IS) s
precizm, pentru nceput, c vocabularul UML opereaz cu trei tipuri de elemente constitutive:
Entiti;
Relaii;
Diagrame.
Observaie
Entitile desemneaz o serie de abstracii care pot fi socotite ceteni de prim rang ntr -un model UML.
Relaiile abstractizeaz diferitele tipuri de legturi care pot exista ntre entiti.
Diagramele sunt folosite pentru a grupa coleciile de entiti, cu scopul de a evidenia mai bine diferitele
nivele de abstractizare ale soluiei unui sistem soft.
Tipuri de entiti n UML
UML opereaz cu patru tipuri de entiti:
Entiti cu funcii structurale;
Entiti cu funcii comportamentale;
Entiti cu funcii de grupare;
Entiti cu funcii de documentare.
Aceste tipuri de entiti reprezint fundamentul oricrei soluii obiect orientate, n UML. Ele sunt utilizate
intens pentru a realiza modele corect specificate (corectitudinea specificrii, n UML, acoper att aspectele de
sintax ale modelelor, ct i cerina de a ncapsula semantica eficient n aceste metode).
Entitile cu funcii structurale (EFS)
Foarte sintetic, EFS sunt substantivele modelelor UML. De cele mai multe ori, EFS reprezint pri statice
ale unui model, reprezentnd elemente care sunt de natur conceptual sau fizic. n total, n UML exist apte
genuri de EFS, pe care le voi prezenta, pe scurt, n continuare.
1. Clasa - este o abstractizare a unei mulimi de obiecte care partajeaz aceleai atribute
informaionale, acelai comportament, aceleai relaii i aceeai semantic .
O clas implementeaz una sau mai multe interfee. Formalismul de reprezentare a unei clase (de esen
grafic, deci vizual) presupune redarea acesteia ca un dreptunghi care, n mod uzual, include: numele clasei,
atributele i operaiile ei, ca n Figura 6.
2. interfaa - abstractizeaz o colecie de operaii care specific serviciile furnizate de o clas sau
component.
n general vorbind, o interfa poate s reprezinte comportamentul complet al unei clase / componente sau
doar o parte a acestui comportament. Este important s subliniem faptul c o interfa se specific printr-o list
de signaturi de operaii, nicidecum prin lista implementrilor acestor operaii. Este o chestiune de nuan prin
care n modelarea softului se face distincia necesar ntre interfa i implementarea acesteia .
Pacient

Nume clas

CNP
Nume_I_Prenume

Atribute informaionale

creare()
eliberare()
adaugare()

Operaii

Figura 5.3. Reprezentarea unei clase n UML

Ca i notaie vizual, o interfa este redat printr-un cerc cruia i se ataeaz numele interfeei (Figura
5.4).

IPacient
Figura 5.4. Reprezentarea unei interfee n UML
3.

colaborare - abstractizeaz o familie de clase, interfee i alte elemente care, prin cooperare,
reuesc s asigure un comportament care nseamn mai mult dect suma mecanic a
comportamentelor prilor.
De remarcat faptul c, o colaborare are att dimensiune structural ct i dimensiune comportamental.
Dintr-o perspectiv ceva mai larg privind, o colaborare reprezint implementarea unui ablon care
abstractizeaz o anumit funcie a unui sistem soft. Notaia pentru colaborare este o elips al crei contur este
realizat cu o linie ntrerupt, n interiorul creia se trece numele colaborrii.
Programare
pacient
Figura 5.5. Reprezentarea unei colaborri n UML
4.

Un context de utilizare (use case, n limba englez) - abstractizeaz o colecie de secvene de

aciuni pe care trebuie s le execute un sistem pentru a produce un rezultat care trebuie observat
de un actor particular.
Contextele de utilizare sunt folosite pentru a structura entitile comportamentale ntr-un model UML.
S mai precizm cititorului faptul c un context de utilizare este realizat de ctre o colaborare.
Semantica realizrii va fi discutat tot n acest paragraf. Notaia pentru context de utilizare este o elips
al crei contur este o linie continu, n interiorul creia se trece numele contextului de utilizare (Figura 5.6).
Planifica
re
pacient
Figura 5.6. Reprezentarea unui context de utilizare n UML
Urmtoarele trei tipuri de EFS (clasele active, componentele i nodurile) sunt, ntr-o oarecare msur,
asemntoare claselor, n sensul c sunt descrise ca mulimi de obiecte care partajeaz aceleai atribute, operaii,
relaii i semantici. i totui, exist suficiente elemente care deosebesc aceste trei tipuri de EFS de tipul clas, i
ntre ele nsele, motiv pentru care sunt tratate distinct de ctre notaia UML.
5. clas activ - este o clas ale crei obiecte posed unul sau mai multe procese sau fire de execuie,
ceea ce nseamn c obiectele pot iniia activiti de control.
Aadar, o clas activ este ntocmai ca o clas obinuit, exceptnd faptul c obiectele sale reprezint
elemente al cror comportament este concurent cu comportamentul altor elemente.
Notaia UML pentru o clas activ se deosebete de notaia pentru clas prin linia ngroat a
conturului. De observat, Figura 5.7.
Cititorul bnuiete, probabil, faptul c avem nevoie de clase active pentru a modela soluiile problemelor n
care se apeleaz la multitasking i, n consecin, apar probleme noi legate de sincronizarea proceselor sau firelor
de execuie.
Supervizor pacient
CNP

Iniiere()
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, realizrii uneia sau mai multor interfee.
Exemple de componente: unit-uri Pascal, ierahii de clase C++ specializate n lucrul cu octeii de iruri,
DLL-uri din lumea Windows, pachetele din Java etc.
Notaia UML pentru o component este ilustrat n Figura 6.8.
Evid_Pacient.java

nume component

Figura 5.8. Notaia UML pentru o component

7.

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

Server
Figura 5.9. Notaia UML, minimal pentru un nod
Acestea au fost cele apte tipuri de entiti cu funcii structurale, care formeaz fundamentul structural
al oricrui model UML autentic. Prezentarea pe care am fcut-o a avut ca scop introducerea notaiei pentru cele
apte EFS, semantica complet a conceptelor prezentate i a notaiilor asociate fiind o problem ce urmeaz a fi
pus n discuie, ulterior, n aceast carte sau, de ce nu, n alt carte, care prezint procesul de utilizare efectiv a
notaiei UML pentru rezolvarea unor probleme date.
Entitile cu funcii comportamentale (EFC)
EFC abstractizeaz aspectele dinamice ale unui sistem n cadrul modelelor UML. Prin urmare, EFC
sunt verbe ale modelelor UML (avnd i o reprezentare grafic sugestiv) care ncearc reprezentarea
comportamentului unui sistem, n timp i n spaiu. UML opereaz cu dou tipuri fundamentale de EFC.
1. interaciune - abstractizeaz un comportament care cuprinde o mulime de mesaje schimbate
ntre obiectele unui sistem, ntr-un context particular, n vederea ndeplinirii unui obiectiv
specific.
Prin urmare, la un anumit nivel de abstractizare, comportamentul unei familii de obiecte sau al unei operaii
individuale poate fi specificat ca o interaciune. O interaciune implic o serie de alte elemente, precum mesaje,
secvene de actiuni (comportamentul invocat de mesaje) i legturi ntre obiecte.
Notaia UML pentru mesaj este prezentat n Figura 5.10.
afieaz()

Figura 5.10. Notaia UML pentru mesaj

Dup cum se vede din notaia prezentat n Figura 5.10, sgeata care indic un mesaj ntre dou obiecte
are asociat i numele operaiei invocate.
2. main de stare (n engleza american, state machine) abstractizeaz, de data aceasta ,
comportamentul unui singur obiect sau al unei interaciuni dintre obiecte, pe timpul vieii
acestora, ca succesiune de aciuni-rspuns la anumite evenimente.
Aadar, comportamentul unei clase sau al unei colaborri ntre clase (cadrul natural de reprezentare al
interaciunilor) poate fi specificat cu ajutorul unei maini de stare. O main de stare implic o serie de alte
elemente, precum: stri, tranziii, evenimente (fapte ce pot declana o tranziie) i activiti (rspunsuri la
tranziii). Notaia UML pentru o stare este prezentat n Figura 5.11 (dreptunghi cu colurile rotunde, n interiorul
cruia se afl numele strii i, eventual, substrile asociate.
Ateptare
Figura 5.11. Notaia UML pentru stare

Interaciunile i mainile de stare sunt elemente comportamentale fundamentale, care pot fi incluse ntrun model UML. Semantic vorbind, aceste elemente sunt, n mod uzual, conectate cu alte elemente structurale,
ndeosebi clasele, colaborrile i obiectele.
Entiti cu funcii de grupare (EFG)
EFG reprezint elemente utile n organizarea modelelor UML, reprezentate ca nite casete n care un
anumit model poate fi descompus n ceea ce se consider a fi prile lui componente. Specia fundamental de
EFG este pachetul.
Un pachet este un mecanism de interes general al limbajului UML, utilizat pentru organizarea
elementelor n grupuri de elemente. La diferite nivele de abstractizare, ntr-un pachet pot fi grupate EFS, EFC i
chiar alte EFG, dac este nevoie.
Spre deosebire de componente (care se manifest, cumva, n timpul execuiei unui sistem soft), EFG au
o valoare de ntrebuinare pur conceptual (n timpul procesului de dezvoltare a sistemului). Notaia UML pentru
un pachet este ilustrat n Figura 5.12. Problematica EFG necesit o discuie mai ampl pentru a nelege
ntreaga semantic a subiectului.
Entiti cu funcie de documentare (EFD)
EFD reprezint prile explicative ale modelelor UML. De fapt, acestea sunt comentarii pe care le putei
folosi n descrierea modelelor UML pentru a lmuri anumite aspecte neclare ale acestora sau pentru a aduga
informaii suplimentare despre proprietile acestor modele. EFD sunt reprezentate n UML ca note.
Reprezentarea aferent notelor n UML este ilustrat n Figura 5.13.

Gestiune pacieni
Figura 5.12. Notaia UML pentru conceptul de pachet
Funcia calculeaz
vrsta pacientului
Figura 5.13. Notaia UML pentru conceptul de not
Relaii n UML
UML utilizeaz patru tipuri de relaii pentru a descrie aspectele de natur relaional ale modelelor:
Dependenele;
Asocierile;
Generalizrile;
Realizrile.
Aceste tipuri de relaii reprezint nucleul conceptelor de baz propuse de UML pentru descrierea relaiilor
dintre diferitele tipuri de entiti ale modelelor UML.
1. dependena - abstractizeaz o relaie semantic ntre dou entiti, caracterizat prin faptul c o
schimbare n una dintre ele poate afecta semantic cealalt entitate.
ntr-o astfel de relaie, despre entitatea n care se poate produce schimbarea se spune c este independent,
iar despre entitatea afectat se spune c este dependent. n lumea IS, o astfel de relaie se ntlnete foarte des,
n diferite ipostaze. Notaia UML pentru relaia de dependen este reprezentat n Figura 6.14.

Figura 5.14. Notaia UML pentru relaia de dependen

asocierea - abstractizeaz o relaie structural prin care se descriu legturile dintre obiecte, de
tipuri diferite sau de acelai tip.
Asocierea (i diferitele variaiuni pe tema asocierii) sunt eseniale pentru descrierea relaiilor statice
dintre obiectele unei aplicaii. Notaia UML pentru asociere nseamn, n mod necesar, o linie continu (vezi
Figura 6.15), un nume i, eventual, restricii de cardinalitate i nume de roluri, direcionate sau nu.
2.

0..1
Medic

Asist

*
Pacient
Figura 5.15. Notaia UML pentru asociere

3.

generalizarea - este abstractizarea unei relaii dintre dou concepte UML, compatibile, a crei
semantic este exprimat astfel:
Unul dintre concepte este concept tat, cellalt este concept fiu
Orice element din categoria conceptual tat poate fi substituit de un element din categoria
conceptual fiu. Acest lucru este posibil deoarece un element fiu motenete structura i
comportamentul elementului printe asociat.

Notaia UML pentru generalizare este prezentat n Figura 5.16.

Figura 5.16. Notaia UML pentru relaia de generalizare

4.

realizarea - este abstractizarea unei relaii semantice ntre clasificatori, exprimat astfel: un
clasificator specific nite capabiliti pentru care alt clasificator 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. Aadar, o anumit clas realizeaz o anumit interfa. Notaia UML pentru realizare este prezentat n
Figura 5.17.

Figura 5.17. Notaia UML pentru realizare

Diagrame n UML
n UML, diagramele sunt reprezentri grafice ale unor colecii de elemente (entiti i relaii).
Diagramele UML sunt grafuri ale cror noduri sunt entiti i ale cror arce sunt relaii. Permind asamblarea
diferitelor tipuri de entiti i relaii pentru a obine descrieri ale sistemelor modelate din diferite perspective,
diagramele UML sunt elemente suport puternice pentru abstractizarea i vizualizarea soluiei unui sistem soft.
Dei n teorie se susine c o diagram poate conine orice combinaie de entiti i relaii, n practic se
recomand utilizarea unui set restrns de tipuri de diagrame, care ncearc s acopere toate cerinele legate de
acceptarea pentru sistemele soft a arhitecturii 4+1.
De aceea, cei care popularizeaz UML-ul recomand urmtoarele nou tipuri de diagrame:
Diagrame de clase;
Diagrame de obiecte;
Diagrame de contexte de utilizare;
Diagrame de secven;
Diagrame de colaborare;
Diagrame hri de stare;
Diagrame de activitate;
Diagrame de componente;
Diagrame de desfurare.
Descrierea i exemplificarea modului de utilizare a acestor diagrame, sarcin de care urmeaz s ne ocupm
n continuare, va lmuri problemele eseniale care apar ntr-un exerciiu de modelare UML.
Reguli UML pentru elaborarea de modele UML corecte
Un model corect este semantic autoconsistent i n armonie cu
modelele cu care intr n relaie.
Regulile UML care susin elaborarea de modele corecte se refer la:
Numele entitilor cum putem denumi entitile, relaiile i diagramele;
Domeniul contextul care d neles specific unui nume;
Vizibilitatea cum poate un nume s fie vzut i folosit de alte nume;
Integritatea cum interacioneaz entitile complet i consistent cu alte entiti;
Execuie ce se nelege prin execuia sau simularea unui model dinamic.
Modelele elaborate pe timpul dezvoltrii unui sistem soft fiind n atenia mai multor categorii de participani,
apar situaii n care modelele sunt afectate de:
Omisiuni - anumite aspecte sunt ascunse pentru a simplifica procesul de nelegere al modulului;
Incomplete - anumite elemente pot lipsi cu desvrire;

 Inconsistente - nu este garantat integritatea unui model.

Obinem astfel modele care sunt, n mod deliberat, la nivele diferite de detaliere pe timpul ciclului de via al
sistemelor soft. Regulile UML ncurajeaz dar nu oblig abordarea celor mai importante aspecte care in de
analiz, design i implementare pentru a obine modele perfectibile n timp.
Mecanisme comune n modelarea UML
O construcie, de orice natur, este realizat mai simplu i mai armonios dac sunt respectate anumite
abloane n ceea ce privete modelarea aa-ziselor nsuiri comune.
De exemplu, dac atunci cnd vrem s construim o cas, optm pentru un anumit stil (bucovinean,
maramureean etc.), putem spune c am rezolvat o problem important, n ceea ce privete arhitectura casei.
Aceast situaie se ntlnete i n modelarea UML, care propune patru mecanisme comune pentru utilizarea
lui consistent:
Specificaiile;
Ornamentele;
Separrile comune;
Mecanismele de extindere.
Specificaiile
Probabil, a fost neles faptul c UML este mai mult dect o notaie vizual. n spatele fiecrui tip de notaie
vizual exist ntotdeauna o specificaie care furnizeaz, sub forma unui enun textual, sintaxa i semantica
blocului constructiv asociat notaiei.
n practic, elementele grafice ale notaiei UML sunt folosite pentru a vizualiza sistemul. Specificaiile
UML sunt folosite pentru a exprima detaliile sistemului.
Ornamentele
Cele mai multe entiti au, n UML, o notaie grafic direct i unic, care asigur o reprezentare
vizual a celor mai importante aspecte ale elementelor. De exemplu, notaia grafic pentru o clas este, n mod
deliberat, uor de realizat, dat fiind faptul c la temelia oricrei soluii obiect-orientate se afl modelul claselor.
Notaia UML pentru o clas ocazioneaz, de asemenea, descrierea celor mai importante aspecte: numele clasei,
atributele i operaiile ei. Specificarea unei clase poate, ns, include i alte detalii, precum: caracterul abstract al
clasei, vizibilitatea atributelor i operaiilor, etc. Astfel c, fiecare element al notaiei UML ncepe cu un simbol
de baz, la care se pot aduga o serie de ornamente, specifice acelui simbol. Se va reveni asupra problemei
ornamentelor chiar n acest capitol.
Separrile comune
n modelarea sistemelor obiect-orientate este uzual mprirea (separarea) produselor efortului de
modelare n perechi de abordare.
Mai nti, este foarte important separarea de tipul clas obiect. Situaia caracterizat de aceast separare
este: n timp ce clasa este o abstractizare, un obiect este o manifestare concret a acestei abstractizri .
Astfel, n UML putem ntlni tandemul clase obiecte, ca n Figura 5.18.

Student

Ion : Student

matricol

: Student
Maria
Maria

<<instance Of>>

Student

Figura 5.18. Clas i obiecte

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

ISecretar

DatePersStud.dll

IDecan
Figura 5.19. Interfeele i implementarea lor
Aa cum, probabil c ai ghicit, n Figura 5.19 sunt prezentate dou interfee implementate de o component
DLL. Multe dintre blocurile constructive UML suport genul de abordare prezentat pe relaia interfa /
implementare. De exemplu, colaborrile realizeaz contextele de utilizare, metodele implementeaz operaiile.
Mecanismele de extindere UML
Un limbaj de modelare, nchis din punct de vedere al notaiei, poate ajunge uor n situaia de a nu putea
exprima, cu mijloace recunoscute de toi utilizatorii lui, o anumit semantic din domeniul problemei sau din
domeniul soluiei.
Pentru acest motiv, UML a fost gndit ca un limbaj de modelare deschis-nchis (open-closed), prin
specificarea unor mecanisme de extindere care includ:
Stereotipurile (stereotypes);
Valorile etichetate (tagged values);
Constrngerile (constraints).
Un stereotip extinde vocabularul UML, permind specialitilor s creeze noi genuri de blocuri constructive,
pornind de la unele existente deja.
O valoare etichetat extinde proprietile unui bloc constructiv UML, permind specialitilor s adauge
informaii noi n procesul de specificare a blocului constructiv.
O constrngere extinde semantica unui bloc constructiv UML, permind specialitilor s adauge reguli noi
sau s le modifice pe cele existente.
EventQueue
<<exception>>
{ version=3.2
Overflow
author=ma}

add()
remove()
flush()

{ordered}

Figura 5.20. Mecanismele UML de extindere, pe un exemplu

n figura 5.20 este prezentat un exemplu de clas stereotip (Overflow), aflat n relaie de dependen cu
clasa EventQueue, creia i-au fost adugate informaii referitoare la versiune i autor folosind sintaxa specific
valorilor etichetate i care are o metod (add()), pentru care obiectele cu care lucreaz (evenimentele) sunt
supuse constrngerii {ordered}.

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 colecii de obiecte care partajeaz aceleai atribute, aceleai operaii,
aceleai relaii i aceeai semantic. UML ofer un formalizm grafic pentru reprezentarea unei clase,
asemntor celui din Figura 6.1.
nume clas

Poligon
coordonate

atribute

perimetru()
aria()
afisare()

operaii

Figura 6.1. Notaia UML pentru clas.

Dup cum se poate vedea, notaia propus n Figura 6.1 permite vizualizarea unei abstractizri, independent
de limbajul de programare i de o manier care permite evidenierea celor mai importante pri ale abstractizrii:
numele, atributele i operaiile clasei.
Numele unei clase
Fiecare clas trebuie s aib un nume care o identific n mod unic, printre alte clase. Un nume de clas este
un ir de caractere care se poate prezenta n dou moduri: nume simplu sau nume cu cale. Un nume simplu de
clas se poate observa n Figura 6.2a. Un nume cu cale, asociat unei clase, se poate observa n Figura 6.2b, el
indicnd, ca un prefix la numele clasei, pachetul n care este rezident clasa.
Client
(a)

java::awt::Rectangle
(b)
Figura 6.2. Specificarea numelui unei clae n UML

Un nume de clas poate fi un ir de caractere de orice lungime, care conine litere, cifre i semne de
punctuaie, cu excepia simbolului ::, utilizat pentru a separa numele clasei de pachetul sau lanul de pachete
care o include. Evident, este necesar un compromis rezonabil ntre lungimea numelui i puterea lui de sugestie.
n practic, numele unei clase se obine prin juxtapunerea mai multor cuvinte care pot dezvlui semantica clasei
respective. De exemple, PoligonAbstract, TriunghiEchilateral, FereastraDeDialog, etc. Se observ cum,
pentru mai mult lizibilitate, fiecare cuvnt din structura numelui ncepe cu liter mare.
Atributele unei clase
Un atribut este numele unei proprieti ( a unei clase) care abstractizeaz un domeniu de valori pe care
instanele proprietii le pot lua.
O clas poate avea orice numr de atribute sau, la limit, nici un atribut.
Un atribut desemneaz, astfel, o anumit proprietate a realitii modelate, proprietate partajat de toate
instanele realitii respective. Ca formalizm de reprezentare, atributele sunt listate n compartimentul situat
imediat sub numele clasei, ca n Figura 6.3.
n funcie de nivelul de abstractizare al clasei (conceptualizare, specificare, implementare), atributele pot fi
listate doar ca nume, dar pot fi listate i ca nume, mpreun cu tipul definitor i, eventual, o valoare iniial. ca n
Figura 6.4.

Student
natricol
numePrenume
adresa
dataNasterii

Lista atributelor

Figura 6.3. Atributele unei clase

Aa 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 ncepnd cu liter mare.

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

Lista atributelor

Figura 6.4. Atribute, complet caracterizate

Operaiile unei clase

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

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

Lista operaiilor

Figura 6.5. Operaiile unei clase

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

Student

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

Lista operaiilor

Figura 6.6. Operaii descrise la nivel de signatur

Utilizarea stereotipurilor pentru clasificarea nsuirilor 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 cruia putem mbogi, progresiv, nsi semantica limbajului. Asupra acestui
mecanism de extensie vom mai reveni.
Responsabilitile unei clase
O responsabilitate este abstractizarea textual a unui serviciu furnizat de o clas. Este deja lmurit
faptul c, la definirea unei clase, este foarte important supoziia c toate obiectele acestei clase au acelai
comportament.
Aceast afirmaie, la un nivel de abstractizare mai nalt, nseamn c atributele i operaiile sunt doar
nite elemente-suport pentru ndeplinirea responsabilitilor clasei. Responsabilitile unei clase, n cazul n care
sunt definite, sunt listate ntr-un compartiment situat la baza simbolului grafic al clasei, ca n Figura 6.8
n practic, elaborarea modelului claselor poate ncepe prin specificarea responsabilitilor entitilor
candidate, nregistrate n vocabularul realizat n faza de analiz a cerinelor. n acest scop se pot folosi tehnici
precum card-urile CRC1 sau analiza bazat pe contexte de utilizare. n procesul de rafinare a modelului claselor,
responsabilitile sunt traduse ntr-un set de atribute i operaii care asigur ndeplinirea optim a
responsabilitilor.

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

Student

Responsabilities

...

creare studeni
actualizare date personale studeni
validare date personale studeni

Figura 6.8. Responsabilitile unei clase

6.2

Relaii

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

dependen

Window

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

Event

generalizri
asociere
ConsoleWindow

DialogBox

Control

Figura 6.9. Reprezentarea relaiilor n UML

Relaia de dependen
Aa cum am mai precizat, o dependen este o relaie de utilizare care exprim faptul c o schimbare n
specificarea unei entiti (de exemplu, clasa Event) poate afecta alt entitate care o folosete ( de exemplu, clasa
Window). Dup cum vom vedea n Capitolul 3, exist un numr semnificativ de stereotipuri, aplicabile relaiilor
de dependen dintre entitile unui model UML.
Dac se consider necesar, relaia de dependen poate avea un nume, care ajut la discriminarea ei ntr un context n care mai sunt i alte dependene, ceea ce ajut la referirea mai uoar a dependenei, n caz de
nevoie.
Relaia de generalizare
O generalizare este o relaie ntre o entitate general (numit superclas sau clas printe) i o varietate
specific a acelei entiti (numit subclas sau clas copil)). n literatura de specialitate, generalizarea mai este
desemnat i prin sintagma relaie is a kind of. Generalizarea nseamn c obiectele copil pot fi folosite
oriunde pot apare obiecte printe. Altfel spus, generalizarea ne asigur de faptul c un copil poate fi un substitut
al printelui su, nu i invers. Trivial, dar trebuie s reamintim (pentru cei care nu sunt documentai suficient
asupra paradigmei obiect-orientate) faptul c un copil motenete toate proprietile printelui (n mod esenial,
atributele i operaiile). Adesea, dar nu ntotdeauna, copilul are atribute i/sau operaii adiionale. O operaie a

unui copil care are aceeai signatur cu o operaie a printelui se spune c suprascrie (redefinete) operaia
printelui, procedeu prin care se pun bazele polimorfismului.
Relaia de asociere
O asociere este o relaie structural care specific faptul c instanele unei clase sunt conectate la
instanele altei clase. Conectarea de care am vorbit mai sus, trebuie neleas astfel: dat o instan a a clasei A,
n clasa B poate fi gsit cel puin o instan b, astfel nct perechea (a,b) abstractizeaz o anumit cerin a
modelului n curs de elaborare. ntr-un anumit sens putem vorbi de navigare de la un obiect al unei clase ctre un
obiect al altei clase i invers, dac cele dou clase sunt n relaie de asociere. O asociere la care particip exact
dou clase se numete asociere binar. Dei nu este o situaie uzual, pot exista i asocieri la care particip mai
mult de dou clase. Astfel de asocieri se numesc asocieri n-are. Formalizmul pentru reprezentarea unei asocieri
poate fi dedus analiznd Figura 6.10.
n practic, numele unei asocieri nu este obligatoriu, fiind folosit pentru a spori claritatea modelului.
nume asociere

Lucreaz pentru

Persoana

sensul navigrii

Firma

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

ntregul
agregarea

multipliciti
*
Departament

partea

Figura 6.11. Exemplu de agregare

Dup cum sugereaz i Figura 6.11, agregarea este o relaie care, n esen, nseamn c un obiect al
clasei ntreg const din unul sau mai multe obiecte ale clasei parte n relaia de agregare. Evident c, putem
ntlni i situaii n care clasa ntreg agreg mai multe clase parte. Cred, de asemenea, c este n folosul
cititorului s afle faptul c o agregare nu reprezint nimic altceva dect o potenial relaie ntreg -parte,
nepreciznd nimic n ceea ce privete competenele instanelor ntreg relativ la crearea i distrugerea
instanelor parte.

6.3 Mecanisme comune

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

Ornamentele
Fornd puin exprimarea, dat fiind i lipsa unui cuvnt nou pentru o semantic parial nou, pentru a
conine ct mai mult semantic i pentru a transmite, diferitelor persoane interesate, ct mai mult din aceast
semantic, modelele UML sunt mpodobite cu o serie de elemente adiionale formalizmului de baz.
Ornamentele asociate modelelor UML sunt de dou tipuri: note i ornamente pentru vizualizarea i detalierea
specificrii.
Ne amintim c o not este un simbol grafic folosit pentru redarea constrngerilor sau comentariilor ataate
unui element sau unei colecii de elemente. Formalizmul pentru o not UML poate fi revzut n Figura 6.12.
text simplu
Aceast component
va fi livrat cel mai
trziu n 13/02/04

ncapsulare URL
A se vedea
http://www.rational.com

legtur 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 ataate unuia sau mai multor elemente care fac parte din specificarea
unui model UML. Pe de alt parte, UML permite utilizarea ornamentelor pentru vizualizarea i detalierea
specificrii. De exemplu, se tie c notaia de baz pentru asociere este o linie; atunci cnd situaia o cere,
aceast linie poate fi ornamentat cu detalii, cum sunt rolurile i multiplicitile ataate fiecrui capt al asocierii.
n utilizarea UML, regula general de urmat este: Se pornete cu notaia de baz pentru fiecare element i
se adaug alte ornamente numai dac acestea sunt necesare pentru a furniza informaii importante
pentru nelegera modelului. Majoritatea ornamentelor sunt redate prin plasarea textului n apropierea
elementului vizat sau prin adugarea unui simbol grafic notaiei de baz. Este posibil ca, uneori, s dorii s
adugai unui element detalii mai multe, ceea ce poate fi destul de dificil folosind textul simplu sau simbolurile
grafice. n astfel de situaii, unor entiti precum clasele, componentele i nodurile le putem aduga un nou
compartiment, situat imediat sub compartimentele uzuale, pentru a furniza alte informaii.
Mecanismele UML de extindere
Stereotipurile
Dup cum am vzut, UML furnizeaz un limbaj pentru capturarea i reprezentarea semanticii urmtoarelor
tipuri de entiti; entiti cu funcii structurale, entiti cu funcii comportamentale, entiti cu funcii de grupare
i entiti cu funcii de documentare. Aceste patru tipuri de entiti sunt suficiente pentru majoritatea sistemelor
pe care le modelm. Exist, ns i situaii n care, n domeniul problemei apar aspecte care reclam introducerea
unor semantici noi, folosind n acest scop formalizme asemntoare celor utilizate n cazul blocurilor
constructive primitive. Pentru a reglementa modul n care se procedeaz n astfel de situaii, n UML au fost
specificate mecanismele de extindere. Acestea sunt: stereotipurile, valorile etichetate i constrngerile.
Stereotipurile
Referindu-ne la aria claselor, un stereotip nu este similar cu o clas printe ntr-o relaie de generalizare
printe-copil. Mai degrab, putem gndi stereotipul ca un metatip, ale crui instane sunt clase noi, n sintaxa
UML. Ca un exemplu, dac suntem familiarizai cu modelul de dezvoltare RUP, vom vedea c acesta conine
recomandri precise n ceea ec privete modelarea claselor, existnd stereotipuri pantru trei tipuri fundamentale
de clase: clasele de frontier, clasele cu funcii de prelucrare i clasele cu funcii de control. Fiecare din cele

trei tipuri de clase poate fi considerat un stereotip, care extinde posibilitile de modelare ale UML -ului, ca n
Figura 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 cruia se afl numele concret al modelului.
Valorile etichetate
Fiecare entitate UML are propriul set de proprieti: clasele au nume, atribute i operaii; asocierile au
nume i dou sau mai multe capete cu propriile lor proprieti, etc. Dup cum am vzut, folosim stereotipurile
pentru a aduga soluiei noastre entiti noi. Pentru a aduga proprieti noi entitilor, folosim valorile
etichetate. n practic, valorile etichetate pot fi folosite pentru a pstra diferite informaii despre proprietile
entitilor. Astfel, informaii de interes pentru managementul unui proiect (data crerii unui model, starea
dezvoltrii lui, autorul, etc.) sau informaii de interes n procesul de instalare a unei aplicaii (memoria intern
necesar, memoria extern necesar, limita inferioar a frecvenei procesorului, etc.) sunt dou exemple uzuale
de utilizare a valorilor etichetate. Formalizmul de prezentare a valorilor etichetate este , transparent prezentat n
Figura 6.14.
Dup cum se poate observa n Figura 6.14, valorile etichetate apar ntre acolade ca secvene de tipul:
{<etichet>=<valoare>}
dac informaiile sunt adugate direct pe entitatea vizat, sau, folosind ca suport nota ataat, urmnd aceeai
sintax, dac este vorba de informaii care se refer la mai multe entiti, de exemplu.
Constrngerile
Este de domeniul evidenei, probabil, faptul c orice construcie sintactic n UML are propria ei
semantic. De exemple, ntr-o relaie de generalizare opereaz principiul substituiei care afirm c un obiect al
clasei copil poate substitui un obiect al clasei printe, dar nu i invers. Acest dar nu i invers este o
constrngere, de care trebuie s fim contieni cnd lucrm cu o ierarhie de clase.
Utiliznd constrngerile, putem, de asemenea, s adugm semantici noi modelelor sau s modificm
regulile fundamentale dup care opereaz modelele. n ultim analiz, o constrngere specific o serie de
condiii care trebuie ndeplinite pentru ca modelul s fie corect. Formalizmul dup care adugm
constrngeri modelelor este deductibil din Figura 6.15.
n general, specificarea constrngerilor poate fi realizat folosind un limbaj textual, liber n expresie.
Dac se dorete mai mult rigoare n specificarea constrngerilor se poate apela la OCL (Object
Constraint Language), un standard care nsoete specificarea complet a UML-ului. Acest standard poate
fi gsit n documentaia pus la dispoziie de firma Rational pe site-ul www.rational.com.

autor=Tudor Stelian
terminat=12/10/2001

Server
{procesoare=2}
{aplicatie=serv.exe}

serv.exe
{doarPeServer,
RamSize=600K}

Figura 6.14. Utilizarea valorilor etichetate

Cont

ContFirma

ContPersonal

Firma

Persoana

{XOR}

lucrator
angajat

angajator

Persoana
*

Firma

0..1

ef

{Persoana.angajator=
Persoana.ef.angajator}

Figura 6.15. Exemple de constrngeri

6.4 Diagrame
Introducere
n paragraful 5.3 am precizat deja rolul diagramelor (ca entiti cu funcii de grupare) n organizarea i
vizualizarea blocurilor constructive ale unui model UML. n practic s-a dovedit, deja, faptul c realizarea unor
diagrame de calitate contribuie la o mai bun nelegere, att a soluiei ct i a sistemului modelat. Necesitatea
diagramelor n modelarea UML are o justificare mult mai profund dect cea prezentat mai sus. Una dintre
provocrile importante n procesul de modelare a comportamentului unui sistem se numete stpnirea
complexitii. Exist motive de natur conceptual dar i motive de natur managerial pentru care, n ingineria

softului, se practic abordarea sistemic, cu necesara infuzie de elemente specifice. Aa se face c, la anumite
nivele de abstractizare a soluiei UML a unei probleme, se va vorbi n termeni de sisteme, subsisteme, modele i
diagrame care grupeaz aceste modele dup principii i reguli specifice diferitelor perspective ntlnite n
arhitectura soluiei UML a unui sistem soft. Aa cum am mai spus, n UML exist nou tipuri de diagrame,
utilizate pentru gruparea modelelor care descriu aspectele statice sau dinamice ale unui sistem.
Pentru descrierea aspectelor statice avem:
1.
2.
3.
4.

Diagrame ale claselor

Diagrame ale obiectelor
Diagrame ale componentelor
Diagrame de desfurare

Pentru descrierea aspectelor dinamice avem:

1.
2.
3.
4.
5.

Diagrame ale contextelor de utilizare

Diagrame de secven
Diagrame de colaborare
Diagrame de hri de stare
Diagrame de activitate

Abilitatea de a realiza diagrame de tipurile mai sus precizate, coerente, corecte i eficiente este tot ceea ce i
dorete, n ultim instan, un specialist n IS, n relaia cu UML. Fr aceast abilitate, mnuirea, cu randament,
a 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 nelegem relaiile
invariante dintre componentele sistemului. Referindu-ne la ingineria softului, din perspectiv UML, aspecte
statice ale soluiei unui sistem soft sunt: relaiile dintre clase, interfeele, colaborrile, ansamblul structurat
al componentelor, topologia hard care susine execuia sistemului. Odat definite relaiile dintre clase,
introducem un element de stabilitate, necesar pentru a putea continua efortul de realizare a soluiei. Odat
specificate interfeele, clienii lor se pot ocupa, n linite, de aspectele legate de utilizarea lor, etc..
Diagrame ale claselor
O diagram a claselor expune un ansamblu de clase, interfee i colaborri, mpreun cu relaiile dintre
ele. Diagramele claselor reprezint tipul de diagram cel mai des ntlnit n modelarea sistemelor obiect
orientate. Folosim diagramele claselor pentru a evidenia perspectiva design (structural) a sistemului . De
asemenea, putem observa faptul c diagramele claselor care includ clase active sunt utile pentru a evidenia
aspectele statice ale perspectivei proces a unui sistem.
Diagrame ale obiectelor
O diagram a obiectelor expune un ansamblu de obiecte, mpreun cu relaiile dintre ele. Folosim
diagramele obiectelor pentru a ilustra structuri de date, instantanee statice ale instanelor entitilor din
diagramele claselor. ntr-o oarecare msur, se subnelege faptul c diagramele obiectelor sunt destinate
evidenierii perspectivei design (static) sau perspectivei proces (static) a unui sistem, cum se ntmpl i n
cazul diagramelor claselor, dar lund n obiectiv instane din lumea real. Scopul unor astfel de diagrame este de
a sublinia, prin infuzia aferent de concret, semantica diagramelor claselor la care se raporteaz.
Diagrame ale componentelor
O diagrama a componentelor expune un ansamblu de componente, mpreun cu relaiile dintre ele.
Folosim acest tip de diagram pentru a ilustra aspectele statice ale perspectivei implementaionale a unui
sistem. Diagramele componentelor se afl n legtur cu diagramele claselor, datorit faptului c, n mod normal,
o component se mapeaz pe una sau maai multe clase, interfee sau colaborri.
Diagrame de desfurare
O diagram de desfurare expune un ansamblu de noduri, mpreun cu relaiile dintre ele. Folosim
acest tip de diagram pentru a ilustra aspectele statice ale perspectivei desfurare a hard-ului care susine
execuia unui sistem soft. Diagramele de desfurare se afl n legatur cu diagramele componentelor, datorit
faptului c, n mod uzual, un nod conine una sau mai multe componente.

Diagrame comportamentale
Dup cum am vzut, exist cinci tipuri de diagrame care pot fi folosite pentru a modela dinamica
(comportamentul) unui sistem soft.
1. Diagramele contextelor de utilizare (use case)
Acestea sunt diagrame care organizeaz comportamentul sistemului
2. Diagramele de sceven (sequence diagram)
Acestea sunt diagrame care se focalizeaz pe ordonarea n timp a mesajelor schimbate ntre obiecte.
3. Diagramele de colaborare (collaboration diagram)
Acestea sunt diagrame care se focalizeaz pe organizarea structural a obiectelor, care trimit i primesc
mesaje.
4. Diagramele hri de stare (statechart diagram)
Acestea sunt diagrame care se focalizeaz pe schimbrile de stare ale unui sistem dirijat de evenimente.
5. Diagramele de activitate (activity diagram)
Acestea sunt diagrame care se focalizeaz pe fluxul de control n procesul de trecere de la o activitate la
alta.
Diagramele contextelor de utilizare
O diagram context de utilizare expune un ansamblu de contexte de utilizare i actori (care pot fi
socotii un gen special de clas), mpreun cu relaiile eferente. Putem folosi diagramele context de utilizare
pentru a ilustra aspecte statice ale contextelor de utilizare a unui sistem (diferite tipuri de relaii ntre
contextele de utilizare) dar, mai ales, pentru a prefigura organizarea i modelarea comportamentului unui
sistem.
Diagrame de secven
O diagram de secven este o diagram de interaciune, care evideniaz ordonarea n timp a mesajelor
care rezolv problemele de comunicare dintre obiectele unei aplicaii. Astfel c, o diagram de secven expune
un ansamblu de obiecte i distribuia temporal a mesajelor, trimise i primite, de ctre aceste obiecte. Obiectele,
n mod uzual au nume, pot fi i instane anonime ale claselor, dar pot reprezenta i instane ale altor tipuri de
entiti precum: colaborri, componente sau / i noduri. Evident, utilizm o diagram de secven pentru a
reprezenta perspectiva dinamic a unui sistem.
Diagrame de colaborare
O diagram de colaborare este o diagram de interaciune care pune accent pe organizarea structural a
obiectelor care trimit sau primesc mesaje. O diagram de colaborare expune un ansamblu de obiecte, legturile
dintre aceste obiecte i mesajele trimise sau primite de aceste obiecte. n mod uzual, obiectele au un nume, pot fi
instane anonime ale claselor, dar pot fi i instane ale altor tipuri de entiti, precum colaborri, componente
sau/i noduri. O diagram de colaborare este, de asemenea, util pentru a reprezenta perspectiva dinamic a unui
sistem.
Diagrame hri de stare (DHS)
O DHS este o main de stare n structura creia intr elemente precum: strile obiectelor, tranziiile,
evenimentele i activitile care pot fi asociate acestor obiecte. Evident, i DHS sunt importante pentru a
reprezenta perspectiva dinamic a unui sistem. Mai mult, putem spune c DHS sunt utile pentru a accentua
comportamentul dirijat de evenimente al unui obiect, lucru absolut necesar n modelarea sistemelor
reactive.
Diagrame de activitate
O diagram de activitate expune fluxul activitilor din interiorul unui sistem (flux care poate fi
secvenial sau ramificat) precum i obiectele asupra crora acioneaz, sau de care sunt demarate aceste activiti.
Diagramele de activitate sunt importante pentru modelarea funciei unui sistem, ca flux de control, n dinamica
activitilor unui obiect sau a unui ansamblu de obiecte-partenere la rezolvarea unei probleme.

Diagrame ale claselor

Diagrama claselor este tipul de diagram care nu poate lipsi din soluia obiect orientat a unui sistem
soft. Cum am mai spus, o diagram a claselor este o diagram care expune un ansamblu de clase, interfee i
colaborri precum i relaiile dintre acestea. Formalizmul grafic de reprezentare al unei diagrame a claselor se

exprim sintetic n formula colecie de noduri i arce. O diagram de clase are un nume (ca orice alt tip de
diagram UML) i o reprezentare grafic, care depinde de structura entitilor coninute:
clase (prezen obligatorie i esenial n orice diagram a claselor);
interfee (prezen strict necesar cnd se modeleaz n spiritul obiectelor (componentelor)
programabile, care separ net interfeele de implementarea lor;
colaborri (este vorba de colaborri din perspectiv structural, care pot fi numite piesele mari ale
unei diagrame a claselor);
dependene, generalizri, relaii de asociere.
Asemenea altor tipuri de diagrame, diagramele claselor pot conine note i constrngeri. Dac necesitile de
abstractizare o impun, diagramele claselor pot conine pachete sau subsisteme, fiecare dintre acestea fiind
utilizate pentru a grupa elemente ale modelului n curs de elaborare, obinndu-se blocuri constructive cu o
semantic specific, accesibil unui anumit tip de beneficiar. Uneori, diagramele claselor pot conine i
instane.
ncercnd un rspuns la ntrebarea Pentru ce elaborm diagramele claselor?, reamintesc faptul c
intenia lor declarat este de a modela aspectele statice ale perspectivei design (structurale). Mergnd ceva mai
departe, trebuie s subliniez faptul c cerinele funcionale ale unui sistem soft trebuie s se mapeze
convenabil peste ansamblul modelelor care compun perspectiva design. De aceea se obinuiete s se afirme
c stabilitatea structural a design-ului static este esenial pentru longevitatea i calitatea unei soluii .
Din punctul de vedere al practicii, utilizm diagramele claselor n una din situaiile urmtoare:

Suntem preocupai de modelarea vocabularului sistemului

Dorim s modelm o colaborare
Dorim s modelm schema logic a unei baze de date

Modelarea vocabularului unui sistem

Aceast activitate implic o serie de decizii relativ la abstraciile care sunt pri componente ale sistemului
n curs de modelare i care vor rmne n afara frontierei sistemului. Folosim diagrame de clase pentru a
vizualiza i specifica aceste abstracii i responsabilitile lor n cadrul sistemului.
Modelarea unei colaborri
O colaborare este o comuniune de clase, interfee i alte elemente care lucreaz mpreun pentru a asigura
un comportament, care nseamn mai mult dect suma mecanic a comportamentelor elementelor care particip
la colaborare (putem vorbi, astfel, despre necesitatea valenelor sinergetice ale unei colaborri). Folosim
diagrame de clase pentru a vizualiza i specifica astfel de colaborri. Un exemplu de colaborare, simpl, poate fi
urmrit n Figura 6.16. Figura 6.16 prezint un set de clase, considerate eseniale pentru implementarea unui
robot autonom. Figura se focalizeaz asupra claselor implicate n mecanismul de deplasare a robotului pe un
traseu. Evident, exist mai multe clase implicate n simularea comportamentului unui robot autonom. Diagrama
din Figura 36 se concentreaz asupra abstraciilor care sunt direct implicate n deplasarea robotului. Ne putem,
lesne, imagina c exist i abstracii preocupate, de exemplu, de gestiunea conflictelor care pot apare n timpul
deplasrii robotului, n anumite condiii de mediu. Vor exista, prin urmare, i alte colaborri n mulimea claselor
care descriu, din punct de vedere static, comportamentul unui robot autonom. Pentru a simplifica procesul de
nelegere a sistemului, este recomandabil procedeul separrii mai multor colaborri, cu relativ coeziune intern
i obiective specifice de ndeplinit.
Modelarea schemei logice a unei baze de date
Prin schem logic a unei baze de date nelegem rezultatul proiectrii conceptuale a bazei de date (De
exemplu, modelul relaional al unei baze de date, adus la o form normal convenabil). Sunt numeroase
aplicaiile n care
avem nevoie de asigurarea persistenei informaiilor, utiliznd baze de date relaionale sau baze de date obiect
orientate. Schema logic a unei baze de date poate fi modelat folosind diagrame de clase, ca n Figura 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 operaiilor utile n manipularea obiectelor unei clase, n clasa de nivel de persisten
imediat superioar (cum este cazul n relaia dintre clasa Facultate i clasa Catedra).

AgentTraseu

SenzorColiziuni

Responsabilities
cutare traseu
evitare obstacole

Driver

Motor de Crm

MotorPrincipal

Motor

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

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

Facultate
{persistent}
nume:TNume
adresa:string
adaugstud()
stergstud()
citestestud()
()

Ar
e

1
1..*
Angaja
t la

Catedr
{persistent}
nume:TNume
adaugProf()
stergProf()

Profesor
{persistent}

1..
*

nume:TNume

nmatric
ulat

Pred

*
Student
{persistent}
nume:TNume
matricol:integer

Curs
{persistent}

Frecvent
eaz

nume:TNume
codCurs:integer

Figura 6.17. Modelarea schemei logice a unei baze de date

Cteva observaii de luat n seam cnd elaborm o diagram a claselor
O diagram a claselor bine structurat va ine cont de urmtoarele cerine:

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

Asocierea unei diagramei de clase cu un nume sugestiv (care s deconspire semantica diagramei);
Expunerea elementelor diagramei astfel nct s reducem la minimum liniile care se intersecteaz;
Folosirea notelor i a culorilor, ca prghii vizuale de dirijare a ateniei asupra aspectelor importante ale
diagramei.

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

7.2 Concepte vehiculate n modelarea interaciunilor

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

mesaj

CitesteUrmNote()

1:PrelNotMat(n)
f:Foaia_Matricola

n:Note
{ordered}

obiect

legtur

obiect
Figura 7.1. Mesaje, legaturi i secvenierea mesajelor

De exemplu, subsistemul Planificarea activitii didactice din cadrul sistemului informaional al unei
faculti este contextul n care instane ale unor clase, precum StatDeFuncii, PlanDenvmnt,
FormaieDeLucru vor interaciona pentru a contribui la rezolvarea problemei orarului semestrial al grupelor
de la fiecare specializare i, de ce nu, al fiecrui profesor n parte.
Interaciuni ntre obiecte descoperim i n procesul de implementare a unei operaii. Parametrii unei operaii,
orice variabil obiect local operaiei i orice obiecte globale (dar nc vizibile operaiei) pot interaciona pentru
a materializa algoritmul corespunztor implementrii operaiei.

Astfel, invocarea operaiei suma() care simuleaz adunarea a dou numere mari, fiecare numr fiind o
instan a clasei NumarMare, este evident c poate fi implementat astfel nct invocarea s aib sintaxa:
nr1.suma(nr2)
ceea ce inseamn interaciune ntre obiectul global nr1, obiectul transmis prin lista de parametrii ( nr2 ) i
un obiect local operaiei, folosit pentru a genera obiectul sum pe care l va returna operaia suma().
n al treilea i ultimul rnd, descoperim interaciuni n contextul unei clase. Altfel spus, putem folosi
interaciunile pentru a vizualiza, specifica, construi i documenta semantica unei clase. Revenind la exemplul
clasei NumarMare, pentru a ilustra comportamentul obiectelor acestei clase, putem imagina interaciuni care
arat cum colaboreaz atributele acestei clase pentru a permite ndeplinirea responsabilitilor asumate de clas,
la specificare.

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

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

Persoana
1..*
afectare (d:Departament)

angajat

*
angajator

Firma

afectare(financiar)
p:Persoana

:Firma
Figura 7.2 Asociere i legtur

Mesaje
Presupunem c avem o colecie de obiecte i un set de legturi care conecteaz aceste obiecte. Un astfel de
model este un model static care poate fi asimilat cu o diagram de obiecte. Diagramele de obiecte modeleaz
starea coleciei de obiecte, la un moment dat i sunt folositoare atunci cnd dorim s vizualizm, s specificm,
s construim sau s documentm o structur static de obiecte.S presupunem, acum, c dorim s modelm
schimbarea strii unei colecii de obiecte de-a lungul unei perioade de timp.
Dac, prin absurd, am putea imagina un procedeu de fotografiere a coleciei de obiecte, la intervale succesive
de timp, atunci ar trebui s observm: obiecte care schimb mesaje ntre ele, provoac evenimente i invoc
operaii. n plus fa de perspectiva asociat scenariului de mai sus, ne putem propune vizualizarea explicit a
strii curente i a rolului instanelor individuale.

Un mesaj este specificarea unei comunicri ntre obiecte, care transmite informaia necesar pentru
producerea unei activiti. Primirea unei instane mesaj poate fi considerat o instan a unui eveniment. Ca
urmare a formulrii unui mesaj, o aciune rspuns va fi declanat. O astfel de aciune poate produce o schimbare
de stare.
n UML pot fi modelate urmtoarele tipuri de aciuni:
Call invocarea unei operaii a unui obiect; un obiect i poate transmite lui nsui un mesaj, ceea ce
este interpretat ca invocare local a unei operaii;
Return ntoarcerea unei valori la apelant;
Send expedierea unui semnal ctre un obiect;
Create crearea unui obiect;
Destroy distrugerea unui obiect; un obiect se poate, la nevoie, autodistruge.
UML ofer o notaie care permite deosebirea, sub aspect vizual, a acestor tipuri de aciuni, care pot fi
asociate unui mesaj. O prim prespectiv asupra acestei notaii poate fi observat n Figura 7.3, care este,
anticipnd, o diagram de secven.
c:Client

p:AsistentPlanificare

<<create>>

:AgentBilete

create
setItinerar(i)

calculRuta()

call

call (invocare
local)

ruta
return

destroy

<<destroy>>
notificare()

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

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

2:selectN(S)

s:Student

2.2:Insert(m)

n:Note

2.2

f:FoaieMaricola

2.1:m=CalcMed()

Figura 7.4. Secven procedural

Mai puin uzuale, dar, evident posibile sunt fluxurile de control plate, care se redau folosind o sgeat
asemntoare celei din Figura 7.5.
1:procesare(p)

p:Persoana

o:OreLucrate

2:generare(o)

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

Crearea, modificarea i distrugerea obiectelor

n majoritatea cazurilor, obiectele care particip ntr-o interaciune exist atta timp ct exist i
interaciunea. Totui, n anumite interaciuni, obiectele pot fi create i/sau distruse n intervale de timp cuprinse
strict ntre nceputul i terminarea interaciunii. La fel stau lucrurile i n cazul legturilor dintre obiecte. Pentru a
indica faptul c un obiect sau o legtur intr ntr-o interaciune i/sau prsete interaciunea, putem ataa
elementului vizat una din urmtoarele constrngeri:
new - specific faptul c instana sau legtura este creat pe timpul execuiei inetraciunii care o
include;
destroyed - specific faptul c instana sau legtura este distrus nainte de terminarea execuiei
interaciunii care o include;
transient - specific faptul c instana sau legtura este creat pe timpul execuiei interaciunii care o
include, dar este distrus nainte de terminarea execuiei.
n sfrit, dac ntr-o interaciune, un obiect suport modificri ale valorilor atributelor lui, modificri de
stare sau de rol, fiecare variant a obiectului poate apare pe aceeai linie a vieii, variantele diferite putnd fi,
eventual, conectate cu mesaje marcate de stereotipul become.

Reprezentarea unei interaciuni

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

7.3 Contexte de utilizare

7.3.1 Elemente introductive
Dei nu au explicitat ntotdeauna acest lucru, specialitii n ingineria softului au acionat conform
principiului: nainte de a realiza un lucru nou, trebui s hotrti cum l vei folosi (= care este valoarea lui
de ntrebuiare)?
Pare de neconceput, dar adevrul este c mult vreme nu s-a sesizat importana covritoare a
problematizrii i formalizrii temeinice a principiului mai sus formulat. Specificare de cerine s-a fcut, ntr-o
form sau alta, dintotdeauna n industria softului. Ceea ce separ optica UML, n ceea ce privete specificarea
cerinelor, de alte limbaje de modelare este unghiul din care se face specificarea cerinelor. UML spune
rspicat: nainte de a gndi la soluia unui sistem soft, determin, cu maximum de acuratee, tipul
utilizatorului acestui sistem soft.
ncerc s sugerez faptul c tipul utilizatorului este o abstracie n care se reflect o serie de cerine
funcionale specifice dar i o serie de cerine aa zis nefuncionale. Un sistem soft burduit cu cerine
funcionale, expuse ignornd cele mai elementare reguli de proiectare a unor interfee ergonomice, nu va putea
nfrunta niciodat un sistem echivalent funcional dar cu interfaa ergonomic.
Dup cum sugereaz i perspectiva UML asupra arhitecturii unui sistem soft, n centrul efortului de
dezvoltare a soluiei unui sistem soft, utiliznd UML, se afl perspectiva context de utilizare (use case).
Perspectiva context de utilizare va descrie comportamentul unui sistem soft aa cum este el vzut de ctre enduser-i, analiti i tester-i.
Un element cheie n crearea contextelor de utilizare este abilitatea de a spune ce face contextul de utilizare
fr a specifica nimic despre implementarea lui. Astfel c putem concluziona faptul c un context de utilizare
specific un comportament dorit (de end-user-i), fr a impune nimic relativ la modul n care va fi implementat
acest comportament. Marele ctig al unui astfel de demers const n faptul c un context de utilizare permite, n
egal masur utilizatorilor finali i experilor n domeniu, s comunice cu specialitii n ingineria softului, care
lucreaz la soluia sistemului soft, n cadrul creia a fost specificat contextul de utilizare.
Pentru moment, un context de utilizare descrie un set de secvene, n care fiecare secven reprezint
interaciunea entitilor din afara sistemului (actorii lui) cu sistemul nsui (i abstraciile lui eseiale) . De
fapt, comportamentele astfel specificate sunt funcii de nivel sistem, utilizate pentru a vizualiza, specifica,
construi i documenta comportamentul scontat al sistemului n timpul fazei de identificare i analiz a cerinelor.
Un context de utilizare reprezint o cerin funcional a sistemului ca ntreg. Ca un exemplu, un
context de utilizare important ntr-o firm care produce automobile este Gestiunea vnzrilor.
Un context de utilizare implic interaciunea dintre actori i sistem. Un actor reprezint un set coerent de
roluri, pe care utilizatorii contextului de utilizare le joac n timp ce interacioneaz cu acesta. Poate fi
actor o fiin uman, un alt sistem soft sau un anumit tip de sistem automat, capabil de interaciune.
n majoritatea proceselor de dezvoltare a unor sisteme soft gsim contexte de utilizare care sunt versiuni
specializate ale altor contexte de utilizare, contexte de utilizare care sunt considerate ca pri ale altor contexte de
utilizare i contexte de utilizare care extind comportamentul unor contexte de utilizare, care definesc
miezul/coloana vertebral a comportamentului sistemului. Pentru a clasifica i organiza comportamentele
contextelor de utilizare, n spiritul reutilizrii, apelm la cele trei tipuri de relaii, mai sus precizate:
generalizarea, includerea i extinderea.
Un context de utilizare ndeplinete, n mod normal, o sarcin concret. Din perspectiva unui actor dat, un
context de utilizare poate efectua nite calcule, poate furniza nite rezultate, poate prelua nite date de intrare,
etc.
Contextele de utilizare pot fi identificate la nivelul ntregului sistem, dar i la nivelul componentelor
sistemului (subsisteme, clase, interfee).
n fiecare caz este important s reinem urmtoarea idee: Contextele de utilizare reprezint comportamentul
scontat al sistemului sau al componentelor acestuia, furniznd, n acelai timp, elemente fundamentale pentru
testarea acestor componente n timpul procesului de dezvoltare. Contextele de utilizare aplicate la nivelul
subsistemelor sunt surse ideale pentru testele desfurate asupra soluiei n curs de elaborare.
Aplicate la nivelul ntregului sistem, contextele de utilizare sunt surse excelente pentru efortul de integrare i
testare a sistemului.
UML furnizeaz o reprezentare grafic simpl pentru actori i contextele de utilizare. Aceast notaie
permite vizualizarea unui context de utilizare separat de realizarea lui i n comuniune cu alte contexte de
utilizare. Fundamentele notaiei aferente contextelor de utilizare sunt prezentate n Figura 7.6.

context de
utilizare

actor

Consultare
planuri de
invatamant
Decan
nume actor

nume context de utilizare

Figura 7.6. Notaia UML pentru actori i contexte de utilizare

7.3.2 Concepte UML din sfera contextelor de utilizare

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

Numele contextelor de utilizare

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

Validare
utilizator

nume cu cale

Financiar::PreluarePontaj

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 cnd
interacioneaz cu acesta. n mod obinuit, un actor reprezint un rol pe care o fiin uman, un dispozitiv
periferic sau chiar alt sistem l joac n relaia cu sistemul cruia i este asociat contextul de utilizare cu care
comunic actorul. De exemplu, un lucrtor la o banc ar putea, abstractizat ca actor, s joace rolul de Agent-demprumuturi; dac, pe de alt parte, suntem interesai s abstractizm rolul unui client n relaia cu banca,
putem reflecta asupra unui actor numit Client. O instan a unui actor reprezint o interaciune individual
specific cu sistemul n cauz. Dei n modelele UML apar actori, acetia nu sunt considerai pri ale sistemului,
fiind rezideni n afara sistemului. Reprezentai grafic sub forma unor omulei stilizai, actorii suport, atunci
cnd este cazul relaia de generalizare, ca n Figura 7.8.
Actorii pot fi conectai la un context de utilizare numai prin asociere. O asociere ntre un actor i un context
de utilizare precizeaz faptul c ntre aceste entiti exist o relaie de comunicare, n sensul c fiecare poate
trimite sau primi mesaje.
S mai subliniem faptul c, apelnd la mecanismele UML de extensie putem stereotipiza un actor pentru a
introduce o notaie diferit, n ideea c aceasta reprezint o replic vizual mai adecvat scopurilor noastre de
moment.

Contextele de utilizare i fluxurile de evenimente

Un context de utilizare descrie ce face un sistem dar nu specific cum face sistemul ceea ce are de fcut. n
general, n procesul de modelare a soluiei unei probleme, este foarte important abilitatea de a distinge interfaa
unui sistem ( ce face? ) de implementarea lui (cum face?).

actor
Client
generalizare

actor
ClientPersoanaFizi
ca

ClientPersoanaJuridica

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 neiniiat s l poat nelege uor. Cnd se redacteaz acest flux de
evenimente, trebuie s specificm cum i cnd ncepe i se termin contextul de utilizare, cnd interacioneaz
contextul de utilizare cu actorii i ce obiecte sunt schimbate, fluxul principal de evenimente, precum i fluxurile
alternative de evenimente.
Exemplificm cu un scenariu asociat contextului de utilizare ValidareUtilizator, din cadrul unui sistem soft
care gestioneaz o reea de bancomate.
Flux principal de evenimente: Contextul de utilizare ncepe n momentul
n care sistemul invit Clientul s introduc codul PIN. Clientul poate
introduce, n acest moment, codul PIN, de la tastatur. Clientul termin de
introdus codul PIN prin apsarea butonului Enter. Sistemul verific
validitatea codului PIN. Dac codul PIN este valid, sistemul confirm
introducerea codului PIN, ceea ce nseamn terminarea contextului de
utilizare.
Flux excepional de evenimente: Clientul poate anula o tranzacie n
orice moment prin apsarea butonului Cancel, fapt care restarteaz
contextul de utilizare. ntr-o astfel de situaie nu se efectueaz nici o
modificare asupra contului Clientului.
Flux excepional de evenimente: Clientul poate terge codul PIN, n
orice moment care precede terminarea introducerii prin apsarea tastei
Enter avnd astfel posibilitatea s reia introducerea codului PIN.
Flux excepional de evenimente: Dac Clientul introduce un cod PIN
invalid, contextul de utilizare este restartat. Dac acest lucru se
ntampl de trei ori la rnd, sistemul anuleaz ntreaga tranzacie,
mpiedicnd Clientul s mai interacioneze cu bancomatul timp de 60 secunde .

Contextele de utilizare i scenariile

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

Candidaii admii, n urma unei sesiuni de admitere, pot fi nmatriculai, la o anumit

specializare;

2.

Studenii admii la aceeai specializare n alte universiti, pot fi nmatriculai, n anumite

condiii;
3.
Studenii admii la specializri nrudite ca profil, n aceeai universitate, pot fi nmatriculai, n
anumite condiii, etc.
Este evident faptul c descrierea contextului de utilizare nmatriculareStudeni trebuie s ia n consideraie
mai multe variante, fiecare variant avnd asociat propria secven de aciuni. n acest caz, fiecare secven se
numete scenariu. Vom numi scenariu o secven specific de aciuni care ilustreaz o variant de
comportament a unui context de utilizare. Din alt perspectiv privind lucrurile, un scenariu este, n relaia cu
contextul de utilizare gazd, ceea ce este un obiect n relaia cu clasa lui definitoare.

Contextele de utilizare i colaborrile

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

Consultare
planuri de
nvmnt

Gestiune
planuri

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 inspiraiei.

Organizarea contextelor de utilizare

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

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

Relaia de includere
O relaie de includere ntre contexte de utilizare se refer la faptul c un context de utilizare de baz
ncorporeaz explicit comportamentul unui alt context de utilizare la o locaie specificat n baz .
Contextul de utilizare inclus nu poate opera singur niciodat, ci doar instaniat ca parte a unui context de utilizare
de baz, care l include.
Folosim relaia de includere pentru a evita descrierea aceluiai flux de evenimente de mai multe ori, prin
descrierea comportamentului comun ntr-un context de utilizare separat, care va fi inclus n unul sau mai multe
contexte de utilizare de baz. O relaie de includere se reprezint ca o relaie de dependen marcat cu
stereotipul include. n descrierea asociat contextului de utilizare de baz, includerea este marcat ca n
exemplul de mai jos.
Fluxul principal de evenimente:
Preluare nume utilizator i parol.
(Validare parol).
Configurare sesiune.
Start sesiune.

include

Relaia de extindere
O relaie de extindere ntr contexte de uilizare se refer la faptul c un context de utilizare de baz
ncorporeaz implicit comportamentul unui alt context de utilizare, la o locaie specificat indirect de
contextul de utilizare care realizeaz extinderea.
Folosim relaia de extindere pentru a modela o parte a unui context de utilizare pe care utilizatorul o percepe
ca fiind un comportament opional al sistemului. n acest mod, separm comportamentul opional de
comportamentul imperativ.
O relaie de extindere este redat ca o relaie de dependen, marcat cu stereotipul extend. Punctele de
extensie pot fi precizate ca simple etichete n fluxul principal de evenimente, ca mai jos:
Fluxul principal de evenimente:
include (Validare parol).
Configurare sesiune( setare_drepturi_suplimentare).
Start sesiune.
n exemplul de mai sus setare_drepturi_suplimentare este un punct de extensie. Ideea este c,
pentru un utilizator obinuit se face validarea parolei, configurarea standard a sesiunii i nceperea sesiunii.
Pentru un utilizator cu privilegii, va fi executat un context de utilizare care permite stabilirea resurselor
suplimentare necesare utilizatorului.

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 hri de stare, diagramele de activitate). Diagramele de contexte de utilizare sunt
eseniale pentru modelarea comportamentului unui sistem, subsistem sau al unei clase. Fiecare diagram de
contexte de utilizare expune un set de contexte de utilizare, mpreun cu actorii asociai lor, precum i relaiile
dintre aceste elemente.

Concepte UML utilizate n sfera diagramelor de contexte de utilizare

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

Coninutul unei diagrame de contexte de utilizare

n mod uzual, diagramele de contexte de utilizare conin:
Contexte de utilizare
Actori
Relaii de dependen, generalizare i/sau asociere.
Ca oricare alt tip de diagram, ele mai pot conine note i constrngeri.

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

Scurt not, relativ la ingineria direct i invers a diagramelor UML

Ingineria direct este procesul de transformare a unui model n cod, n conformitate cu limbajul ales pentru
implementare, transformare realizat de ctre un tools care nelege modelarea UML.
Ingineria invers este operaia prin care, pornind de la cod, putem obine modelul UML asociat.
Ambele operaii urmresc asigurarea unei mapri benefice a soluiei UML a unei probleme, peste soluialimbaj de implementare int i invers. Avantajele sunt evidente, att n cazul ingineriei directe ct 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, avnd
corespondene la nivelul sistemului executabil), diagramele de contexte de utilizare sunt puin diferite, n sensul
c ele mai mult reflect dect specific implementarea unui sistem, subsistem, etc. Un context de utilizare
descrie cum se comport un element, nu cum este implementat comportamentul, motiv pentru care nu poate fi
supus, n mod natural unei operaii de inginerie direct sau invers.

7.5 Diagrame de interaciune

Diagramele de secven i diagramele de colaborare numite, mpreun, diagrame de interaciune, sunt,
dup cum am mai spus, dou din cele cinci tipuri de diagrame folosite de UML pentru modelarea aspectelor
dinamice ale sistemelor.
Diagramele de interaciune sunt importante nu doar pentru modelarea aspectelor dinamice ale unui sistem ci
i pentru obinerea codului executabil, att prin inginerie direct ct i prin ingineria invers.

Conceptele vehiculate n procesul de elaborare i

nelegere a diagramelor de interaciune
O diagram de interaciune expune o interaciune, determinat de o mulime de obiecte, mpreun cu
relaiile dintre ele, inlcuznd i mesajele care pot fi schimbate ntre aceste obiecte.
O diagram de secven este o diagram de interaciune care pune accent pe ordonarea n timp a mesajelor. Ca
formalism de reprezentare, o diagram de secven poate fi asimilat cu un tabel care expune obiectele aranjate
de-a lungul axei absciselor i mesajele ordonate dup evoluia n timp de-a lungul axei ordonatelor.
O diagram de colaborare este o diagram de interaciune care pune accent pe organizarea structural a
obiectelor care trimit sau recepioneaz mesaje. Ca formalism de reprezentare, o diagram de colaborare este o
colecie de noduri i arce.
S mai precizez, n aceast faz a prezentrii, faptul c, asemenea tuturor tipurilor de diagrame, diagramele de
interaciune au un nume i un coninut grafic, care, de altfel, face distincia ntre diagramele de interaciune i
alte tipuri de diagrame.

Coninutul unei diagrame de interaciune

n mod uzual, o diagram de interaciune conine:

obiecte
legturi
mesaje

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

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

Obiecte
s:Student

m:FoaieMatricola

n:Note

f:FluxFoiMatricole

Timpul

<<create>>

return
prelNote(m)

setDatePer()

insert(m)
<<destroy>>

linia vieii

Figura 7.10. Diagram de secven

n mod normal, obiectul cel mai din stnga va fi obiectul care declaneaz interaciunea, urmat, spre dreapta,
de celelalte obiecte, n ordinea participrii la interaciune. Urmeaz, precizarea mesajelor pe care aceste obiecte
le expediaz i le recepteaz, de-a lungul axei ordonatelor, figurat, de asemenea, simbolic.
Alinierea mesajelor se face, de sus n jos, n ordinea cresctoare a timpului n care sunt emise, obinndu-se
o redare vizual clar a fluxului de control, n timp.
Diagramele de secven au dou caracteristici care le deosebesc de diagramele de colaborare.
Mai nti, este vorba despre linia vieii obiectului. O linie a vieii unui obiect este o linie vertical
ntrerupt, care reprezint existena unui obiect de-a lungul unei perioade de timp. Majoritatea obiectelor care
apar ntr-o diagram de interaciune vor avea durata de via ct timp exist interaciunea, prin urmare, aceste
obiecte vor fi aliniate n partea de sus a diagramei; pentru aceste obiecte linia vieii acoper toat verticala
diagramei, ncepnd de la obiect n jos. Pot exista i obiecte care sunt create pe timpul interaciunii, la primirea
unui mesaj purtnd marca stereotipului create. Pentru aceste obiecte linia vieii ncepe din momentul
receptrii mesajului (a se observa linia vieii pentru obiectul m, n Figura 76). Obiectele pot fi distruse pe timpul
interaciunii. Linia vieii pentru un astfel de obiect se termin odat cu primirea mesajului purtnd marca
stereotipului destroy, moment marcat prin prezena unui X lrgit, care puncteaz terminarea liniei vieii (a
se observa linia vieii pentru obiectul m, n Figura 7.10).
n al doilea rnd, este vorba despre focalizarea controlului pe un obiect. Focalizarea controlului pe un obiect
este indicat printr-un dreptunghi nalt i de lime mic, prin care se figureaz perioada de timp n care un
obiect execut o aciune, direct sau dintr-o procedur subordonat. Partea de sus a dreptunghiului coincide cu
startul aciunii; partea de jos este asociat cu terminarea aciunii i poate fi nsoit de un mesaj de tip return
(cum se ntmpl n Figura 7.10, la terminarea aciunii obiectului n; de observat i forma particular a sgeii n
cazul unui mesaj de tip return).
Imbricarea focalizrii controlului (datorit apelurilor recursive, apelului unei self-operaii, etc.) poate fi
redat cu ajutorul unor dreptunghiuri desenate uor la dreapta focus-ului printe, ca n Figura 7.11.

print()

Figura 7.11. Imbricarea focalizrii controlului

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

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

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

Scurt not relativ la ingineria direct i invers a diagramelor de interaciune.

Ingineria directa (=obinerea codului pornind de la model) este posibil pentru ambele tipuri de diagrame
de interaciune, ndeosebi, atunci cnd contextul diagramei este o operaie. Cantitatea i acurateea codului
generat depinde att de inteligena softului care proceseaz modelul (n cazul nostru diagrama de interaciune)
ct i de cantitatea i acurateea informaiei coninut de model.
Este previzibil faptul c ne aflm ntr-un stadiu de abstractizare n care mai sunt nc muli pai de fcut
pentru a mapa eficient modelul pe codul care l implementeaz.
Ingineria invers (=crearea modelului pornind de la cod) este, de asemenea, posibil, pentru ambele tipur i
de diagrame de interaciune, ndeosebi atunci cnd codul n cauz este implementarea unei operaii.

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 situaii, aceasta nseamn modelarea pailor secveniali (uneori concureniali) ai unui proces de calcul.
De asemena, putem folosi diagrame de activitate pentru a modela trecerea unui obiect dintr-o stare n
alta, prin punctele specifice fluxului de control.
Diagramele de activitate pot fi utilizate pentru a vizualiza, specifica, construi i documenta aspecte
dinamice ale unei societi de obiecte sau pentru a modela fluxul de control specific unei operaii. n vreme
ce diagramele de interaciune pun accent pe fluxul de control fundamentat pe trecerea, ntr-o anumit ordine, de
la un obiect la altul, diagramele de activitate pun accent pe fluxul de control care urmrete trecerea, ntr-o
anumit ordine, de la o activitate la alta. Prin activitate desemnm o prelucrare neatomic, n curs de
desfurare n interiorul unei maini cu stri. Calculatoarele reale sunt exemple remarcabile de maini cu
stri, privite, de exemplu, din punct de vedere al modului n care funcioneaz procesorul. Ideea de neatomic
subliniaz faptul c din punct de vedere al mainii cu stri pe care se mapeaz activitatea, aceasta poate fi
descompus. n ultim analiz, activitile sunt secvene de aciuni atomice (nentreruptibile din punct de vedere
al modului n care funcioneaz maina cu stri) care au ca rezultat schimbri n starea sistemului sau returnarea
unei valori. Diagramele de activitate sunt importante nu doar pentru modelarea aspectelor dinamice ale unui
sistem ci i pentru construirea sistemelor executabile prin inginerie direct sau invers.

Concepte folosite n realizarea diagramelor de activitate

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

Coninutul unei diagrame de activitate

n mod vizual, o diagram de activitate conine:
stri de activitate i stri de aciune;
tranziii;
obiecte.
n esen, o diagram de activitate este o proiecie a elementelor care pot fi gsite ntr-un graf de activitate, care este un caz particular
de main de stare, n care toate tranziiile sunt declanate de terminarea activitiilor n starea surs.

Deoarece o diagram de activitate este un gen de main de stare, va avea toate caracteristicile unei maini
de stare. Aceasta nseamn c diagramele de activitate pot conine stri simple i compuse, ramificri (specifice
unor prelucrri secveniale sau paralele), etc.
Evident, asemenea tutror celorlaltor diagrame, diagramele de activitate mai pot conine i constrngeri.

Stri de aciune i stri de activitate

n fluxul de control modelat de o diagram de activitate, se ntmpl diferite lucruri. Se pot evalua expresii
pentru a seta valorile unor atribute sau pentru a returna o valoare. Se poate apela o operaie a unui obiect, se
poate trimite un semnal unui obiect, se poate crea sau distruge un obiect.
Aceste operaii atomice, executabile pe un calculator real, se numesc stri de aciune deoarece sunt
stri ale sistemului, fiecare dintre ele reprezentnd execuia unei aciuni.
O stare de aciune se reprezint ca n Figura 7.13.
Strile de aciune nu pot fi descompuse. Mai mult chiar, strile de aciune sunt atomice, ceea ce, la modul
consistent, nseamn c chiar dac apar evenimente, ele nu pot fi ntrerupte.

Selectare etaj

I:=I+1

aciuni simple

Expresii
Start

V[I]:=I+10

Figura 7.13. Stri de aciune

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

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

starea de start

stri de aciune

tranziii

starea final
Figura 7.14. Reprezentarea tranziiilor n UML
n momentul n care aciunea unei stri surs date este terminat, se va executa aciunea specific ieirii,
dac exist vreuna. Dup care, necondiionat, are loc tranziia ctre urmtoarea aciune sau activitate. Urmeaz
executarea aciunii specifice intrrii n noua stare (dac exist) i executarea aciunii/activitaii asociate noii stri,
etc. Exist situaii n care fluxul de control evolueaz nedefinit, dar exist i foarte multe situaii n care acesta
nceteaz la ntlnirea unei stri finale.
Notaiile pentru starea iniial i starea final pot fi observate n Figura 7.14.
Ramificarea (branching) i unirea (merge)
Tranziiile secveniale, simple, sunt destul de obinuite, dar nu sunt singurele ntlnite n procesul de
modelare a fluxurilor de control. La fel ca n cazul schemelor logice (hrile de fluxuri flowchart-uri), putem
apela la ramificri pentru a specifica tranziii alternative, ghidate de o anumit expresie boolean. O ramificare,
se introduce, din punct de vedere al notaiei, ca un romb; poate avea o singur tranziie la intrare i dou sau mai
multe tranziii la ieire. Pe fiecare tranziie de ieire se indic o expresie boolean, evaluat la intrarea n
ramificare. Evident, expresiile boolene asociate tranziiilor care ies dintr-o ramificare (numite i expresii de
gard) trebuie s fie mutual exclusive. Un exemplu, n Figura 7.15.
Se mai adaug i faptul c simularea unei iteraii este destul de simpl, folosind ramificarea.
Diagrama din Figura 7.15 poate fi completat, ca semantic i din punct de vedere al notaiei, ca n Figura
7.16.

Do verificareCont(s)

ramificarea
(branch, n englez)

[else]

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]

Do afisareStareCont()

[exista suma]

Do tranzactie(s)

Figura 7.16. Un exemplu complet de ramificare

Bifurcare (fork) i imbricare (join)
Tranziiile secveniale i ramificrile sunt elementele cel mai frecvent ntlnite n diagramele de activitate.
Cu toate acestea, att n modelarea fluxurilor de lucru dintr-o organizaie, ct i n anumite tipuri de aplicaii,
care mizeaz pe multitasking, apare problema fluxurilor de activiti concurente. n UML, putem utiliza o bar
de sincronizare pentru a specifica bifurcarea i imbricarea fluxurilor de control paralele. O bar de sincronizare
se red ca o linie orizontal sau vertical, ngroat, dup cum se vede i n Figura 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 activitiile GtirePizza, PreparareSos i
DestupareSticlVin s se desfoare n paralel, deci sunt introduse folosind bifurcaia. Dintre aceste trei
activiti, care pot avea fire de execuie paralele (ca s mai colorm puin expunerea), dou dintre ele
(GtirePizza i PreparareSos) trebuie s fie terminate nainte de a se trece la combinare (de aici necesitatea
primei mbinri).
Tot n Figura 7.17 se mai observ i posibilitatea, natural, de altfel, de a introduce fire de execuie
condiionate.
Participarea la osp poate s aib succes i cu sau fr vin, conform diagramei din Figura 7.17.

bifurcaia

GtirePizza

PreparareSos

[se dorete vin]

DestupareSticlVin
Combinare

mbinri

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

Teme pentru proiecte la disciplina Ingineria softului

1.

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

2.

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

3.

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

4.

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

5.

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

6.

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

7.

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

8.

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

9.

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

10. Folosind sintaxa UML, s se reprezinte aspectele statice ale aplicaiei care automatizeaz fluxurile
informaionale ale secretariatului unei faculti.
11. Elaborai arhitectura UML a soluiei problemei informatizrii unei universiti.
12. Elaboraii arhitectura UML a soluiei problemei realizrii unei librrii virtuale care funcioneaz pe
lng o editur.
13. Elaborai arhitectura UML a soluiei problemei realizrii unui sistem de informare i documentare care
funcionez pe lng o primrie.
14. Elaborai arhitectura UML a soluiei problemei informatizrii fluxurilor informaionale ale unui birou
notarial.

BIBLIOGRAFIE SELECTIV
[1] Bennet, S., McRobb, S., Farmer, R., Object Oriented Systems Analysis and Design using UML, McGrawHill 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, AddisonWesley, 1999

CUPRINS
1

Probleme a cror rezolvare depinde esenial 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 specialitii n IS ........................................................................................ 6
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
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. Cteva exemple. ................................................................................. 18
3.2.1
Modelul cascad( MC)................................................................................................................... 19
3.2.2
Modelul V (MV)............................................................................................................................ 20
3.2.3
Modelul prototipizrii (MP)........................................................................................................... 20
3.2.4
Concluzii........................................................................................................................................ 22
Abstractizarea soluiei unui sistem soft ......................................................................................................... 24
4.1 Modelarea. Limbaje de modelare ............................................................................................................ 24
4.2 Arhitectura unui limbaj de modelare ....................................................................................................... 28
Modelarea obiect orientat cu UML ............................................................................................................. 30
5.1 Ce este UML(fr a intra n detalii)?....................................................................................................... 30
5.2 Date eseniale pentru nelegerea UML ...................................................................................................31
5.3 Scurt incursiune n universul conceptual al UML ................................................................................. 34
Modelarea aspectelor structurale. Elemente-suport fundamentale ................................................................ 41
6.1 Clase........................................................................................................................................................ 41
6.2 Relaii ...................................................................................................................................................... 44
6.3 Mecanisme comune.................................................................................................................................45
6.4 Diagrame ................................................................................................................................................. 48
Introducere..................................................................................................................................................... 48
Diagrame structurale...................................................................................................................................... 49
Diagrame comportamentale........................................................................................................................... 50
Diagrame ale claselor ....................................................................................................................................50
Modelarea aspectelor comportamentale. Elemente-suport fundamentale...................................................... 54
7.1 Interaciuni .............................................................................................................................................. 54
7.2 Concepte vehiculate n modelarea interaciunilor ................................................................................... 54
7.2.1
Contextul n care se manifest interaciunile ................................................................................. 54
Obiecte i roluri ............................................................................................................................................. 55
Legturi.......................................................................................................................................................... 55
Secvenare...................................................................................................................................................... 56
Crearea, modificarea i distrugerea obiectelor............................................................................................... 57
Reprezentarea unei interaciuni ..................................................................................................................... 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 colaborrile............................................................................................................ 61
Organizarea contextelor de utilizare .............................................................................................................. 61
Relaia de generalizare...................................................................................................................................61
Relaia de includere ....................................................................................................................................... 62
Relaia de extindere ....................................................................................................................................... 62
7.4 Diagrame de contexte de utilizare ........................................................................................................... 62
Concepte UML utilizate n sfera diagramelor de contexte de utilizare.......................................................... 62
Coninutul unei diagrame de contexte de utilizare......................................................................................... 62
Scurt not, relativ la ingineria direct i invers a diagramelor UML ......................................................... 63
7.5 Diagrame de interaciune......................................................................................................................... 63
Coninutul unei diagrame de interaciune ...................................................................................................... 63
Diagrame de secven ....................................................................................................................................63
Diagrame de colaborare .................................................................................................................................65

7.6 Diagrame de activitate............................................................................................................................. 66

Coninutul unei diagrame de activitate .......................................................................................................... 66
Stri de aciune i stri de activitate............................................................................................................... 66
Tranziiile ...................................................................................................................................................... 67
Teme pentru proiecte la disciplina Ingineria softului....................................................................................... 70
BIBLIOGRAFIE SELECTIV ......................................................................................................................... 71
CUPRINS ............................................................................................................................................................ 72