Universitatea Transilvania din Braov

Facultatea de Matematic i Informatic

Catedra de Informatic aplicat













Sisteme integrate de Sisteme integrate de Sisteme integrate de Sisteme integrate de
proiectare i programare proiectare i programare proiectare i programare proiectare i programare

Elemente introductive n ingineria softului
(Suport de curs pentru semestrul I)







Dorin Bocu Dorin Bocu Dorin Bocu Dorin Bocu







Motto-ul cursului

Nevoia de a cunoate a dus la inventarea conceptelor.
Nevoia de a explica cunoaterea a dus la inventarea meta-conceptelor.
Nevoia de a ascunde o parte din cunoatere a dus la inventarea limbajelor
de modelare.
nainte de a fi un "stil de interpretare", arta de a modela este un mod de" a
face compoziie".

Autorul









































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 teoretico-
aplicative 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 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.





























Capitolul 1
Probleme a cror rezolvare depinde esenial
de ingineria sistemelor soft

Sistemele care se adapteaz uor la condiiile de mediu sunt nzestrate cu
subsisteme informaionale performante i fiabile. De exemplu, conducerea
unei afaceri astfel nct aceasta s funcioneze fr sprijin din afar, ba
chiar s fie generatoare de resurse ale dezvoltrii, este o problem
complex care pretinde persoanelor implicate cunotine i abiliti
remarcabile relativ la achiziionarea datelor necesare pentru cunoaterea
strii afacerii, interpretarea corect a datelor i a conexiunilor dintre
acestea i, pe aceast baz, elaborarea de decizii.
Cunoscnd modul de a gndi i aciona al unor manageri, fcnd haz de
necaz, deducem, i din cele spuse mai sus, c pentru a avea timp s
doarm, unii manageri confund informarea sistematic cu arta de a
supravieui ct mai mult informndu-se fr metod.











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:

1
0
Abstractizarea soluiei unui sistem soft, prin care desemnm demersul conceptual n
urma cruia specialistul n IS trece de la enunul problemei la soluia acesteia.

2
0
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.

3
0
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.

4
0
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:

1
0
Fiecare metodologie dorete s instaureze o anumit rigoare n procesul de
elaborare a soluiei unui sistem soft.

2
0
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.).

3
0
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.



















Figura 1.1 Binomul cercetare-aplicaii n evoluia MDS

Firme/Persoane implicate n
realizarea de sisteme soft
Idei, cerine, soluii
pariale noi
Laboratoare de cercetare

MDS nou
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
Microsoft) 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:

1
0
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.

2
0
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.


3
0
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.
Simbolic vorbind, funcia obiectiv care st la baza optimizrii are multe variabile i o
expresie necunoscut. De aceea nu se poate vorbi serios despre o optimizare n sens
matematic ci despre efortul permanent de a imagina procedee de stpnire a
complexitii problemelor care apar n timpul realizrii unui sistem 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.
Pentru a menine n echilibru pozitiv nevoia de sistematizare i tendina unor specialiti n
IS de a ajunge la soluie dnd cu tifla sistematizrii, este nevoie de mult abilitate din partea
celor care specific paradigme de modelare a softului (dac cititorul mi ngduie aceast
exprimare).
Istoria a reinut de-a lungul erei informaticii exemple de paradigme n care normarea i
formalizmul au descurajat pe muli amatori de sistematizare, exemple de paradigme care au
soluionat satisfctor doar o parte din probleme, lsnd la latitudinea specialitilor n IS
rezolvarea altora, exemple de paradigme care mbin elegant formalizmul cu puterea de
sugestie n rezolvarea unui numr ct mai mare de probleme, etc. Din pcate (sau poate din
fericire) universul IS, la capitolul probleme posibile, este deschis.
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 obiecte).
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.




















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.

Nivel conceptual
(Ce face sistemul soft)
Nivel logic
(Cine, cnd i unde
execut prelucrrile)
Nivel operaional
(Cum se efectueaz
prelucrrile)
Soluia conceptual
Soluia logic
Sistem soft operaional
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. Punctul de vedere pe care l prezentm reprezint o
sintez a expunerii fcut pe aceast tem n [10].
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. Schema clasic n care apare problema portabilitii este prezentat n
Figura 1.4.
Orice dificultate n portarea unui sistem soft de pe o platform pe alta este surmontabil
dac :


se fac modificrile necesare n codul surs(uneori aceste modificri pot fi dramatice);
Exist compilatorul care tie s genereze cod executabil pentru platforma int
(dac nu exist, trebuie cumprat, ceea ce nseamn c portabilitatea poate s coste).
Orice dificultate n portarea unui sistem soft de pe o platform pe alta este surmontabil
dac :

se fac modificrile necesare n codul surs(uneori aceste modificri pot fi dramatice);
Exist compilatorul care tie s genereze cod executabil pentru platforma int
(dac nu exist, trebuie cumprat, ceea ce nseamn c portabilitatea poate s coste).























Figura 1.4 Dependena de platform i efectele asupra portabilitii n varianta
clasic
Evident, ar fi mult mai bine dac aceste dou probleme nu ar exista. Din pcate
probelmele exist i specialitii n IS trebuie s ia n calcul la specificare i aspecte care
afecteaz portabilitatea sistemului soft. O situaie aproape diametral opus celei prezentate n
Figura 1.5 o reprezint soluia Java pentru asigurarea portabilitii aplicaiilor.
De remarcat faptul c situaia descris n Figura 1.5 este posibil n condiiile n care toat
comunitatea recunote o anumit versiune de compilator Java. Trecerea de la o versiune la
alta se face respectnd regulile de portare potrivit crora documentul neles de o versiune
oarecare a unui sistem soft este totdeauna neles de o versiune mai nalt, nu i invers.



















Figura 1.5 Soluia Java la problema portabilitilor sistemelor soft.


Cod surs/care poart amprenta mediului
de execuie i a mainii gazd scontate
Compilator/care poart amprenta
mediului de execuie int i a mainii
gazd scontate

Cod executabil/dedicat perechii (mediu
de execuie, main gazd) recunoscut
de compilator.


Cod
Java
Compilator
Java
Bytecode
Java
(Independent
de platform)
Interpreter
Java
(Pentium)
Interpreter
Java
(Power PC)
Interpreter
Java
(SPARC)
Aceasta este, pn la data scrierii acestei cri singura modalitate de a dezvolta sisteme ct
de ct portabile. Se pltete, ca de fiecare dat, tribut pentru acest ctig, la capitolul
performan n timpul execuiei. Dar, ce mai conteaz, omenirea viseaz cu ochii deschii,
ceea ce nseamn c ntr-o bun zi vom ajunge s dm alt sens i portabilitii.

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. Despre unele dintre aceste subiecte
vom avea un cuvnt de spus n Capitolul 4.


































Capitolul 2
Ce este o metodologie de dezvoltare a
softului?

De mult (nu putem spune exact cnd deoarece nu tim nici cnd a nceput
povestea omului) s-a nscut ideea de paradigm . Poate, la nceput
paradigma avea nelesul pe care ni-l dezvluie Dicionarul explicativ al
limbii romne. n zilele noastre, cnd natura de-abia se mai regsete
printre creaiile omului, nu putem supravieui dect inventnd, devornd i
iar inventnd paradigme din ce n ce mai sofisticate. Cnd spun nu putem
supravieui m refer la toi cei care, realmente sau doar nchipuindu-i,
cultiv o veche ndeletnicire chinezeasc (autoreflexia) pentru a descoperi
mcar o parte din taina cunoaterii att de bine ascuns n proiectul Homo
Sapiens.















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.
Dei ne-ar place s semene cu o problem de matematic, este corect s spunem c nu este
chiar aa.
n matematic, o problem poate suna cam n genul:

Dat triunghiul oarecare ABC, s se afle locul geometric al punctelor M, interioare
triunghiului, pentru care S
ABM
=S
ACM
.

Nu este cazul s intru prea adnc n consideraii metodice pe marginea rezolvrii acestei
probleme. i totui, cineva care vrea s rezolve aceast problem are nevoie de trei puncte de
sprijin:

1
0
Posibilitatea de a ncadra problema ntr-o clas tipologic. Dac aceast clas nu
exist, gloria rezolvitorului sporete, specificnd clasa respectiv. n cazul nostru, fiind o
problem de loc geometric, rigoarea ne cere s identificm locul geometric, dup care s
facem verificarea c fiecare punct al locului geometric satisface proprietatea care a stat la
baza identificrii
locului.

2
0
Odat stabilit clasa tipologic, trebuie s avem control asupra semanticii
noiunilor care intervim n enunul problemei.
n cazul nostru ne confruntm cu noiuni precum: loc geometric, interiorul unui
triunghi, aria unui triunghi i, de ce nu, triunghi.

3
0
Pentru a gsi rezolvarea ne trebuie abilitatea de a valorifica avantajele prezentate la
punctele 1
0
i 2
0
n vederea obinerii soluiei problemei.
n general, aceast abilitate o au persoanele care sunt capabile de inferen. Abilitatea de
a comite inferene autentice o au oamenii inteligeni. Evident, cine rezolv o problem
faceun fel de descoperire, deci este un fel de creator.
Folosesc sintagma un fel de deoarece face descoperire autentic cel care rezolv primul
o problem sau propune i rezolv o problem nou.
n cazul problemei noastre, pentru a ne face mai bine nelei ne-ar prinde bine
reprezentarea din Figura 2.1.








Figura 2.1.

Din enunul problemei, avem, n mod evident:
-ABC oarecare;
-M interiorului ABC; S
ABM
=S
ACM
.

Tot din enunul problemei face parte i prelungirea lui AM care intersecteaz BC n O i
ca urmare avem posibilitatea imediat de a proiecta B i C pe prelungirea lui AM n B
'
,
respectiv C
'
.
Acum este momentul inferenei specifice problemei:

S
AMB
=
2
'
BB AM

S
AMC
=
2
'
CC AM


S
AMB
=S
AMC
BB=CC BBOCCO BO=CO Mmedianei din A a ABC,
etc.

n IS situaia este puin modificat. 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 mult modificat. 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
sistem 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
contradiciilor, 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.2.
Diagrama din Figura 2.2. 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.
Pentru a obine date noi asupra semnificaiei noiunii de ciclu de via prezentm diagrama
din Figura 2.3.








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




Analiza Proiectarea Implementarea Testarea
Etape de dezvoltare






















Figura 2.2 Ciclul de via al unui sistem soft (dintr-o perspectiv rudimentar)

Avnd ca pretext diagrama prezentat n Figura 2.3., 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:



Problem
Dezvoltare
Utilizare
Abandonare soft
Modificare
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, conform i celor
specificate n [3]) 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.



Mult vreme MDS s-au bazat pe secvenialitatea propus n Figura 2.3., care sugereaz c
trecerea dintr-o etap nou este posibil numai dup trimiterea lucrului n etapa precedent. A
rezultat astfel un proces de dezvoltare cunoscut sub numele modelul cascad (waterfall
model).
Acest nume subliniaz faptul c procesul de dezvoltare poate decurge ntr-o singur
direcie.
Studiile de specialitate arat c abordarea propus de modelul cascad este ntr-o
contradicie flagrant cu nevoia de a tatona profunzimile soluiei unei probleme (prin
ncercri), resimit de spiritul creativ al rezolvitorului.

n timp ce modelul cascad schieaz un mediu de rezolvare a problemei riguros structurat,
rezolvarea creativ se desfoar ntr-un mediu n care structurarea temporar poate fi
abandonat n favoarea sugestiilor unor strfulgerri de intuiie.

n ultimii ani, preocuprile IS ncearc s reflecte aceast contradicie, beneficiind i de
suportul oferit de instrumentele ingineriei soft asistate de calculator (Computer Aided
Software Engineering CASE). Utilizarea acestor instrumente CASE faciliteaz parcurgerea
etapelor de analiz, proiectare i implementare, ntr-o form sau alta prezente n orice MDS.
n aceste condiii este mai uor s se revin, n caz de eroare, sau chiar s se planifice o
dezvoltare n spiral a soluiei sistemului soft (a se vedea paradigma RAD Rapid
Application Development asupra creia vom reveni n Capitolul 3).

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, nzuin 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.




























Capitolul 3
Ciclul de via al unui sistem soft

nclinaia omului spre rigoare si are izvorul n apetitul lui pentru
improvizaie. Formele de manifestare a rigorii n IS au un defect la urma
urmei pozitiv: rmn destul de repede n urma timpului.
De aceea, "forfota" din laboratoarele de cercetare a IS se va menine
pentru mult vreme dac nu vom gsi ceva mult mai bun de pus n locul
actualelor paradigme. Ce s punem n loc? Ceva mai simplu care s poat
nmagazina mult mai mult complexitate. Iat, aadar, tema fundamental a
cercettorilor IS n mileniul 3:
Generarea complexitii cu ajutorul unor sisteme cu structur
simplificat.
Subtilitile temei sunt cunoscute din alte ncercri ale omului. Ceea ce
trebuie descoperit este foarte aproape de cea mai mare necunoscut a
omului: gndirea.
Nu ne rmne dect s nvm s gndim ciclic i asimptotic la aceast
mare necunoscut.














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.






Figura 3.1 Un model primitiv de dezvoltare a softului











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. 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.
Specificarea
cerinelor
Implementare
Specificarea
cerinelor
Diagrama de
structur
Implementare
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 suport
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.























Figura 3.3. Modelul cascad
Definirea
cerinelor
Utilizarea
i instruirea
Analiza
Proiectarea
Testarea
Implementarea

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 iterativ-incremental (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.




















Figura 3.4. Modelul V

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.
n acord cu [12], s menionm faptul c MV, n forma consacrat aparine lui Ould, care
l-a adus n faa comunitii specialitilor n IS n 1990.

3.2.3 Modelul incremental (MI)
Putem considera c este o alt form a MC. ncercnd s repare unele dintre neajunsurile
criticate la MC i MV, MI se expune criticilor venind din alt direcie. S vedem, mai nti
oferta MI sub form grafic (Figura 3.5).
Dup cum se observ n Figura 3.5, dup dou faze desfurate la nivel de sistem
(definirea cerinelor i analiza) care permit obinerea unei perspective arhitecturale asupra
sistemului modelat, MI propune, pe aceast baz, descompunerea proiectului n subproiecte
care genereaz o cascad de activiti paralele care permit obinerea componentelor
necesare sistemului final. Fa de MV, MI ofer posibilitatea atingerii scopului final n dou
variante: sistem global livrat la sfrit sau componente livrate distinct.
n categoria avantajelor MI considerm:

MI se bazeaz pe posibilitatea de a aplica principiul Divide et impera;

MI permite livrarea de componente realizate n intervale de timp scurte;

Definirea
cerinelor
Validare
Proiectare
sistem
Testare
sistem
Proiectare
subsisteme
(componente)
Testare
subsisteme
(componente)
Codificare/
asamblare
componente
Proiectul sau sistemul final poate fi realizat de mai multe echipe sau persoane datorit
modularizrii lui.






















Figura 3.5. Modelul incremental
Dintre dezavantajele imediate considerm:

Imposibilitatea aplicrii MI n toate cazurile; exist situaii n care, pur i simplu nu
exist elementele necesare aplicrii principiului Divide et impera n sensul pe care l
presupune o modularizare de calitate;

Componentele pot fi realizate numai dup ce ntregului sistem i se definete arhitectura,
totul derulndu-se conform exigenelor principiului top-down de abstractizare; o cerin
destul de dur care sugereaz cunoaterea i formularea cerinelor din faza iniial de abordare
a sistemului;

Posibilitatea de a realiza sistemul soft dintr-o sum de componente, pune n faa echipei
(echipelor) care particip la realizarea sistemului soft probleme deosebite de integrare a
componentelor pentru a obine sistemul executabil.

Evident, calitatea demersului de abstractizare a soluiei poate salva sau compromite
MI.

3.2.4 Modelul spiral (MS)
A fost lansat de un specialist n IS cu preocupri ndelungate legate de ciclul de via al
dezvoltrii sistemelor soft, B.W.Boehm. La baza MS stau dou convingeri:

natura inerent iterativ a dezvoltrii i nevoia de planificare i evaluare a riscurilor
fiecrei iteraii;

Definirea
cerinelor
Analiza
Proiectare
compo-
nenta_1
Implementare
compo-
nenta_1
Instalare
compo-
nenta_1

ntreinere
compo-
nenta_1

Proiectare
compo-
nenta_n
Implementare
compo-
nenta_n
Instalare
compo-
nenta_n

ntreinere
compo-
nenta_n

Arhitectura
sistemului
deficiena nregistrat la MV n care validarea se efectueaz prea trziu, l determin pe
Boehm s propun realizarea acesteia ct mai devreme posibil, de ct mai multe ori, prin
construirea de prototipuri, ca n Figura 3.6.
n varianta Boehm, echipa de dezvoltare i utilizatorii se angajeaz treptat n proiect,
diminund riscurile la nivel de prototip. Interesant este i posibilitatea valorificrii
experienei acumulate n planificarea activitilor din prototipul urmtor.
De precizat faptul c MC se regsete n fiecare iteraie.
Ca elemente ce condiioneaz utilizarea cu succes a modelului semnalez:

-profesionalismul echipei de dezvoltare;

-flexibilitatea n aciune a echipei (=utilizarea resurselor, definirea activitilor de
ntreprins).























Figura 3.6. Modelul spiral

3.2.5 Modelul evolutiv (ME)
Este cunoscut faptul c abordarea obiect orientat asigur un nalt grad de mapare a
domeniului problemei peste domeniul soluiei ceea ce faciliteaz dezvoltarea incremental
a sistemelor soft. ntr-o opoziie net cu aspectul monolitic, aspectul evolutiv al ciclului de
via se regsete n toate metodologiile obiect-orientate. Pornind de la aceast constatare
putem spune c, n principiu, modelul evolutiv const n efectuarea unei investigaii iniiale,
elaborarea unei strategii pentru descompunerea proiectului n segmente (pri), fiecare
segment avnd o valoare deosebit pentru client. Segmentele sunt dezvoltate i livrate n mod
iterativ, contribuind la sporirea gradual a performanelor sistemului. Fiecare segment trece
prin toate fazele de dezvoltare a sistemelor: definirea cerinelor, analiz, proiectare,
implementare, testare, utilizare.

START
Evaluare
prototip 1
Evaluare
prototip n
Evaluare
prototip 2
STOP
































Figura 3.7. Modelul evolutiv

La terminarea unui segment, clientul intr n posesia unei forme cvasi-finite a sistemului.
Puternica orientare a modelului evolutiv ctre lumea utilizatorilor are un impact deosebit
asupra implicrii acestora n dezvoltarea segmentelor sistemului. Reuita utilizrii modelului
evolutiv const n specificarea unei arhitecturi deschise, flexibile, prin implicarea tuturor
prilor interesate, inclusiv a utilizatorilor, dar i a unor specialiti IS profesioniti.
ME preia caracteristica esenial a modelului circular, o form existent printre modelele
tradiionale. Concepia modelului circular se baza pe ciclul unui sistem, realizat prin cercuri
complete. La nchiderea unui ciclu se trece la o nou versiune a sistemului sau la un sistem
nou.

3.2.6 Modelul tridimensional (MT)
A fost lansat n Frana i este susinut de adepii metodologiei MERISE.
Modelul surprinde dezvoltarea sistemelor printr-o redare grafic bazat pe trei axe care
descriu: ciclul de via al sistemului, ciclul de via al proiectului i ciclul de abstractizare
(Figura 3.8).
STUDIUL INIIAL
DESCOMPUNERE N SEGMENTE
SEGMENT_1
DEFINIRE CERINE
ANALIZA
PROIECTARE
IMPLEMENTARE
TESTRI
UTILIZARE
SEGMENT_n
DEFINIRE CERINE
ANALIZA
PROIECTARE
IMPLEMENTARE
TESTRI
UTILIZARE
INTEGRARE SISTEM
Ciclul de via al sistemului soft surprinde timpul vieii acestuia i perioadele principale
dup care se efectueaz schimbri majore, precum: creterea semnificativ a volumului
datelor i tranzaciilor de prelucrat i nregistrat, modificarea platformelor hard sau soft, etc.
Toate acestea determin aciunile de ntreprins n timpul realizrii sau ntreinerii sistemului.
Ciclul de abstractizare trateaz nivelurile succesive ale specificaiilor, pornind de la
elaborarea nivelului conceptual. ntrebarea de baz este: Ce face sistemul?. Rspunsul la
aceast ntrebare este independent de aspectele tehnice i organizatorice.
Urmeaz elaborarea nivelului logic (Cine execut prelucrrile? Cnd i unde?).
Rspunsul la aceste ntrebri trebuie s fie independent doar de aspectele tehnice (platforma
hard, sistemul de operare, limbajul de programare ales pentru implementare, etc.).
n sfrit, ajungem la elaborarea nivelului fizic (Cum se execut prelucrrile?).


































Figura 3.8. Modelul tridimensional

Evident, cantitatea de informaie acumulat la nivelul fizic este cea necesar pentru a avea
ceea ce n alte metodologii numim soluia tehnic a problemei.
Ciclul de via al proiectului
ntreinere
Implementare
Studiul tehnic
Studiul detaliat
Studiul preliminar
Ciclul de
via al
sistemului
Sistem
generaia 1
Sistem
generaia 2
Nivelul
fizic
Nivelul
logic
Nivelul
conceptual
Ciclul de abstractizare
Dup aceast soluie tehnic se poate face implementarea cu minimum de efort dac
limbajul ales este bine stpnit. De semnalat virtuile explicite ale aezrii soluiei pe trei
nivele de abstractizare. Cea mai mare ar fi introducerea unei ierarhii a rezistenei soluiei
la diferite tipuri de modificri. n aceast ierarhie, nivelul fizic preia ocurile datorate
modificrilor cu dinamica cea mai nalt (platform soft, platform hard), nivelul logic preia
ocurile datorate modificrilor organizaionale (cu o frecven mai redus dect, s zicem,
ocurile tehnice), nivelul conceptual preia ocurile cele mai grave care pot afecta un sistem n
genere din punct de vedere structural.
n tratarea relaiei dintre date i prelucrri lipsesc virtuile abordrii obiect orientate.
n sfrit, ciclul de via al proiectului ofer o perspectiv asupra efortului de dezvoltare
a soluiei unei probleme, izomorf cu viziunea clasic asupra ciclului de via al sistemelor
soft.
Aadar, dup cum se spune i n [12], dezvoltarea unui sistem soft nseamn orientarea
permanent i simultan pe cele trei axe. Recunoatem un smbure de adevr n afirmaia c
luarea n consideraie a ciclului de via al sistemului permite o planificare riguroas a
evoluiei sistemului i a schimbrilor de efectuat, n timp ce ciclul de abstractizare permite
obinerea unei soluii care nu depinde de opiunile tehnice ceea ce uureaz extinderea
sistemului n viitor.
Nefiind un model cu priz la autorii consacrai ai domeniului, muli specialiti pun sub
semnul ntrebrii viabilitatea clamat, de altfel cu destul talent de ctre specialitii francezi n
IS.

3.2.7 Modelul fntn artezian (MA)
Acest model i are originea n modelul spiral i n altele care au adus mbuntiri ale
acestuia.
Deoarece modelul spiral i are originea n modelul cascad iar MA preia idei din
variante mbuntite ale modelului spiral, s-ar prea c MA este un model cruia ar trebui
s-i acordm oarecare atenie. n acest sens pledeaz i semantica Figurii 3.9.
Analiza Figurii 3.9 ne arat c modelul este aplicabil n cazul dezvoltrii de sisteme obiect
orientate, cum de altfel ne spun i prinii modelului (Brian-Sellers Henderson i J.M.
Edwards) n lucrrile dedicate prezentrii modelului.
ntre timp, inteniile valoroase ale acestui model ca i inteniile valoroase ale altor modele
prezentate deja au fost preluate de paradingma UML de modelare obiect orientat a sistemelor
soft.

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






























Figura 3.9. Modelul fntn artezian

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.
FOND SOFTWARE
Studiul cerinelor i al
fezabilitii
Proiectare
sistem

Analiza
Proiectare componente
Codificare
Testare componente
Testare sistem
ntreinere
Evaluare
Utilizare aplicaie
O perspectiv mai clar asupra proprietilor modelului MP putem obine i din Figura
3.10.

























Figura 3.10. 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
Analiza
iniial
Definire
obiective
prototip
Specificare
prototip
Construire
protoip
Evaluare prototip
i stabilire
schimbri
Prototip
complet
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.9 Modelul OMT
OMT (prescurtare de la Object Modeling Technique) este un model de dezvoltare al crui
artizan este J. Rumbaugh. Urmrind s ofere suport pentru dezvoltarea obiect-orientat a
sistemelor soft, modelul are urmtoarele faze:

-Analiza;
-Proiectarea sistemului;
-Proiectarea claselor;
-Implementarea.

Noutatea modelului poate fi sintetizat astfel: dezvoltarea obiect-orientat a sistemelor
soft este un proces conceptual independent de limbajul de programare pn la ultima
faz.
Vom sesiza aceast deplasare de accent i din scurta prezentare a coninutului fazelor n
cele ce urmeaz.

Analiza
Pornind de la enunul problemei, analiza are ca rezultat construirea unui model al lumii
reale n care sunt evideniate proprietile importante ale acesteia.
Activitatea n aceast faz debuteaz prin efortul de a nelege problema deoarece enunul
problemei este rareori complet sau corect.
Modelul obinut n faza de analiz este o abstractizare precis i concis a ceea ce trebuie
s fac sistemul, nefiind relevant, deocamdat cum o va face. n acest model se opereaz cu
obiecte din domeniul aplicaiei, analistul nefiind preocupat de obiecte din domeniul
implementrii precum: structur de date, procedur recursiv, etc.
Un model bun poate fi neles i criticat de specialiti n IS, care nu sunt neaprat
programatori. Modelul analizei nu trebuie s conin nici o decizie de implementare. Ca un
exemplu, o clas Window ntr-un sistem de monitorizare a ferestrelor aplicaiilor la o staie de
lucru ar putea fi descris n termeni de atribute i operaii vizibile utilizatorului.

Proiectarea sistemului
Specialitul IS implicat n aceast faz trebuie s ia decizii de nivel nalt relativ la
arhitectura de ansamblu a sistemului. Astfel, sistemul int poate fi organizat n subsisteme
innd cont att de arhitectura propus ct i de analiza structural.
Proiectantul trebuie s decid ce caracteristici de performan trebuie s optimizeze, s
aleag o strategie de abordare a problemei i s fac o tratativ de alocare a resurselor.

Proiectarea claselor
n aceast faz este elaborat un model care se bazeaz pe modelul realizat n faza de
analiz, cruia i se adaug detalii de implementare. Proiectantul adaug detalii n conformitate
cu strategia stabilit pe timpul proiectrii sistemului. Obiectivul fazei l reprezint, n esen,
specificarea structurilor de date i a algoritmilor necesari pentru implementarea fiecrei clase.
Clasele de obiecte din faza de analiz sunt nc semnificative dar sunt completate cu
algoritmi i structuri de date din domeniul soluiei alese astfel nct s se mbunteasc
performanele sistemului. Att obiectele din domeniul aplicaiei ct i obiectele din domeniul
soluiei sunt descrise de aceleai concepte i notaii de esen obiect-orientat, dei ele exist
n planuri conceptuale diferite.



Implementarea
Clasele i relaiile dintre ele aa cum au rezultat n faza de proiectare a claselor sunt acum
descrise n conformitate cu exigenele unui limbaj de programare, innd cont de
particularitile de organizare a bazelor de date sau de anumite elemente hard specifice.
Principial vorbind, activitatea de programare ar trebui s fie o parte relativ mic i
mecanic a ciclului de dezvoltare a sistemului soft, deoarece se presupune c toate decizile
dificile au fost deja luate n faza precedent.
S mai adugm faptul c pentru descrierea soluiei unui sistem de-a lungul celor trei faze
care premerg implementarea, se folosesc trei tipuri de modele: modelul obiectelor (care
descrie obiectele din sistem i relaiile dintre ele), modelul dinamic (care descrie
interaciunile dintre obiectele sistemului) i modelul funcional (care descrie transformrile
pe care le suport datele din sistem).
Susinute de o notaie consistent, aceste modele au fcut din OMT un element hotrtor
n specificarea uneia dintre cele mai importante paradigme de modelare: UML.

3.2.10 Modelul Raional (RUP)
RUP (Rational Unified Process) este ciclul de via considerat cel mai adecvat pentru
paradigma de modelare UML, asupra creia vom face o serie de consideraii n capitolul 4.
Scopul RUP, redus la esene, ar putea fi formulat astfel:

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

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

Caracteristici ale RUP

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

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

FAZE
Fluxuri de
lucru
n interiorul
fazelor
Iniiere Elaborare
Consturc
ie
Tranziie
Modelare
afacere

Specificare
cerine

Analiz i
proiectare

Implementar
e

Testare
Configurare
hard

Fluxuri
suport

Management
ul
schimbrilor

Management
ul proiectului

Asigurarea
mediului de
lucru

Iteraie Iteraie Iteraie

Iteraii
prelimin
are
#1 #2 #n
#n+
1
#m
#m+1

Figura 3.11. Ciclul de via RUP

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

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

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

RUP ncurajeaz preocuprile pentru controlul calitii i managementului
riscului.

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

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

Iniiere (Inception);

Elaborare (Elaboration);

Construire (Construction);

Tranziie (Transition).

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

Iniiere
Este faza n care se face ceea ce n limba romn s-ar numi studiul de oportunitate care
trebuie s precizeze:

-domeniul proiectului;
-criteriile pentru aprecierea reuitei;
-evaluarea riscurilor;

-estimarea resurselor necesare;
-un grafic de execuie preliminar raportat la cele patru faze principale

Cu tehnologiile de dezvoltare existente este ct se poate de uzual s se realizeze un
prototip executabil care ajut la ntrirea celor precizate mai sus.

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

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

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



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























































Capitolul 4
Abstractizarea soluiei unui
sistem soft

Avem nevoie de modele pentru a explica, cu un interes anume, dinamica
unui sistem bnuit de noi c ar exista sau care exist sub ochii notri, n
toat complexitatea lui. Elabornd modele, mbogim lumea sistemelor,
care, privind lucrurile cu obiectivitate tiinific, par a deschide una dintre
marile pori ctre tainele alctuirii universului. O ntrebare, veche de cnd
lumea, ar fi : Cum elaborm modelele?
De cnd a nceput s se nfiripe, tiina n genere nu face altceva dect s
ne nvee cum putem dibui modele n cele mai neateptate coluri de univers.
















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.

Comentnd, pe scurt, doar descompunerea funcional, putem semnala faptul c aceasta a
aprut i s-a consolidat ca metod n perioada de glorie a programrii structurate. Dintre
autorii remarcabili care au abordat descompunerea funcional, amintesc pe civa mai
reprezentativi: De Marco, Yourdon i Constantine, Jackson, Page-Jons, Warnierr-Orr.
Descompunerea funcional este cea care premerge, n IS, analiza i proiectarea
structurat. La limit, descompunerea funcional a fost introdus cu scopul de a permite
controlul complexitii problemelor opernd cu tehnici de tipul divide et impera. Aadar,
fiecare funcie este descompus n subfuncii .a.m.d pn cnd se obin componente (uniti
de prelucrare) uor de transpus n instruciunile limbajului de programare ales.
Descompunerea funcional (DF) poate fi neleas, reinnd esenialul, ca o ecuaie de
tipul:

DF = FUNCII +
SUBFUNCII +
INTERFEE FUNCIONALE

Evident, n cadrul descompunerii funcionale, preocuparea de baz a specialistului n IS
este s identifice prelucrrile necesare n sistem i interfeele funcionale asociate.

Avantaje ale utilizrii DF:

-simplitate n utilizare ntruct, orice s-ar spune, este o cale natural de rezolvare a unei
probleme.

-obinerea, cu destul lejeritate, a cerinelor utilizatorului.

-generarea de soluii pe diferite nivele de abstractizare (sistem, subsistem, funcie,
subfuncie), fapt benefic pentru controlul complexitii problemelor n diferite ipostaze.

Dezavantaje ale utilizrii DF:

-concentrarea eforturilor asupra aspectelor funcionale conduce la acumularea natural a
multor date redundante.

-nu exist reguli precise pentru operaionalizarea DF.

-interaciunile non-ierarhice dintr-o soluie orientat pe funcii sunt dificil de evideniat.

Pentru eliminarea acestor dezavantaje au fost propuse o serie de principii suplimentare
(n contextul modularizrii n genere) care urmresc un control sporit asupra coeziunii
modulelor i cuplrii lor.
Termenul coeziune se refer la gradul de nrudire a componentelor interne ale unui
modul ceea ce, n termeni mai precii, msoar gradul de specializare al modulului. O
apreciere corect a importanei coeziunii este posibil dac privim evoluia unui proiect de-a
lungul ntregului ciclu de via. Dac, deci, n perspectiva apropiat sau mai ndeprtat sunt
necesare modificri ale unui modul, acestea sunt mai uor de controlat i de localizat dac
modulele sunt nalt coezive.

Coeziunea poate avea mai multe forme de exprimare.
Fundamentale n procesul de abstractizare a soluiei unui sistem soft sunt coeziunea
logic i coeziunea funcional.

Coeziunea logic a unui modul rezult ca urmare a faptului c elementele lui interne
permit realizarea unor activiti de aceeai natur. De exemplu, putem presupune c am
proiectat un modul care se ocup de comunicarea sistemului soft cu lumea exterioar. Ceea ce
unete componentele unui astfel de modul este faptul c toate activitile au legtur cu ideea
de comunicare.
Evident, ns, comunicarea se poate referi la multe lucruri diferite (preluarea datelor,
afiarea datelor, raportarea unor erori, etc.).
O form mai puternic de coeziune este coeziunea funcional care msoar gradul de
integrare al componentelor unui modul n vederea realizrii unei singure activiti. Problema
care apare aici este: Ce se nelege prin ideea de activitate?. Rspunsul depinde, n mare
msur, de contextul n care se pune ntrebarea.

Termenul cuplare este introdus n modularizare pentru a msura gradul de interconectare
a modulelor. Interconectarea modulelor este obligatorie pentru ca acestea s formeze un
sistem coerent. ns, raiunile de dezvoltare i ntreinere ne pun din nou n faa unei cerine de
tipul o modificare efectuat ntr-un modul nu trebuie s afecteze imprevizibil
comportarea celorlaltor module. Simplu i firesc. Pentru ca s fie i adevrat este clar c
un obiectiv constant al modularizrii trebuie s fie maximizarea independenei modulelor,
ceea ce se obine prin minimizarea cuplrii acestora.
Cuplarea modulelor se poate realiza prin control i prin date.
Cuplarea prin control apare atunci cnd unul dintre module cedeaz controlul ctre alt
modul.
Cuplarea prin date se refer la partajarea datelor de ctre modulele unui sistem soft.
Indiferent de tipul cuplrii este important ca aceasta s fie ct se poate de vizibil deoarece
cuplarea implicit (ascuns) este cauza multor erori, ndeosebi de programare.
Prin incursiunea fcut sper c am reuit s atrag atenia cititorului asupra complexitii
decizilor cu care se confrunt un limbaj de modelare i, n egal msur, un specialist IS n
relaia cu o problem de modelare.
Singura certitudine n procesul de modelare a soluiei unui sistem soft ar putea fi rezumat
astfel:
orice decizie luat n procesul de modelare genereaz probleme noi. Datoria specialistului
n IS este de a ine sub control influenele nedorite ale acestor probleme.
De fapt, ntreaga evoluie n materie de modelare merge pe ideea de nlocuire a unei
paradigme vechi de modelare cu o paradigm nou, atenund sau eliminnd defeciunile
vechii paradigme, introducnd probleme noi care, asumate corect de ctre specialistul n IS,
nu pot afecta semnificativ calitatea sistemului soft.
S mai facem o precizare necesar: apariia unei paradigme noi de modelare nu nseamn
negarea tuturor ideilor vechilor paradigme.
Astfel, de la descompunerea funcional la modelarea obiect-orientat este, sincer vorbind,
cale lung. Aceasta nu nseamn, ns, c elementele de abordare funcional au disprut cu
totul. Ele sunt n continuare prezente dar la un anume nivel de abstractizare a soluiei.
Relum o idee pe care am mai vehiculat-o n acest capitol:

suportul oferit de o MDS pentru abstractizarea soluiei unui sistem soft trebuie s l ajute
pe specialistul n IS s fac trecerera de la domeniul problemei ctre domeniul soluiei
conservnd ct mai multe dintre avantajele pe care experiena n materie de modelare le-a
certificat.

Pentru efectuarea unei treceri, specialistul n IS trebuie s gseasc n limbajul de
modelare universul conceptual adecvat.
Deoarece sistemele reale, supuse modelrii suport adeseori modificri, uneori
strructurale, ceea ce creaz premize pentru apariia, n timp, a unor semnificaii particulare la
nivelul sistemului real este evident c limbajul de modelare trebuie s posede, att ct este
posibil i mecanisme pentru extinderea controlat a semanticii limbajului de modelare
(a se vedea exemplul oferit de UML n aceast privin).
nchei aici consideraiile pe marginea celei de-a doua probleme cu care se confrunt un
SLM.

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 obiect-orientate (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 limbajului.
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 i-au 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.
O astfel de abordare este prezent i n politica firmei Rational Software Corporation de
promovare a limbajului de modelare UML, de exemplu.
Aa cum se ntmpl, n general, arhitectura unui limbaj de modelare este rezultatul
unui efort special de clasificare i ierarhizare conceptual, efort pe care l-am putea numi
metamodelare.
La ora actual specialitii IS n materie de limbaje de modelare precum i organismele
care se ocup de promovarea standardelor n domeniu agreeaz dezvoltarea de arhitecturi
pentru limbaje de modelare cu patru nivele de abstractizare. Care sunt aceste nivele i ce
funcii ndeplinesc ele se poate vedea n Figura 4.1.
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:


Nivel Descriere nivel
Exemple de
concepte
Meta-metamodel Reprezint
infrastructu-ra
necesar pentru
meta-modelarea
arhitecturii.
Definete limbajul
pentru specificarea
metamodelelor.
Meta clase,
Meta operaii,
meta atribute, etc.
Metamodel Este o instan a
unui meta-
metamodel.
Definete limbajul
pentru specificarea
unui model.
Clas, atribut,
Operaie, etc.
Model Este o instan a
unui metamodel.
Definete limbajul
necesar pentru
descrierea unui
anumit domeniu
informaional.
Matricol, Adresa,
Medie-la-admitere,
etc.
Obiecte utilizator
(date utilizator)
Un obiect utilizator
este o instan a
unui model. Un
obiect utilizator
specific un anumit
domeniu
informaional.
111, Calea
Victoriei 81 Bl 2,
Sc A, Ap. 20, 10

Figura 4.1. Arhitectura standard pe patru nivele a unui limbaj de
modelare

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.

Foarte bine! Nu s-ar putea s m exprim i mai concret n legtur cu cele dou
dimensiuni ale procesului de modelare semnalate mai sus?

Voi ncerca acest lucru n continuare.
Aadar, dat o problem adevrat (= volum mare de informaii, stabilitate structural n
mod nativ perisabil), specialistul n IS execut sarcini de genul:

Identificarea fluxurilor informaionale eseniale; este tiut faptul c multe dintre
creaiile omului, inclusiv limbajele naturale, apeleaz la redundan pentru a-i consolida
virtuile semantice.
Excesul de semantic se justific dac exist beneficiari imediai pentru acest exces. Dac
beneficiarii nu exist, atunci excesul de semantic ntemeiat pe redundan trebuie eliminat. n
aceast ncletare pentru identificarea fluxurilor informaionale, specialistul IS trebuie s
fie, n egal msur, un culegtor harnic de date despre fluxurile informaionale dar i un abil
mnuitor al procedeelor de clasificare, ierarhizare, codificare, abstractizare i documantare a
acestor fluxuri informaionale.
Rezultatul acestui demers: un tablou ct se poate de complet al tipurilor de date
considerate importante pentru rezolvarea problemei.

Identificarea cerinelor fa de sistemul soft care soluioneaz problema. Acest tip de
demers este complementar celui semnalat mai sus. Odat enunate aceste cerine, specialistul
IS trece la definirea lor.
Din nou se pune mare accent pe abstractizare pentru a alege din mulimea alternativelor
calea cea mai apropiat de cerinele imediate dar i cea mai potrivit din punct de
vedere al posibilitilor de evoluie.
Rezultatul demersului: o perspectiv de nivel de abstractizare nalt asupra proprietilor
eseniale ale soluiei:

-date
-funcii
-componente
-resurse angajate.

Proiectarea soluiei sistemului soft. Numeroasele obiective i restricii asumate pn la
nceperea proiectrii reprezint cadrul de valorificare a acumulrilor din activitile
specificate generic mai sus.
Un bun proiectant nelege rolul nsemnat jucat de abilitatea de a-i impune i gestiona
o sumedenie de factori de constrngere, inereni n procesul de realizare a unui soft de
calitate.
Nenumrate sunt momentele de cumpn n realizarea unui sistem soft. i aceasta se
ntmpl deoarece procesul de dezvoltare a unui sistem soft nu este liniar i are multe
elemente de descoperire n structura lui.

Consider c abilitatea de baz a unui specialist IS avnd competene n analiz,
proiectare sau implementare rmne capacitatea de a abstractiza metodic.

Este o abilitate care se formeaz prin exerciiu autoimpus i autocenzurat.
Dorina de a obine bijuterii n IS, transformat n exerciiu de plcere, iat secretul
evoluiei profesionale i n materie de paradigme n IS.




4.3. Complemente. Elemente de teoria general a sistemelor
Am mai fcut referiri scurte la importana, consider eu, major a teoriei generale a
sistemelor (TGS) n cunoatere, n modelare, n economie, politic, etc. Greu de gsit un col
n lume cruia s nu i se potriveasc ceva din abordarea TGS. n acest paragraf voi ncerca s
explicitez o serie de idei care, sub presiunea necesitii, se manifest i implicit.
Pentru nceput s observm c, n general vorbind, noiunea de sistem, n jurul creia vom
articula discursul acestui paragraf, are un dublu neles. Cu mai mult sau mai puin
discernmnt, numim sistem: un obiect, fenomen sau proces cu existen material l
vom numi sistem real (SR) supus la un moment dat ateniei unui observator oarecare; tot
sistem numim i un model care aproximeaz comportamentul unui SR. Aadar, atragem
atenia vorbitorilor de TGS asupra acestei surse de ambiguitate pe care o pot activa cu mare
uurin, dac nu i menin atenia treaz.
Prima ntrebare pe care ne-o punem n TGS este, evident, urmtoarea: Ce este un
sistem?.

4.3.1. Definiia i caracteristicile unui sistem
n TGS se numete sistem o colecie de componente interconectate astfel nct se
poate spune c evolueaz n comun pentru ndeplinirea unui obiectiv predefinit.

La scara universului se poate vorbi, despre omniprezena unor variate tipuri de sisteme
care respect definiia de mai sus i care se integreaz n sisteme din ce n ce mai complexe
deoarece, chiar i filozofic vorbind, interdependenele sunt eseniale pentru a discrimina
multe dintre proprietile unui sistem.
Dintre proprietile sistemelor (reale sau teoretice) importante i pentru o corect utilizare
a paradigmei TGS n IS voi prezenta, n continuare, pe cele mai importante.

Orice sistem are un mediu n care exist.
Este dincolo de nelegerea omeneasc posibilitatea existenei unui sistem fr nici o alt
conexiune cu alte sisteme. Noiunea de sistem nchis este o utopie teoretic.
Contientizarea mediului n care exist un sistem real, de exemplu, poate fi esenial
pentru calitatea modelrii acestuia, dac se urmrete acest lucru.

Orice sistem este delimitat de mediul n care exist de un anumit tip de frontier.
Frontiera unui sistem este o noiune cu o semantic discutabil. Nici ntr-un caz,
frontiera unui sistem nu este utilizat pentru a realiza nchiderea acestuia. Frontiera este
o noiune cu ajutorul creia se realizeaz o delimitare ntre dinamica intern a unui sistem i
dinamica relaiilor sistemului cu mediul nconjurtor. Avem nevoie de o cunoatere exact a
frontierelor pentru a face raionamente corecte relativ la proprietile unui sistem.
Interfaa sistemului cu mediul este dependent de structura frontierei sistemului. n teorie,
nu se poate ncepe procesul de modelare a unui SR dac nu au fost convenite frontierele
acestuia.

Orice sistem are intrri i ieiri.
Intrrile sunt semnale (mesaje) ale mediului ctre sistem. Ieirile sunt rspunsuri pe care
sistemul le d mediului n care se afl.

Orice sistem are interfa.
Interfaa permite comunicaia ntre dou sau mai multe sisteme. n IS, n jurul conceptului
de interfa s-au dezvoltat tehnologii soft importante pentru viitorul tehnologiilor
informaionale (COM, DCOM, CORBA, etc.).

Orice sistem poate avea, potenial, subsisteme.
Este o constatare care, sub lupa filozofilor este asociat cu posibilitile de observare ale
omului, inerent limitate att n perspectiv microscopic ct i n perspectiv macroscopic.
Cert este c orice subsistem poate fi, la rndul lui, neles ca sistem care, de asemenea, se
poate descompune n subsisteme. Operatorul de descompunere a sistemelor n subsisteme
este recursiv i se aplic cu maximum de discernmnt. Afirmaia de bun sim n ceea ce
privete acest operator este c nu se descompune ceea ce din perspectiva intereselor
imediate de modelare sau cunoatere este invizibil.

Orice sistem care rezist n timp are un mecanism de control.
Problema durabilitii n timp a sistemelor are legtur nemijlocit cu problema stabilitii
structurale a sistemelor la care vom face referiri n 4.3.2.
Mecanismele de control ale sistemelor pot fi de tip feedback sau, uneori, de tip feed-
forward. Controlul pe baz de feedback presupune dirijarea informaiilor despre ieirile
sistemului ctre subsistemul de control. Controlul pe baz de feed-before presupune
colectarea permanent de date despre intrri i transmiterea acestora ctre subsistemul de
control. Dei nu am spus explicit acest lucru, cititorul nelege faptul c subsistemul de control
poate modifica comportamentul sistemului (n condiiile meninerii unei anumite stabiliti
structurale) pentru a asigura o relaie scontat ntre intrri i ieiri.
Sistemele pe baz de feedback reacioneaz mai lent la semnalele mediului. Sistemele pe
baz de feed-before sunt mai sensibile la schimbrile de mediu ceea ce le mrete capacitatea
de adaptare.
Problema principal o reprezint costurile proiectrii sistemelor de control de tipurile
mai sus menionate.
Sistemele de control orientate feed-before sunt mai scumpe i mai dificil de implementat.

Ultima remarc pe care o adugm noiunii de sistem este urmtoarea: un sistem are
ntotdeauna proprieti care nu sunt deductibile direct din proprietile prilor. Aceste
proprieti le putem numi proprieti integratoare (emergent properties, n englez). Cu ct
aceste proprieti integratoare se manifest mai pregnant cu att mai mare este gradul de
organizare a sistemului.
Iat, aadar, alt subiect de care specialitii n IS sunt ct se poate de interesai: gradul de
organizare a sistemelor. Dac am continua am ajunge la consideraii savante privind
msurarea entropiei unui sistem din perspectiv probabilist-informaional ceea ce nu ne
propunem, de fapt, n aceast lucrare.
Este momentul s atragem cititorului atenia asupra puternicului impact pe care gndirea
holist (sistemic-integratoare) l poate avea asupra calitii modelelor elaborate n IS.
Ca un rezumat al ideilor prezentate n paragraful 4.3.1. v invit s analizai semantica
Figurii 4.2.
A ncheia acest paragraf atrgnd atenia cititorului asupra faptului c elementele
introductive pe care le-am prezentat sunt, n mod sigur, un nceput de drum pentru specialitii
IS interesai n surprinderea i modelarea proprietilor numeroaselor tipuri de sisteme
informaionale care populeaz nvmntul, lumea afacerilor, sistemele nuclearo-energetice,
etc. ...

4.3.2. Structura unui sistem
n definiia dat unui sistem se face trimitere la relaiile dintre componentele unui sistem.
tiu c printre filozofi exist adevrate certuri n legtur cu problema clasificrii i
individualizrii acestor relaii. Pentru exigenele muncii n IS este important s tim c
nelegerea unui sistem este, pe lng o problem de delimitare n spaiu i o problem de
evoluie n timp.
n evoluia n timp a unui sistem se pot deosebi dou tipuri fundamentale de relaii ntre
componentele unui sistem: relaii stabile i relaii accidentale (ntmpltoare).

Ansamblul relaiilor stabile dintre elementele unui sistem formeaz structura sistemului.



















Figura 4.2. Componentele fundamentale ale unui
sistem i relaiile dintre ele

Pentru un specialist n IS, mai important dect faptul c structura unui sistem poate fi
abstractizat de un sistem de ecuaii de nu tiu care tip, este cunoaterea faptului c un proces
de modelare a unui sistem real este posibil s aib succes doar dac acestui sistem real i se
poate asocia o perspectiv din care s se ntrezreasc un anumit gen de stabilitate structural.
Zic un anumit gen de stabilitate structural ca o recunoatere a faptului c modelarea
sistemelor nseamn, de fapt, aproximarea comportamentului lor dintr-o perspectiv
concordant cu obiectivele asociate sistemului modelat.
Astfel c nu este deloc o ntmplare faptul c una dintre primele cerine ale succesului n
modelarea specific IS o reprezint specificarea corect a binomului obiective+diagnostic
stabilitate structural relativ la dezvoltarea unui sistem soft.
Cu ncredinarea c cititorul care a ajuns n acest punct al crii a fost provocat la studierea
mai atent a utilitii TGS n abstractizarea soluiei sistemelor soft i nu numai, pun punct
paragrafului 4.3.

4.4. Complemente. Principii ale modelrii cu impact deosebit n IS
Dei unii dintre cititori vor fi de prere c afirmaiile pe care le voi face n continuare le
erau de mult cunoscute, acest fapt nu m mpiedic s le fac gndindu-m la cei care nu au
avut nc fora necesar pentru a se ridica la nivelul acestor principii n deplin cunotin de
cauz.
Aadar, este vorba de patru principii care, coroborate cu abilitile de gndire sistemic i
cu abilitile de modelare specifice IS, v pot ajuta s traversai cu succes jungla de
obstacole care se dezvolt, n mod natural, ntre enunul problemei i soluia acesteia.

Ce face sistemul
Intrri Ieiri
Cum este controlat
sistemul
Fluxuri de
control
Feed-back Feed-before
Frontier sistem
Mediul nconjurtor al sistemului

Primul principiu
Alegerea tipului de model pe care urmeaz s l creai are o influen profund asupra
modului n care abordai problema i deci asupra caracteristicilor soluiei acesteia.
Aa cum insinuam i n alt context al prezentului capitol, acest principiu atrage atenia
explicit asupra efectelor pe care le pot produce, asupra soluiei n ultim faz, diferitele
opiuni fcute de specialistul IS pe parcursul abstractizrii soluiei.
Pentru a convinge cititorul asupra greutii acestui principiu n IS, trebuie s l
informm c, pornind de la o aceeai problem ntr-un fel arat soluia dac este tributar
obinuinelor de abordare specifice unui dezvoltator de baze de date, altfel arat soluia dac
este tributar obinuinelor de abordare ale analizei structurate .a.m.d.
Alegerea tipului de model poate influena semnificativ calitatea sistemului soft, costurile
i beneficiile datorate utilizrii acestuia.

Al doilea principiu
Fiecare model poate fi exprimat la diferite nivele de abstractizare (precizie).
Mesajul exact al acestui principiu poate fi neles dac privim lucrurile din interiorul
exigenelor unui laborator de modelare.
Ca un exemplu n acest sens s ne amintim faptul c n IS un sistem soft, nainte de a
ajunge n stadiul final de dezvoltare, trece prin mai multe nivele de abstractizare. Fiecare nivel
de abstractizare conine informaiile ateptate de o anumit categorie de participani la
dezvoltarea softului i reprezint un element-suport pentru gestiunea complexitii
procesului de abstractizare.

Al treilea principiu
Cele mai bune modele sunt modelele conectate la realitate.
Mesajul de baz al principiului este simplu dar de mare utilitate: modelai transfigurnd
realitatea modelat ct mai puin. Problema transfigurrii realitii modelate este neleas
mai uor dac ne punem ntrebri asupra modului n care domeniul problemei se mapeaz
peste domeniul soluiei. Ideal este ca tehnica de modelare pe care o folosim s permit chiar
maparea dup mai multe perspective dac acest lucru este benefic pentru procesul de
modelare. Din nou fac trimitere la UML care instituionalizeaz, aproape, cerina conjugrii
obiect-orientate cu abordarea multi-perspectiv.

Al patrulea principiu:
Un singur model nu este suficient. Fiecare sistem netrivial este cel mai bine aproximat de
un set limitat de modele relativ independente.
Sistemele netriviale sunt sisteme a cror complexitate trebuie structurat pentru ca
modelul rezultat s ncapsuleze toat semantica relevant a sistemului modelat. Structurarea
complexitii sistemului modelat poate s nsemne i necesitatea ca sistemul modelat s fie
descris din mai multe perspective, obinndu-se astfel descrieri cu relativ autonomie
semantic, care suprapuse (combinate) permit obinerea unei imagini holografice asupra
sistemului modelat.



Pun punct Capitolului 4 cu sperana c cititorul a neles care sunt problemele n domeniul
abstractizrii soluiei unui sistem soft i, de ce nu, va pune chiar umrul la clarificarea, la alt
nivel de abstractizare, a acestor probleme.

































































Capitolul 5
Managementul proiectelor n industria softului

Succesul unei aciuni depinde, esenial, de modul n care i sunt
gestionate problemele. nc mai exist manageri care viseaz cu ochii
deschii c subalternii lor (ruinai, automotivai, din patriotism i pe mai
nimic) sunt gata n orice clip s mearg pn la sacrificiul suprem pentru
salvarea incompetenei efilor.
Iertat fie nedumerirea ngrmdit n acest preambul de capitol.
Un om se poate schimba nvnd i luptnd mpotriva obinuinei. O
echip, ai crei membri nu sunt clone ale unui aceluai prototip uman
(deosebit din punct de vedere al calitilor), are nevoie de conductor
pentru a ajunge s funcioneze, ct de ct, ca un tot. n industria softului
este nevoie de conductori care tiu managementul unei afaceri n genere i
nc ceva pe deasupra. Acel nc ceva pe deasupra ne va interesa, cu
predilecie, n Capitolul 5.
















5.1. Scurt introducere
Nu este n intenia acestei cri s dezvolte teme ale teoriei managementului, n genere.
Mult lume, ns, este convins de faptul c managementul proiectelor soft (MPS) i
asum, ntr-un context particular, aceleai probleme i aceleai principii de baz pentru
rezolvarea lor. De aceea nu mi se pare deloc o glum introducerea n planurile de
nvmnt ale instituiilor de nvmnt superior care pregtesc specialiti IS a unor
cursuri de iniiere n teoria managementului. Exist cel puin dou motive pentru care este
nevoie de o astfel de abordare.

Aceste cunotine i ajut pe managerii din industria softului s aib succes n
afacerile pe care le conduc;

Cunoaterea principiilor dup care se structureaz i se operaionalizeaz
managementul n cazul unei afaceri oarecare, este de mare utilitate pentru cei care,
n definitiv, produc tehnologii informaionale pentru a ntmpina o cerin de baz al
actului de management: optimizarea fluxurilor informaionale (vitez, calitate,
spectru problematic).

Practica demonstreaz destul de convingtor faptul c un specialist IS care lucreaz la
soluia unei probleme formulat de managementul unei afaceri, trebuie s intre metodic n
semantica specific acestui management. n lipsa unui orizont minimal, specialistul va
trebui s nvee ct mai multe dac nu vrea s bjbie pn la obinerea soluiei tehnice. Cei
pii, dar i nepiii, contientizeaz faptul c este greu s modelezi temeinic bazndu-te doar
pe inspiraia de moment.
Concretiznd, n faa problemei realizrii unui sistem soft, managementul se lovete, n
mod natural, de ntrebri de tipul: Ct va costa sistemul?, Cnd va fi terminat?.
Acestea sunt doar dou din ntrebrile la care un rspuns corect este destul de dificil.
Foarte multe proiecte "i-au dat bugetul iniial de mai multe ori peste cap" i au fost
finalizate mult timp dup termenul estimat al predrii. De aceea, printre obiectivele de baz
ale MPS vom regsi:

Planificarea sarcinilor proiectului;
Estimarea succesului sau a eecului proiectului, raportat la
planul de dezvoltare adoptat;
Estimarea timpului i a forei de munc necesare pentru
finalizarea proiectului, ca ntreg i pe etape.

5.2. Teme fundamentale n managementul softului
5.2.1. Introducere
Poate, cu riscul de a schematiza prea tare, voi ncerca s introduc cititorul n universul
preocuprilor fundamentale ale unei persoane implicate n MPS.
Aadar, pe lista subiectelor MPS vom regsi, n mod necesar, consideraii referitoare la:

-dezvoltarea sistemelor soft (procese, activiti, management);

-managementul riscului;

-tehnici de reprezentare a MPS;

-estimarea mrimii proiectelor;

-managementul calitii.

Fiecare dintre aceste subiecte ncearc s abstractizeze o categorie deosebit de probleme,
abilitatea managerului fiind cea care va rezolva problema convertirii cunotinelor despre
aceste subiecte ntr-o strategie coerent de conducere a proiectelor soft.
Cititorul informat intuiete, probabil, c n industria sofutlui, la fel ca n orice alt domeniu
de activitate, managementul se structureaz att pe vertical (ca urmare vom avea mai multe
nivele de management) ct i pe orizontal (ca urmare, este plauzibil s avem mai multe arii
de management).

Amploarea procesului de structurare a managementului n industria softului depinde de
complexitatea activitilor desfurate i de atitudinea managementului de top fa de
delegarea structural a competenelor manageriale.

Ca de obicei, n IS, nu exist reete infailibile nici n MPS. Se poate vorbi ns, despre
exemple concrete de structurare a MPS i despre o anumit perspectiv asupra procesului de
structurare a MPS.
Exemplele concrete de structurare a MPS (veritabile studii de caz) pot oferi date
interesante despre relaia dintre anumite tipuri de procese i managementul asociat acestora.
Aceste date pot fi valorificate efectiv dac se operaionalizeaz, de exemplu, perspectiva
asupra procesului de structurare a MPS prezentat n Figura 5.1.

























Figura 5.1. Dezvoltarea iterativ i incremental a managementului n industria softului


Activitate de dzvoltare a
softului cu obiective iniiale
limitate.
Management cu structur
simplificat.
Diversificare/complexificare a
activitii de dezvoltare a
softului.
Exist indicii c performanele
actualului sistem de
management sunt criticabile?
NU
Restructurare
sistem de
management
DA
5.2.2. Dezvoltarea sistemelor soft din perspectiv managerial
5.2.2.1. Produse. Procese. Resurse.
MPS manifest un interes deosebit fa de o serie de aspecte ale dezvoltrii softului care
devin obiect de activitate pe toat durata dezvoltrii unui sistem soft. Astfel, din perspectiv
MPS, dezvoltarea softului nseamn:

-Produsele realizate;
-Procesele desfurate;
-Factorul uman implicat.

Produsele realizate n timpul dezvoltrii softului
n ceea ce privete produsele realizate n timpul dezvoltrii unui sistem soft,
managementul are o atitudine, evident pragmatic, fiind preocupat de:

cerinele pe care acestea trebuie s le ndeplineasc;

structura pe care acestea se bazeaz n timpul funcionrii.

n ceea ce privete cerinele, acestea pot fi:
-cerine funcionale (ce trebuie s fac sistemul?)
-cerine de calitate (ct de bine va lucra sistemul?)
-cerine n ceea ce privete resursele (ct va costa sistemul, n ultim
analiz).

Primele dou cerine sunt i n atenia MPS dar i preocup ndeosebi pe cei care lucreaz
n analiz, proiectare i/sau programare.
Al treilea tip de cerin este de competena managementului, folosind, evident, datele
furnizate de specialitii care lucreaz n analiz, proiectare, programare.
Tot din punct de vedere al managementului este util s se tie, cu precizie, care sunt
tipurile de documente care nsoesc realizarea unui sistem soft. Aadar, din punct de vedere
managerial, putem spune c un sistem soft nu se rezum doar la codul executabil al acestuia;
el const dintr-o serie de documente care, n mod uzual, pot fi:

-un document care cuprinde cerinele fa de sistemul soft, cerine care sunt rezultatul
unui consens al tuturor celor interesai, ntr-o form sau alta, n dezvoltarea sistemului
soft;

-documentul care descrie specificarea cerinelor, structurate la nivel de sistem i,
respectiv la nivel de componente;

-documentul care descrie soluia tehnic a sistemului soft, elaborat n faza de
proiectare, de obicei. Schematiznd, un astfel de document va conine informaii
structurate astfel:

descrierea soluiei sistemului soft ca ntreg;

descrierea coleciilor de date;

descrierea interfeei cu utilizatorul;

descrierea prelucrrilor asociate funciilor sistemului soft.

-codul surs al sistemului soft;

-datele de test ale sistemului soft, structurate pe module i la nivelul sistemului ca ntreg;

-documentaia utilizator care nsoete sistemul soft; n aceast categorie putem include:

ghidul de instalare a sistemului soft;

manualul de referin al sistemului soft;

sistemul de help on-line;

suporturile de curs pentru instruire n utilizarea sistemului soft, etc.

Toate aceste tipuri de documente trebuie realizate la standarde de calitate deosebite dac
se dorete meninerea sistemului soft pe o traiectorie ascendent n topul preferinelor
clienilor.
Este momentul s spunem c, vorbind despre clieni, din punct de vedere managerial
acetia pot fi:

clieni pentru care dezvoltm un sistem soft dedicat;

clieni pentru care dezvoltm un sistem soft de interes general.

S mai adugm faptul c, dintre toate documentele care nsoesc realizarea unui sistem
soft unele sunt destinate a fi livrate clientului, altele sunt pentru uzul intern al firmei
productoare de soft.

Procesele desfurate n timpul dezvoltrii softului
Dac dorete s se implice n gsirea unui rspuns ct mai bun la ntrebarea Cum este
realizat sistemul soft?, MPS trebuie s exercite un control metodic asupra modului n
care se desfoar activitile pe baza crora sunt realizate documentele menionate mai
sus, n acest paragraf. Ideea de control metodic poate avea nelesuri diferite pentru manageri
diferii. A sugera cititorului s priveasc aceast idee din perspectiv pragmatic: cel care
investete n dezvoltarea unui sistem soft este preocupat ca procesul de dezvoltare a
softului s fie structurat pe principii de eficien i calitate.
Eficiena micoreaz costurile de producie, calitatea micoreaz costurile cu
ntreinerea sau dezvoltarea.
Iat motive destul de puternice pentru ca un manager s fie preocupat de coninutul unui
proces de dezvoltare a softului.
Din punct de vedere al managerului, problemele care apar n dezvoltarea softului se vd
astfel:

1.Deoarece producerea unui document este posibil ca urmare a unei activiti specifice,
ntregul proces de dezvoltare a softului va fi ntotdeauna o sum de activiti care de
fapt formeaz un sistem de activiti, dac lum n seam nenumratele
interdependene dintre acestea.

2.Activitile de dezvoltare tipice pentru un sistem soft ar putea fi
considerate:

analiza cerinelor;

specificarea formal a sistemului i a prilor acestuia;

proiectarea arhitecturii sistemului i a componentelor acestuia;

implementarea sistemului;

testarea componentelor sistemului;

integrarea componentelor n sistem i testarea sistemului;

scrierea manualelor i a altor tipuri de documentaii utilizator;

instalare sistem;

ntreinerea sistemului pe timpul exploatrii.

Deducem c este sarcina MPS s defineasc procesele de dezvoltare pentru a indica:

-care sunt documentele i produsele care urmeaz a fi realizate;
-ce activiti vor fi desfurate;
-cnd va primi clientul documentele i produsele pe care le ateapt;
-cnd vor fi desfurate activitile.

De aceea este imperios necesar ca activitile de dezvoltare s fie organizate, ceea ce
implic desfurarea unor activiti adiionale procesului de dezvoltare a softului. Aceste
activiti adiionale dau consisten unui proces paralel cu procesul de dezvoltare a softului:
procesul de management al proiectului de realizare a unui sistem soft.
Am vzut c activitile de dezvoltare au ca rezultat o mare varietate de documente.
Activitile de management au ca rezultat esenial planurile pe baza crora se desfoar
activitile de dezvoltare. Prevederile i implicaiile acestor planuri sunt negociate cu clientul,
deoarece conin multe elemente de interes pentru acesta (resurse, termene de execuie, etc.).

Factorul uman implicat n dezvoltarea sistemelor soft
Proiectele soft de medie i mare complexitate presupun o participare semnificativ din
punct de vedere al factorului uman. M refer, n primul rnd, la specialitii n IS care se
implic n desfurarea activitilor de dezvoltare. Atunci cnd se lucreaz n echip la
rezolvarea unei probleme, gestiunea relaiilor dintre membrii echipei devine o problem
important. Aa cum ne nva tratatele de management ntre membrii unei echipe de
dezvoltare pot apare: relaii profesionale (de colaborare sau de subordonare), relaii de natur
general-uman (simpatie, antipatie, indiferen, etc.), relaii legate de partajarea unor resurse
comune (ncperile n care se lucreaz, grupurile sanitare, biblioteca, etc.) .a.m.d.
Este sarcina managerului s gseasc soluiile cele mai simple pentru optimizarea
funcionrii acestui complex de relaii.
Evident, managementul este interesat, n primul rnd, de eficientizarea relaiilor
profesionale. De aceea, managementul proiectelor soft va propune un model de organizare a
membrilor unei echipe de dezvoltare. Cu toate c mai exist i vistori care vd o echip de
proiectare ca o sum natural de preocupri convergente, practica recunoate ca valabile
modelele ierarhice de organizare. Astfel c este posibil un model de organizare a membrilor
unei echipe de dezvoltare, pentru un proiect mare, ca n Figura 5.2.
Un astfel de model ncapsuleaz, evident, o serie de elemente birocratice, indispensabile
pentru bunul mers al activitilor ntr-o echip de dezvoltare. Tot managementul este cel care
trebuie s gseasc cea mai corect dimensionare a structurii birocratice a unui proiect, n
funcie de mrimea proiectului i prioritile acestuia.
O astfel de structur birocratic este necesar pentru a asigura, i din punct de vedere
managerial, abstractizarea efortului de dezvoltare a unui sistem soft. Pentru o mai bun
nelegere a rolului managementului n dezvoltarea sistemelor soft, n paragraful 5.2.2.2 voi
face o scurt trecere n revist a ideilor de baz ale teoriei generale a managementului din
perspectiv informaionial.
















Figura 5.2 Model ierarhic, ipotetic, de organizarea a membrilor unei echipe de proiectare

5.2.2.2. Informaie i management
Sistemele informaionale pot mbunti considerabil procesul de elaborare a deciziilor
manageriale. Veritabila industrie de sisteme informaionale bazate pe calculator a impus
concepte precum: sisteme de management informaional (SMI) i sisteme informaionale
executive (SIE). Semnificaia precis a acestor concepte o voi prezenta n cele ce urmeaz.

Informaia i funciile managementului
Managementul este, n general, descris ca un proces de conducere care implic
urmtoarele funcii: planificarea, organizarea, coordonarea i controlul. Aceste funcii ale
managementului au fost identificate i expuse pentru prima dat de ctre Henri Fayol, un
pionier al teoriei managementului din Frana.

Planificarea
Ca funcie a managementului, planificarea presupune estimarea evoluiei proceselor i
fenomenelor viitoare, respectiv, a efectelor pozitive i negative pe care aceasta le poate genera
asupra sistemului condus. Tot de previziune ine i capacitatea managementului de a pregti
din timp strategii i scenarii de aciune pentru minimizarea riscurilor i maximizarea
gradului de realizare a obiectivelor urmrite.

Manager de
proiect
Colec-
tiv de
asigu-
rare a
calitii
Colectiv
de verifi-
care i
validare
Colectiv
de mode-
lare a
soluiei
Colec-
tiv de
progra-
mare
Colectiv
pentru a-
sigurarea
suportu-
lui hard
Integrare Subsistem 1 Subsistem n
.......
Organizarea
Ca funcie a procesului de management, organizarea definete ansamblul proceselor de
conducere prin intermediul crora se divizeaz activitatea sistemului condus, stabilindu-se i
delimitndu-se subactivitile i sarcinile corespunztoare acestora.
Altfel spus, organizarea nseamn gruparea dup criterii de funcionalitate i eficien
a sarcinilor i delegarea responsabilitii necesare ndeplinirii lor.

Coordonarea
Ca funcie a procesului de management, coordonarea const n ansamblul proceselor
prin care se sincronizeaz deciziile i aciunile personalului unui sistem organizaional
(n cadrul previziunilor i organizrii anterior stabilite), cu scopul asigurrii resurselor
necesare, n timp util, de calitatea stabilit i n cantitatea dorit, pentru atingerea
obiectivelor sistemului organizaional. ndeplinirea acestei funcii a sistemului de
management este posibil cu ajutorul unui sistem de comunicare adecvat la toate nivelele de
management.

Controlul
Prin control desemnm ansamblul proceselor de urmrire a modului n care se desfoar
diferite aciuni sau ntreg procesul de management, ct i de reglare a activitilor organizaiei
prin gsirea unor metode eficiente de identificare i eliminare a efectelor perturbaiilor aprute
n funcionarea sistemului.
Schematiznd i dezvoltnd puin subiectul avem Figura 5.3.
Cititorul are ocazia s-i formeze o imagine ceva mai cuprinztoare asupra dificultilor
meseriei de manager. Pe lng faptul c pretinde competen, uneori interdisciplinar,
pentru a menine n echilibru diferitele tendine care se pot manifesta la nivelul sistemului
condus i la diferite niveluri de management, meseria de manager este marcat de numeroase
responsabiliti, att fa de indivizii sau grupurile profesionale conduse ct i fa de
organizaie n ansamblu.
Poate c, n acest moment, cititorul i-a modificat oarecum atitudinea i fa de MPS.

Pentru a nu eua, un proiect soft are nevoie de un management eficient, elastic,
corect dimensionat.

Toate aceste caliti ale actului de management(eficient, elastic, corect dimensionat)
depind de virtuile sistemelor informaionale pe care se bazeaz managementul. Dintre
componentele sistemelor informaionale un rol esenial l joac, dup cum am ami spus SMI,
SAD, SIE.

SMI (Sistemele de management informaional)
Numite n diferite lucrri i sisteme de raportare a informaiilor, aceste sisteme au fost
primul tip de sistem informatic-suport pentru actul de management.
SMI produc date i informaii necesare pentru fundamentarea multora dintre deciziile
zilnice ale managerilor. Beneficiari obinuii ai SMI: managerii de nivel tactic i operaional.

SAD (Sistem de asistare a deciziilor)
Sunt sisteme de informare bazate pe calculator care furnizeaz suport informaional
interactiv managerilor n timpul procesului de elaborare a deciziilor. Astfel de sisteme pot
folosi: modele analitice, baze de date specializate, sisteme expert, etc. Beneficiari obinuii ai
SAD: managerii de nivel tactic i strategic.

















































Figura 5.3.c Niveluri de management

Management
strategic
Management
tactic
Management
operativ
Planificare i control al aciunilor
de interes general; competena
managerului de top
Planificare i control al aciunilor
la nivelul subunitilor
componente; competena
managerului mediu
Planificare i control al operaiilor
zilnice; competena managerilor
care au contact direct cu nivelul
operativ
Date i informaii
Planificarea
Stabilire obiec-
tive i dezvolta-
re strategii i
tactici
Organizarea
Delegarea
responsabilit-
iilor la nivel de
individ i de
grup
Coordonarea
Conducerea
personalului
prin motivare i
comunicare
Controlul
Evaluarea i
ajustarea
performanelor
organizaionale
Figura 5.3.a Funciile managementului
Interpersonal
Leader profesional
Legtur cu mediul
Leader formal
Informaional
Supervizor
Difuzor
Leader de opinie
Decizional
Antreprenor
Gestiune conflict
Alocare resurse
Negociere
Figura 5.3.b Rolurile managementului
SIE (Sisteme informaionale executive)
Sunt sisteme informaionale care combin multe dintre nsuirile SIM i SAD. Atunci
cnd au fost dezvoltate pentru prima dat, SIE au fost focalizate pe ideea de asigurare a
managerilor de nivel top cu informaii strategice. Astfel de sisteme trebuie s permit
managerilor de top un acces rapid la informaii despre factorii de succes critici din
perspectiva ndeplinirii obiectivelor asumate de organizaie.
n lucrarea [11] subiectul de fa este amplu dezvoltat i, ceea ce este important, dintr-o
perspectiv pregnant pragmatic, ceea ce l ajut pe cititor s neleag mai bine relaia dintre
informaie i management care, n alt plan este nimic altceva dect relaia dintre informaie i
putere. nchei aici mica incursiune n lumea managementului, invitnd cititorul s-i
completeze cultura i cu o serie de cunotine care ar putea s fac lumin ntr-o zon n care,
altfel, poate bntui improvizaia.
Cu perspectiva asupra managementului modificat n acord cu cele spuse n 5.2.2.2,
putem aborda probleme cheie ale MPS ca n paragraful 5.2.2.3.

5.2.2.3. Esenial i la obiect despre MPS
Aadar, MPS este un caz particular de management de proiect, care la rndul lui este un
caz particular de management n genere. Prin urmare, putem defini MPS rspunznd la
ntrebrile:

1. Ce activiti desfoar managerii n industria softului?

2. Ce rol joac managerii ca i componente ale MPS?

Rspunsul la aceste ntrebri mi cere s precizez urmtoarele:

Activiti desfurate/competene ale managerilor:

-Planificarea (=stabilire obiective i organizarea modului de ndeplinire a acestora);

-Urmrirea evoluiei proiectului prin msurarea progreselor realizate n raport cu planul;

-Efectuarea coreciilor necesare pentru ca evoluia proiectului s aib o curb ascendent,
n limitele planului stabilit;

-Tratarea excepiilor, adic efectuarea unor corecii majore la planul de execuie pentru a
evita un posibil eec al proiectului.

Aceste tipuri de activiti sunt desfurate la diferite nivele de management:

-la nivel strategic (privesc ntreaga firm de dezvoltare a softului, pe o perioad de cteva
luni sau chiar mai mult);

-la nivel de proiect (privesc derularea unui proiect, n acord cu termenele de execuie
asociate);

-la nivel de echip de proiectare (privesc o faz n dezvoltarea unui sistem soft);

-la nivel individual (privesc desfurarea activitilor la nivel individual de pe o zi pe
alta).

Aspectele fundamentale pe care se structureaz aceste activiti sunt:

resursele; este vorba, n principal, de utilizarea celei mai importante resurse n IS,
timpul de lucru al specialitilor IS; deci, clasica, de-acum, problem: cine, ce i unde
face?.

calitatea; este vorba de calitatea sistemului soft n curs de dezvoltare, adic, trebuie
clarificat care sunt obiectivele urmrite din acest punct de vedere i care sunt modalitile
de ndeplinire a acestor obiective.

riscurile; este vorba de apariia unor situaii care pot afecta evoluia corect a
proiectului; din punctul de vedere al managementului, problema este:
-cum pot fi identificate aceste situaii?
i
-cum pot fi prevenite aceste situaii?

Dezvoltarea sistemelor soft folosete intens capacitile explicative i de reprezentare
ale modelelor:

-diferite modele pentru structura i proprietile produselor realizate n timpul dezvoltrii
sistemului soft;

-diferite modele pentru structura i proprietile proceselor specificate n diferite planuri
de dezvoltare.

La fel ca i n alte domenii, se face uz de dou tipuri fundamentale de modele:
-modele calitative
i
-modele cantitative.

Modelele calitative (indiferent dac este vorba de produse sau procese) sunt utilizate
pentru descrierea structurii acestora n termeni de componente i relaii ntre componente.
Modelele calitative pot admite mai multe tipuri de reprezentri (de tip diagram cazul
UML, matematizate grafuri sau arborescene, formale codul surs ntr-un limbaj de
programare). Sunt posibile, dac se pltete tributul necesar rigorii, transformri de la o
reprezentare la alta, dac acest lucru este n beneficiul evoluiei spre succes a proiectului.

Modelele cantitative i propun cuantificarea atributelor msurabile ale produselor sau
proceselor, precum i a interaciunilor dintre acestea. Efectiv, aceste modele se reduc la
diferite tipuri de ecuaii matematice.

n managementul proiectelor, modelele calitative sunt folosite pentru a descrie:
-cum este compus procesul de dezvoltare din activiti;

-ce documente produce un proces i ce documente sunt necesare pentru a desfura un
proces;

-cum se constituie ntr-o faz activitile care coopereaz pentru a produce un produs
livrabil ctre un anume tip de client;

-cum se nlnuie fazele pentru a forma un proces complet.

De asemenea, se poate spune c, n managementul proiectelor modelele cantitative sunt
folosite pentru a descrie:
-atributele care msoar calitatea i resursele implicate n dezvoltarea unui sistem soft;

-cum pot fi estimate valorile acestor atribute la nceputul proiectului;

-cum pot fi actualizate valorile acestor atribute n timpul derulrii proiectului pentru a
menine un trend favorabil ndeplinirii obiectivelor proiectului.

Putem aborda acum i subiectul numit n MPS Planificarea iniial a unui proiect.
Este o activitate deosebit de important a managementului care trebuie abordat cu maxim
profesionalism. Multe dintre deciziile care determin succesul unui proiect depind de
calitatea planificrii iniiale. Abordarea corect a acestui subiect presupune:

1
0
Stabilirea obiectivelor
Obiectivul fundamental al unui proiect de dezvoltare a softului este realizarea unui
sistem care corespunde cel puin cerinelor clienilor.
Spun cel puin clienilor (care corespund, dup cum am vzut n Capitolul 1, factorilor
externi ai calitii unui sistem soft i nu numai) deoarece exist i cerine fa de sistemele soft
care in de exigenele de natur intern, asumate de specialitii IS n procesul de modelare.
n mod uzual, obiectivul fundamental descris mai sus are trei subobiective importante:

obiective sistem ce servicii ateapt clientul de la sistem astfel nct s rezulte i nite
beneficii;
costurile asociate dezvoltrii i folosirii sistemului soft;
efectele secundare ale utilizrii sistemului soft alte avantaje pe care clientul le poate
avea dac utilizeaz sistemul soft.

Problema derivat din ncercarea de stabilire a obiectivelor unui sistem soft este
urmtoarea: de multe ori clientul nu poate defini exact propriile lui cerine, ceea ce, mai
devreme sau mai trziu, poate afecta proiectul.
De asemenea, la stabilirea obiectivelor nu trebuie uitat faptul c este dreptul clientului s
atepte beneficii din utilizarea sistemului soft care depesc costurile de dezvoltare i
utilizare.

2
0
Planificarea iniial
n acord cu cele spuse relativ la stabilirea obiectivelor, planificarea iniial va ncerca s
determine ct mai exact:

-ce produse trebuie livrate clientului pentru a garanta ndeplinirea obiectivelor asumate;

-ca urmare, ce activiti sunt necesare;

-n consecin, ce documente trebuie realizate n aceste activiti;

-n sfrit, ce alte activiti sunt necesare pentru a produce aceste documente.

Oriunde exist dubii, acestea pot fi tratate n aceast etap prin categorisirea articolelor
(documente, activiti, funcii, etc.) ca fiind:

-imperative (aceste articole sunt neaparat necesare pentru ntmpinarea cerinelor
clientului);

-de dorit (aceste articole ar putea fi foarte folositoare, dar este posibil satisfacerea
cerinelor clientului i fr producerea lor);

-opionale (aceste articole pot fi folositoare, dar, n mod sigur, este posibil satisfacerea
cerinelor importante ale clientului fr ele.

Rezultatul planului iniial va fi o list care cuprinde:

-activitile posibile;

-documentele care vor fi livrate clientului;

-documentele interne;

-clasificarea acestora dup importana lor pentru proiect.

5.2.3. Managementul riscului
5.2.3.1. Dereglare i risc
Din activitatea cotidian a unui angajat al unei firme este cunoscut faptul c treburile nu
merg ntotdeauna cum i-ar dori acesta. Lipsa de organizare sau presiunea exercitat asupra
activitii de factori aleatori pot provoca dereglri (incidente, disfuncii) ale acestei activiti.

Voi numi dereglare orice situaie care poate apare n desfurarea unei activiti i care
dac nu este combtut de management poate aduce prejudicii desfurrii activitii
conform planului.

Trivial, dar trebuie spus c orice dereglare are circumstane care o produc (=cauze) i
rezultate n caz de ignorare a dezvoltrii dereglrii (=efecte).
Evident, este de competena managerului s identifice cauzele dereglrii pentru a
aciona asupra lor. Este cunoscut prostul exemplu dat de unii manageri care se lupt cu
efectele deoarece nelepciunea i competena pe care o au nu i ajut s obin o reprezentare
ct mai precis asupra cauzelor dereglrii.

Se numete risc n procesul de management orice dereglare care reprezint o ameninare la
adresa ndeplinirii obiectivelor eseniale ale unui proiect.

n IS, obiectivele eseniale ale unui proiect pot fi: cerinele fa de sistem, costurile
estimate ale ntregului ciclu de via, etc.
n acest moment putem observa c, odat aprut un risc n procesul de management,
atunci acesta implic:

-o dereglare a unei activiti;

-probabilitatea ca dereglarea s apar (altfel spus, probabilitatea de manifestare a cauzelor
apariiei dereglrii);

-impactul pe care dereglarea l va avea asupra succesului proiectului, dac apare (cu alte
cuvinte, msura efectelor dereglrii asupra activitii).

Din punct de vedere al tipului de impact putem vorbi despre:

-riscuri binare (la care efectele sunt pe principiul totul sau nimic);

-riscuri scalate (la care efectele dereglrilor asociate pot varia pe o scal valoric dat);
deci sunt riscuri cu manifestare gradat dup circumstanele n care apare i se dezvolt o
anumit dereglare.

Motivul pentru care managementul unui proiect este pndit de riscuri are o explicaie
foarte simpl: lipsa informaiilor sau cunotinelor relativ la ceea ce urmeaz s se
ntmple n evoluia proiectului.
Altfel spus, n timpul dezvoltrii unui proiect putem s ne confruntm cu evenimente,
practic, nepredictibile dar i cu evenimente care pot fi puse pe seama lipsei de informare.
Aadar, putem vorbi despre evenimente incerte sau despre estimarea incert a
proprietilor evenimentelor.
Ca un exemplu, n IS este uzual ca specialitii s vorbeasc astfel:

-S-ar putea ca cerinele fa de sistemul soft s se schimbe;

-S-ar putea ca unii membri ai echipei s fac grip la iarn;
-S-ar putea s nu se gseasc pe pia un anume echipament, la preul scontat.

Toate aceste posibiliti descriu nite evenimente incerte.
Tot aa de bine, specialitii IS se pot exprima astfel:

-Nu tim ct poate dura iniierea utilizatorilor n folosirea sistemului soft;

-Nu avem date despre performanele echipamentului cutare.

n ambele situaii prezentate mai sus, datele exist pe undeva dar nu au ajuns singure la
urechea celor interesai.

5.3.2.2. Identificarea riscurilor n IS
Att teoreticienii (care nainte de a ajunge teoreticieni au fost buni practicieni) ct i
marea parte a practicienilor sunt contieni de numeroasele riscuri pe care le presupune
dezvoltarea unui sistem soft.
n IS, am mai spus-o i altundeva n carte, ne aflm pe un teren minat.
Bucuria de a izbuti n faa unei provocri a proiectului poate fi uor umbrit de o ncercare
neateptat. Faptul c multe proiecte importante au euat datorit modului superficial n care
au identificat i cuantificat riscurile arat importana cunoaterii acestor riscuri.
Cauze comune ale riscurilor n dezvoltarea sistemelor soft sunt:

cerinele fa de sistemul soft sunt neclare sau susceptibile de a fi modificate;

utilizarea unor tehnologii noi fr a avea cunotinele i deprinderile necesare;

dificulti n estimarea timpului de execuie i a altor resurse necesare;

dificulti n estimarea performanelor sistemului;

ncrederea oarb n furnizorii de componente i n posibilitatea de a termina proiectul cu
indivizi cu abiliti ndoielnice;

lipsa standardelor i a unor reguli minimale de urmat n procesul de dezvoltare a
softului.

ncercnd o clasificare a acestor cauze, oarecum, dup originea lor, avem:

Cauze care pot fi puse pe seama clientului
-necunoaterea cerinelor proprii fa de sistemul soft;
-neimplicarea corect i efectiv n efortul de dezvoltare a proiectului;
-necunoaterea clar a beneficiilor i costurilor proiectului.

Cauze care pot fi puse pe seama mediului n care va lucra sistemul
soft
-nivel de organizare deficitar;
-probabilitate mare de producere a unor schimbri majore.

Cauze care pot fi puse pe seama tehnologiei folosite
-aceasta nu furnizeaz facilitile cerute de dezvoltarea sistemului;
-aceasta nu are suficient performan n raport cu obiectivele sistemului.

Cauze care pot fi puse pe seama resurselor disponibile
-nu exist timp suficient pentru proiect;
-oamenii implicai n proiect sunt insuficieni;
-echipamentele disponibile pentru proiect sunt insuficiente sau uzate moral.

Cauze care pot fi puse pe seama echipei de dezvoltare
-necunoaterea tehnologiilor;
-necunoaterea metodologiei de dezvoltare;
-incapacitatea de a rezolva probleme punctuale;
-dependena exagerat de anumii membri ai echipei.

Toate motivele de ngrijorare reprezentate de aceste cauze (i nc multe altele) este bine
s fie luate n serios de managementul unui proiect de sistem soft care trebuie s procedeze
metodic i n problema riscurilor asociate proiectului, adic:

-identificnd riscurile i clasificndu-le;

-descriind riscurile pn la un nivel la care cauzele care le produc devin clare;

-cuantificnd riscurile (probabilitatea de apariie i mrimea impactului n caz de
apariie).

5.2.3.3. Reducerea riscului n MPS
Evident c n faa ameninrilor de tot felul la adresa succesului unui proiect,
managementul trebuie s ia msuri de reducere a riscului de manifestare a acestor ameninri.
Deoarece trebuie s fie foarte clar pentru managerii din IS, voi sublinia, nc odat, ideea c:

Managementul unui proiect de dezvoltare a unui sistem soft trebuie s desfoare o
activitate metodic pentru reducerea riscurilor care pot prejudicia succesul proiectului.

Ce poate face managementul n acest scop?
Cteva direcii de aciune ar putea s fie:

Obinerea de informaii pentru a diminua impactul necunoscutului asupra
anselor de reuit ale proiectului prin:
-organizarea de experimente i efectuarea de msurtori;

-efectuarea de cercetri i construirea de modele;

-construirea i evaluarea unor prototipuri, etc.

ncercarea de a preveni evoluia riscurilor prin:
-contientizarea oamenilor-cheie ai proiectului asupra ameninrilor la adresa proiectului;

-proiectarea i implementarea unor procedee de monitorizare a activitilor;

-perfecionarea profesional a membrilor echipei.

Mandatarea ctre un grup specializat a problemei managementului riscurilor unui
proiect.

A aminti cititorului c exist metodologii de dezvoltare a softului care se autointituleaz
risk-driven (deci pun n centrul ateniei preocuparea de a diminua riscurile la care poate fi
expus un proiect). A aminti n acest sens modelul spiralei (Boehm i Papaccio).

Ca un fel de concluzie a paragrafului 5.2.3 voi spune c planul de dezvoltare a unui
sistem soft poate fi modificat semnificativ n bine dac managementul i exercit cu
abilitate i funcia de gestiune a riscurilor care pot amenina succesul unui proiect. Dac
managementul unui proiect nelege rolul conducerii preventive printre ameninrile
naturale la adresa proiectului, atunci costurile, termenele de livrare i calitatea sistemului soft
pot fi salvate de la abateri nedorite.
5.2.4. Tehnici de reprezentare a MPS
Managerul unui proiect, n general, managerul unui proiect de dezvoltare a unui sistem
soft, n particular, dispun de numeroase tehnici pentru reprezentarea i descrierea planurilor
de proiectare.
Cititorul a neles, probabil, faptul c unul dintre rezultatele importante ale activitii
managementului n IS este reprezentat de planurile de dezvoltare.
Pentru reprezentarea acestor planuri se folosesc modele de tip reea sau diagrame Gantt.
Toate aceste tipuri de reprezentare urmresc, n esen, acelai lucru: identificarea aspectelor
critice ale planurilor de dezvoltare cu scopul de a focaliza atenia managementului
asupra acestor aspecte.
nainte de a trece la descrierea succint a tehnicilor de analiz a drumurilor critice ale
unui plan de dezvoltare trebuie s informez cititorul c exist sisteme soft dedicate asistrii
managementului proiectelor n general (CA Super-Project, Rational Rose).

5.2.4.1. Analiza drumului critic
Tehnica cunoscut sub denumirea CPA (prescurtare de la Critical Path Analysis) a fost
dezvoltat la sfritul anilor 50 pentru a fi folosit n dezvoltarea unor proiecte mari ale
marinei americane. La origine, cunoscut ca metoda PERT (Project Evaluation and Review
Technique), mai este numit i analiza de tip reea, fiind folosit intens n nenumrate
proiecte. Istoricul CPA i PERT arat c PERT este mai elaborat dect CPA. n esen, ns,
ambele abordri folosesc pentru reprezentarea proiectelor concepte precum activitile i
evenimentele.
Terminarea unei activiti echivaleaz cu producerea unui eveniment n mersul
proiectului. Un astfel de eveniment mai este desemnat i ca reper (milestone n englez) n
dezvoltarea proiectului. Fiecare reper reprezint nceputul unor activiti care sunt direct
dependente de terminarea activitilor precedente. Deoarece pentru prezentarea ideilor de baz
ale analizei de tip reea m voi limita la semantica CPA, voi mai spune c CPA se bazeaz pe
analiza dependenelor secveniale ntre activiti i folosete durata estimat pentru fiecare
activitate cu scopul de a deduce o estimare a duratei proiectului. De asemenea, CPA permite
identificarea dependenelor dintre activiti care sunt critice pentru evoluia proiectului.
Etapele care trebuie parcurse pentru a elabora o analiz CPA sunt prezentate mai jos.

Etapa 1
Tabelarea tuturor activitilor i reperelor proiectului
Aceast etap presupune ntocmirea de tabele care conin informaii similare celor
prezentate n Figura 5.4.

Activitate Descriere Reper
Activiti
precedente
Durata
estimat
Personal necesar
A Interviuri utilizator 2 5 u.t. 2
B Pregtire contracte
de utilizare
3 2 u.t. Cel de la A
C Rafinare contexte de
utilizare
4 A,B 2 u.t. 3
D Schimabre ecrane
interfa utilizator
5 C 2 u.t. 2
E Rafinare proiectare
ecrane utilizator
6 D 2 u.t. 2
F Identificare clase 7 C 2 u.t. 3
G Analiza relaiilor
dintre clase
8 F 4 u.t. 3
H Schiare diagram
clase
9 F 5 u.t. 3
I Rafinare diagram
clase
10 G,H 4 u.t. 4

Figura 5.4. Un exemplu de proiect de activiti n IS



Etapa 2
Determinarea dependenelor dintre activiti
Anumite activiti nu pot ncepe pn cnd altele nu s-au terminat.
Predecesorii activitilor sunt reprezentai n coloana patru a tabelului de tipul celui din
Figura 5.4. Ca un exemplu, activitatea rafinare contexte de utilizare trebuie s fie terminat
nainte de a trece la identificarea claselor.

Etapa 3
Estimarea duratei fiecrei activiti
Pentru rezolvarea acestei probleme exist mai multe abordri datorit elementelor incerte
implicate n estimarea duratei activitilor.
Una dintre cele mai mult folosite formule este:

6
) * 4 ( MPT MLT MOT
ED
+ +
=

unde:
-ED este durata estimat a activitii (Expected Duration);
-MOT este aprecierea cea mai optimist asupra duratei activitii (Most Optimistic
Time);
-MLT este aprecierea cea mai probabil asupra duratei activitii (Most Likely Time);
-MPT este aprecierea cea mai pesimist asupra duratei activitii (Most Pessimistic
Time).

Odat calculat durata estimat a unei activiti, aceasta este trecut n coloana 5 a unui
tabel asemntor celui din Figura 5.4.

Etapa 4
Elaborarea diagramelor CPA
Exist dou stiluri principale de notaii utilizate n elaborarea diagramelor CPA,
desemnate prin activiti n nod sau activiti pe muchii.
Amndou tipurile de notaii folosesc acelai tip de informaii dei arat diferit. n cele ce
urmeaz voi adopta soluia activiti pe muchii. n aceast variant fiecare reper este
reprezentat printr-un cerc cu trei compartimente.
Un compartiment este etichetat cu numrul reperului iar celelalte dou vor indica termenul
cel mai devreme de ncepere a activitii (TDI), i, respectiv, termenul cel mai ntrziat de
ncepere a activitii (TII). Ilustrm cele spuse n Figura 5.5.











11
15
7
18
24
8
D
7
Numr reper
Termenul cel mai devreme de ncepere pentru
activitatea D
Termenul cel mai ntrziat de
ncepere pentru activitatea D
Durat activitate
Etichet
activitate
Figura 5.5. Exemple de notaie CPA
Diagrama CPA, parial completat, relativ la datele indicate n Figura 5.4. este prezentat
n Figura 5.6.
Voi face cteva observaii relativ la Figura 5.6. Mai nti, acolo unde apar sgei punctate
spunem c avem activiti fictive, a cror durat este 0. Astfel de activiti fictive sunt dictate
de raiuni de tipul:

Conform datelor din Figura 5.4. activitile G i H depind de terminarea activitii F
(reperul 7);

De asemenea, G i H sunt predecesori pentru I (reper 9, unde ncepe activitatea I).
Deoarece nu este obligatoriu ca G i H s se termine n acelai timp, fiecare activitate are
nevoie de reper separat.













Figura 5.6. Diagrama CPA parial completat pentru un exemplu din Figura 5.4.

Practic, activitatea fictiv n discuie face legtura necesar ntre reperele 8 i 9.

Etapa 5
Completarea datelor de tip TDI i TII pentru fiecare reper
Pentru completarea cu date de tip TDI a diagramei CPA se folosete procedeul mersului
nainte prin diagram, de la reperul considerat de start pn la reperul final i completarea cu
date astfel:

1) TDI pentru reperul de start, n mod convenional este 0.
2) Pentru reperele care au un singur predecesor valoarea TDI se obine prin nsumarea la
valoarea TDI a predecesorului, a duratei estimate a activitii acestor repere;
3) Pentru reperele care au mai muli predecesori valoarea TDI se obine prin nsumarea la
valoarea TDI cea mai mare (din lista valorilor TDI ale predecesorilor) a duratei estimate a
activitii asociate alegerii respective.
4) Evident, nainte de a calcula valoarea TDI pentru un reper, valorile TDI pentru toi
predecesorii trebuie s fie deja calculate.

Urmnd o astfel de procedur s-au obinut valorile TDI n diagrama CPA din Figura 5.6.
Pentru completarea cu date de tip TII a diagramei CPA se folosete procedeul mersului
napoi prin diagram, de la reperul considerat final pn la reperul de start i completarea cu
date astfel:

1) TII pentru reperul final este considerat, convenional, egal cu TDI al acestui reper;
0
1
18
10
14
9
9
7
7
4
5
3
11
6
9
5
2
2
13
8
E
2
I
4
H
5
F
2
C
2
A
5
B
2
D
2
G
4 activitate
fictiv
2) Pentru toate reperele care au un singur succesor, valoarea TII se obine scznd din
valoarea TII a succesorului (deja calculat) durata activitii corespunztoare;
3) Pentru reperele care au mai muli succesori se fac toate diferenele dintre TII ale
succesorilor i duratele activitilor asociate, alegndu-se ca valoare pentru TII ale
reperelor n cauz, diferena cea mai mic;
4) Din nou se presupune c, ajungnd s calculm valoarea TII a unui reper, toi succesorii
au fost deja examinai.

Forma complet a diagramei CPA prezentat n Figura 5.6. o avem n Figura 5.7.













Figura 5.7. Diagrama CPA complet pentru exemplul
prezentat n Figura 5.4.

Etapa 6
Identificarea drumului critic
Dup completarea cu valori a etichetelor TDI i TII ale reperelor se poate calcula timpul
de ateptare al reperelor ca diferen dintre TDI i TII. Aceast diferen reprezint timpul cu
care o activitate poate fi ntrziat fr a provoca probleme de ncadrare n grafic celorlaltelor
activiti ale proiectului.
O succesiune de repere pentru care diferenele ntre TDI i TII sunt 0 se numete
drum critic. n Figura 5.7. activitile care aparin unui drum critic au muchiile marcate cu o
bar vertical dubl. Drumurile critice rein, n mod deosebit atenia managementului unui
proiect, datorit faptului c orice ntrziere pe o traiectorie critic poate afecta evoluia
proiectului.

5.2.4.2. Diagrame Gantt
Aceste diagrame (denumite astfel dup inventatorul lor Henry Gantt) reprezint o
tehnic extrem de simpl i eficient de reprezentare a ealonrii n timp a activitilor unui
proiect.
Tehnica folosete barele orizontale pentru a reprezenta activitile proiectelor. ntr-o astfel
de diagram axa orizontal reprezint timpul, fiind etichetat cu repere de tip uniti de timp
(ore, zile, sptmni) fcnd mai uoar urmrirea evoluiei proiectului n timp. Activitile
sunt aezate pe vertical, imediat n stnga diagramei, de sus n jos. Lungimea barei asociate
fiecrei activiti n diagram este proporional cu durata activitii.
S mai adugm faptul c diagramele Gantt arat n mod foarte sugestiv care sunt timpii
de ateptare asociai activitiilor i pot, de asemenea, da informaii cu privire la alocarea n
timp a resursei personal. Prezentm exemplul din Figura 5.4. din perspectiva diagramelor
Gantt, n Figura 5.8.
0
0
1
18
18
10
14
14
9
9
9
7
7
7
4
5
5
3
11
18
6
9
16
5
2
5
2
13
14
8
E
2
I
4
H
5
F
2
C
2
A
5
B
2
D
2
G
4
5.2.4.3. Alte precizri asupra problemei reprezentrii planurilor de
dezvoltare a sistemelor soft
MPS are nevoie de o logistic de calitate pentru a monitoriza evoluia activitilor unui
proiect din mai multe considerente, dintre care voi enumera cteva n continuare:

1.Prin utilizarea tehnicilor de reprezentare de tip CPA sau diagrame Gantt (DG) funcia
de control a managemenrului are o foarte solid fundamentare metodologic. Se elimin
controlul dup ureche sau bazat pe intuiia genial a managerului de proiect.
2.Prin utilizarea tehnicilor CPA sau DG riscurile rezultate din planificare pot fi
estimate i, ca atare, se pot lua din timp msuri de diminuare sau eliminare a acestora.
3.Prin utilizarea tehnicilor CPA sau DG se instituie un cadru sistematic pentru
controlul diferitelor tipuri de resurse ale proiectelor (personalul uman i productivitatea
acestuia).
4.O planificare riguroas dar echilibrat influeneaz hotrtor costurile unui
proiect.
5.Utilitatea acestor tehnici depinde de acurateea instrumentelor cu ajutorul crora se
stabilesc duratele activitilor i necesarul de personal pe activitate.
Aceste elemente se obin cu ajutorul altor tehnici (metrici), a cror importan o subliniez,
dar informez cititorul c n aceast carte nu voi dezvolta acest subiect.































ZILE
4
3
3
3
2
2
3
3
Numr angajai
Activiti
A
B
C
D
E
G
F
H
I
ZILE
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
10

9

8

7

6

5

4

3

2

1
Numr de
angajai
Figura 5.8. Diagram Gantt a activitilor i pentru alocarea
angajailor pe activitile proiectului
Voi atrage, totui, atenia cititorului c este vorba despre metode de estimare a mrimii
proiectelor (gen COCOMO), nc controversate, deci nc insuficiente din punct de vedere al
obiectivitii tiinifice.
Cititorul trebuie s mai afle, n ncheiere, c subiectul managementului proiectelor soft i
preocup insistent i pe dezvoltatorii de medii CASE care ncearc s integreze n acestea i
elemente suport pentru MPS.





























































Capitolul 6
Aspecte metodologice n abordarea unor
probleme de dezvoltare a unor sisteme soft

Fr aplicaii orice teorie moare repede. Fr exemple de aplicare orice
paradigm rmne o vorb goal. Dei n aceast carte nu am prezentat pe
larg o metodologie anume, voi folosi (acolo unde este cazul), pentru
ilustrarea unora dintre ideile repetate insistent n celelalte capitole ale
crii, o serie de elemente preluate dup Object Modelling Technique
(OMT) n contextul unei probleme pretext. Complexitatea problemei puse n
discuie nu este devastatoare; adevrul este c nici nu caut aa ceva n
aceast carte.
Problema are, ns, destule elemente care necesit din partea celui care le
abordeaz reflecie , metod i spirit creator, nainte de a se repezi la
tastatur, cum au obiceiul muli dintre softitii zilelor noastre.














\
6.1 Inteniile acestui capitol
Pentru specialistul n IS aflat n faa unei probleme ntrebarea cea mai important rmne :
"Cum se poate abstractiza enunul respectivei probleme astfel nct soluia obinut s
aib mcar o parte din nsuirile unui sistem soft de calitate?".
Atrag atenia cititorului c nu vreau s minimalizez cu nimic rolul celorlaltor prghii
metodologice n dezvoltarea sistemelor soft. Exist, ns, un motiv simplu pentru care, n
aceast carte, voi insista mai mult pe elementele de abstractizare: prezentarea limbajului pe
care l propune o metodologie pentru modelarea (=abstractizarea) soluiei unui sistem soft este
un exerciiu de maxim seriozitate care, eventual, poate face obiectul altei cri.
De aceea, soluia problemei-pretext pe care o voi aborda n acest capitol va fi reprezentat
folosind limbajul natural i, eventual, reprezentri grafice uor de neles sau care fac parte din
categoria conveniilor de reprezentare cunoscute de marea majoritate a specialitilor n IS.
S mai precizm, n sfrit, c problema este interesant tipologic, fapt care, sper eu, va
menine treaz atenia cititorului.

6.2 Problem pretext pentru modelarea orientat obiect
Pledoaria acestui paragraf are dou motivaii:

1
0
Din ce n ce mai muli specialiti n IS ar vrea s adere la "religia OO" dar, mai nti,
trebuie ca cineva s-i conving. Ctigarea de adereni autentici (nu formali) ai "religiei
OO" nseamn s faci din aceti adereni practicani din convingere. tiu c nu este
simplu, dar voi ncerca.

2
0
Modelarea OO este o ocazie de a abstractiza de o manier care poate sensibiliza i
ncnta chiar i pe specialitii n IS recunoscui pentru ndrjirea cu care i apr vechile
principii.

Problema pretext asupra creia m opresc are urmtorul enun preliminar:


Modelarea orientat obiect a unei stive generice


Odat cu mine, nelege i cititorul c, nainte de a trece la rezolvarea propriuzis a
problemei, trebuie s desluim, mcar n parte, semantica sintagmei "modelare orientat
obiect".

6.2.1 Ce este modelarea orientat obiect?
Iat o ntrebare bun la care este greu de dat un rspuns care s mulumeasc pe toat
lumea. n IS, de exemplu, se vorbete despre orientare obiect n modelarea informaiilor,
analiza i proiectarea sistemelor i, evident, n programare. Prezentarea pe care o fac va pune
accent pe "liniile de for" ale sintagmei OO, dac mi este ngduit exprimarea.
Mai nti, i voi reaminti cititorului c, indiferent dac se afl n domeniul problemei(DP)
sau n domeniul soluiei (DS), specialistul n IS se confrunt, n esen, cu dou tipuri de
probleme:

organizarea datelor;

organizarea prelucrrilor.

Din perspectiv clasic, pentru rezolvarea acestor dou probleme exist modele i metode
de abordare specifice. Aa se face c vor exista modele de organizare a datelor (relaional,
reea, ierarhic, fiiere clasice) i metode de organizare a prelucrrilor (orientate pe funcii,
dirijate de date, dirijate de evenimente, etc.).
Rezultatul unui demers din perspectiv clasic, n mare, este cel prezentat n Figura 6.1.
















Figura 6.1 Maniera clasic de obinere a soluiei tehnice a unei probleme

Obiecia fundamental adus paradigmei ilustrat de Figura 6.1 se refer la sensibilitatea
deosebit a soluiei tehnice n faa modificrilor de orice tip. Originea acestei sensibiliti
se afl n autonomia relativ a celor dou modele, benefic pentru dezvoltarea separat, de
calitate, a modelelor, avnd n vedere o serie de cerine pe termen scurt fa de soluie ca
ntreg, dar generatoare, n mod natural, de dependene ntre modele, care nu favorizeaz
continuitatea modular, extensibilitatea, portabilitatea, reutilizabilitatea, aspecte ale calitii
unui sistem soft relevante pe termen lung.
Foarte sintetic spus domeniul problemei se mapeaz slab pe domeniul soluiei.
Att din interiorul laboratoarelor IS ct i din afara acestora s-a exercitat o presiune
permanent pentru aezarea pe baze noi a relaie dintre date i prelucrri. O variant, validat
practic ca eficient, de reaezare a relaiei date-prelucrri o reprezint modelarea orientat
obiect.
Imperativul cheie al paradigmei OO pare a fi asigurarea unor condiii naturale de
mapare sporit a domeniului problemei pe domeniul soluiei.
Pentru realizarea acestui deziderat era nevoie de o modificare radical de abordare, pe
care voi ncerca s o prezint n continuare n ceea ce are ea esenial.

Aa cum rezult din Figura 6.2 modelarea OO a soluiei unei probleme se face pe trei
nivele de abstractizare. Conceptele eseniale (i specifice) ale modelrii OO se regsesc la
primul nivel de abstractizare, numit n majoritatea metodologiilor OO modelul claselor. S
mai semnalez cititorului c suportul pentru maparea DP pe DS se regsete, n principal, la
primele dou nivele de abstractizare.





Problema
Determinare
cerine fa
de sistemul
soft
Modelul
datelor
Modelul
prelucrrilor
Soluia tehnic

















Figura 6.2 Maniera OO de obinere a soluie tehnice a unei probleme

Concepte fundamentale n elaborarea modelului claselor
Am afirmat n mai multe rnduri faptul c sistemele reale care suport un proces de
modelare informaional reprezint punctul de plecare n demersul de dezvoltare a unui sistem
soft care deservete un anumit sistem real.
Obiectele care populeaz sistemul real i sunt importante din punct de vedere al cerinelor
formulate fa de sistemul soft pot fi caracterizate informaional i comportamental. n
limbaj IS se spune c un obiect din lumea real poate fi abstractizat de o list de atribute
informaionale i de o list de atribute comportamentale.

Conceptul de clas
Toate obiectele care sunt abstractizate de aceeai list de atribute informaionale i de
aceeai list de atribute comportamentale formeaz o clas.

Punnd n valoare afirmaia de mai sus este evident c obiectele care populeaz sistemul
real sunt partiionate n funcie de raportarea lor la o anumit list de atribute informaionale i
comportamentale.
Paradigma OO merge mai departe i afirm c a defini o clas n spirit OO nseamn:

1
0
A stabili lista de atribute informaionale (necesare i suficiente att din punct de
vedere al logicii interne a obiectelor abstractizate de aceast clas ct i din punct de vedere al
cerinelor de reprezentare a relaiilor cu obiecte avnd alte clase definitoare).
2
0
A declara aceast list ca fiind privat(=ascuns) fa de clienii clasei.
3
0
A stabili lista de atribute comportamentale (necesare i suficiente att din punct de
vedere al logicii interne a obiectelor abstractizate de aceast clas ct i din punct de vedere al
solicitrilor formulate de ctre obiecte avnd alte clase definitoare).
4
0
Declararea ca publice a acelor atribute comportamentale care abstractizeaz
mulimea serviciilor adresate obiectelor avnd alte clase definitoare (mulimea acestor
atribute se numete interfa).

Aplicarea consecvent a conceptului de clas astfel formulat nseamn, n paradigma OO,
promovarea sistematic a principiului ncapsulrii.
Problema
Determinare cerine
fa de sistemul soft
Abstractizarea soluiei ca o colecie de clase,
interconectate (asocieri, generalizri,
agregri)
Abstractizarea structurii de control a fiecrei
clase
Abstractizarea transformrilor suportate de
fluxurile de date
Dup cum se poate deduce, ncapsularea are dou obiective precise:
abstractizarea similaritilor informaionale i comportamentale ale unei colecii de
obiecte;
abstractizarea serviciilor oferite clienilor de ctre obiectele din colecia menionat mai
sus.

Conceptul de obiect
n paradigma OO se numete obiect o instan a unei clase
n modelare, ca i n programare, un obiect este caracterizat prin:

identitate;
o list de valori asociat listei de atribute informaionale;
mulimea atributelor comportamentale partajate mpreun cu alte obiecte avnd
aceeai clas definitoare.

Din punct de vedere al identitii, un obiect are o identiate fizic, asigurat de sistemul
care monitorizeaz procesul de declarare a obiectelor, ct i o identitate logic, datorat
protocoalelor pe baza crora, pentru fiecare obiect cu identitate fizic, recunoscut, se atribuie
nite valori atributelor informaionale aferente.

Conceptul de atribut informaional
n modelarea OO exist deja consens n ceea ce privete sintaxa de principiu i semantica
unui atribut informaional, n sensul c un atribut informaional se specific prin:

<nume_atribut_informaional> : <tip>[=<Valoare_implicit>]

Aadar, orice atribut informaional are nume, tip i, eventual, valoare implicit.
Semantica atributului informaional depinde, evident, de contextul n care acesta este utilizat.

Operaii i metode
Descrierea comportamentului obiectelor unei clase este realizat, la cel mai nalt nivel de
abstractizare de operaii. Exist un consens relativ i n ceea ce privete specificarea unei
operaii n modelarea OO.
Sintaxa de specificare a unei operaii este, n general:

[<Tip_returnat>] <Nume_operaie>([<Lista_de_parametri>])

Aadar, o operaie poate s returneze o dat de un tip specificat sau nimic, are un
nume i poate face schimb de date cu apelantul n toate modurile posibile prin intermediul
listei de parametri.
Cititorul este contient de faptul c, specificnd o operaie (nu implementnd-o),
descriem, practic, utilitatea acestei operaii i modul de folosire a acesteia.

n aceast faz a expunerii este cazul s pregtesc cititorul pentru noi dezvluiri n ceea ce
privete potenialul modelrii OO.
Din nenumrate motive (nevoia de rafinare treptat a soluiei, nevoia de reutilizare a
efortului de modelare, nevoia de specificare a unor contexte polimorfice) soluia orientat
obiect a unei probleme poate fi rezultatul unor eforturi de abstractizare care se desfoar pe
trei direcii:

pe orizontal, obinndu-se clase avnd aproximativ acelai nivel de abstractizare i
structuri informaionale i comportamentale dizjuncte;
pe vertical, obinndu-se lanuri de derivare, prin intermediul crora se gestioneaz
similaritile partajate de clase;
n adncime, obinndu-se, dac este cazul, alternative (replici) la o soluie dat. Dei,
formulat ca idee i nc nefolosit, abstractizarea n adncime, cu un suport adecvat la
nivelul limbajelor de programare ar putea constitui soluia sistematic pentru o problem mai
veche :problema polimorfismului de nivel sistemic.

Revenind la ideea abstractizrii OO pe vertical (deoarece problema de care ne vom ocupa
va fi abordat din aceast perspectiv), voi prezenta, cu intenia de a comenta, situaia din
Figura 6.3.















Figura 6.3 O ierarhie de clase
Figura 6.3 ne sugereaz urmtoarele:

1
0
Clasa referit cu 1 abstractizeaz similaritile provenind de la cele dou lanuri de
derivare. Abstractizarea, dup cum spune i psihologia gndirii, este o operaie tipic de
generalizare. De aceea, n procesul de abstractizare pe vertical, o relaie posibil ntre clase
este relaia de generalizare (privit de jos n sus) sau relaia de derivare (spacializare) dac
privim de sus n jos. Conform Figurii 6.3 clasa referit de 2 generalizeaz clasa referit de 4
i n acelai timp specializeaz clasa referit de 1, ntr-o anumit direcie. Cititorul este invitat
s dea dovad de mult rbdare din punct de vedere al apetitului pentru comunicarea ideilor n
modelarea OO. Exist un exces de limbaj, n mare parte scuzat de dorina celor care
comunic, de a surprinde noi faete ale unui fenomen att de complex cum este modelarea
OO. Ca un exemplu, ntr-un lan de derivare, o clas care generalizeaz se numete
superclas, clas de baz sau clas printe iar o clas care specializeaz se numete clas
derivat, clas motenitoare sau clas urma. Oarecum ngrijorat de amploarea pe care o ia
aceast "scurt prezentare" a fenomenului OO, trebuie totui s mai adaug c specializarea se
poate realiza n dou moduri:

prin adugarea de noi atribute;
prin redefinirea unor atribute comportamentale.

A

A
B
A
C
A
B
D
1
2
3
4
Atunci cnd este prezent fenomenul de redefinire a atributelor comportamentale,
versiunea unui atribut comportamental la nivelul clasei rdcin se numete operaie,
versiunile situate n clasele derivate direct sau indirect din clasa rdcin se numesc metode.
Paradigma OO abstractizeaz eforturile de gestiune a similaritilor n relaiile
dintre clase ridicnd la rang de principiu ideea de motenire. Pentru cititorul atent
motenirea reprezint o poart larg deschis ctre utilizarea efortului de dezvoltare, dac
principiul motenirii este judicios aplicat i n deplin respect fa de ncapsularea OO.
Evident c, cititorul curios va dori s afle i ce alte tipuri de relaii se mai pot concepe
ntre clase. i voi spune c aceste relaii mai pot fi: de asociere, de agregare, de asociere ca i
clase, etc.). Tot cititorului curios i voi mai spune c modelarea OO mai susine fervent nc
un principiu important, principiul polimorfismului, a crui nelegere este, parial,
condiionat de nelegerea conceptului de mesaj.

Conceptul de mesaj
n modelarea OO se numete mesaj apelul unei metode a unui obiect, formulat de ctre
un client al obiectului respectiv.

Evidente sunt urmtoarele dou lucruri:

orice mesaj trebuie s primeasc un rspuns;
obiectele comunic ntre ele cu ajutorul mesajelor.

Acum suntem n msur s spunem c, n condiii tehnice dependente de limbajul de
programare un mesaj avnd aceeai structur sintactic poate primi rspunsuri diferite,
n funcie de contextul n care s-a creat obiectul care este destinatar al mesajului. O
operaie care se poate comporta astfel se numete operaie polimorfic.
Nu-i rmne cititorului dect dorina de a alege o paradigm OO pentru a se familiariza cu
toate exigenele ei n ceea ce privete: notaia utilizat, structura ciclului de via, structura
procesului de management al softului, etc.

6.2.1 Elemente de modelarea pe marginea problemei propuse
S ne reamintim c problema pretext a paragrafului 6.2 este:

Modelarea orientat obiect a unei stive generice

Un curs de structuri de date ne nva c stiva este o structur de date n care operaiile de
inserare i extragere a elementelor sunt restricionate n sensul c:

1
0
Operaia de inserare (numit i PUSH n majoritatea implementrilor) se face
ntotdeauna naintea ultimului element introdus, dac acest ultim element introdus exist.
Ultimul element introdus este referit de o variabil special a stivei numit vrf sau top.
Dac stiva este vid, atunci vrful stivei (care are o valoare special ) este actualizat astfel
nct s refere elementul introdus.
De remarcat c la inserarea unui element n stiv putem avea depire superioar, n
situaia n care capacitatea predefinit a stivei este saturat.

2
0
Operaia de extragere (numit i POP n majoritatea implementrilor) se refer la
elementul din vrful stivei, dac acesta exist. n urma unei operaii de extragere, vrful
stivei este actualizat. De remarcat, de asemenea, c n situaia n care se foreaz o
extragere de element dintr-o stiv vid, spunem c avem depire inferioar.


Exprimndu-ne n limbaj OO, operaiile obligatorii pentru o stiv sunt operaiile PUSH()
i POP(). Evident, cnd modelm comportamentul unei stive, ne pot fi de folos i alte operaii
a cror natur depinde de contextul n care este folosit stiva. Exemple de astfel de alte
operaii voi prezenta n propunerea de soluie la aceast problem.

Stiva pe care vrem s-o modelm trebuie s fie generic

Cititorul a neles, probabil, c o structur de date este un tip de dat structurat, prin
urmare este viabil n momentul n care cunoatem, printre altele, tipul elementelor care
populeaz structura. Astfel c putem avea stive de ntregi, stive de numere reale, stive de
iruri de caractere, etc.

O structur de date devine generic dac este specificat n aa fel nct s permit
aplicarea acelorai operaii asupra unor tipuri diferite de date

Dac la cerina genericitii adugm i cerina de a putea avea drept suport pentru
pstrarea stivei memoria RAM sau o specie adecvat de memorie extern, problema ncepe
s-i contureze un enun consistent.
Sunt n msur (poate cititorului o s i se par prea devreme, dar m va nelege dup ce
va aborda singur o astfel de problem) s formulez urmtoarele cerine fa de sistemul soft pe
care vreau s-l dezvolt:

1
0
Codul rezultat trebuie gndit astfel nct s poat fi partajat de orice client
(programator) interesat;
2
0
Fiecare client s poat opera cu un tip de dat propriu;
3
0
Fiecare client s poat opta pentru suportul adecvat pentru stiv (RAM sau memorie
extern);
4
0
Protocolul de lucru cu stiva s fie ct mai simplu;
5
0
Se vor avea, pe ct posibil, n vedere, cerine precum: structurarea, modularizarea,
orientarea pe obiect, lizibilitatea, documentarea, etc.

Ultimele dou cerine se refer, evident, la cod.
Inventarul faptic al enunului problemei n cauz, mpreun cu cerinele mai sus formulate
ne ngduie s evideniem, din perspectiv orientare-obiect, urmtoarele clase candidate
(Figura 6.4).









Figura 6.4 Clase candidate la soluia OO a problemei

Este clar c aceste clase prezint similariti de comportament. Intenia n acest moment
este de a schia soluia problemei ca o ierarhie de clase, avnd aliura din Figura 6.5.

Stiva_RAM
Stiva_M_Extern












Figura 6.5 Ierarhia de clase asociat soluiei problemei

Dup cum se vede, s-a introdus o clas abstract (TAbsStiva) a crei menire este de a
colecta similaritile venind pe cele dou ramuri:

Ramura din stnga
TRamStiva
modeleaz stiva RAM
se deriveaz din TAbsStiva

TVideoStiva
modeleaz stiva utiliznd ca surs de date pentru stiv memoria
video n mode text;
se deriveaz din TRamStiva

Ramura din dreapta
TMVStiva
modeleaz stiva pstrat pe o memorie extern (virtual)
se deriveaz din TAbsStiva deoarece n comportamentul clasei TMVStiva apar
elemente care fac improprie derivarea din una dintre clasele TRamStiva sau
TVideoStiva.

Schema prezentat n Figura 6.5 poate fi considerat modelul claselor pentru problema
noastr. n treact fie spus, clasele prezentate n ierarhia din Figura 6.5 nu exceleaz prin
dinamism, deci sunt triviale din punct de vedere modelului dinamic (structura de control, n
Figura 6.2).
Pentru a spori semantica schemei din Figura 6.5 prezentm, n extenso, definiiile claselor
(rezultate n urma unui proces de abstractizare-ncapsulare uor de intuit de cititorul curios).

TabsStiva
Lungime_Element : intreg pozitiv;
Numar_curent_de_elemente : intreg pozitiv=0;
Eroare_de_alocare_memorie: boolean=false
atribute private

*Init(LE:intreg pozitiv)
*Done() ;virtual;
boolean GetAllocateError;
TAbsStiva
TRamStiva
TVideoStiva
TMVStiva
Push( X: referin la element de inserat) ; virtual
boolean Pop(X: referin la elementul extras) ; virtual
Clear() ;virtual;
RollUp() ;virtual;
RollDn() ;virtual

Dup cum se vede din definiia clasei TabsStiva, toate operaiile fac parte din interfa,
nefiind declarate ca private.
De asemenea, cititorilor care au ncercat gustul programrii OO n Pascal, C++ sai Java
trebuie s le atrag atenia asupra operaiilor speciale (marcate cu asterisc) , Init (constructor de
clas) i Done (destructor de clas), operaii care joac un rol important n alocarea dinamic
a memoriei pentru obiecte, iniializarea lor i a tabelelor cu metode virtuale n caz c este
cazul.
S mai adugm faptul c unele operaii ale clasei sunt urmate de clauza virtual ceea ce
atrage atenia asupra inteniei redefinirii acestor operaii n descendeni.
Se observ c atributele informaionale care au putut fi incluse n lista de atribute
informaionale a clasei TAbsStiva sunt:
-Lungime_Element; un ntreg pozitiv care va pstra lungimea n octei a
elementului stivei;

-Numar_curent_de_elemente; un ntreg pozitiv care pstreaz numrul de
elemente din stiv; la crearea unei instane valoarea este 0.

-Eroare_de_alocare_memorie: camp boolean care ajut la monitorizarea
erorilor de alocare.

Invit cititorul la refelecie pe tema implicaiilor pe care le are genericitatea asupra
procesului de modelare i, n final s urmreasc codul Pascal care implementeaz ideile
prezentate mai sus.

TramStiva (derivat din TAbsStiva)
Top: referin la element stiv (autoreferire)
atribut privat
*Init(LE:intreg pozitiv)
*Done() ;virtual;
boolean GetAllocateError;
Push( X: referin la element de inserat) ; virtual
boolean Pop(X: referin la elementul extras) ; virtual
Clear() ;virtual;
RollUp() ;virtual;
RollDn() ;virtual


TMVStiva (derivat din TAbsStiva)
Buffer :referin la o zon de memorie tampon
Mesaj_Eroare : ir de caractere
Nume_extern_fiier_asociat stivei :ir de caractere
atribute private
Hfiier :Handle de fiier
*Init(LE:intreg pozitiv)
*Done() ;virtual;
boolean GetAllocateError;
Push( X: referin la element de inserat) ; virtual
boolean Pop(X: referin la elementul extras) ; virtual
Clear() ;virtual;
RollUp() ;virtual;
RollDn() ;virtual


TvideoStiva (derivat din TRamStiva)

PushScreen()
boolean PopScreen()

nainte de a prezenta codul surs care "materializeaz" inteniile de proiectare prezentate
mai sus voi mai aduga o serie de observaii de interes pentru cititor.

1
0
Utilizatorul ierarhiei de clase poate beneficia de comportamentul polimorfic al ntregii
ierarhii. Singura lui obligaie este s fac jonciunea cu codul aferent ierarhiei, n programul
client.
2
0
Genericitatea impune ca n protocolul de utilizare a ierarhiei, la un moment dat s se
"coboare" la nivel de octet. Acest efort, ns, este derizoriu n comparaie cu prelucrrile
asumate n ierarhie.
3
0
Utilizatorul ierarhiei beneficiaz, totodat i de facilitile oferite de ierarhie penru
depistarea posibilelor erori. Evident, tratarea unei erori este de competena clientului.
4
0
Alegerea limbajului este o sarcin relativ comod pentru problema noastr. Am ales
limbajul Pascal pentru a m face mai uor neles. n realitate aceast alegere nseamn c mi-
am pus codul obinut la dispoziia comunitii programatorilor de Pascal i, eventual, Delphi.
Cunosctorii de C++ tiu, ns, c suportul oferit de C++ pentru programare OO i
programarea n genere este mult mai interesant.

n sfrit, despre semantica ierarhiei, cel mai mult ne vorbete codul Pascal, ncapsulat
ntr-un unit, pe care l prezint n continuare.

6.2.3 Implementarea modelului
Cititorul are la dispoziie n acest paragraf unit-ul Pascal care ncapsuleaz toate
specificaiile convenite n paragraful 6.2.2 precum i o mic aplicaie care folosete una dintre
capabilitile unit-ului. Artificiile Pascal folosite pentru a rezolva problema genericitii pot fi
uor nelese urmrind comentariile incluse n codul surs i avnd cunotine elementare de
lucru cu structurile dinamice n Pascal. Cititorul poate trage nvminte i din analiza atent a
modului n care conceptele OO din modelare i gsesc suport n Pascal, limbaj care s-a
nscut, iniial cu alte scopuri dect promovarea principiilor OO.

unit StivaGen;
{
----------------------------------------------------
Unit-ul ncapsuleaz soluia orientat obiect pentru
stiva avand ca suport:

-Memoria RAM;
-Hard disc-ul;

Autor: Dorin Bocu
Ianuarie 2001
----------------------------------------------------
}

{
----------------------------------------------------
Interfaa unit-ului
----------------------------------------------------
}
interface
const
Screen_Bytes = 4000;
var
{
----------------------------------------------------
Variabile necesare pentru recuperarea adresei
memoriei video
----------------------------------------------------
}
VideoMode :byte absolute $0040:$0049;
VideoAddress :word;
VideoPtr :pointer;
type

{
----------------------------------------------------
Declaraii de tipuri necesare pentru a specifica
structura nodului listei suport pentru stiva RAM
----------------------------------------------------
}
GenStivaPtr = ^GenStivaRec;
GenStivaRec = record
DataPtr : Pointer;
NextLink : GenStivaPtr
end;

{
----------------------------------------------------
Clasa care modeleaz o stiv abstract
----------------------------------------------------
}
PTAbsStiva=^TAbsStiva;
TAbsStiva=object
constructor Init(ElementSize:word);
destructor Done ;virtual;
function GetAllocateError:boolean;
procedure Push(X:pointer) ;virtual;
function Pop(X:pointer):boolean;virtual;
procedure Clear ;virtual;
procedure RollUp ;virtual;
procedure RollDn ;virtual;
private
ElemSize,
Height : word;
AllocateError : boolean;
end;

{
----------------------------------------------------
Clasa care modeleaz stiva cu suport memoria RAM
----------------------------------------------------
}
PTRamStiva=^TRamStiva;
TRamStiva = object(TAbsStiva)
constructor Init(ElementSize:word);
destructor Done ;virtual;
procedure Push(X :pointer ) ;virtual;
function Pop(X:pointer):boolean;virtual;
procedure Clear ;virtual;
procedure RollUp ;virtual;
procedure RollDn ;virtual;
private
Top : GenStivaPtr;
end;

{
----------------------------------------------------
Clasa care modeleaz stiva cu suport memoria externa
----------------------------------------------------
}
PTMVStiva=^TMVStiva;
TMVStiva = object(TAbsStiva)
constructor Init(ElementSize : word; Filename:
string);
destructor Done ;virtual;
function GetErrorMessage : string;
procedure Push(X:pointer) ;virtual;
function Pop(X:pointer):boolean ;virtual;
procedure Clear ;virtual;
procedure RollUp ;virtual;
procedure RollDn ;virtual;
private
DataBuffer:pointer; {pointer la buffer
-ul de date }
ErrorMessage, {messaj eroare }
VMfilename : string;{nume extern fisier}
VMfile : file; {variabila fisier }
end;

{
----------------------------------------------------
Clasa care modeleaz o stiv RAM care utilizeaz ca sursa de
date memoria video
----------------------------------------------------
}

PTVideoStiva=^TVideoStiva;
TVideoStiva= object(TRamStiva)
procedure PushScreen;
function PopScreen:boolean;
end;

implementation

{
---------------------------------------------------
Implementare operaii abstracte TAbsStiva
---------------------------------------------------
}
constructor TAbsStiva.Init(ElementSize :word);
begin
end;

destructor TAbsStiva.Done;
begin
Clear
end;

procedure TAbsStiva.Push(X:pointer);
begin
end;

function TAbsStiva.GetAllocateError:boolean;
begin
GetAllocateError := AllocateError
end;

function TAbsStiva.Pop(X:pointer):boolean;
begin
end;

procedure TAbsStiva.Clear;
begin
end;

procedure TAbsStiva.RollUp;
begin
end;

procedure TAbsStiva.RollDn;
begin
end;

{
---------------------------------------------------
Funcie utilizator care foreaz sistemul s
returneze nil n caz de apel new sau getmem
nesoluionat. Soluie Pascal!!!!!
---------------------------------------------------
}
function HeapErrorHandler(Size : word):integer;far;

begin
HeapErrorHandler := 1
end;

{
---------------------------------------------------
Implementare metode TRamStiva
---------------------------------------------------
}
constructor TRamStiva.Init(ElementSize:word);
begin
ElemSize := ElementSize;
if ElemSize = 0
then
ElemSize := 1;
Height := 0;
AllocateError := false;
Top := nil;
end;

destructor TRamStiva.Done;

begin
Clear
end;

procedure TRamStiva.Push(X:pointer);
var p : GenStivaPtr;
begin
AllocateError := false;
if Top <> nil
then
begin
new(p); { alocare element nou in stiva}
if p = nil then begin
AllocateError := true;
exit;
end;

getmem(p^.DataPtr, ElemSize);
if p^.DataPtr = nil
then
begin
AllocateError := true;
exit;
end;
move(X^, p^.DataPtr^, ElemSize);
p^.NextLink := Top;
Top := p
end
else
begin
new(Top);
if Top = nil
then
begin
AllocateError := true;
exit;
end;
getmem(Top^.DataPtr, ElemSize);
if Top^.DataPtr = nil
then
begin
AllocateError := true;
exit;
end;
move(X^, Top^.DataPtr^, ElemSize);
Top^.NextLink := nil
end;
inc(Height)
end;

function TRamStiva.Pop(X:pointer):boolean;
var
p:GenStivaPtr;
begin
if Height > 0
then
begin
Move(Top^.DataPtr^, X^, ElemSize);
FreeMem(Top^.DataPtr, ElemSize); { dealocare data
}
p :=Top;
Top:=Top^.NextLink;
dispose(p); { dealocare nod stiva
}
dec(Height);
Pop:=true
end
else
Pop:=false
end;

procedure TRamStiva.Clear;
var
x:Pointer;
begin
GetMem(x, ElemSize);
while Pop(x) do
freemem(x, ElemSize);
end;

procedure TRamStiva.RollUp;
var
old_top,
next_one: GenStivaPtr;
begin
if (Top = nil) or (Height < 2)
then
exit;
old_top := Top;
Top := Top^.NextLink;
old_top^.NextLink := nil;
next_one := Top^.NextLink;
while next_one^.NextLink <> nil do
next_one := next_one^.NextLink;
next_one^.NextLink := old_top;
end;

procedure TRamStiva.RollDn;
var
last_one, next_one : GenStivaPtr;
begin
if (Top = nil) or (Height < 2)
then
Exit;
last_one := nil;
next_one := Top;
while next_one^.NextLink <> nil do
begin
last_one := next_one;
next_one := next_one^.NextLink;
end;
next_one^.NextLink := Top;
Top := next_one;
last_one^.NextLink := nil
end;

{
---------------------------------------------------
Implementare metode TMVStiva
---------------------------------------------------
}
constructor TMVStiva.Init(ElementSize:word; Filename
:string);
begin
if ElementSize = 0
then
ElementSize := 1;
ElemSize := ElementSize;
VMfilename := Filename;
Height := 0;
assign(VMfile, VMfilename);
{$I-}
rewrite(VMfile,ElemSize);
{$I+}
if IOresult <> 0
then
begin
ErrorMessage:='Nu se poate deschide fisierul '
+VMfilename;
exit;
end;
GetMem(DataBuffer,ElemSize);
if DataBuffer=nil
then
begin
AllocateError :=true;
ErrorMessage :='Eroare alocare dinamica'
end
else
begin
AllocateError :=false;
ErrorMessage :=''
end;
end;

destructor TMVStiva.Done;
begin
Clear;
freemem(DataBuffer, ElemSize);
end;

function TMVStiva.GetErrorMessage:string;
begin
GetErrorMessage:=ErrorMessage
end;

procedure TMVStiva.Push(X:Pointer);
begin
inc(Height);
seek(VMfile, Height-1);
blockwrite(VMfile, X^, 1);
end;

function TMVStiva.Pop(X:Pointer):boolean;
begin
if Height > 0
then
begin
dec(Height);
seek(VMfile, Height);
blockread(VMfile, X^, 1);
Pop := true
end
else
Pop := false;
end;

procedure TMVStiva.Clear;
begin
Height := 0;
{$I-}
close(VMfile);
erase(VMfile);
{$I+}
end;

procedure TMVStiva.RollUp;
var
I:word;
begin
seek(VMfile, Height-1);
blockread(VMfile, DataBuffer^, 1);
seek(VMfile, Height);
blockwrite(VMfile, DataBuffer^, 1);
for I := Height-1 downto 1 do
begin
seek(VMfile, I-1);
blockread(VMfile, DataBuffer^, 1);
seek(VMfile, I);
blockwrite(VMfile, DataBuffer^, 1);
end;
seek(VMfile, Height);
blockread(VMfile, DataBuffer^, 1);
seek(VMfile, 0);
blockwrite(VMfile, DataBuffer^, 1);
end;

procedure TMVStiva.RollDn;
var
I:word;
begin
seek(VMfile, 0);
blockread(VMfile, DataBuffer^, 1);
seek(VMfile, Height);
blockwrite(VMfile, DataBuffer^, 1);
for I:=2 to Height do
begin
seek(VMfile, I-1);
blockread(VMfile, DataBuffer^, 1);
seek(VMfile, I-2);
blockwrite(VMfile, DataBuffer^, 1);
end;
seek(VMfile, Height);
blockread(VMfile, DataBuffer^, 1);
seek(VMfile, Height-1);
blockwrite(VMfile, DataBuffer^, 1);
end;

{
---------------------------------------------------
Implementare metode TVideoStiva
---------------------------------------------------
}
procedure TVideoStiva.PushScreen;
begin
Push(VideoPtr)
end;


function TVideoStiva.PopScreen:boolean;
begin
PopScreen:=Pop(VideoPtr);
end;

{
---------------------------------------------------
Secvena de initializare a unit-ului in care variabila
unitului SYSTEM HeapError este forat la valoarea <adresa
functiei HeapErrorHandler> care
ar putea trata excepiile la alocarea dinamic a memorie.
De asemenea se stabilete adresa memoriei video
---------------------------------------------------
}
begin
HeapError:=@HeapErrorHandler;
if VideoMode=7
then
VideoAddress:=$B000
else
VideoAddress:=$B800;
VideoPtr:=Ptr(VideoAddress,0);
end.

program Apl_Stiva_cu_sursa_de_date_memoria_video;
{$M 8192, 0, 655350}
{
---------------------------------------------------
Autor: Dorin Bocu
Ianuarie 2001
---------------------------------------------------
}
uses crt, StivaGen;

var
S : TVideoStiva;
I, NumarEcran : byte;
AKey : char;

{
---------------------------------------------------
Procedura umple ecranul cu un caracter dependent
de numrul de ecran primit ca parametru
---------------------------------------------------
}
procedure FillScreen(var SN : byte);
var
row : byte;
C : char;
AString : STRING;
begin
inc(SN);
clrscr;
C := chr(64 + SN);
FillChar(AString[1], 80, C);
AString[0] := chr(80);
writeln('Numar ecran ', SN);
for row := 2 to 24 do
write(AString);
end;
{
---------------------------------------------------
Programul principal
---------------------------------------------------
}
begin
clrscr;
{
---------------------------------------------------
Apelare constructor motenit de la TRamStiva
---------------------------------------------------
}
S.Init(Screen_Bytes);
NumarEcran := 0;

{
---------------------------------------------------
Pregtete trei ecrane cu informaii i le
salveaz n RAM
---------------------------------------------------
}
for I:=1 to 3 do
begin
FillScreen(NumarEcran);
S.PushScreen;
delay(1000);
end;
clrscr;
write('Asteptati va rog ...');
delay(1000);
{
---------------------------------------------------
Refacere ecrane prin apel succesiv al metodei Pop
---------------------------------------------------
}
while S.PopScreen do
delay(1000);
gotoxy(1,25);
clreol;
write('Apasati o tasta ... ');
AKey := readkey;
S.Done;
end.



































Capitolul 7
Asigurarea calitii n cadrul unei firme
productoare de soft

...Exist oameni sau naiuni pentru care teoria lucrului bine fcut
poate fi un motiv de bclie individual sau, de ce nu, naional.
Defeciunea provine de la nelegerea greit a importanei detaliilor
(care nu necesit anvergur spiritual deosebit, ci comportament
binevoitor) asupra chestiunilor paradigmatice (care sunt un prilej de
etalare a profunzimii potenelor intelectuale). Problema ar suna cam
aa: <Presupunnd c suntem inteligeni, cum putem dobndi
nelepciunea necesar pentru a folosi decent aceast inteligen?!>

(Extras din monologul pronunat de autor, n surdin, cu prilejul
unei cltorii, neateptate, ntr-un autoturism Mercedes)










7.1 Introducere
Aa cum am mai spus i n Capitolul 1, este nevoie de soft de calitate, produs n timp util
i la preuri competitive, pentru a face fa rigorilor supravieuirii pe piaa concurenial.
Expresia n timp util nseamn respectarea termenelor convenite pentru livrarea produselor.
Expresia la preuri competitive nseamn ncadrarea proiectului n restriciile bugetare
convenite.
Este evident faptul c cele dou cerine pot fi ndeplinite prin crearea tuturor condiiilor
pentru creterea continu a productivitii muncii.
Preocuparea sistematic pentru creterea productivitii muncii poate, ns, intra n
conflict cu cerina de a menine calitatea la standarde nalte, dac nu se studiaz cu atenie
impactul oricrei inovaii n procesul de dezvoltare, asupra calitii.
Metoda clasic pentru a face fa posibilelor conflicte dintre cele dou cerine se bazeaz
pe delegarea competenelor n materie de calitate, ctre persoane sau colective care se ocup,
exclusiv, de toate problemele presupuse de monitorizarea abaterilor de la calitate. Altfel spus:









Figura 7.1 Metoda clasic de asigurare a calitii

Mi se pare o abordare total depit n condiiile actuale. Calitatea trebuie s fie, n esen,
creaia operativului.
Majoritatea mijloacelor de promovare efectiv a calitii este concentrat n minile celor
care lucreaz nemijlocit la dezvoltarea softului (analiti, proiectani, programatori, etc). De
aceea, alternativa corect la Figura 7.1 mi se pare a fi cea prezentat n Figura 7.2.
Cteva consideraii pe marginea strategiei schiate n Figura 7.2, n cele ce urmeaz.

Activitile n ingineria softului (IS) se deosebesc mult de activitile din alte domenii
de activitate. n locul muchilor se folosete mult gndirea. Rutina exist, dar nu n prim plan,
cum se ntmpl n alte industrii. n prim plan se afl creativitatea specialistului n IS, care,
n fiecare proiect este obligat s fac fa la cerine noi, indiferent de faza n care se afl
dezvoltarea unui sistem soft. Pentru a se manifesta, creativitatea are nevoie de libertate de
aciune. Pentru a nu produce sub nivelul standardelor, creativitatea trebuie s se
raporteze contient la standarde.









Figura 7.2. Metoda propus pentru managementul calitii ntr-o firm modern de soft

Factorii care determin calitatea n IS sunt din ce n ce mai sofisticat distribuii i
articulai n cmpul de aciune al unui specialist IS. Multe probleme din IS pot fi rezolvate
optim prin alegerea tehnologiei (tehnologiilor) adecvate exigenelor proiectului. Am vrut s
subliniez, nc odat, faptul c asigurarea calitii este o problem de strategie, dac discutm
despre principii de promovare a standardelor de calitate i este o problem de competena
operativului, dac discutm despre mijloacele de operaionalizare a acestor principii. Ideea
care se degaj, cred c este clar.

O component a
managementului
firmei
Monitorizeaz
abaterile de la
calitate ale ...

Operativului

Managementul
firmei
Asigur un transfer sistematic
de resurse i competene,
pentru asigurarea calitii,
ctre nivelul...

Operativ
Dac se dorete, neaprat, implicarea managementului n rezolvarea problemelor de
calitate (ceea ce este imperativ pentru o firm care se respect), abordarea ideal
este urmtoarea:
Stabilirea principiilor fundamentale care trebuie respectate n procesul de
dezvoltare a softului (la nivelul conducerii firmei);
Convenirea mijloacelor de operaionalizare a principiilor; aceste mijloace pot fi
independente de proiect sau, dac este cazul, dependente de proiect.

Din perspectiv obiect orientat, situaia se reprezint ca n Figura 7.3.
Fcnd analogie cu o abordare clasic din ingineria softului, competenele n materie de
asigurare a calitii softului, n cadrul unei firme, pot fi structurate pe trei nivele de
abstractizare:
-Nivelul conceptual (Conducerea firmei);
-Nicelul specificare (Coordonatorii de proiecte);
-Nivelul implementare (Membrii colectivelor de dezvoltare, repartizai pe
proiecte)



















Figura 7.3. Propunere de abordare, la nivel sistemic, a problemei calitii ntr-o firm de soft

Managementul calitii la nivelul conducerii firmei
-Conceptualizarea factorilor generici care determin calitatea unui
sistem soft;
-Conceptualizarea factorilor de calitate identificai de firm;
-Modaliti de aciune.

Managementul calitii la nivelul coordonatorilor de proiecte
-Specificarea factorilor generici care determin calitatea unui sistem
soft;
-Specificarea factorilor de calitate identificai de firm;
-Modaliti de aciune.

Managementul calitii la nivelul colectivelor de dezvoltare
(La nivelul conducerii firmei)
Principii fundamentale n
asigurarea calitii
(La nivelul coordonatorilor de
proiecte)
Mijloace de operaionalizare a
principiilor independente de proiect
(La nivelul colectivului de
proiectare 1)
Mijloace de
operaionalizare specifice
Proiect_1
(La nivelul colectivului de
proiectare k)
Mijloace de
operaionalizare
specifice Proiect_k
-Implementarea factorilor generici care determin calitatea unui
sistem soft;
-Implementarea factorilor de calitate identificai de firm;
-Modaliti de aciune.

7..2 Idei pentru programul de asigurare a calitii n cadrul unei firme oarecare de
soft

7.2.1 Nivelul conceptual (Conducerea firmei)
Ori de cte ori este nevoie, la acest nivel trebuie reflectat asupra urmtoarelor trei tipuri de
probleme:

-factori socotii, n genere, ca fiind importani pentru calitatea softului, pe
care firma vrea s i monitorizeze. Descrierea lor la nivel conceptual.

-factori identificai de conducerea firmei ca fiind importani pentru
calitatea unui proiect anume. Descrierea lor la nivel conceptual.

-modaliti de aciune la nivel conceptual.

Observaie
Problema calitii softului este condiderat n literatura de specialitate o problem
dificil, deoarece enunul ei se modific odat cu tehnologiile folosite pentru dezvoltarea
softului. Marea diversitate a abordrilor din punct de vedere tehnologic m-a determinat
s propun cele dou tipuri de factori ai calitii, n vederea monitorizrii.


FACTORII GENERICI AI CALITII
Literatura de specialitate distinge trei categorii de factori generici ai calitii.

-factori care se refer la comportarea unui sistem soft dup ce a fost
dat n exploatare:
-Corectitudinea;
-Fiabilitatea;
-Performana;
-Eficiena;
-Securitatea.

-factori care se refer la comportarea unui sistem soft n cazul n care
apar modificri:
-modularitatea;
-stilul de codificare i documentare;

-factori care se refer la comportarea unui sistem soft n cazul n care
acesta migreaz spre alte platforme hard sau de operare:
-portabilitatea
-reutilizabilitatea

nelesul dat la nivel conceptual acestor factori l prezentm, n reluare, pe scurt, n
continuare.

Corectitudinea se refer la abilitatea unui sistem soft de a executa toate sarcinile convenite
la specificarea cerinelor.

Fiabilitatea se refer la capacitatea sistemului soft de a-i conserva calitatea n timpul
exploatrii. n unele cri, fiabilitatea sistemelor soft se mai numete i robustee n
exploatare.

Performana se refer la modul n care sistemul soft, n format executabil, satisface
cerinele de performan convenite (timpii de rspuns la interogri, n medie sau minimali i
maximali, etc.).

Eficiena se refer la abilitatea sistemului soft de a utiliza eficient posibilitile mainii
fizice pe care acesta este executat.

Observaie
n condiiile n care resursele hard critice ale sistemelor de calcul i mbuntesc
permanent indicii de performan, s-ar prea c performana i eficiena nu mai sunt nite
prioriti, potrivit opiniei unor specialiti.
Opinia mea este c trebuie s monitorizm, n continuare, aceti factori deoarece, oricnd
pot ajuta un proiect s ctige btlia cu alte proiecte similare.

Securitatea se refer la abilitatea sistemului soft de a minimiza pierderile de date n timpul
avariilor la alimentare sau n cazul unor ncercri de utilizare neautorizat.

Modularitatea este un atribut de importan major al oricrui sistem soft de complexitate
medie i mare. Modularitatea trebuie planificat i urmrit judicios deoarece de realizarea ei
n condiii optime depinde esenial disponibilitatea unei soluii de a se adapta la condiii noi
de execuie i de a face fa la cerine noi (reutilizabilitatea i exetnsibilitatea). Modularizarea
corect este, practic, visul oricrui specialist n ingineria softului i mai ales al oricrui
programator iscusit. Practic, a modulariza corect nseamn :

arhitectur simpl a soluiei + descentralizarea optim a capabilitilor acesteia.

Stilul de codificare i documentare poate susine sau compromite evoluia unui sistem
soft, att n faza de proiect ct i n perioada de utilizare efetctiv. Stabilirea unui set minimal
de reguli i elemente suport pentru activitile de codificare i documentare trebuie s fie o
prioritate pe agenda celor care urmresc calitatea softlui n cadrul firmei.

Portabilitatea soluiei unui sistem soft msoar capacitatea sistemului soft de a face
fa, cu eforturi minimale, la exerciii de migrare pe alte platforme hard i de operare. n
condiiile n care varietatea arhitecturilor hard existente pe pia este n cretere iar lumea
mediilor de operare tinde s se dezvolte, nc n dispre fa de standardizarea tehnologiilor de
baz, este firesc s se aib, permanent n atenie i acest factor al calitii.

Reutilizabilitatea este un vis al oricrei firme de dezvoltare a softului. Ideea este
urmtoarea: dac un proiect, prin generalitatea lui, are disponibilitate spre reutilizare, n
ansamblu sau pe componentele, atunci reutilizabilitatea trebuie planificat sistematic.

FACTORI DE CALITATE IDENTIFICAI DE FIRM
<De studiat problema cu ntregul echipaj al firmei>

MODALITI DE ACIUNE LA NIVEL CONCEPTUAL.

S-ar putea sugera, de exemplu, urmtoarele direcii de aciune.

1. Pentru fiecare proiect se va alege procesul de dezvoltare cel mai adecvat. Putem, de
exemplu adopta urmtoarea atitudine: Mrimea i caracteristicile proiectelor aflate n lucru
ne-au condus la ideea c tipul de proces ideal, n cadrul firmei de soft XXXXX , este modelul
RAD (Rapid Application development).

2. Alegerea limbajului de modelare i a tools-urilor care promoveaz conceptele
acestuia. n aceast direcie sugerm o anumit constan a opiunilor deoarece nvarea unui
limbaj de modelare este o problem de timp i de bani. Ultimele evoluii n domeniu m
determin s sugerez utilizarea UML-ului, n combinaie cu tools-uri carre l promoveaz,
precum: Rational Rose, ObjectiF, etc..

3. Evaluarea lunar a calitii soluiei unui proiect, indiferent de nivelul de
abstractizare la care s-a ajuns.

7.2.2 Nivelul specificare (Coordonatorii de proiecte)

Specificarea corectitudinii
Atenia coordonatorilor de proiecte se va focaliza pe:
-Completitudinea listei cerinelor;
-Claritatea formulrii cerinelor;
-Identificarea relaiilor dintre cerine;
-Identificarea conflictelor dintre cerine si explorarea soluiilor de
compromis.

Specificarea performanei
Atenia coordonatorilor de proiecte se va focaliza pe:
-completitudinea listei indicatorilor de performan;
-Claritatea formulrii indicatorilor de performan;
-Identificarea relaiilor dintre indicatori
-Identificarea conflictelor dintre indicatori i explorarea soluiilor de
compromis.

Specificarea eficienei
Atenia coordonatorilor de proiecte se va focaliza pe:
-Selectarea indicatorilor de performan ai soluiei, sensibili la indicatorii de
performan ai resurselor hard critice;
-Identificarea protocoalelor de mapare a indicatorilor selectati peste indicatorii de
performanta ai resurselor hard critice

Specificarea fiabilitii
Atenia efilor de proiecte se va focaliza pe:
-Identificarea componentelor (interne i externe sistemului soft) care pot afecta
sigurana n funcionare a acestuia;
-Stabilirea strategiei de asigurare a fiabilitii pentru fiecare component n parte:
-elemente-suport conceptuale;
-elemente-suport la nivelul limbajului de programare;
-elemente-supot la nivelul mediului de dezvoltare.

7.2.3 Nivelul implementare (membrii colectivelor de dezvoltare,
repartizai pe proiecte)
La acest nivel se impun msuri care s asigure un feed-back permanent pe traseul
calitatea la nivel conceptualcalitatea specificatcalitatea la nivel de
operativcalitatea la nivel conceptual.

Msurile preconizate sunt de doua tipuri:
-punctuale;
-anticipative.

Msurile punctuale
Constituie un ansamblu de activiti, convenite de management, pentru a verifica modul n
care se realizeaz transferul de competene n domeniul calitii de la nivel de management
spre nivelul operativ. Pentru ca aceste activiti s se poat desfura corect este necesar s se
accepte urmtoarele condiii minimale:
-un proces de dezvoltare, care va permite implementarea feed-back-ului n domeniul
calitii;
-un limbaj de modelare i reprezentare adecvat, ceea ce va facilita
procesul de urmrire a calitii.

Msurile anticipative
Constituie ansamblul activitilor de informare i formare sistematic a tuturor
partenerilor unui proiect, n acord cu reponsabilitile curente i de perspectiv.

Msuri concrete pentru promovarea calitii la nivel operativ

-Elaborarea riguroas a documentaiei sistemelor soft
-documentaie tehnic;
-documentaie de utilizare
-documentaie de prezentare
Persoana care rspunde de calitate va defini abloanele pe baza crora se vor elabora
aceste tipuri de documentaii. efii de proiecte vor furniza toate datele necesare pentru
elaborarea documentaiilor. Tools-ul folosit va fi ObjectiF, de exemplu.

-Planificarea riguroas a procedurilor de testare (de urmrit paragraful 7.3 pentru mai
multe detalii relativ la rolul testrii n asigurarea calitii softului)

-ncadrarea efortului de dezvoltare ntr-un model de dezvoltare convenabil;
-Utilizarea, pentru elaborarea i reprezentarea soluiei, a unui limbaj
de modelare adecvat

Pentru testare, practica recomand combinarea tehnicilor top-down i bottom-up.
Ca model de dezvoltare, la mrimea i natura aplicaiilor de la firma de soft XXXXX
recomand prototipizarea.
Ca limbaj de modelare propun UML-ul.

-Accentuarea preocuprilor pentru managementul proiectelor i pe alte coordonate
care influeneaz calitatea (reutilizarea efortului de dezvoltare, nivelul de informare,
planificarea calendaristic, identificarea i gestiunea riscurilor, climatul de lucru etc.)
7.3 Prin testare spre sisteme soft de calitate
7.3.1 Consideraii preliminare

Activitatea de testare nu genereaz direct calitate, dar, planificat judicios, poate
contribui la realizarea softului de calitate.

Una dintre formulrile care au fcut carier n dezbaterile pe tema calitii softului
sun, sec, astfel: Testarea complet a componentelor unui sistem soft poate fi considerat
strategia de baz pentru asigurarea calitii softului.
n aceast seciune a crii nu voi relua discuia pe marginea factorilor care
determin calitatea unui sistem soft. Este esenial, ns, s constatm c factori precum
corectitudinea, robusteea i performana, evaluai cu superficialitate, pot compromite
ansele de reuit ale unui proiect.
De fapt, lucrurile sunt foarte simplu de formulat: Dac sistemul soft ajunge la
utilizator cu bug-uri, costurile pe care le implic remedierea (fix-area) acestor bug-uri sunt,
statistic vorbind, net superioare costurilor pe care le presupune prevenirea lor n timpul
proiectrii.
De aici, al doilea principiu care ar trebui s fie ncorporat obligatoriu n orice strategie de
testare: Procesul de testare a soluiei unui sistem soft trebuie s nceap, dac se poate,
nc din fazele timpurii ale proiectrii.
Admind ca fiind, realmente posibil, implementarea acestui ultim principiu, se pune
ntrebarea: Cum trebuie organizat procesul de testare a soluiei unui sistem soft de-a lungul
diferitelor stadii de abstractizare prin care aceasta trece. ntrebarea este destul de complicat,
fie c o abordm din perspectiv istoric, fie c ncercm s punem cap la cap ultimele idei
relativ la topic.
Se cuvine s adugm o remarc banal, de altfel: Testarea nu este o activitate
paralel cu procesul de dezvoltare. Organizarea judicioas a testrii este o necesitate din
punct de vedere al managementului i efectiv posibil doar cu aportul echipei de
dezvoltare, s spunem, din prima linie.
Aceasta deoarece cunostinele absolut necesare pentru a organiza testarea soluiei
unui sistem soft sunt cel mai coerent articulate n mintea echipei de dezvoltare din prima
linie.
Ca un exemplu, n UML, comportamentul diferitelor obiecte care contribuie la dinamica
unei aplicaii este capturat cu ajutorul modelelor vizuale de la diferite nivele de
abstractizare. n jurul acestor modele se pot dezvolta, ulterior, componente, a cror testare i
integrare progresiv este absolut natural. Exist, ns, o condiie esenial pentru ca lucrurile
s mearg pe acest fga:
Soluia trebuie dezvoltat orientat pe componente. Experiena arat c dezvoltarea
orientat pe componente asigur numeroase avantaje dezvoltatorilor (reutilizabilitate,
fiabilitate, manevrabilitate n timpul testrii) dar solicit o atenie deosebit n timpul
proiectrii interfeelor componentelor, n principal.

Se impune din ce n ce mai pregnant ideea c dezvoltarea softului trebuie s devin o
activitate n care improvizarea unei soluii tinde s fie nlocuit, sistematic, cu un efort
planificat de abstractizare i verificare a soluiei. n sprijinul unei astfel de atitudini poate
veni accesul constant la noutile n materie de metode de abstractizare i introducerea, pe
acest temei, a obinuinei de a utiliza instrumentele CASE pentru a optimiza diferitele tipuri
de activiti care contribuie la asigurarea calitii soluiei unui sistem soft.
Aadar, problemele de calitate n ingineria softului sunt de natur sistemic i, n
consecin, necesit o abordare sistemic. Fiind o problem al crei enun are geometrie
variabil, problema calitii va avea rezolvri nuanate, n funcie de: tipul proiectului,
viziunea managementului asupra calitii, tipul de proces utilizat n dezvoltare, metoda de
abstractizare folosit,etc. .
Simplificnd, n mod voluntar, lucrurile, calitatea soluiei unui sistem soft poate fi
asigurat dac managementul proiectului a reuit s specifice clar modul n care, pe parcursul
dezvoltrii se va verifica aderena soluiei la factorii de calitate monitorizai.
Beneficiarul principal al unui soft de calitate este clientul. Din punctul lui de vedere
calitatea nseamn regsirea cerinelor i implementarea optim a acestor cerine.
Beneficiarul unui soft de calitate poate fi i firma productoare de soft, pentru care
calitatea nseamn tot ceea ce ateapt clientul plus cerine precum: adaptarea flexibil la
cerine noi, localizarea ocurilor provocate de modificri ale soluiei, etc..
Dup acest scurt tur de orizont n problematica calitii softului, este cazul s fixm nite
idei concrete relativ la posibilitatea de a asigura efectiv calitatea ntr-un proces de dezvoltare.

7.3.2 Despre prototipizare, testare i asigurarea calitii
Modelarea obiect orientat a soluiei unui sistem soft permite integrarea unor metode
variate de asigurare a calitii. Aa cum am mai subliniat i cu alt prilej, prototipizarea este un
model de dezvoltare adecvat pentru o gam larg de proiecte. Din acest motiv voi ncerca s
evideniez virtuile prototipizrii n materie de asigurare a calitii.
Reordonnd ideile prezentate n Capitolul 3, se poate vorbi, pentru nceput, de
prototipizare explorativ, pe timpul fazei de analiz, ca pretext pentru a defini clar domeniul
problemei i alte cerine fa de sistemul soft. Acest tip de prototipizare poate fi folosit i
pentru a evalua(=testa) eventualele soluii alternative.
Odat cu trecerea n faza de proiectare putem vorbi despre prototipizare experimental,
care poate fi un mod de a evalua(=testa), grosier vorbind, utilizabilitatea soluiei dezvoltate.
Criteriile de calitate urmrite, n principal, sunt: performana i ceea ce am putea numi,
implementabilitatea n genere.
Ambele tipuri de prototipizare se desfoar, n principiu, dup regulile evoluiei iterative
i incrementale a seriilor de prototipuri ctre produsul complet.
Este evident faptul c, nainte de elaborarea fiecrui prototip este necesar formularea
explicit i documentarea att a aspectelor referitoare la modificri sau extinderi ct i a
aspectelor referitoare la testarea prototipului.
Testarea trebuie organizat (ce date se folosesc, cum se obin aceste date, ce strategie de
testare folosim, admind c soluia este corect modularizat, care sunt criteriile convenite
ntre dezvoltatori i utilizatori pentru aprecierea prototipului?).
Ideea obsesiv este una singur: Indiferent de perspectiva din care este urmrit,
asigurarea calitii trebuie s devin o preocupare permanent, eventual susinut de
tools-uri specializate (Rational Quality Architect, de exemplu, dac se folosesc tools-uri
de la Rational).
Efortul de organizare a procesului de testare a soluiei unui proiect ar trebui s se
structureze pe dou tipuri fundamentale de activiti: planificarea logic a testrii i
planificarea calendaristic a testrii.
Ca un exemplu, planificarea logic a testrii soluiei unui proiect oarecare ar putea cuprinde:

Testarea modulului XXXX

-Testare funcionalitate;
-verificarea corectitudinii specificrii i modelrii cerinelor;
-verificarea eficienei i a performanei;
-verificarea integritii bazei de date n situaia n care baza de date este utilizat n
mod concurent;
-Testare robustee (=verificarea comportrii modulului n situaii anormale de utilizare);
-Testare protocoale de securitate(dac este cazul);
-Stress testing-ul (urmrirea implicaiilor acestuia asupra corectitudinii i performanei);

Testarea modulului YYYY
-Elaborare de aplicaii pentru evaluarea funciilor modulului YYYY;

Testarea modului n care coopereaz tehnologiile folosite la n cadrul aplicaiei
XXXX.

Realizarea feed-back-ului ntre echipa de dezvoltare i echipa de testare, respectiv,
echipa de dezvoltare i utilizatori.

n ceea ce privete planificarea calendaristic, aceasta va lua n calcul testarea care va fi
efectuat de ctre programatori i testarea care va fi efectuat de ctre utilizatori.

Bibliografie

[1] Barden, R., Stepney, S., Cooper, D., Z in Practice, Prentice Hall, 1994,

[2] Bennet, S., McRobb, S., Farmer, R., Object Oriented Systems Analysis and Design
using UML, McGraw-Hill Publishing Company, 1999

[3] Bocu, D., Introducere n programarea calculatoarelor utiliznd limbajul Pascal,
Editura Albastr, 1999

[4] Bocu, D., Iniiere n ingineria sistemelor soft, Editura Albastr, 2001

[5] Bocu, D., Iniiere n modelarea obiect orientat a sistemelor soft utilizand UML,
Editura Albastr, 2002

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

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

[8] Brookshear, J., G., Introducere n informatic, Editura Teora, 1998

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

[10] Hicks, J., O., Management Information Systems, West Publishing Company1993,

[11] Lano, K., Formal Object-Oriented Development, Springer, 1995

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

[13] OBrien, J., A., Management Information Systems, Mc Grow-Hill Companies, 1996

[14] Oprea, D. , Analiza i proiectarea sistemelor informaionale economice, Editura
Polirom,1999

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

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

[17] Roman, D., Ingineria programrii obiectuale, Editura Albastr, 1996

[18] Rumbaugh, J., Jacobson, I., Booch, G., The Unified Modeling Language Reference
Manual, Addison-Wesley, 1999

[19] Wetherbe, J., C., Vitalari, N., P., Sistem Analysis and Design-Best Practices, Wesp
Publishing Company, Fourth Edition, 1994

[20] Wu, S.,Y, Wu, M.,S., Sistem Analysis and Design, West Publishing Company, 1994

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

[22] Roman, D., Ingineria programrii obiectuale, Editura Albastr, 1996

























Precizri cu privire la evaluarea pregtirii
studenilor

La aceast disciplin evaluarea va consta n:

1. Verificarea cunotinelor teoretice acumulate, printr-o lucrare
scris, pentru care se acord note de la 1 la 10.
2. Elaborarea unui proiect n cadrul activitilor de laborator

Fiecare proiect va conine obligatoriu urmtoarele seciuni:

1. Enunul problemei.
2. Specificarea cerinelor fa de sistemul soft elaborat n cadrul proiectului.
3. Elemente de proiectarea soluiei:
a) Diagrama claselor
b) Interfee
c) Funciile sistemului soft
d) Consideraii relativ la implementarea funciilor
4. Ghid de utilizarea a sistemului soft
5. Ghid de instalare a sistemului soft
6. Consideraii relativ la stabilitatea / exetensibilitatea soluiei


Prof. univ. dr. Dorin Bocu