Universitatea “Transilvania” din Braşov Facultatea de Matematică şi Informatică Catedra de Informatică aplicată

Sisteme integrate de Sisteme integrate de Sisteme integrate de Sisteme integrate de

proiectare şi programareproiectare şi programareproiectare şi programareproiectare şi programare ☯

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

Dorin BocuDorin BocuDorin BocuDorin Bocu

Motto-ul cursului Nevoia de a cunoaşte a dus la inventarea conceptelor. Nevoia de a explica cunoaşterea a dus la inventarea meta-conceptelor. Nevoia de a ascunde o parte din cunoaştere 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 compoziţie".

Autorul

Cuvânt înainte

Deşi relativ nouă, lumea informaticii impune respect prin problemele formulate, conceptele şi teoriile dezvoltate pentru rezolvarea acestor probleme.

Fundamentarea teoretică a universului informaţional aflat în zona de impact cu calculatorul este un exemplu de demers în spirală a cărui dinamică şi profunzime este greu de egalat în alte domenii.

Permanenta schimbare a “infrastructurilor” informaţionale orientate pe calculator menţine la cote de alertă maximă efortul de redefinire a paradigmelor teoretico-aplicative din lumea softului.

Aproape toate tipurile de activitate umană pot fi organizate şi desfăşurate cu totul altfel în prezenţa calculatorului. Motivul acceptării calculatorului în preajma omului sau în locul acestuia? Operativitate, precizie, obiectivitate.

Despre consecinţele în plan estetic şi moral ale “rătăcirii” omului în sofisticata junglă a universului informaţional planetar (în curs de configurare) este, probabil, prematur să discutăm şi nici nu ne propunem aşa ceva în această lucrare.

Desprinderea omului de condiţiile lui naturale de viaţă a început de mult, în preistorie, odată cu descoperirea focului. În zilele noastre această desprindere continuă cu o viteză (sau grabă) care, uneori, ne pune pe gânduri.

Din această uriaşă epopee a desprinderii omului de natură ne propunem să analizăm unele aspecte care se referă, în fond, la nevoia acestuia de a crea o realitate virtuală care să-l ajute, să-l deconecteze şi, dacă se poate, să-l substitue.

Acest joc în care s-au angajat energii uriaşe are toate şansele să dureze deoarece multe dintre abilităţile omului sunt greu de modelat şi, spre “deliciul” cercetătorilor, unele dintre ele aproape insurmontabile.

Această lucrare încearcă un lucru destul de dificil (ţinând cont de marea diversitate a abordărilor în literatura de specialitate) şi anume identificarea bazelor ingineriei sistemelor soft.

Adresându-se tuturor celor interesaţi de ştiinţa şi, în egală măsură, arta de a realiza sisteme soft, prezenta lucrare poate fi începutul unui drum lung, uneori complicat şi, de ce nu, interesant.

Capitolul 1 Probleme a căror rezolvare depinde esenţial

de ingineria sistemelor soft

…Sistemele care se adaptează uşor la condiţiile de mediu sunt înzestrate cu subsisteme informaţionale performante şi fiabile. De exemplu, conducerea unei afaceri astfel încât aceasta să funcţioneze fără sprijin din afară, ba chiar să fie generatoare de resurse ale dezvoltării, este o problemă complexă care pretinde persoanelor implicate cunoştinţe şi abilităţi remarcabile relativ la achiziţionarea datelor necesare pentru cunoaşterea stării afacerii, interpretarea corectă a datelor şi a conexiunilor dintre acestea şi, pe această bază, elaborarea de decizii. Cunoscând modul de a gândi şi acţiona al unor manageri, făcând 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 supravieţui cât mai mult informându-se fără metodă.

1.1 Ce este ingineria sistemelor soft? Mai întâi, să observăm frecvenţa destul de mare cu care întâlnim sau vom întâlni sintagma

ingineria softului. Pentru comoditate o voi nota, prescurtat şi IS. Din dorinţa de a închega repede un dialog cu cititorul, anticipez că:

Ingineria softului este o ramură a ştiinţei calculatoarelor, în permanentă evoluţie, care fundamentează teoretic o parte din activităţile specifice realizării sistemelor soft.

Spunem “o parte” deoarece realizarea unui sistem soft are, de regulă, în spate, cunoştinţe din multe alte ramuri ale ştiinţei calculatoarelor precum şi din alte domenii (algoritmică, programarea calculatoarelor, limbaje formale, cercetări operaţionale, psihologie, teoria generală a sistemelor, etc.).

Tentantă şi interesantă problema definirii riguroase a sintagmei “ştiinţa calculatoarelor”. Autorul acestei lucrări vede în spatele acestei sintagme domenii precum: algoritmica,

teoria matematică a algoritmilor (calculabilitate şi decidabilitate), bazele matematice ale sistemelor de calcul, bazele logice ale sistemelor de calcul, teoria formală a specificării limbajelor de programare, problematica limbajelor de programare, bazele contructive ale sistemelor de calcul (un domeniu de mare complexitate şi cu o dinamică remarcabilă), inteligenţa artificială (un domeniu în care căutările sunt din ce în ce mai ramificate şi mai profunde), ingineria softului, teoriile dezvoltate în jurul problematicii bazelor de date, teoriile dezvoltate în jurul arhitecturilor de tip reţea, etc.

Este clar, sper şi pentru cei care încă mai văd în informatică “un exerciţiu de utilizare inspirată a tastaturii”, faptul că ştiinţa calculatoarelor este variată ca preocupări, solicită intens intelectul şi, încă un amănunt important, viteza cu care afirmaţiile din informatică devin istorie este mult mai mare decât viteza cu care se întâmplă acelaşi lucri în fizică, sau matematică, de exemplu”.

Care sunt, totuşi, acele activităţi specifice realizării sistemelor soft care cad sub incidenţa IS?

Le putem rezuma astfel: 10 Abstractizarea soluţiei unui sistem soft, prin care desemnăm demersul conceptual în

urma căruia specialistul în IS trece de la enunţul problemei la soluţia acesteia. 20 Organizarea procesului de abstractizare (modelare) a soluţiei unui sistem soft.

Îndeosebi în cazul sistemelor soft de complexitate mare şi medie modul de organizare a efortului de modelare poate influenţa hotărâtor calitatea unui sistem soft.

30 Reprezentarea soluţiei unui sistem soft de-a lungul întregului proces de modelare;

documentarea completă a soluţiei sistemului soft. Este vorba, în esenţă, de rezolvarea eficientă a unor probleme de comunicare între

participanţii la realizarea unui sistem soft, precum şi de rezolvarea unor probleme de comunicare între realizatorii sistemului şi diferitele categorii de beneficiari ai sistemului soft.

40 Optimizarea managementului procesului de realizare a unui sistem soft. Ca în

orice alt tip de industrie şi în industria softului contează enorm (pentru lansarea pe piaţă cu succes a unui sistem soft) calitatea actului de management.

Sloganul – cheie în IS ar trebui să fie: ”Cum se poate sistematiza ,eventual automatiza,

procesul de realizare a unui sistem soft de calitate, ieftin şi obţinut în timp util?”.

IS încearcă (în diferite chipuri şi de mai mult timp) să ne înveţe cum poate deveni realitate acest slogan. Modalitatea prin care IS rezolvă această problemă este (simplificând lucrurile) propunerea de metodologii de dezvoltare a softului (MDS).

Istoria MDS este lungă şi destul de dificil de sintetizat fără a omite numeroase aspecte interesante. Firul călăuzitor al acestei istorii ar putea fi, totuşi, definit astfel:

10 Fiecare metodologie doreşte să instaureze o anumită rigoare în procesul de

elaborare a soluţiei unui sistem soft. 20 Fiecare metodologie se individualizează prin accentul pe care îl pune pe un anumit

element definitor (unul sau mai multe concepte de bază, unul sau mai multe principii de bază, formalizmul de reprezentre, etc.).

30 Fiecare metodologie doreşte să ofere suport cât mai consistent pentru realizarea

de sisteme soft de calitate.

După unele aprecieri există, încă, o diversitate prea mare de metodologii de dezvoltare a softului, fapt care nu stimulează neapărat productivitatea specialiştilor în IS. În jurul marilor firme producătoare de soft se cristalizează, progresiv, elemente şi idei cu ajutorul cărora se alimentează procesul de fundamentare a unor noi MDS. Aceste MDS primesc, de regulă, girul mediilor academice, după care se întorc la utilizatori, care le consideră adecvate pentru rezolvarea problemelor lor. Schematizând, avem situaţia din Figura 1.1, adică “un fel de circuit al apei în natură”. Privind mai atent, însă, observăm că este vorba de un proces cu conexiune inversă pozitivă care, pe termen lung, are ca scop optimizarea suportului de care au nevoie specialiştii în IS pentru a realiza sisteme soft.

Astfel se prezintă IS dacă “privim lucrurile din avion”. În realitate situaţia este mult mai complexă. Acest fapt va ieşi la iveală în cele ce urmează, când aplicând descompunerea top-down în conjuncţie cu un permanent efort de abstractizare, vom înţelege mai bine structura şi specificul unui demers IS.

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

Firme/Persoane implicate în realizarea de sisteme soft

Idei, cerinţe, soluţii parţiale noi

Laboratoare de cercetare

MDS nouă

1.2 Ce este un sistem soft? Destul de dificil un răspuns de tip definiţie la această întrebare deoarece diversitatea

“creaţiior” care concurează la calitatea de sistem soft este din ce în ce mai mare. Astfel, poate fi sistem soft un program executabil, obţinut cu ajutorul unui compilator C++. Tot sistem soft putem considera şi un sistem de programe executabile care cooperează pentru rezolvarea unei probleme date. De ce n-am socoti sistem soft un compilator, un SGBD sau chiar un sistem de operare? Tot un sistem soft poate fi considerat, cu deplin temei, un control ActiveX.

De fapt, când vine vorba de tehnologiile soft de ultimă oră (îndeosebi cele promovate de Microsoft) noţiunea de sistem soft face faţă unor conotaţii cu totul remarcabile (DLL-urile, controalele OLE, obiectele programabile, alţi derivaţi ai tehnologiilor COM şi DCOM, etc.).

Evident, se poate încerca, pentru a face mai multă ordine în prezentare, o clasificare a aplicaţiilor recunoscute de platforma Microsoft/Win32. Aceste tipuri de aplicaţii sunt: • aplicaţia de tip consolă; este aplicaţia care aduce în lumea Windows caracteristicile de

bază ale unei aplicaţii cu interfaţă orientată pe text. • aplicaţii Win32 tradiţionale; o astfel de aplicaţie are toate elementele care sunt prezente

într-o aplicaţie Windows completă (fereastră de afişare, bară de meniuri, bară cu instrumente, bară de stare, etc.). O stfel de aplicaţie, spre deosebire de aplicaţia de tip consolă are mari disponibilităţi de cooperare cu sistemul de operare Windows.

• biblioteci cu legături dinamice (DLL-Dynamic Link Library); o bibliotecă DLL este, în

esenţă, o colecţie de funcţii care pot fi apelate din alte module executabile Windows. Nu discutăm aici motivele care au generat specificarea acestei tehnologii de către specialiştii de la Microsoft(deşi acesta ar fi un foarte interesant studiu de caz într-o lucrare pe teme IS). Important este că, realizarea unei biblioteci DLL este un exerciţiu deosebit atât din punct de vedere al elaborării soluţiei tehnice cât şi din punct de vedere al programării. Aceasta deoarece, mai mult decât într-o aplicaţie Windows ordinară, realizarea unei biblioteci DLL pune la încercare abilităţile specialistului IS în ceea ce priveşte definirea de interfeţe optimale pentru funcţii, specificarea/scierea de cod generic, specificarea/scrierea de cod reentrant, cunoaşterea particularităţilor programării sub Windows, etc..

• Controalele ActiveX; sunt un gen de mini-aplicaţii care pot fi încapsulate în orice obiect

de tip container. Container poate fi fereastra cadru a unei aplicaţii, sau un document HTML. Reprezentând, de fapt, extinderea tehnologiei OLE la cerinţele universului INTERNET, ActiveX permite programatorilor să sporească gradul de funcţionalitate al programelor fără prea mult efort. Prin utilizarea tehnologiei ActiveX, programatorul consimte să respecte o serie de reguli, să surmonteze o serie de obstacole, dar are şi avantajul de a beneficia de efortul de modelare al altor specialişti în IS, în caz de convergenţă de interese cu aceştia.

Am terminat, astfel, scurta trecere în revistă a tipurilor de aplicaţii suportate suportate de

platforma Windows. Evident, am pus în discuţie elemente noi care ne-ar putea ajuta la definirea noţiunii de sistem soft.

Continuând mica noastră investigaţie, ne putem întreba dacă un document HTML poate fi considerat sistem soft? Întrebări asemănătoare ne putem pune relativ la creaţii precum: colecţiile de fonturi utilizate de editoarele de texte, aşa zisele fişiere cu resurse promovate de mediile vizuale de programare, colecţiile de clase gen MFC (Microsoft Foundation Class), etc.

Este clar, sper, motivul pentru care, la începutul acestui paragraf, am afirmat că este dificil de dat o definiţie “viabilă” noţiunii de sistem soft. Nu ar fi acesta singurul caz (Biblia operează cu noţiunea de Dumnezeu fără să ne-o definească. Cu toate acestea există oameni care consideră biblia o capodoperă atât din punct de vedere al tipului de scriitură cât şi din punct de vedere al modului de organizare a argumentaţiei).

Contând, mai ales pe valoarea ei didactică, propun următoarea definiţie a noţiunii de sistem soft.

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

Aşadar, atributele esenţiale ale unui sistem soft sunt: 10 Capacitatea de a fundamenta / realiza protocoale efective de prelucrare /

comunicare a datelor / informaţiilor. Exemple. -MFC poate fundamenta protocoale efective de prelucrare / comunicare date şi informaţii; -Un sistem expert realizează un protocol efectiv de prelucrare / comunicare date / informaţii; -Un document HTML realizează un protocol efectiv de prelucrare / comunicare date / informaţii, etc. 20 Protocolul fundamentat sau realizat are o autonomie relativă. Ideea de bază a acestei autonomii relative constă în faptul că protocolul este capabil, în

anumite împrejurări, de iniţiativa în relaţia cu mediul de interpretare sau de execuţie a protocolului.

Ca un contraexemplu, o resursă Delphi, neintegrată într-un sistem complet de alte elemente ale unei aplicaţii Delphi, nu poate fi considerată sistem soft. Integrată, însă, poate fi considerată parte a unui sistem soft.

30 Protocolul operează într-un context informaţional dat. Nu prea avem motive să acceptăm ca sistem soft o creaţie IS care nu operează într-un

context informaţional specific. Chiar dacă nu este întotdeauna evident, acest context informaţional există. De exemplu, un mediu vizual de realizare a sistemelor soft este, el însuşi, un sistem soft care operează cu un context informaţional specific, abstractizat de conceptele şi principiile de utilizare a acestor concepte pentru a modela vizual soluţia unei probleme date.

Cititorul, mai mult sau mai puţin avizat, întrezăreşte, probabil, faptul că noţiunea de sistem soft are un conţinut discutabil. Mai presus de orice discuţie, însă, se află faptul că în IS denumirea generică a produselor finite este sistem soft.

Actualmente, omenirea trăieşte un moment de cotitură din punct de vedere al modului de procesare a informaţiilor care o interesează. Acest moment de cotitură ar putea fi numit revoluţie informaţională.

După ce o mare parte din istoria omului a fost dedicată cuceririi redutelor substanţiale şi energetice, a sosit timpul unor modificări importante în ceea ce priveşte valorificarea dimensiunii informaţionale a tuturor activităţilor omului.

Diversificarea pe orizontală şi pe verticală a producţiei de sisteme soft înseamnă modificarea permanentă a ofertei de tehnologii informaţionale (TI), tot mai mult cerute de societatea informaţională în curs de cristalizare.

Circuitul producţie TI - utilizare TI - redefinire cerinţe faţă de TI – producţie TI are o dinamică a cărei trăsătură principală pare a fi “efectul de autoaprindere”.

Tăvălugul informatizării societăţii omeneşti pare a fi în faza în care rostogolirea lui nu mai poate fi oprită fără a prejudicia grav progresul metodelor de investigare şi complexificare a realităţilor substanţiale şi energetice, fără să mai vorbim de cele informaţionale.

Nu peste mult timp, o mare parte din locuitorii planetei vor fi nevoiţi să înveţe meşteşugul utilizării şi producerii TI.

După cum se poate observa şi în alte domenii de activitate şi în industria softului există tendinţa de a:

-extinde permanent capabilităţile interactive şi de procesare ale sistemelor soft, ţinând cont de cerinţele concrete ale utilizatorilor dar şi formând la utilizatori obişnuinţa de a învăţa tehnologii informaţionale noi, destinate modificării comportamentului; -creşte sistematic calitatea sistemelor soft; -diminua permanent costurile de producţie. Manifestarea efectivă a acestor trei tendinţe este posibilă numai printr-un efort permanent

de îmbunătăţire a elementelor suport în procesul de realizare a sistemelor soft. Studiul critic al elementelor suport în procesul de realizare a sistemelor soft este de

competenţa disciplinei prezentată în literatura anglo-saxonă sub denumirea “Software engineering”, care în limba română s-ar traduce convenabil prin Ingineria softului.

După ce am încercat o scurtă incursiune în lumea preocupărilor IS, voi prezenta, în continuare, o serie de probleme care (de la începuturile erei informaticii sau mai recent) menţin treaz interesul specialiştilor în IS pentru regândirea permanentă a paradigmelor.

1.3 Probleme cu care se confruntă specialiştii în IS Familiarizaţi oarecum cu încărcătura semantică de bază a noţiunilor discutate în

paragrafele 1.1 şi 1.2, în acest paragraf vom analiza unele dintre problemele care au jucat şi joacă un rol important în evoluţia IS.

De menţionat faptul că şi acesta este un subiect în care abordările abundă deoarece universul problemelor IS poate fi analizat din mai multe puncte de vedere iar în interiorul unui punct de vedere utilizând formalizme diferite. De exemplu, problema elaborării soluţiei unui sistem soft poate fi discutată, la un nivel de formalizm socotit convenabil, în scopul dezvoltării abilităţilor unui specialist în IS sau în vederea informării exacte a managerilor cu privire la particularităţile şi utilitatea unui astfel de demers.

Specialistul în IS vrea să înveţe cât mai multe detalii despre arta de a realiza sisteme soft de calitate. Managerul care se instruieşte pe probleme de IS este interesat de cunoaşterea invarianiţilor unui astfel de demers pentru a decide în cunoştinţă de cauză modul în care, cu minimum de resurse se pot obţine maximum de rezultate (atât pe termen scurt cât şi, eventual, pe termen mediu sau lung) prin automatizarea fluxurilor informaţionale ale afacerii în conducerea căreia este implicat.

Pentru a clarifica unele probleme de limbaj care ar putea să apară în continuare, să precizăm faptul că în literatura de specialitate anglo-saxonă se consideră că trei categorii de indivizi sunt foarte importanţi pentru succesul sau eşecul unui proiect de realizare a unui sistem soft. Aceste categorii sunt:

-utilizatorii direcţi (end-users) ai sistemelor soft; -utilizatorii indirecţi (clients) ai sistemelor soft; -specialiştii în IS. ����Probleme datorate perspectivei “utilizator direct” Operând la extreme, utilizatorul direct al unui sistem soft este sau un individ având

afinităţi cu lumea IS sau un individ a cărui cultură informatică este structurată, modest, în jurul abilităţilor necesare pentru utilizarea sistemului soft.

În primul caz este vorba de un utilizator a cărui părere despre calităţile sistemului soft poate fi deosebit de activă şi pertinentă. Al doilea tip de utilizator este, în general, sensibil la confortul oferit de utilizarea sistemului soft. Ambele categorii de utilizatori, într-o formă sau alta, se pot considera la originea revendicării pernanente: sporirea interactivităţii sistemului soft cu utilizatorul direct, promovând mijloace de comunicare cât mai ergonomice.

În mod evident, interactivitatea sistem soft-utilizator direct în sensul de mai sus presupune proiectarea şi realizarea efectivă a unor interfeţe ergonomice.

Într-o interfaţă ergonomică, utilizatorul direct găseşte funcţionalitatea dorită de o manieră care nu pune la încercare nici înţelegerea, nici răbdarea şi nici sănătatea acestuia.

Practica a demonstrat şi demonstrează faptul că este o artă să proiectezi interfeţe inteligibile, este o sarcină mult mai complicată să realizezi interfeţe care răspund operativ şi dau dovadă de maximă îngăduinţă faţă de capriciile utilizatorului direct; în sfârşit, destul de pretenţioasă este şi misiunea de a realiza interfeţe care nu numai că nu dăunează facultăţilor psihice ale utilizatorului direct, ba chiar, încearcă reconfortarea lor.

Mulţi factori care determină calitatea unui sistem soft (problemă asupra căreia vom reveni, pe larg, în acest capitol) îşi găsesc o formă de manifestare şi în modul în care “se exprimă” o interfaţă în relaţia cu utilizatorul.

De exemplu, robusteţea unui sistem soft, considerată un factor extern de calitate, măsoară abilitatea unui sistem soft de a rezista la iniţiative din partea utilizatorului direct (transmise prin intermediul interfeţei) care depăşesc cerinţele specificate ale sistemului soft.

����Probleme datorate perspectivei “utilizator-indirect” Utilizatorul indirect (care poate fi întruchipat de orice consumator inteligent de servicii

furnizate de un anumit sistem soft) dacă se manifestă constructiv este un partener cu care specialistul în IS trebuie să coopereze strâns deoarece soluţia multora dintre problemele care pot să apară pe timpul realizării unui sistem soft depinde de acesta.

�Utilizatorul indirect decide începerea/neînceperea finanţării proiectului de realizare

a unui sistem soft; tot el este şi cel care, în urma analizelor periodice cu privire la evoluţia proiectului, poate decide abandonarea/continuarea proiectului. Absolut trivial este faptul că într-o economie de piaţă fără finanţare nu se poate materializa nici o idee de proiect, oricât de generoasă şi ambiţioasă ar fi aceasta. Acesta este motivul pentru care managementul proiectului de realizare a unui sistem soft trebuie să trateze cu maximum de profesionalism relaţia cu utilizatorii indirecţi-variabile importante în ecuaţia finanţării unui proiect.

�Utilizatorul indirect îşi asumă, în mod normal şi rolul de furnizor de date cu privire

la structura proceselor informaţionale modelate şi, ca o prelungire firească, rolul de

furnizor de elemente cu privire la cerinţele faţă de sistemul soft în curs de realizare. Dacă utilizatorul indirect nu îşi asumă aceste două roluri de pe o poziţie corectă, specialistul în IS este în faţa unei probleme al cărei enunţ “are geometrie variabilă”:

�Utilizatorul indirect nu este capabil să descrie corect procesele informaţionale modelate;

cineva din echipa de proiectare trebuie să facă acest lucru şi, evident, nota de plată a proiectului se încarcă;

�Utilizatorul indirect indică cerinţele faţă de sistemul soft derivate din poziţia pe care el

(utilizatorul indirect) o are în ierarhia utilizatorilor indirecţi. Apare, în acest fel, o problemă nouă şi importantă pentru specialiştii în IS, anume

distilarea şi asamblarea viziunilor unilaterale ale utilizatorilor indirecţi pentru a obţine o perspectivă sistemică asupra proceselor modelate.

�Utilizatorul indirect are, statistic vorbind, toate calităţile unui om obişnuit: poate face

omisiuni, poate emite judecăţi inconsistente, poate avea probleme în comunicarea datelor şi informaţiilor pe care le deţine, etc. Această posibilitate ar trebui să sporească semnificativ încordarea cu care specialiştii în IS culeg de la utilizatorii direcţi date şi informaţii necesare evoluţiei pozitive a proiectului.

Oricare ar fi situaţia, specialiştii în IS trebuie să acorde o atenţie deosebită utilizatorilor indirecţi; părerea lor faţă de calităţile unui sistem soft poate determina “înmormântarea” acestuia înainte de a se naşte, sau asigurarea condiţiilor pentru ca sistemul soft să aibă un ciclu de viaţă pozitiv.

Noţiunea de ciclu de viaţă “bate la uşă”, dar de semantica aflată în spatele ei (destul de polimorfă) vom discuta mai multe în Capitolele 2 şi 3..

Deocamdată, ciclul de viaţă al unui sistem soft, conform unei metodologii date, descrie etapele prin care trece un proiect de la faza de enunţ al problemei până la soluţia executabilă pe calculator ş.a.m.d dacă se pune problema dezvoltării, întreţinerii, etc.

����Probleme generate sau descoperite de specialiştii în IS Nu este decât o confirmare a regulii faptul că IS este un univers ale cărui probleme sunt

inventate, inventariate şi rezolvate datorită dorinţei specialiştilor în IS de a optimiza procesul de realizare a sistemelor soft.

Simbolic vorbind, funcţia obiectiv care stă la baza optimizării 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 stăpânire a complexităţii problemelor care apar în timpul realizării unui sistem soft. Cele mai dificile probleme care pot apare în timpul realizării unui sistem soft sunt, totuşi, problemele care îşi au originea în ”laboratoarele IS” sau se reflectă în activitatea acestor “laboratoare”. Vom prezenta, în continuare, enunţul problemelor fundamentale pe care trebuie să le aibă în vedere orice specialist în IS.

�Pentru nenumărate motive (dintre care, unele le vom prezenta în continuare) procesul

de realizare a unui sistem soft trebuie sistematizat. Această nevoie de sistematizare acoperă mai multe dimensiuni:concepţie, eşalonarea în

timp, reprezentarea soluţiei, documentarea, conducerea proiectului, etc. Sistematizarea înseamnă, în esenţă, introducerea de reguli de urmat pentru a asigura,

teoretic, succesul unui proiect. Nevoia de sistematizare intră în conflict cu tendinţa multor

specialişti în IS de a se exprima ignorând protocoalele, normele, regulile adoptate de colectivele din care fac parte.

Pentru a menţine în echilibru pozitiv nevoia de sistematizare şi tendinţa unor specialişti în IS de a ajunge la soluţie “dând cu tifla sistematizării”, este nevoie de multă abilitate din partea celor care specifică paradigme de modelare a softului (dacă cititorul îmi îngăduie această exprimare).

Istoria a reţinut de-a lungul erei informaticii exemple de paradigme în care normarea şi formalizmul au descurajat pe mulţi amatori de sistematizare, exemple de paradigme care au soluţionat satisfăcător doar o parte din probleme, lăsând la latitudinea specialiştilor în IS rezolvarea altora, exemple de paradigme care îmbină elegant formalizmul cu puterea de sugestie în rezolvarea unui număr cât mai mare de probleme, etc. Din păcate (sau poate din fericire) universul IS, la capitolul probleme posibile, este deschis.

Este din ce în ce mai greu de ţinut evidenţa tipurilor de sisteme soft cunoscute, pentru a valorifica creator experienţa acumulată prin realizarea lor, specificând MDS infailibile şi atotcuprinzătoare. Deşi la ora actuală au fost edificate MDS care impresionează puternic prin obiectivele propuse şi mijloacele de atingere a acestor obiective, omul rămâne în continuare singurul în măsură să însufleţească aceste MDS sau să le adauge capabilităţi noi în situaţii problematice deosebite (A se vedea, de exemplu, OM,T şi UML, două MDS relativ recente, cu aspiraţii interesante pentru orice gânditor care înţelege lumea orientat pe obiecte).

�Prin sistematizarea procesului de realizare a sistemelor soft se urmăreşte crearea unor condiţii avantajoase pentu gestiunea complexităţii problemelor specifice unui proiect. Oferirea de suport pentru gestiunea complexităţii este benefică pentru diviziunea muncii (dacă se lucrează în echipă) şi calitatea soluţiei. Există o mare varietate de abordări care propun şi elemente suport explicite pentru gestiunea complexităţii. Dintre aceste abordări să enumerăm şi noi câteva care au ca numitor comun modularizarea. Putem modulariza orientat pe proceduri, putem modulariza orientat pe date, putem modulariza orientat pe obiecte. Rezultatul trebuie să fie de fiecare dată acelaşi: “Soluţia=o colecţie de module care cooperează pentru rezolvarea unei probleme date”.

����Prin sistematizarea procesului de realizare a sistemelor soft se pun bazele reutilizării efortului de modelare, în anumite circumstanţe. Astfel, aşa după cum vom vedea, îndeosebi în Capitolele 2 şi 4, soluţia unei probleme poate fi elaborată pe mai multe nivele de abstractizare, fiecare nivel fiind dedicat descrierii unor proprietăţi specifice ale soluţiei. Regulile de bază în organizarea unei soluţii pe nivele de abstractizare pare simplă: nivelul de abstractizare al unei soluţii scade odată cu creşterea infuziei de informaţie statică şi dinamică în soluţie.

Creşterea infuziei de informaţie statică şi dinamică înseamnă trecerea soluţiei de la o arhitectură cu o anumită stabilitate structurală la o arhitectură cu stabilitate structurală diminuată. Este o legitate care poate fi combătută constructiv doar prin utilizarea unei scheme de rafinare a soluţiei care să limiteze diminuarea stabilităţii structurale a nivelului de abstractizare.

Teoretic vorbind, cu cât avem mai multe nivele de abstractizare, cu atât mai mic este efortul de regândire a unui anumit nivel de abstractizare. Practic, însă trebuie găsit un compromis eficient între numărul de nivele de abstractizare propuse şi efortul depus de specialişti în IS pentru obţinerea soluţiei în acest context.

Astfel stând lucrurile, o soluţie obţinută, să spunem, pe trei nivele de abstractizare (conceptual, logic, operaţional, a se vedea Figura 1.2) are cea mai mică stabilitate la nivel operaţional. Dacă apar modificări care afectează acest nivel (şi ele sunt cele mai plauzibile), atunci soluţia este regândită, refăcând, în principal, nivelul operaţional. Aceasta înseamnă că soluţia are o rezistenţă structurată la modificări şi că specialiştii în IS fac reutilizare de efort de modelare în obţinerea unei soluţii.

Comentariu la Figura 1.2 Cele trei nivele de abstractizare au o semantică apropiată perspectivei pe care o oferă

teoria managementului asupra actului de conducere, analizat pe verticală. Comentariu la Figura 1.3 Schema din Figura 1.3 ilustrează componentele managementului, structurat pe nivele; deşi

nu sunt vizibile, între aceste componente există relaţii foarte interesante pentru cineva care proiectează sistemul informaţional al unei afaceri.

Figura 1.2 Exemplu de ciclu de abstractizare a soluţiei unui sistem soft

Figura 1.3 Piramida managementului din perspectivă sistemică.

Managementul de TOP, dacă este specificat corect trebuie să aibă cea mai mare stabilitate

structurală. Managementul TACTIC formulează politicile necesare pentru îndeplinirea obiectivelor managementului de TOP. Dacă este necesar, stabilitatea structurală a acestor politici poate fi schimbată. În sfârşit, managementul OPERATIV face tot ceea ce este necesar pentru a operaţionaliza politicile stabilite de managementul TACTIC. Nivelul operativ al managementului este supus, cu prioritate, schimbărilor atunci când se pune problema adaptării sistemului condus la condiţii de performanţă noi.

Nivel conceptual (Ce face sistemul soft)

Nivel logic (Cine, când şi unde

execută prelucrările)

Nivel operaţional (Cum se efectuează

prelucrările)

Soluţia conceptuală

Soluţia logică

Sistem soft operaţional

����Prin sistematizarea procesului de realizare a sistemelor soft se urmăreşte creşterea permanentă a calităţii acestora.

Este momentul să facem o scurtă incursiune în semantica deosebit de complexă a sintagmei “calitatea sistemelor soft”. Punctul de vedere pe care îl prezentăm reprezintă o sinteză a expunerii făcută pe această temă în [10].

Atât în teorie cât şi în practică se acceptă faptul că softul de calitate este rezultatul luării în consideraţie a o serie de factori interni şi externi procesului de configurare a soluţiei finale a unui sistem soft.

În limbaj comun se vorbeşte despre necesitatea de a realiza sisteme soft fiabile, uşor de folosit, structurate, etc. Astfel de epitete asociate unui sistem soft caracterizează două tipuri de proprietăţi ale sistemelor soft:proprietăţi externe şi proprietăţi interne.

����Calitatea sistemelor soft şi proprietăţile externe Dintre proprietăţile externe care decid calitatea unui sistem soft, le considerăm ca fiind

foarte importante pe următoatele: -corectitudinea; -robusteţea; -extensibilitatea; -reutilizabilitatea; -compatibilitatea; -eficienţa; -portabilitatea; -uşurinţa în folosire. Corectitudinea Este abilitatea unui sistem soft de a executa toate sarcinile convenite cu utilizatorii şi

beneficiarii în faza de specificare Corectitudinea este o proprietate de maximă prioritate a sistemelor soft. Un sistem soft

care “face altceva decât s-a stabilit de comun acord cu beneficiarii şi utilizatorii lui” este obligatoriu să fie corectat (dacă efortul necesar pentru a face acest lucru este asumat de cei care au greşit) sau abandonat pentru a relua efortul de a găsi o soluţie care să aibă, printre altele şi atributul corectitudinii.

Deşi se poate vorbi uşor şi mult despre corectitudine, este o “probă de rezistenţă şi de îndemânare profesională” specificarea corectă a sistemelor soft.

Pentru teoreticienii IS corectitudinea, dincolo de acceptarea rutinei, este sinonimă cu rigoarea în specificare şi proiectare, ceea ce nu este “agreat” de specialiştii în IS adepţi ai utilizării unor limbaje cu suport natural în specificare şi proiectare.

Robusteţea Este abilitatea unui sistem soft de a reacţiona adecvat în condiţii anormale de utilizarea. Este evident faptul că robusteţea completează corectitudinea. În timp ce corectitudinea se

referă la comportamentul unui sistem relativ la o anumită specificare corectă, robusteţea apreciază ce se întâmplă cu sistemul soft în situaţii care, în chiar procesul de specificare ar trebui identificate ca excepţii.

Realizarea de sisteme soft robuste este o sarcină care începe în faza de specificare şi se întinde până în faza de programare. Pe acest traseu specialiştii în IS trebuie să înfrunte două clase mari de execpţii:

����Excepţiile externe sistemului soft; ����Excepţiile interne sistemului soft.

Frontiera dintre aceste două clase de excepţii trebuie privită cu multă circumspecţie deoarece, în realitate este oricând posibil ca, potenţial, o excepţie externă să inducă o excepţie internă şi invers.

De asemenea, să mai observăm că în timp ce excepţiile externe pot fi “înfruntate” descurajând iniţiativele “nespecificate” ale utilizatorului, problematica excepţiilor interne este mult mai complicată.

În cazul sistemelor care gestionează relaţia cu utilizatorul prin intermediul unei interfeţe cu o semantică deosebit de complexă, excepţiile externe, înainte de a fi inhibate trebuie identificate.

Iată, deci, încă o problemă de care specialiştii în IS se lovesc dacă doresc să “scoată pe piaţă” sisteme soft care “rămân pe picioare” la apariţia unor excepţii. Se poate formula şi un fel de principiu relativ la odiseea tratării excepţiilor într-un sistem soft:

În timp ce interfaţa unui sistem soft îşi sporeşte receptivitatea faţă de curiozitatea şi comoditatea utilizatorilor, efortul de tratare complexă şi corectă a posibilelor excepţii creşte astfel încât poate deveni o problemă care nu poate fi rezolvată decât prin metoda aproximaţiilor succesive.

Este cazul sistemelor de operare, de exemplu, a căror robusteţe este, adeseori, rezultatul

unui proces de ajustare pe banii şi pe răbdarea diferitelor categorii de utilizatori.

Extensibilitatea Este abilitatea unui sistem soft de a se adapta uşor la modificări în faza de specificare Problema extensibilităţii este o problemă de situare pe scala complexităţii: programele

mici sunt uşor de modificat; sistemele soft din ce în ce mai mari devin tot mai dificil de adaptat la modificări. Rămânând în sfera afirmaţiilor valabile, dar generale, putem adăuga că două principii sunt utile în realizarea de sisteme soft extensibile. Acest principii sunt:

�Simplitatea proiectării Ideea de bază este că o arhitectură simplă este întotdeauna mai uşor de modificat decât o

arhitectură complexă. Inevitabil, însă, vine întrebarea: când spunem că un sistem soft are o arhitectură simplă? Un răspuns complet şi precis la această întrebare nu încape în paginile acestei cărţi. Simplitatea este un deziderat urmărit de orice creator care se respectă. Faptul că există destule creaţii ale omului care uimesc prin dificultatea cu care îşi transmit mesajul (inepţii literare, subproduse cinematografice, discursuri politice sterile, etc.) dovedeşte caracterul imprevizibil al modului în care un creator ajunge să opereze cu avantajele simplităţii în munca sa. Nu se poate algoritmiza obţinerea simplităţii pentru că, în forma ei cea mai înaltă de exprimare, este sinonimă cu creaţia. O creaţie plăsmuită cu talent va provoca întotdeauna exclamaţii de genul:”Ce simplu era!”, “Foarte uşor de înţeles!”, “Nici că se putea mai bine!”, “Cum de nu mi-a trecut prin cap?!”, etc.

O “creaţie” plăsmuită doar pentru a umple fizic unul din multele goluri care există în viaţa oamenilor provoacă exclamaţii de tipul:”Doamne, ce îmbâcseală!”, Nu înţeleg mai nimic!”, Mai bine lipsă!”, “Aşa ceva puteam şi eu să fac!”, etc.

Nu este pierdere de vreme să urmărim simplitatea şi în IS. Doar că, şi aici, obţinerea ei cere timp, pentru a şlefui soluţia unei probleme, astfel încât să putem obţine un sistem soft care este, cel puţin:

-lizibil; -corect modularizat; -eficient în timpul execuţiei.

Sunt nenumărate motive, însă, pentru care în IS se sacrifică simplitatea, asigurându-se, de exemplu, corectitudinea şi robusteţea. Enumerăm câteva dintre aceste motive: necesitatea scurtării termenelor de execuţie, modificarea paradigmelor de modelare, modificarea limbajelor de programare, modificarea sistemelor de operare, creşterea puterii de calcul a sistemelor hard (frecvenţă de lucru foarte mare+ dimensiuni, de vis altădată, ale memoriei RAM).

�Descentralizarea Dacă extensibilitatea este dorită cu orice preţ şi poate că nu există suficient timp pentru a

obţine un sistem soft cu arhitectură simplă, atunci mai avem un punct de sprijin în descentralizare: cu cât autonomia modulelor care compun sistemul soft este mai mare cu atât mai mare este probabilitatea ca o schimbare simplă să afecteze un număr redus de module.

Reutilizabilitatea Este abilitatea componentelor unui sistem soft de a putea fi utilizate la dezvoltarea mai

multor aplicaţii diferite. Necesitatea reutilizării unor componente soft se întemeiază pe observaţia că, adeseori,

sisteme soft diferite pot fi construite pe baza unor soluţii-şablon similare. Promovarea sistematică a reutilizării influenţează alţi factori de apreciere a calităţii sistemelor soft, precum corectitudinea şi fiabilitatea.

Reutilizarea este un factor cardinal în multe paradigme de programare şi modelare. Astfel, programatorii Windows pot utiliza în procesul de realizare a propriilor aplicaţii, potenţialul MFC (Microsoft Foundation Class). De asemenea, mediile vizuale de programare (Delphi, Visual Basic, Visual C++, CBuilder, etc.) oferă exemple consistente de reutilizare.

Compatibilitatea Este o măsură a uşurinţei cu care componentele unui sistem soft se combină cu alte

componente pentru a forma aplicaţii noi. Fireşte, compatibilitatea este importantă deoarece, în general, sistemele soft nu pot fi

dezvoltate în vid; ele vor interacţiona cu alte sisteme soft. Secretul compatibilităţii se află în omogenitatea proiectării şi în acceptarea unor

standarde de comunicare între programe. Aşadar, pentru a realiza sisteme soft compatibile, efortul de proiectare trebuie să ia în

calcul şi cele două cerinţe formulate mai sus. Comunitatea IS nu se poate “mândri” cu impunerea unor standarde şi principii de detaliu în acest sens. Există “fani” Windows care promovează tehnologiile, trebuie să recunoaştem remarcabile, ale Microsft-ului. Există, însă, şi “fani” Linux care promovează propriile lor idei şi tehnologii în ceea ce priveşte caracteristicile mediilor de dezvoltare a sistemelor soft. Am dat două exemple de “medii” de dezvoltare a softului. Mai sunt nenumărate altele al căror istoric nu este momentul să îl facem; raţiunea lor de a fi este următoarea:

����Lumea IS îşi datorează remarcabila dinamică unui permanent efort de inovare

teoretică şi în plan aplicativ; ����Lumea IS, în marea ei varietate, are nevoie de puncte de convergenţă pentru a face

posibilă interoperabilitatea crescândă între sistemele soft. Este destul de dificil de făcut o predicţie relativ la dezvoltarea pârghiilor de

compatibilizare a sistemelor soft în viitor. Actualmente, lumea aplicaţiilor Internet se prefigurează ca un “câmp de desfăşurare a unor bătălii importante pentru noua faţă a

universului IS”. Este nevoie de timp, răbdare şi efort susţinut pentru a găsi noi formule de specificare a proprietăţilor fundamentale ale sistemelor soft, printre care se află şi compatibilitatea.

Eficienţa (Performanţa) Este abilitatea unui sistem soft de a minimiza cererile de resurse hard (timp UC, memorie

RAM, memorie externă, etc.). Comunitatea IS are două atitudini tipice faţă de eficienţă. �Există “softişti” care fac o pasiune din optimizarea permanentă a sistemelor la care

lucrează. Din “mâinile” unor astfel de specialişti ies adevărate bijuterii din punct de vedere al performanţelor. Preţul plătit împingând performanţa dincolo de un anumit prag logic este, în principal, diminuarea portabilităţii softului respectiv. Într-o lume care visează la compatibilizarea sistemelor soft este greu de crezut că portabilitatea poate fi sacrificată.

�Există şi “softişti” care gândesc astfel: “Să facem sistemul soft corect înainte de a fi

eficient cu orice preţ”. Un astfel de slogan merge în aplicaţiile în care absenţa performanţei nu este critică pentru funcţionarea softului, mizându-se pe un fapt absolut real în ultima vreme: “Eficienţa poate fi obţinută pe seama progreselor în materie de tehnologii hard”. Ca de obieci, adevărul trebuie să fie undeva la mijloc, ceea ce înseamnă că specialistul IS trebuie să stăpânească arta de a obţine performanţa cerută cu minimum de cheltuieli de resurse.

Portabilitatea Este o măsură a uşurinţei cu care un sistem soft poate fi transferat pe diferite platforme

hard şi medii de operare. Dată fiind marea diversitate de platforme hard şi medii de operare, problema este reală şi

dificil de rezolvat. Esenţa acestei probleme constă în faptul că orice sistem soft, ajuns în faza executabilă, pe un calculator real, trebuie “să se înţeleagă cu calculatorul respectiv”. Aceasta înseamnă că un cod execuatbil are o anumită structură şi instrucţiunile pe care le conţine sunt recunoscute de procesorul maşinii gazdă. Structura codului executabil este importantă pentru sistemul de operare, care supervizează încărcarea codului executabil în memorie şi execuţia acestuia, pas cu pas. Schema clasică în care apare problema portabilităţii este prezentată în Figura 1.4.

Orice dificultate în portarea unui sistem soft de pe o platformă pe alta este surmontabilă dacă :

�se fac modificările necesare în codul sursă(uneori aceste modificări pot fi dramatice); �Există compilatorul care ştie să genereze cod executabil pentru platforma ţintă

(dacă nu există, trebuie cumpărat, 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 modificările necesare în codul sursă(uneori aceste modificări pot fi dramatice); �Există compilatorul care ştie să genereze cod executabil pentru platforma ţintă

(dacă nu există, trebuie cumpărat, ceea ce înseamnă că portabilitatea poate să coste).

Figura 1.4 Dependenţa de platformă şi efectele asupra portabilităţii în varianta clasică

Evident, ar fi mult mai bine dacă aceste două probleme nu ar exista. Din păcate probelmele există şi specialiştii în IS trebuie să ia în calcul la specificare şi aspecte care afectează portabilitatea sistemului soft. O situaţie aproape diametral opusă celei prezentate în Figura 1.5 o reprezintă soluţia Java pentru asigurarea portabilităţii aplicaţiilor.

De remarcat faptul că situaţia descrisă în Figura 1.5 este posibilă în condiţiile în care toată comunitatea recunoşte o anumită versiune de compilator Java. Trecerea de la o versiune la alta se face respectând regulile de portare potrivit cărora documentul înţeles de o versiune oarecare a unui sistem soft este totdeauna înţeles de o versiune mai înaltă, nu şi invers.

Figura 1.5 Soluţia Java la problema portabilităţilor sistemelor soft.

Cod sursă/care poartă amprenta mediului de execuţie şi a maşinii gazdă scontate

Compilator/care poartă amprenta mediului de execuţie ţintă şi a maşinii gazdă scontate

Cod executabil/dedicat perechii (mediu de execuţie, maşină 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, până la data scrierii acestei cărţi singura modalitate de a dezvolta sisteme cât de cât portabile. Se plăteşte, ca de fiecare dată, tribut pentru acest câştig, la capitolul performanţă în timpul execuţiei. Dar, ce mai contează, omenirea visează cu ochii deschişi, ceea ce înseamnă că într-o bună zi vom ajunge să dăm alt sens şi portabilităţii.

Uşurinţa în folosire Se referă la modul în care oameni cu diferite nivele de instruire pot învăţa să folosească

sistemul soft pentru rezolvarea unor probleme reale. Se referă, de asemenea, la uşurinţa instalării şi operării sistemului soft.

Închei prezentarea proprietăţilor externe ale sistemelor soft cu precizarea că problematica

proprietăţilor interne (structurare, modularizare, obiect orientare, etc.) reprezintă un capitol la a cărui scriere încă se lucrează, neexistând un consens deplin al specialiştilor asupra modului de articulare a acestora într-o explicaţie stabilă structural. Despre unele dintre aceste subiecte vom avea un cuvânt de spus în Capitolul 4.

Capitolul 2 Ce este o metodologie de dezvoltare a

softului?

…De mult (nu putem spune exact când deoarece nu ştim nici când a început povestea omului) s-a născut ideea de paradigmă . Poate, la început paradigma avea înţelesul pe care ni-l dezvăluie Dicţionarul explicativ al limbii române. În zilele noastre, când natura de-abia se mai regăseşte printre creaţiile omului, nu putem supravieţui decât inventând, devorând şi iar inventând paradigme din ce în ce mai sofisticate. Când spun “nu putem supravieţui” mă refer la toţi cei care, realmente sau doar închipuindu-şi, cultivă o veche îndeletnicire chinezească (autoreflexia) pentru a descoperi măcar o parte din taina cunoaşterii atât de bine ascunsă în proiectul Homo Sapiens.

2.1 De ce avem nevoie de MDS? În Capitolul 1 am prezentat o serie de consideraţii, aş zice cu pretenţii de stabilitate

structurală, referitoare la universul IS. Este, însă, prea devreme pentru a-mi închipui că “ucenicii” într-ale producerii softului sau creatorii de soft după “reţete” proprii au devenit adepţi convinşi ai promovării “reţetelor” IS.

În acest paragraf vom inventaria o serie de probleme concrete de care, vrând-nevrând, specialistul în IS (afiliat sau nu la o metodologie) se loveşte.

Procedând astfel legitimăm o stare de lucruri întâlnită şi în alte domenii ale cunoaşterii.

Structura discursului în IS este determinată atât de cerinţe epistemologice specifice cât şi de nevoia de organizare a diferitelor forme de manifestare a existentului în procesul de realizare a sistemelor soft.

Evident, o parte din cerinţele epistemologice specifice le-am surprins în Capitolul 1. În acest paragraf vom încerca să evidenţiem o parte dintre formele de manifestare a

existentului în procesul de realizare a sistemelor soft. Deşi ne-ar place să semene cu o problemă de matematică, este corect să spunem că nu este

chiar aşa. Î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 SABM=SACM.” Nu este cazul să intru prea adânc în consideraţii metodice pe marginea rezolvării acestei

probleme. Şi totuşi, cineva care vrea să rezolve această problemă are nevoie de trei puncte de sprijin:

10 Posibilitatea de a încadra problema într-o clasă tipologică. Dacă această clasă nu

există, gloria rezolvitorului sporeşte, specificând clasa respectivă. În cazul nostru, fiind o problemă de loc geometric, rigoarea ne cere să identificăm locul geometric, după care să facem verificarea că fiecare punct al locului geometric satisface proprietatea care a stat la baza identificării locului.

20 Odată stabilită clasa tipologică, trebuie să avem control asupra semanticii

noţiunilor care intervim în enunţul problemei. În cazul nostru ne confruntăm cu noţiuni precum: loc geometric, interiorul unui

triunghi, aria unui triunghi şi, de ce nu, triunghi. 30 Pentru a găsi rezolvarea ne trebuie abilitatea de a valorifica avantajele prezentate la

punctele 10 şi 20 în vederea obţinerii soluţiei problemei. În general, această abilitate o au persoanele care sunt capabile de inferenţă. Abilitatea de

a “comite” inferenţe autentice o au oamenii inteligenţi. Evident, cine rezolvă o problemă face”un 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 înţeleşi ne-ar prinde bine reprezentarea din Figura 2.1.

Figura 2.1.

Din enunţul problemei, avem, în mod evident: -∆ABC – oarecare; -M∈ interiorului ∆ABC; SABM=SACM .

Tot din enunţul 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 inferenţei specifice problemei:

SAMB = 2

'BBAM ⋅

SAMC = 2

'CCAM ⋅

SAMB=SAMC ⇒ BB’=CC’ ⇒∆BB’O≡∆CC’O ⇒ BO=CO ⇒ M∈medianei din A a ∆ABC, etc. În IS situaţia este puţin modificată. Trecerea de la enunţ la soluţie, în cazul problemelor de

complexitate mijlocie sau mare (în care, de regulă, se cere modelarea comportamentului unui anumit proces informaţional) este mult modificată. Astfel, în forma iniţială, enunţul problemei poate sesiza nişte carenţe într-o activitate care pot fi eliminate prin utilizarea calculatoarelor sau poate intui nişte avantaje într-o activitate dacă se apelează la suportul calculatoarelor.

În ambele cazuri, pentru a obţine enunţul complet al problemei se trece la analiza informaţională a problemei. Scopul acestei activităţi este obţinerea unui enunţ complet al problemei care cuprinde cerinţele faţă de sistemul soft sub forma unei soluţii cu nivel înalt de abstractizare.

Activitatea de analiză informaţională este dificilă şi este primejdios ca, din diferite motive, să nu incluzi printre cerinţe un anumit aspect informaţional.

Dacă s-a pus punct analizei informaţionale, trebuie să se treacă la elaborarea soluţiei tehnice (un fel de documentaţie constructivă a sistemului soft). Deşi elaborarea soluţiei tehnice înseamnă descrierea până la detaliu a componentelor sistemului soft şi a legăturilor

dintre acestea, ceea ce înseamnă infuzie treptată de elemente concrete în soluţie, în paralel se desfăşoară şi activităţi cu pronunţat caracter de abstractizare (pentru a elimina redundanţele, pentru a optimiza prelucrările, pentru a optimiza legăturile dintre date, pentru a spori rezistenţa sistemului la modificări, etc.).

De foarte multe ori se poate spune că obiectul analizei informaţionale ca şi obiectul activităţii de obţinere a soluţiei tehnice au afinităţi cu nisipurile mişcătoare. Ce-i de făcut? Trebuie multă răbdare şi abilitate pentru a sesiza invarianţii procesului ceea ce ar permite începerea efortului de modelare.

În situaţia în care “calvarul” obţinerii soluţiei tehnice a fost depăşit începe activitatea de

transpunere a soluţiei tehnice în acord cu exigenţele de sintază, semantică şi pragmatică specifice unui limbaj de programare.

N-aş zice că nu există nisipuri mişcătoare şi în această încercare! În mod cert, numitorul comun al problemelor de matematică cu problemele de informatică este complexitatea. În cazul matematicii predomină complexitatea structurală; în cazul informaticii, de cele mai multe ori predomină complexitatea spaţială.

Dacă la aceste elemente se adaugă altele, precum: necesitatea reprezentării soluţiei pentru a fi înţeleasă de diferite categorii de utilizatori, necesitatea de a partaja anumite tipuri de resurse în procesul de elaborare a soluţiei unui sistem soft, necesitatea de a armoniza efortul de dezvoltare în cazul în care se lucrează în echipă, etc. ne facem o imagine mai precisă asupra amănuntelor care alcătuiesc specificul unei probleme în IS.

Pentru a înfrunta toate aceste probleme şi multe altele, comunitatea specialiştilor în IS a încercat încă din epoca de început a erei informaticii să îngrădească liberul arbitru în procesul de dezvoltare a softului, lăsând, totuşi, loc de manifestare spiritului creator, prin iniţiative de genul:

-studiul teoretic al proprietăţilor algoritmilor: formalizare a reprezentărilor; clasificarea algoritmilor; -studiul teoretic al unor metode generale de elaborare a algoritmilor (Backtracking, Greedy, Divide et Impera, Programarea dinamică);

-elaborarea unor metode de programare (programarea structurată, programarea obiect-orientată); -elaborarea unor metode de analiză a sistemelor informaţionale (procedee de investigare, mod de reprezenatare, concepte utilizate, etc.);

-elaborarea unor metode de elaborare a soluţiei tehnice (Top-down, HIPO, Warnierr-Orr, etc.); -dezvoltarea unor elemente suport pentru specialiştii în IS (sisteme de documentare, generatoare de programe, medii de dezvoltare a soluţiei cu ajutorul calculatorului, etc.);

-specificarea unor procedee de cuantificare a muncii depuse de specialiştii IS pentru realizarea sistemelor soft; -elaborarea unor metode de planificare a efortului de dezvoltare a sistemelor soft.

Acumulările în direcţiile semnalate mai sus sunt impresionante; evoluţia abordărilor în IS, atât teoretice cât şi practice, seamănă, metaforic vorbind, cu evoluţia populaţiilor în sistemele genetice; călauzită de legităţi, aparent stochastice, comunitatea specialiştilor în IS produce generaţii succesive de elemente suport în dezvolatrea softului, le evaluează, în practică, reţine ceea ce este valoros în ele şi promovează ca parte componentă în generaţiile următoare.

De la o perspectivă fragmentată sau incompletă asupra procesului de dezvoltare a softului s-a ajuns în ultimii ani la elaborarea unor metodologii unitare de dezvoltare a softului, creaţii ale specialiştilor în IS puse în slujba specialiştilor în IS, cea mai mare parte din “viaţa” unui sistem soft.

2.2. Încercare de caracterizare a unei metodologii generice de dezvoltare a softului În Capitolul 1, paragraful 1.1 am prezentat o listă de activităţi specifice realizării

sistemelor soft. Aceste activităţi sunt: -abstractizarea soluţiei unui sistem soft (ASS); -desfăşurarea în timp a (=organizarea) procesului de abstractizare a soluţiei unui sistem soft (OPA); -reprezentarea şi documentarea evoluţiei unui sistem soft (RDS); -optimizarea managementului procesului de realizare a unui sistem soft (OMP). Putem să definim o metodologie generică de dezvoltare a softului astfel:

Un set finit de concepte, principii, norme, convenţii şi reguli de operaţionalizare a acestora, pentru a da răspunsuri satisfăcătoare problemelor care apar în activităţile de tip AAS, OPA, RDS, OMP.

Să încercăm, în continuare, o serie de precizări relativ la semantica acestei definiţii.

(Despre pragmatica acestei definiţii, încă nu putem spune mare lucru. Dacă am fi vorbit despre o metodologie anume, alta era situaţia în ceea ce priveşte pragmatica.)

����Orice metodologie care “urmăreşte priza la public” trebuie să facă faţă

contradicţiilor, inerente pentru semantica binomului MDS-specialist în IS. Una dintre contradicţii se referă la dorinţa de a oferi un set relativ restrâns de concepte,

principii şi reguli de utilizare a acestora în opoziţie cu aspiraţia legitimă a oricărui autor de MDS de a oferi sintaxă care să permită descrierea unei semantici, cât mai bogată posibil.

Altă contradicţie se referă la înclinaţia spre formalizm a spiritelor riguroase în opoziţie cu înclinaţia spre intuitiv a altora.

Nu în ultimul rând (pentru că mai sunt şi alte exemple) semnalez contradicţia dintre necesitatea de a standardiza mare parte a procesului de dezvoltare a sistemelor soft şi nevoia de exprimare liberă resimţită de unii specialişti. În alt plan ne întâlnim cu contradicţia dintre nevoia de a creşte productivitatea muncii şi necesitatea de a realiza sisteme soft de calitate.

Cei care specifică MDS se străduiesc să menţină echilibrul între aceste contradicţii prin diferite mijloace.

De exemplu, referitor la prima contradicţie, metodologia UML oferă o semantică foarte bogată cu ajutorul unui set bine ales de concepte şi principii, oferind şi câteva mecanisme de extensie cu ajutorul cărora semantica metodologiei poate fi îmbogăţită.

����În ceea ce priveşte capacitatea unei MDS de a oferi suport pentru rezolvarea

problemelor de tip ASS, suntem datori cu o serie de precizări importante. Pentru o MDS recomandările pe care aceasta le face pentru a transforma enunţul unei probleme de informatică în soluţie executabilă pe un calculator real, practic definesc însăşi substanţa metodologiei. Aceste recomandări desemnează, conform literaturii de specialitate, ciclul de abstractizare al unei MDS.

Pentru un specialist în IS prima întrebare pe care şi-o pune în faţa unei probleme noi este destul de lungă.

“Cum să derivez din datele problemei o soluţie, respectând termenele de execuţie, fără să dezamăgesc utilizatorul direct, întâmpinând exigenţele curente şi de perspectivă ale utilizatorului indirect şi, chiar dacă pare un pic utopie, fără să mă stresez peste măsură?”.

Fără îndoială, o astfel de întrebare poate avea o serie de conotaţii etice, filozofice, etc. dar

nu acestea îl preocupă pe specialistul în IS. Evidenţiind doar ingredientele esenţiale ale unei probleme de IS, avem: -Date -Prelucrări -Interfeţe Toate aceste ingrediente există în domeniul problemei în format utilizator.

În domeniul problemei, pentru descrierea soluţiei se folosesc concepte pe care le înţeleg, probabil, oricare dintre participanţii la un proiect, dar, în orice caz, ar trebui să le înţeleagă participanţii din sfera utilizatorilor şi clienţilor.La celălalt capăt al balanţei se află domeniul soluţiei în care se vehiculează concepte pe care le înţelesc specialiştii în IS.

În format utilizator datele sunt organizate supralicitând redundanţa, prelucrările, fiind

aplicate unor date în care “musteşte” redundanţa, nu sunt automat cea mai fericită alegere. Tot atât de delicată este şi problema “organizării” interfeţelor deoarece în elaborarea

acestora trebuie gestionată optim contradicţia dintre dorinţa de a oferi utilizatorului confort şi pornirea naturală a specialistului în IS de a raţionaliza interfaţa cu utilizatorul.

Acestea sunt o parte din motivele pentru care o MDS trebuie să ofere suport pentru elaborarea treptată (pe mai multe nivele de abstractizare) a soluţiei pentru probleme de genul:

-organizarea optimă a datelor utilizate de un sistem soft; -organizarea optimă a prelucrărilor specifice unui sistem soft; -organizarea pe principii ergonomice şi de eficienţă a interfeţelor unui sistem soft. Suportul oferit pentru rezolvarea problemelor semnalate mai sus depinde de metodologie.

Rămânând la ideea de metodologie generică, ar trebui să spunem că acest suport poate reprezenta un set de concepte, principii şi reguli de operaţionalizare a acestora cu ajutorul cărora se reprezintă proprietăţile de un anumit tip ale procesului în curs de modelare.

De exemplu, proprietăţile informaţionale ale procesului modelat, odată ce au fost identificate, caracterizate şi clasificate ne pot da o descriere a aspectelor statice ale procesului; în acest scop metodologiile oferă modele de organizare a datelor, eventual pe mai multe nivele de abstractizare.

Proprietăţile comportamentale ale procesului pot fi descrise utilizând modele capabile să surprindă diferite “nuanţe” ale dinamicii unui sistem.

Pare simplu, dar nu este aşa. Pentru a obţine o reprezentare cât mai exactă a proprietăţilor informaţionale şi comportamentale ale unui proces, trebuie să elaborăm:

-modele care reprezintă statica unui sistem; -modele care reprezintă dinamica unui sistem; -modele care reprezintă fluxurile informaţionale într-un sistem ş.a.m.d. Altfel spus, sistemul modelat este privit din mai multe perspective, fiecare perspectivă

permiţând descrierea unui anumit tip de proprietăţi; laolaltă, putem spune, fortând puţin lucrurile, perspectivele ne ajută să obţinem o “imagine holografică” asupra sistemului modelat. Până unde merge acurateţea acestei imagini?! Iată o întrebare cu mai mult de două tăişuri pentru cei care dezvoltă softuri dar mai ales pentru cei care specifică noi MDS.

����În ceea ce priveşte capacitatea unei MDS de a oferi suport pentru rezolvarea

problemelor de tip OPA. Oferta MDS privind rezolvarea problemelor de tip OPA este desemnată în literatura de

specialitate prin sintagma ciclul de viaţă al sistemelor soft. Ciclul de viaţă al sistemelor soft este, alături de ciclul de abstractizare, o caracteristică

fundamentală a MDS. Este evident faptul că, la detaliu, fiecare MDS are propria propunere de ciclu de viaţă. Făcând abstracţie de metodologie, o primă perspectivă asupra semanticii noţiunii de ciclu de viaţă o obţinem în Figura 2.2.

Diagrama din Figura 2.2. surprinde elementele esenţiale pe baza cărora începe să aibă sens noţiunea de ciclu de viaţă.

Adevărul este că, pentru sisteme soft de complexitate mare sau medie, ciclul de viaţă al unei MDS trebuie să propună reguli de etapizare/organizare a efortului de realizare a unui sistem soft reunite sub denumirea “Dezvoltare”. Tot din ciclul de viaţă face parte şi utilzarea sistemului soft, de la care putem avea feed-back-uri care pot genera modificări.

Pentru a obţine date noi asupra semnificaţiei noţiunii de ciclu de viaţă prezentăm diagrama din Figura 2.3.

Figura 2.3. Conţinutul 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ă) Având 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ă existenţa unei pieţe pentru un produs de uz general, fie că o anumită

organizaţie are nevoie de un soft specializat, în mare măsură această primă etapă presupune mai degrabă luarea unor decizii de management şi marketing decât abordarea unor probleme legate de studiul algoritmilor, de exemplu.

După luarea deciziei de dezvoltare a sistemului soft începe analiza propriu-zisă, al cărei scop principal este identificarea necesităţilor utilizatorului potenţial al sistemului soft. De exemplu, în cazul unui produs de uz general, care urmează a fi vândut pe o piaţă concurenţială, trebuie stabilit un public ţintă. Dacă se construieşte un sistem soft de gestiune a stocurilor ce urmează a fi folosit în departamentul de aprovizionare al unei firme constructoare de maşini, atunci trebuiesc identificate necesităţile şi aşteptările celor care lucrează în cadrul acestui departament.

Unul dintre rezultatele formale ale etapei de analiză îl reprezintă un set de cerinţe pe care noul sistem soft ar trebui să le satisfacă. Acestea trebuiesc formulate din punctul de vedere al utilizatorului (direct sau indirect), sau în limbajul de specialitate al IS.

După ce au fost identificate cerinţele, acestea sunt transformate în specificaţii tehnice. Ca un exemplu, cerinţa ca accesul la datele sistemului să fie permis doar persoanelor autorizate se poate transforma în specificaţia că sistemul nu trebuie să răspundă decât după introducerea unei parole de exact unsprezece caractere, confirmată de sistem.

Fireşte, se pot pune întrebările:

Problemă

Dezvoltare

Utilizare

Abandonare soft

Modificare

“Care sunt regulile care guvernează procesul de identificare şi reprezentare a cerinţelor faţă de sistemul soft?”

şi

“Care sunt regulile care guvernează domeniul de elaborare şi reprezentare a specificaţiilor tehnice?”.

Răspunsul este simplu: metodologia oferă suport de tip ASS şi suport de tip RDS care se

foloseşte în această etapă a ciclului de viaţă cât mai eficient cu putinţă. Proiectarea Este etapa în care soluţia sistemului soft este specificată în detaliu. În termeni generali vorbind, sistemul soft imaginat în etapa de analiză este descompus,

progresiv, în componente mai uşor de modelat, numite, generic, module. Implementarea sistemelor complexe devine posibilă tocmai prin această descompunere modulară. Astfel, mulţimea detaliilor tehnice care trebuie luată în considerare ar fi imposibil de stăpânit. Proiectarea modulară creează, totodată condiţii pentru lucrul în echipă şi vine în întâmpinarea efortului de întreţinere, dacă acesta este reclamat.

Una dintre concluziile greu de combătut ale generaţiilor de MDS poate fi formulată astfel:

“O structură modulară, chibzuit proiectată este benefică atât pentru implementarea sistemului cât şi pentru modificarea sa ulterioară.”

Probabil, acesta este unul dintre principalele motive pentru care modelarea orientată spre

obiecte câştigă tot mai mult teren. În faza de proiectare, ca şi în cea de analiză suportul de tip ASS şi RDS este esenţial

pentru a obţine o soluţie tehnică de calitate. Implementarea Este etapa în care are loc scrierea efectivă a programelor, crearea fişierelor şi, în

consecinţă, dezvoltarea bazei de date a sistemului soft astfel obţinut. Testarea Este etapa strâns legată de etapa anterioară deoarece, în mod normal, fiecare modul al

sistemului este testat în timpul implementării. Într-un sistem bine proiectat (ceea ce ar face trimitere directă la o serie de posibili factori

interni ai calităţii precum: decompozabilitatea modulară, compozabilitatea modulară, înţelegerea modulară, continuitatea modulară şi protecţia modulară, conform şi celor specificate în [3]) fiecare modul poate fi testat în mod independent, utilizând versiuni simplificate ale celorlalte module pentru a simula interacţiunea modulului ţintă al testării cu restul sistemului. Evident, pe măsură ce diferite module sunt finalizate şi combinate, testarea individuală face loc treptat testării generale a întregului sistem.

Practica dovedeşte că testarea şi complementara acestei activităţi, care este depanarea, sunt, îndeosebi în cazul sistemelor mari activităţi greu de finalizat. Sistemele de mari dimensiuni pot conţine foarte multe erori chiar şi după efectuarea celor mai complexe teste. Multe erori pot rămâne neobservate pe toată durata vieţii sistemului soft. Punerea la punct a unor strategii de eliminare a acestor erori este un obiectiv major al IS. Practica ne arată că în această direcţie mai sunt încă multe probleme de rezolvat.

��� Multă vreme MDS s-au bazat pe secvenţialitatea 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ă direcţie.

Studiile de specialitate arată că abordarea propusă de modelul cascadă este într-o contradicţie flagrantă cu nevoia de a tatona profunzimile soluţiei unei probleme (prin încercări), resimţită de spiritul creativ al rezolvitorului. În timp ce modelul cascadă schiţează un mediu de rezolvare a problemei riguros structurat, rezolvarea creativă se desfăşoară într-un mediu în care structurarea temporară poate fi abandonată în favoarea sugestiilor unor străfulgerări de intuiţie.

În ultimii ani, preocupările IS încearcă să reflecte această contradicţie, 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 condiţii este mai uşor să se revină, în caz de eroare, sau chiar să se planifice o dezvoltare în spirală a soluţiei sistemului soft (a se vedea paradigma RAD – Rapid Application Development – asupra căreia vom reveni în Capitolul 3).

����În ceea ce priveşte capacitatea unei MDS de a oferi suport pentru rezolvarea

problemelor de tip RDS, putem, de asemenea, să facem o serie de consideraţii cu caracter general.

Pe tot parcursul elaborării soluţiei unei probleme, aceasta trebuie documentată şi reprezentată.

Soluţia trebuie documentată deoarece există mai multe categorii de persoane interesate în utilizarea acestei documentaţii (operatorii sistemului soft, cei care distribuie şi instalează sistemul soft, programatorii care se ocupă de întreţinerea sistemului soft, partenerii proiectului de realizare a sistemului soft, etc.).

Documentaţia de utilizare poate fi realizată sub forma unor ghiduri de utilizare tipărite sau poate fi încorporată în structura sistemului soft sub formă de help interactiv. Spre binele autorilor sistemelor soft sau spre binele celor care ar trebui să modifice sistemul soft este bine ca însuşi codul sursă al sistemului soft să fie generos documentat.

Deoarece, de calitatea documentaţiei depinde în mare măsură şi priza sistemului soft la

segmentul de piaţă căruia i se adresează, marile firme producătoare de soft au transformat documentarea unui sistem soft într-o activitate supusă în mare măsură standardelor, automatizării, legilor pieţei.

Se cunosc exemplele remarcabile oferite în această privinţă de firme precum Microsoft

sau Borland. Soluţia trebuie reprezentată în fiecare etapă a ciclului de viaţă deoarece: -permite schimbul de informaţii de natură tehnică între partenerii de proiect; -serveşte ca sursă de documentare strict necesară celor care vor să aducă modificări

sau dezvoltări acestei soluţii.

Atât pentru documentarea cât şi pentru reprezentarea soluţiei se folosesc limbaje sau sisteme adecvate.

Astfel, pentru documentare se foloseşte, în esenţă, limbajul natural, manifestându-se o grijă deosebită pentru rigoarea, claritatea, sugestivitatea şi uşurinţa în utilizare a diferitelor tipuri sau sisteme de documentare. Programatorii, îndeosebi, sunt deja obişnuiţi cu încorporarea în mediile de programare sau în funcţionalitatea diferitelor sisteme soft a unor help-uri interactive de mare complexitate sau a tutorialelor care asistă învăţarea operării sistemelor soft. Ultima “găselniţă” în materie de documentare a sistemelor soft o reprezintă capabilităţile de tip “wizards” care scutesc utilizatorii de grija de a memora anumite protocoale de utilizare a sistemelor soft, lăsându-le însă întotdeauna libertatea de a gândi care este cea mai bună alegere într-un anumit moment al utilizării softului în cauză.

În ceea ce priveşte reprezentarea soluţiei, aducem la cunoştinţa cititorului faptul că lucrurile sunt mai puţin aşezate decât în cazul documentării.

Limbajele alese pentru reprezentarea soluţiei unui sistem soft pot fi: -tributare cerinţei de a fi intuitive, caz în care textul este combinat cu grafica conform

unor reguli specificate riguros din punct de vedere sintactic (a se vedea notaţia utilizată în UML!);

-tributare excesului de formalizm, indispensabil, spun teoreticienii pentru a asigura un spor de corectitudine în specificare, analiză, proiectare. Formalizmul excesiv este cerut şi de, încă ipotetica, năzuinţă a IS de a implica sisteme soft specializate în generarea automată a codului executabil pornind de la soluţia tehnică (a se vedea Z, Z++, VDM, VDM++, sisteme formale de reprezentare a soluţiei unui sistem soft care au reuşit câteva străpungeri experimentale în lumea practică a IS şi atât deocamdată).

Referitor la notaţie (cum se mai numeşte limbajul de reprezentare a soluţiei) să precizăm că aceasta în manualele de prezentare a MDS este strâns dependentă de semantica metodologiei, adică limbajul de reprezentare a soluţiei “respiră acelaşi aer” cu limbajul de abstractizare a soluţiei.

����În ceea ce priveşte capacitatea unei MDS de a oferi suport pentru rezolvarea

problemelor de tip OMP Din cele expuse până în acest punct al lucrării s-a înţeles, presupun, faptul că lucrul în

cadrul unui proiect de dezvoltare a unui sistem soft ridică probleme deosebite din punctul de vedere al managementului. Deja, practica lucrului în cadrul proiectelor de realizare a unor sisteme soft serioase a confirmat valabilitatea afirmaţiei potrivit căreia:

Un management slab poate compromite uşor şansele de reuşită ale unei echipe de proiectare redutabilă profesional; un management bun poate gestiona eventualele probleme datorate nivelului profesional necorespunzător al unora dintre membrii echipei de proiectare.

Lumea în care trăim este, fără să exagerăm deloc, opera diferitelor tipuri de management. Specialişti sau nu în probleme de management, este bine să ştim că există discipline care

studiază problemele fundamentale ale managementului, dar, complexitatea activităţilor imaginate de om depăşind de mult capabilităţile explicative şi operaţionale ale unui tratat de bazele managementului, asistăm la apariţia unor varietăţi noi de management cu obişnuinţa cu care la un anumit timp după apusul soarelui ne vine din ce în ce mai greu să rezistăm tentaţiei de a ne culca. Printre aceste varietăţi de management se află şi managementul proiectelor de realizare a sistemelor soft (MPRSS). Multe dintre principiile fundamentale ale teoriei managementului operează şi în cadrul MPRSS. Mai mult, putem afirma că, cel puţin în cazul

etapei de analiză din ciclul de viaţă al unui sistem soft cunoştinţele de management sunt de mare utilitate (dacă sistemul soft este realizat la cererea conducerii unei organizaţii cu sau fără profit).

Multe din întrebările care se pun în etapa de analiză (ce obiective are de îndeplinit sistemul soft?, care sunt mijloacele de îndeplinire a acestor obiective?, cum îşi mapează sistemul soft funcţiile pe domeniul activităţilor deservite?, etc.) primesc răspunsuri mult mai clare dacă analistul are şi cunoştinţe de management. Sperând că v-am convins, oarecum, de utilizarea unui management adecvat al procesului de dezvoltare a unui sistem soft, să anticipăm că în atenţia MPRSS se află trei tipuri fundamentale de activităţi:

-gestiunea resurselor angajate în realizarea sistemului soft; -asigurarea calităţii sistemului soft; -gestiunea riscurilor asociate procesului de realizare a sistemului soft. Toate aceste trei tipuri de activităţi se desfăşoară după o planificare riguroasă care

presupune, în esenţă stabilirea cadrului optim din punct de vedere organizatoric şi logistic care permite valorificarea suportului oferit de MDS pentru rezolvarea problemelor de tip ASS, OPA, RDS.

Nu ne va surprinde, aşadar, să constatăm că specialiştii care depun eforturi pentru dezvoltarea suportului metodologic de tip OMP propun o serie de modele calitative şi cantitative cu ajutorul cărora se încearcă măsurarea sau evaluarea rezultatelor activităţilor mai sus precizate.

Date fiind particularităţile acestor activităţi în cazul proiectelor de realizare a unor sisteme soft, este de aşteptat ca multe direcţii de acţiune ale managementului să se supună unor legităţi specifice.

Orice patron de firmă soft va scăpa de multe probleme în ziua în care din laboratorul de cercetare va ieşi pe piaţă o metodologie care:

articulează atât de bine contradicţiile, certitudinile şi incertitudinile din munca unui specialist în IS, încât toate merg ca într-o linie de fabricaţie a unor echipamente necesare pentru dotarea unor capsule spaţiale.

Fericire sau ghinion, cert este că mai avem cale lungă până acolo. Nu cred că este cazul să

vă spun explicit de ce. Doar atât mai adaug: de vină este complexitatea unora dintre activităţile specifice gândirii omeneşti.

Nu ne rămâne decât să alegem dintre nenumăratele rele pe care le avem în faţă pe cea mai puţin costisitoare din toate punctele de vedere.

Capitolul 3 Ciclul de viaţă al unui sistem soft

…Înclinaţia omului spre rigoare îsi are izvorul în apetitul lui pentru improvizaţie. Formele de manifestare a rigorii în IS au un defect la urma urmei pozitiv: rămân destul de repede în urma timpului. De aceea, "forfota" din laboratoarele de cercetare a IS se va menţine pentru multă vreme dacă nu vom găsi 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ă, aşadar, tema fundamentală a cercetătorilor IS în mileniul 3: Generarea complexităţii cu ajutorul unor sisteme cu structură simplificată. Subtilităţile temei sunt cunoscute din alte încercări ale omului. Ceea ce trebuie descoperit este foarte aproape de cea mai mare necunoscută a omului: gândirea. Nu ne rămâne decât să învăţăm să gândim 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 întâlni abordări 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 îmbunătăţit de dezvoltare a softului Tot ceea ce se poate spune despre modelele de dezvoltare sugerate de figurile de mai sus

este faptul că abstractizează frumos, dar ineficient procesul de dezvoltare a sistemelor soft de mare şi medie complexitate.

Conform Figurii 3.1, specialistul în IS trebuie să aibă abilităţi remarcabile care să-i permită să facă un salt uriaş de la cerinţe la codul care descrie, practic, în detaliu, soluţia executabilă a sistemului soft.

Există oameni care pot face acest lucru. Diferitele nivele de abstractizare şi faze de dezvoltare a softului se înfiripă în creierele acestora şi capătă contururi suficient de clare pentru a permite alimentarea cu “materie primă de calitate” a procesului de codificare. Chiar şi în cazul unor astfel de oameni, saltul de la cerinţe la cod este plin de riscuri.

Îmbunătăţirea sugerată de Figura 3.2 este reală dar insuficientă. Ani la rând, în laboratoarele de cercetare ale IS s-au făcut eforturi extrem de diverse şi uneori foarte originale, pentru găsirea celei mai bune formule de desfăşurare în timp a procesului de abstractizare a soluţiei unui sistem soft.

Toate aceste formule se concretizează într-o listă lungă de propuneri de cicluri de viaţă, din care vom analiza în continuare câteva exemple reprezentative.

Deşi ciclul de viaţă propus de o MDS funcţionează optim în conjuncţie cu o anumită strategie de abstractizare a soluţiei, specifică MDS, în analiza pe care o fac în paragraful 3.2 voi insista doar pe elementele care definesc particularităţile unei MDS din punct de vedere al ciclului de viaţă.

3.2. Ciclul de viaţă al sistemelor soft. Exemple. Schimbările care s-au produs, în timp, în ceea ce priveşte tehnologiile informaţionale şi

MDS s-au reflectat şi în ciclul de viaţă al sistemelor soft, fie prin schimbarea etapelor acestuia, fie prin modificarea strategiei de parcurgere a acestor etape.

Specificarea cerinţelor

Implementare

Specificarea cerinţelor

Diagrama de structură

Implementare

Un studiu comparativ al diferitelor exemple de MDS evidenţiază o serie de elemente interesante.

Numărul fazelor ciclului de viaţă specific unei MDS poate varia de la trei (analiză, proiectare, implementare) până la douăzeci sau mai multe.

Este evident faptul că, şi în acest domeniu, concurenţa, beţia teoretică şi ruperea contactului cu realitatea zămislesc, din când în când, adevăraţi monştri metodologici. Pentru a trece cu brio examenul practicii, o MDS trebuie să manifeste o preocupare deosebită pentru două dintre trăsăturile ciclului de viaţă asociat:

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

viaţă al sistemelor soft reprezentative, urmând să degajez o serie de concluzii generale după prezentarea acestor modele.

3.2.1. Modelul cascadă( MC) Numit şi water-fall, este un exemplu de ciclu de viaţă care a făcut istorie. El afost “lansat

la apă” la începutul deceniului 7 de către W. W. Royce şi constă într-o descompunere a ciclului de viaţă al unui sistem soft în faze secvenţiale. Fazele sunt descompuse în activităţi. Trecerea de la o fază la alta se realizează după ce precedenta a fost parcursă integral.

Să mai reţinem şi faptul că MC se aplică la nivel de sistem. Alte informaţii cu privire la model în Figura 3.3.

Figura 3.3. Modelul cascadă

Definirea cerinţelor

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, evidenţiindu-se clar “întinderea” lor ca o colecţie de activităţi şi subactivităţi specifice;

�Este uşor de însuşit de către partenerii unui proiect, inclusiv de cei cu experienţă redusă; �Fiecare fază este “acompaniată” de o documentaţie destul de bine structurată. Dezavantaje ale modelului cascadă �Aplicându-se la nivel de sistem, evident că nu oferă suport prea consistent pentru

controlul complexităţii în cazul sistemelor mari; �Deşi, după cum reiese şi din Figura 3.3, nu este descurajată abordarea iterativă a unor

faze sau componente ale lor, restricţiile de timp impuse de programarea calendaristică a fazelor limitează ofertele benefice ale posibilităţii de revenire la o etapă anterioară.

Acest fapt nu este tocmai convenabil dacă ţinem cont de faptul că, în practică, nu numai că sunt necesare reluări ale fazelor, mai mult se simte nevoia lucrului în paralel la o scară mai mare decât o permite modelul cascadă;

�Evident, sistemul se predă doar după parcurgerea etapelor anterioare, ceea ce înseamnă

o lungă perioadă de timp până când utilizatorul vede sistemul la lucru, ceea ce nu este convenabil pentru nici una din faze (utilizatorul are destul timp să emită alte pretenţii faţă de sistemul soft);

�MC nu oferă suport adecvat pentru abordarea dinamică a proceselor de modelat; �MC nu are protecţie explicită faţă de modificările care pot interveni pe parcursul

dezvoltării sistemului soft. Nu am considerat necesar să mai insist asupra conţinutului fazelor prezentate în Figura

3.3. Paragraful 2.2 al acestei lucrări conţine suficiente informaţii lămuritoare în acest sens. Cu toate că are destui critici, modelul cascadă a fost şi este folosit, integral sau parţial, ori

de câte ori se doreşte un ciclu de viaţă cu o structură echilibrată. 3.2.2 Modelul V (MV) Acest model preia ideile de bază ale modelului cascadă, integrându-le într-o concepţie

ierarhică de controlare a modului în care sunt parcurse fazele de dezvoltare. (A se vedea Figura 3.4)

Modelul, prezentat în Figura 3.4, descrie o strategie de organizare a procesului de abstractizare în care se propune o perspectivă mai clară asupra elementelor de feed-back ale procesului, o abordare mai modernă a relaţiei sistem-componente, o delimitare mai precisă a interferenţelor procesului cu utilizatorul sistemului soft rezultat.

Adevărul este că marile mutaţii produse în lumea tehnologiilor informaţionale orientează eforturile specialiştilor în IS către posibilitatea abordării unui sistem orientat pe componente, de o manieră iterativ-incrementală (ceea ce înseamnă mai mult decât oferta modelului V) cu o atenţie deosebită faţă de utilizator.

În actuala etapă de dezvoltare a IS utilizatorul a devenit un partener ale cărui opinii trebuie luate în seamă pentru ca sistemul soft să poată trece cu bine “examenul pieţei”.

Figura 3.4. Modelul V Aş mai sublinia faptul că în cadrul MV se face o distinţie clară între verificare şi

validare, ca activităţi specifice laturii din dreapta a V-ului modelului. Verificarea se referă la testarea sistemului, în diverse faze de dezvoltare, din punct de

vedere al corectitudinii logice. În schimb, validarea permite verificarea corectitudinii specificării cerinţelor iniţiale faţă de sistemul soft. Figura 3.4 ne arată că validarea stabileşte dacă sistemul, în forma lui finală, corespunde sau nu cerinţelor. Faptul că validarea este posibilă doar când sistemul ajunge în forma finală este un punct slab al modelului, îndeosebi în situaţia în care procesul de modelat are afinităţi structurale sau conjuncturale cu “nisipurile mişcătoare”.

În acord cu [12], să menţionăm faptul că MV, în forma consacrată aparţine lui Ould, care l-a adus în faţa comunităţii specialiştilor în IS în 1990.

3.2.3 Modelul incremental (MI) Putem considera că este o altă formă a MC. Încercând să repare unele dintre neajunsurile

criticate la MC şi MV, MI se expune criticilor venind din altă direcţie. Să vedem, mai întâi oferta MI sub formă grafică (Figura 3.5).

După cum se observă în Figura 3.5, după două faze desfăşurate la nivel de sistem (definirea cerinţelor şi analiza) care permit obţinerea unei perspective arhitecturale asupra sistemului modelat, MI propune, pe această bază, descompunerea proiectului în subproiecte care generează o “cascadă” de activităţi paralele care permit obţinerea componentelor necesare sistemului final. Faţă de MV, MI oferă posibilitatea atingerii scopului final în două variante: sistem global livrat la sfârşit sau componente livrate distinct.

În categoria avantajelor MI considerăm: �MI se bazează pe posibilitatea de a aplica principiul “Divide et impera”; �MI permite livrarea de componente realizate în intervale de timp scurte;

Definirea cerinţelor 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ă modularizării lui.

Figura 3.5. Modelul incremental Dintre dezavantajele imediate considerăm: �Imposibilitatea aplicării MI în toate cazurile; există situaţii în care, pur şi simplu nu

există elementele necesare aplicării 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 defineşte arhitectura,

totul derulându-se conform exigenţelor principiului top-down de abstractizare; o cerinţă destul de dură care sugerează cunoaşterea şi formularea cerinţelor din faza iniţială de abordare a sistemului;

�Posibilitatea de a realiza sistemul soft dintr-o sumă de componente, pune în faţa echipei

(echipelor) care participă la realizarea sistemului soft probleme deosebite de integrare a componentelor pentru a obţine sistemul executabil.

Evident, calitatea demersului de abstractizare a soluţiei poate salva sau compromite

MI. 3.2.4 Modelul spirală (MS) A fost lansat de un specialist în IS cu preocupări îndelungate legate de ciclul de viaţă al

dezvoltării sistemelor soft, B.W.Boehm. La baza MS stau două convingeri: �natura inerent iterativă a dezvoltării şi nevoia de planificare şi evaluare a riscurilor fiecărei iteraţii;

Definirea cerinţelor

Analiza

Proiectare compo- nenta_1

Implementare compo- nenta_1

Instalare compo- nenta_1

Întreţinere compo- nenta_1

Proiectare compo- nenta_n

Implementare compo- nenta_n

Instalare compo- nenta_n

Întreţinere compo- nenta_n

Arhitectura sistemului

�deficienţa înregistrată la MV în care validarea se efectuează prea târziu, îl determină pe Boehm să propună realizarea acesteia cât mai devreme posibil, de cât 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,

diminuând riscurile la nivel de prototip. Interesantă este şi posibilitatea valorificării experienţei acumulate în planificarea activităţilor din prototipul următor.

De precizat faptul că MC se regăseşte în fiecare iteraţie. Ca elemente ce condiţionează utilizarea cu succes a modelului semnalez: -profesionalismul echipei de dezvoltare; -flexibilitatea în acţiune a echipei (=utilizarea resurselor, definirea activităţilor 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 soluţiei ceea ce facilitează dezvoltarea incrementală a sistemelor soft. Într-o opoziţie netă cu aspectul monolitic, aspectul evolutiv al ciclului de viaţă se regăseşte în toate metodologiile obiect-orientate. Pornind de la această constatare putem spune că, în principiu, modelul evolutiv constă în efectuarea unei investigaţii iniţiale, elaborarea unei strategii pentru descompunerea proiectului în segmente (părţi), fiecare segment având o valoare deosebită pentru client. Segmentele sunt dezvoltate şi livrate în mod iterativ, contribuind la sporirea graduală a performanţelor sistemului. Fiecare segment trece prin toate fazele de dezvoltare a sistemelor: definirea cerinţelor, 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 către lumea utilizatorilor are un impact deosebit

asupra implicării acestora în dezvoltarea segmentelor sistemului. Reuşita utilizării modelului evolutiv constă în specificarea unei arhitecturi deschise, flexibile, prin implicarea tuturor părţilor interesate, inclusiv a utilizatorilor, dar şi a unor specialişti IS profesionişti.

ME preia caracteristica esenţială a modelului circular, o formă existentă printre modelele tradiţionale. Concepţia 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 Franţa şi este susţinut de adepţii 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 INIŢIAL �DESCOMPUNERE ÎN SEGMENTE

SEGMENT_1

�DEFINIRE CERINŢE �ANALIZA �PROIECTARE �IMPLEMENTARE �TESTĂRI �UTILIZARE

SEGMENT_n

�DEFINIRE CERINŢE �ANALIZA �PROIECTARE �IMPLEMENTARE �TESTĂRI �UTILIZARE

INTEGRARE SISTEM

Ciclul de viaţă al sistemului soft surprinde timpul vieţii acestuia şi perioadele principale după care se efectuează schimbări majore, precum: creşterea semnificativă a volumului datelor şi tranzacţiilor de prelucrat şi înregistrat, modificarea platformelor hard sau soft, etc. Toate acestea determină acţiunile de întreprins în timpul realizării sau întreţinerii sistemului.

Ciclul de abstractizare tratează nivelurile succesive ale specificaţiilor, pornind de la elaborarea nivelului conceptual. Întrebarea de bază este: “Ce face sistemul?”. Răspunsul la această întrebare este independent de aspectele tehnice şi organizatorice.

Urmează elaborarea nivelului logic (Cine execută prelucrările? Când şi unde?). Răspunsul la aceste întrebări trebuie să fie independent doar de aspectele tehnice (platforma hard, sistemul de operare, limbajul de programare ales pentru implementare, etc.).

În sfârşit, ajungem la elaborarea nivelului fizic (Cum se execută prelucrările?).

Figura 3.8. Modelul tridimensional Evident, cantitatea de informaţie acumulată la nivelul fizic este cea necesară pentru a avea

ceea ce în alte metodologii numim soluţia tehnică a problemei.

Ciclul de viaţă al proiectului

Întreţinere

Implementare

Studiul tehnic

Studiul detaliat

Studiul preliminar

Ciclul de viaţă al

sistemului

Sistem generaţia 1

Sistem generaţia 2

Nivelul fizic

Nivelul logic

Nivelul conceptual

Ciclul de abstractizare

După această soluţie tehnică se poate face implementarea cu minimum de efort dacă limbajul ales este bine stăpânit. De semnalat virtuţile explicite ale aşezării soluţiei pe trei nivele de abstractizare. Cea mai mare ar fi introducerea unei ierarhii a rezistenţei soluţiei la diferite tipuri de modificări. În această ierarhie, nivelul fizic preia şocurile datorate modificărilor cu dinamica cea mai înaltă (platformă soft, platformă hard), nivelul logic preia şocurile datorate modificărilor organizaţionale (cu o frecvenţă mai redusă decât, 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 relaţiei dintre date şi prelucrări lipsesc virtuţile abordării obiect orientate. În sfârşit, ciclul de viaţă al proiectului oferă o perspectivă asupra efortului de dezvoltare

a soluţiei unei probleme, izomorfă cu viziunea clasică asupra ciclului de viaţă al sistemelor soft.

Aşadar, după cum se spune şi în [12], dezvoltarea unui sistem soft înseamnă orientarea permanentă şi simultană pe cele trei axe. Recunoaştem un sâmbure de adevăr în afirmaţia că luarea în consideraţie a ciclului de viaţă al sistemului permite o planificare riguroasă a evoluţiei sistemului şi a schimbărilor de efectuat, în timp ce ciclul de abstractizare permite obţinerea unei soluţii care nu depinde de opţiunile tehnice ceea ce uşurează extinderea sistemului în viitor.

Nefiind un model cu priză la autorii consacraţi ai domeniului, mulţi specialişti pun sub semnul întrebării viabilitatea clamată, de altfel cu destul talent de către specialiştii francezi în IS.

3.2.7 Modelul fântână arteziană (MA) Acest model îşi are originea în modelul spirală şi în altele care au adus îmbunătăţiri ale

acestuia. Deoarece modelul spirală îşi are originea în modelul cascadă iar MA preia idei din

variante îmbunătăţite ale modelului spirală, s-ar părea că MA este un model căruia ar trebui să-i acordăm oarecare atenţie. În acest sens pledează şi semantica Figurii 3.9.

Analiza Figurii 3.9 ne arată că modelul este aplicabil în cazul dezvoltării de sisteme obiect orientate, cum de altfel ne spun şi “părinţii” modelului (Brian-Sellers Henderson şi J.M. Edwards) în lucrările dedicate prezentării modelului.

Între timp, intenţiile valoroase ale acestui model ca şi intenţiile valoroase ale altor modele prezentate deja au fost preluate de paradingma UML de modelare obiect orientată a sistemelor soft.

3.2.8 Modelul prototipizării (MP) Multe modele de dezvoltare se bazează pe utilizarea, în anumite momente, a abordărilor

iterative (de exemplu, analiza poate implica o serie de sarcini care sunt iterativ repetate până când modelele analizei sunt considerate complete).

Deşi promite un cadru mai realist de dezvoltare a softului o astfel de abordare poate fi uşor “descumpănită” de constatarea că, în zilele noastre utilizatorul final sau indirect ştie să folosească sistemul odată ce acesta a fost livrat, ceea ce creează foarte repede împrejurările necesare pentru ca acesta (utilizatorul) să observe eventualele neconcordanţe între cerinţele lui faţă de sistem şi cele implementate efectiv.

MP oferă o abordare care, potenţial, poate contribui la eliminarea omisiunilor şi ambiguităţilor care pot exista în cerinţe.

În IS se numeşte prototip un sistem sau un sistem parţial finisat care este construit

rapid pentru a explora anumite aspecte ale cerinţelor faţă de sistem şi care nu este considerat sistem gata de livrarea finală la utilizator.

Figura 3.9. Modelul fântână arteziană Un sistem soft aflat în faza de prototip se deosebeşte de un sistem soft gata de livrare prin

o serie de omisiuni asumate sau strecurate involuntar în faza de codificare (implementare). Astfel că un prototip are, în mod obişnuit, o funcţionalitate incompletă (capacitate limitată

de procesare a datelor, performanţe reduse în timpul execuţiei, siguranţă în funcţionare problematică, etc.).

Dezvoltarea prototipului este posibilă efectiv doar utilizând instrumente pentru dezvoltarea rapidă a sistemelor soft (medii vizuale de proiectare, medii vizuale de programare, etc.).

Când realizăm un prototip putem avea diferite obiective în minte. Putem construi un prototip pentru a investiga cerinţele utilizator; în acest scop ne putem

focaliza efortul de dezvoltare pe realizarea interfeţei cu utilizatorul pentru a stabili ce date aşteaptă utilizatorul de la sistem şi ce date furnizează utilizatorul sistemului.

Prototipul poate fi folosit pentru a determina cel mai adecvat gen de interfaţă. Putem construi un prototip pentru a stabili dacă o platformă de implementare anume poate

suporta anumite cerinţe de prelucrare. În sfârşit, un prototip ar putea să urmărească determinarea eficienţei unui limbaj

particular, a unui SGBD sau a unei infrastructuri de comunicaţie.

FOND SOFTWARE

Studiul cerinţelor şi al fezabilităţii

Proiectare sistem

Analiza

Proiectare componente

Codificare

Testare componente

Testare sistem

Întreţinere Evaluare

Utilizare aplicaţie

O perspectivă mai clară asupra proprietăţilor modelului MP putem obţine şi din Figura 3.10.

Figura 3.10. Dezvoltarea rapidă a softului utilizând prototipizarea

Aşadar, fazele principale necesare pentru a pregăti un prototip sunt: �Efectuarea unei analize iniţiale; �Definirea obiectivelor prototipului ; �Specificarea prototipului; �Construirea prototipului; �Evaluarea prototipului şi stabilirea schimbărilor de efectuat. Efectuarea unei analize iniţiale Întreaga activitate de dezvoltare a softului foloseşte resurse valoroase. Începerea unui

exerciţiu de prototipizare fără o analiză iniţială este posibil să conducă la o activitate nestructurată şi greşit focalizată care va produce un soft proiectat nesatisfăcător.

Definirea obiectivelor prototipului Prototipizarea este de dorit să aibă obiective clar stabilite. Un exerciţiu de prototipizare

poate implica multe iteraţii, fiecare iteraţie având drept rezultat o anumită îmbunătăţire a

Analiza iniţială

Definire obiective prototip

Specificare prototip

Construire protoip

Evaluare prototip şi stabilire schimbări

Prototip complet

prototipului. Pentru participanţii la un exerciţiu de prototipizare, la un moment dat poate fi dificil de stabilit dacă prototipizarea trebuie sau nu să continue.

Pentru evitarea unei astfel de posibilităţi definirea clară a obiectivelor de îndeplinit poate fi de mare folos.

Specificarea prototipului Deşi prototipul nu este realizat în perspectiva unor operaţii de extindere este, evident,

important să aibă un comportament scontat. De aceea, este absolut firesc să luăm în calcul posibilitatea unor modificări care să apropie prototipul cât mai mult de comportamentul scontat.

Aceste modificări sunt mult mai uşor de făcut dacă softul este realizat potrivit unor principii de proiectare profunde.

Construirea prototipului Deoarece este important ca prototipul să fie realizat rapid este firesc ca în această fază să

se apeleze la un mediu de dezvoltare rapidă a plicaţiilor (Delphi, Visual Basic, Visual C, C-Builder, etc.).

Evaluarea prototipului şi stabilirea schimbărilor de efectuat Motivul principal pentru care realizăm un prototip este testarea şi explorarea anumitor

aspecte ale sistemului soft de realizat. Prototipul trebuie evaluat în conformitate cu obiectivele identificate la începerea exerciţiului de prototipizare. Dacă obiectivele nu au fost îndeplinite, evaluarea are drept consecinţă o serie de modificări care urmăresc apropierea prototipului de obiectivele asumate.

După cum se vede şi din Figura 3.10, ultimele trei faze sunt parcurse ciclic, până când toate obiectivele asumate de exerciţiul de prototipizare sunt îndeplinite.

În cele ce urmează putem prezenta avantajele acestui model dar şi o serie de aspecte de care ar trebui să ţinem cont înainte de a ne “aventura” în prototipizare.

Avantaje: �Ilustrarea timpurie a funcţionalităţii sistemului ajută la identificarea tuturor

dezacordurilor dintre specialistul IS şi client; �Cerinţele client omise au şanse să fie identificate; �Dificultăţile legate de proiectarea interfeţei pot fi conştientizate şi rezolvate; �Realizabilitatea şi utilitatea sistemului soft pot fi testate chiar dacă, prin natura lui,

prototipul este incomplet. Probleme: �Clientul poate percepe prototipul ca parte a sistemului final dar nu poate înţelege

amploarea efortului cerut, uneori, de realizarea formei finale a sistemului, motiv pentru care are senzaţia că acesta (sistemul final) trebuie livrat mai curând decât este posibil în realitate;

�Prototipul poate distrage atenţia de la aspectele funcţionale (uneori critice pentru sistem) către problemele de interfaţă (fetişizate oarecum de nevoia de a da permanent satisfacţie clientului/utilizatorului);

�Prototipizarea se bazează pe o implicare semnificativă a utilizatorului; �Managementul care se bazează pe modelul MP are de luat decizii dificile de-a lungul

întregului ciclu de viaţă.

3.2.9 Modelul OMT OMT (prescurtare de la Object Modeling Technique) este un model de dezvoltare al cărui

artizan este J. Rumbaugh. Urmărind să ofere suport pentru dezvoltarea obiect-orientată a sistemelor soft, modelul are următoarele 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 până la ultima fază.

Vom sesiza această deplasare de accent şi din scurta prezentare a conţinutului fazelor în cele ce urmează.

Analiza Pornind de la enunţul problemei, analiza are ca rezultat construirea unui model al lumii

reale în care sunt evidenţiate proprietăţile importante ale acesteia. Activitatea în această fază debutează prin efortul de a înţelege problema deoarece enunţul

problemei este rareori complet sau corect. Modelul obţinut î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 aplicaţiei, analistul nefiind preocupat de obiecte din domeniul implementării precum: structură de date, procedură recursivă, etc.

Un model bun poate fi înţeles şi criticat de specialişti în IS, care nu sunt neapărat programatori. Modelul analizei nu trebuie să conţină nici o decizie de implementare. Ca un exemplu, o clasă Window într-un sistem de monitorizare a ferestrelor aplicaţiilor la o staţie de lucru ar putea fi descrisă în termeni de atribute şi operaţii vizibile utilizatorului.

Proiectarea sistemului Specialiştul 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 ţinând cont atât de arhitectura propusă cât ş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ă, căruia i se adaugă detalii de implementare. Proiectantul adaugă detalii în conformitate cu strategia stabilită pe timpul proiectării sistemului. Obiectivul fazei îl reprezintă, în esenţă, specificarea structurilor de date şi a algoritmilor necesari pentru implementarea fiecărei clase.

Clasele de obiecte din faza de analiză sunt încă semnificative dar sunt completate cu algoritmi şi structuri de date din domeniul soluţiei alese astfel încât să se îmbunătăţească performanţele sistemului. Atât obiectele din domeniul aplicaţiei cât şi obiectele din domeniul soluţiei sunt descrise de aceleaşi concepte şi notaţii de esenţă obiect-orientată, deşi ele există în planuri conceptuale diferite.

Implementarea Clasele şi relaţiile dintre ele aşa cum au rezultat în faza de proiectare a claselor sunt acum

descrise în conformitate cu exigenţele unui limbaj de programare, ţinând cont de particularităţile 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 adăugăm faptul că pentru descrierea soluţiei 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 relaţiile dintre ele), modelul dinamic (care descrie interacţiunile dintre obiectele sistemului) şi modelul funcţional (care descrie transformările pe care le suportă datele din sistem).

Susţinute de o notaţie consistentă, aceste modele au făcut din OMT un element hotărâtor în specificarea uneia dintre cele mai importante paradigme de modelare: UML.

3.2.10 Modelul Raţional (RUP) RUP (Rational Unified Process) este ciclul de viaţă considerat cel mai adecvat pentru

paradigma de modelare UML, asupra căreia vom face o serie de consideraţii în capitolul 4. Scopul RUP, redus la esenţe, ar putea fi formulat astfel: asigurarea cadrului pentru realizarea unor sisteme soft de calitate deosebită, care corespund în cel mai înalt grad cerinţelor utilizatorilor, dispunând de buget şi grafic de execuţie predictibile.

RUP reuneşte 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 organizaţională.

În ceea ce priveşte elementele de management, RUP furnizează, potenţial vorbind, o abordare disciplinată a problemelor legate de gestiunea sarcinilor şi responsabilităţilor î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 secvenţială

unidirecţională a problemei. Există însă, în practica IS, nenumărate probleme a căror rezolvare înseamnă dezvoltarea unor sisteme de mare complexitate sau de-a dreptul sofisticate. Pentru astfel de sisteme, abordarea “secvenţă unidirecţională” este total nerealistă. Alternativa o reprezintă abordarea iterativă care sprijină înţelegerea progresivă a problemei prin rafinări succesive şi creşterea incrementală a soluţiei efective pe baza unor cicluri multiple. Abordarea iterativă oferă flexibilitate în acomodarea la cerinţe noi sau modificări tactice la nivelul obiectivelor sistemului modelat. De asemenea, abordarea iterativă permite participanţilor la proiect să identifice şi să rezolve riscurile înainte ca acestea să devină o povară în procesul de dezvoltare a proiectului. Activităţile RUP pun accent pe realizarea şi întreţinerea unor modele spre deosebire de alte metodologii care fetişizează rolul documentelor care însoţesc reprezentarea soluţiei.

Modelele, îndeosebi cele realizate cu ajutorul UML permit reprezentări cu semantică bogată ale sistemelor soft în curs de dezvoltare. Aceste modele pot fi vizualizate în diferite moduri iar informaţia asociată lor poate fi manevrată electronic în regim on-line. Deplasarea

accentului spre modele urmăreşte minimizarea cheltuielilor necesare pentru generarea şi întreţinerea documentelor şi, totodată, maximizarea informaţiilor cu conţinut relevant.

����Dezvoltarea sistemelor soft conform RUP este centrată pe arhitectură. RUP este un model care conţine 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 măreşte probabilitatea de a reutiliza unele componente ale sistemului. De asemenea, o arhitectură robustă este de dorit şi din punct de vedere al managementului dezvoltării sistemului soft.

FAZE

Fluxuri de lucru

în interiorul fazelor

Iniţiere Elaborare Consturcţ

ie Tranziţie

Modelare afacere

Specificare cerinţe

Analiză şi proiectare

Implementare

Testare

Configurare hard

Fluxuri suport

Managementul

schimbărilor

Managementul proiectului

Asigurarea mediului de

lucru

Iteraţie Iteraţie Iteraţie

Iteraţii prelimin

are #1 #2… #n #n+1…

#m #m+1

… Figura 3.11. Ciclul de viaţă RUP

����Activităţile de dezvoltare sub RUP sunt dirijate de contextele de utilizare (use case-

driven). RUP pune mare accent pe construirea sistemelor luând în consideraţie modul în care

sistemul, odată livrat, va fi utilizat.

����RUP suportă tehnicile obiect-orientate. Fiecare model în cadrul RUP este obiect-orientat, realizat conform notaţiei 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 încât să corespundă cerinţelor unor organizaţii mergând pe scara complexităţii de la echipe de dezvoltare mici până la firmele mari şi foarte mari.

����RUP încurajează preocupările pentru controlul calităţii şi managementului

riscului. Evaluarea calităţii este realizată pe tot parcursul dezvoltării soluţiei, cu implicarea

progresivă a tuturor participanţilor, utilizând 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 dăuna succesului unui proiect.

Faze şi iteraţii î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 următoare, dacă este cazul.

RUP constă în următoarele patru faze: �Iniţiere (Inception); �Elaborare (Elaboration); �Construire (Construction); �Tranziţie (Transition). Se poate vedea viziunea Rational asupra procesului de dezvoltare a unui sistem soft, din

perspectivă sistematică urmărind ideile prezentate în Figura 3.11. Cititorul atent poate să observe marele potenţial încapsulat în modelul RUP. Dacă

adăugăm şi precizarea că acest model este susţinut integral de instrumentele CASE elaborate de firma Rational Software, cititorul trebuie să fie de acord cu faptul că toată “vâlva” care se face în jurul UML şi RUP are explicaţii care au depăşit deja faza confruntărilor teoretice.

Pentru edificare, în continuare voi oferi câteva explicaţii pe marginea conţinutului celor patru faze.

Iniţiere Este faza în care se face ceea ce în limba română s-ar numi studiul de oportunitate care

trebuie să precizeze: -domeniul proiectului; -criteriile pentru aprecierea reuşitei; -evaluarea riscurilor;

-estimarea resurselor necesare; -un grafic de execuţie preliminar raportat la cele patru faze principale Cu tehnologiile de dezvoltare existente este cât se poate de uzual să se realizeze un

prototip executabil care ajută la întărirea celor precizate mai sus. Elaborare În această fază este analizat domeniul problemei, se stabileşte un fundament arhitectural

robust, se realizează planul proiectului şi se elimină factorii de risc înalt ai proiectului. Deciziile arhitecturale trebuie luate având o viziune bine conturată asupra întregului sistem. Aceasta înseamnă că cea mai mare parte a cerinţelor faţă de sistem trebuie specificate corect.

Pentru validarea arhitecturii propuse se poate implementa un sistem orientat pe contextele de utilizare (use case) semnificative).

Construcţie În această fază, procedând iterativ şi incremental se elaborează un produs complet, capabil

să pornească spre comunitatea utilizatorilor lui. Aceasta implică descrierea cerinţelor omise în faza de elaborare, proiectarea până la detaliu a sistemului şi completarea implementării şi testării acestuia.

Tranziţie În timpul acestei faze softul este livrat utilizatorilor. Odată ajuns la utilizatori este posibil

să apară cerinţe de dezvoltare adiţională, este posibil, de asemenea, să fie scoase la iveală “bug”-uri scăpate 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 iteraţii, o iteraţie fiind un ciclu de dezvoltare complet în cadrul unei versiuni a sistemului soft executabil, având ca rezultat un subset al produsului final, care se va îmbogăţi funcţional de la iteraţie la iteraţie până când ajunge să îndeplinească condiţiile de livrare la utilizatori.

���

3.3 Concluzii Deşi din motive didactice am încercat să focalizez atenţia cititorului pe noţiunea de ciclu

de viaţă, acesta va înţelege, probabil, legătura indisolubilă dintre ciclul de viaţă şi celelalte componente ale unei MDS. Îndeosebi binomul ciclu de viaţă – ciclu de abstractizare trebuie înţeles profund de către practicanţii IS care vor să valorifice la maximum potenţialul unei MDS.

Exemplele prezentate arată, pe de o parte, dificultăţile întâmpinate de-a lungul timpului de specialişti IS în încercarea lor de a spori randamentul metodologiilor de dezvoltare a softului, pe de altă parte tendinţa permanentă a MDS de a oferi o perspectivă cât mai realistă asupra procesului de dezvoltare a sistemelor soft.

Aşa cum se vede şi din exemplele prezentate nu lipsesc nici exagerările, multe din modelele specificate de-a lungul timpului funcţionând frumos doar în închipuirea creatorilor lor.

Ca o concluzie de bun simţ, am putea spune că un model de dezvoltare este bun dacă este agreat de un număr mare de specialişti.

Acest lucru se poate întâmpla dacă: ����modelul este uşor de învăţat şi operaţionalizat; ����modelul este bine ancorat în realitatea procesului de dezvoltare; ����modelul oferă suport consistent de-a lungul întregului proces de dezvoltare a sistemelor soft. Cititorul începe, probabil, să fie de acord cu mine atunci când spun că în IS "nisipurile

sunt mişcătoare", multe probleme nerezolvate stau la vedere, deci cei care se simt cu muşchii tari pot să iasă la "interval".

Expediţia noastră continuă pentru că mai avem şi alte necunoscute de scos la iveală în capitolele care urmează.

Capitolul 4 Abstractizarea soluţiei unui

sistem soft

…Avem nevoie de modele pentru a explica, cu un interes anume, dinamica unui sistem bănuit de noi că ar exista sau care există sub ochii noştri, în toată complexitatea lui. Elaborând modele, îmbogăţim lumea sistemelor, care, privind lucrurile cu obiectivitate ştiinţifică, par a deschide una dintre marile porţi către tainele alcătuirii universului. O întrebare, veche de când lumea, ar fi : Cum elaborăm modelele? De când a început să se înfiripe, ştiinţa în genere nu face altceva decât să ne înveţe cum putem dibui modele în cele mai neaşteptate colţuri de univers.

4.1. Modelarea. Limbaje de modelare După Capitolul 3, în care libertatea de mişcare a gândirii a fost oarecum îngrădită de

exigenţele subiectului abordat, iată-ne din nou pe un teritoriu vast, complex şi în continuă prefacere: universul modelării.

Activitatea de elaborare a modelelor se bazează, prin definiţie, pe un mare consum de energie intelectuală.

Cu atât mai mare este efortul de modelare cu cât orizontul epistemologic al celui implicat în efort este nestructurat sau structurat neconcludent.

Ori de câte ori este vorba despre activităţi care se bazează pe “muşchii” gândirii, trebuie

să ne asumăm deopotrivă riscurile, frumuseţea şi noutatea pe care o presupune rezolvarea unei probleme. Chiar şi atunci când “drumul este, pe alocuri, bătătorit” pentru a reuşi avem nevoie de două tipuri de abilităţi:

����abilităţi de elaborare sistematică a realităţii, ����metodă de modelare în domeniul de care aparţine problema. Pentru a fi “meseriaşi” adevăraţi ne mai trebuie doar atâta îndoială în ceea ce ştim la un

moment dat cât să ne fie permanent trează dorinţa de a şti mai multe în fiecare clipă. Ce este un model?

Un model este reprezentarea într-un anumit mediu a unui obiect, proces sau fenomen din acelaşi mediu sau dintr-un mediu diferit. Vom numi sistem real (SR) obiectul, procesul sau fenomenul supus procesului de modelare.

Modelul surprinde aspectele considerate importante ale unui SR, dintr-un anumit

punct de vedere, simplificând sau omiţând celelalte aspecte ale SR. Ingineria, arhitectura, astronomia, fizica şi, de ce nu, IS folosesc intens modele.

Odată realizate, modelele pot fi fizice (în construcţii, în muzeologie, etc.) sau pot lua forma unor reprezentări adecvate pe un suport de memorie externă (hârtie, floppy-disk, hard-disk, etc.).

În IS proprietăţile modelelor sunt reprezentate cu ajutorul limbajelor.

Făcând abstracţie de cele fizice, modelele se impun atenţiei celor care le studiază prin

semantica şi notaţia lor. Mai pe înţelesul unui specialist IS, înţelegerea unui model este o problemă de sintaxă, semantică şi, pentru a fi toate bune, trebuie să fie şi o problemă de pragmatică.

Dacă singurul merit al unui model s-ar rezuma la faptul că generează problemele mai sus menţionate, probabil că, îndeosebi în zilele noastre, ne-am lepăda de ele.

Realitatea este că avem nenumărate motive pentru care acest lucru nu se întâmplă. Modelarea poate fi utilizată pentru reprezentarea unor sisteme de cunoştinţe în

vederea simplificării înţelegerii acestora de către persoanele interesate. În lumea IS se folosesc frecvent astfel de modele pentru a capacita utilizatorii în procesul

de specificare a cerinţelor faţă de un sistem soft, de exemplu.

Elaborarea de modele pare a stimula creativitatea celor care proiectează un anumit

sistem. Înainte de a fi ceea ce este în forma finală, un sistem este descris dintr-o serie de

perspective care prilejuiesc realizarea a o serie de modele preliminare. Sistemul final este aproximarea unui SR, obţinută prin agregarea sintaxei şi semanticii

tuturor modelelor preliminare asociate. Dacă ar fi să dăm un exemplu din lumea IS, atunci sintaxa şi semantica unui sistem soft ar

putea fi rezultatul agregării a trei tipuri fundamentale de modele: -modele care descriu aspectele statice ale SR modelat; -modele care descriu aspectele dinamice ale SR modelat; -modele care descriu aspectele funcţionale ale SR modelat. Un model poate fundamenta realizarea unui sistem de organizare, clasificare,

vizualizare şi editare a informaţilor despre sistemele mari. Altfel spus, nu ne putem imagina procedee de simplificare a efortului de modelare într-un

anumit domeniu dacă nu rezolvăm problema paradigmei-cadru de modelare. Sistemele dinamice pot fi modelate utilizând, să zicem, paradigma UML. Cu ajutorul modelelor putem simplifica procesul de alegere a unei soluţii alternative. Numeroase sunt situaţiile în care factorii care condiţionează la un moment dat procesul de

realizare a unui sistem soft complică peste măsură decizia de continuare a procesului. O modalitate de a ieşi din impas într-o astfel de situaţie o reprezintă elaborarea de modele alternative şi alegerea celui mai bun pe baza evaluării avantajelor şi riscurilor asociate acestora.

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

complexe. Este, probabil, una dintre virtuţile cel mai mult încercată în IS. Sistemele soft mari (large

software system) pot fi abstractizate pe diferite nivele cu ajutorul modelelor, ceea ce simplifică procesul de înţelegere a SR modelat (evident, este vorba de un exemplu de sistem informaţional), evidenţiază mai uşor structura sistemului sau permite anticiparea impactului pe care eventuale schimbări le pot produce asupra SR.

Oprim aici o analiză care ar putea fi continuată la alt nivel de abstractizare pentru a spune

mai multe în favoarea utilităţii modelelor.

Convingerea mea, probată şi de practică, este că merită să înveţi să modelezi oricât de dificil pare, la început, universul paradigmei folosite.

Ce este un limbaj de modelare? Cititorul bănuieşte, probabil, că nu ajunge să vorbim frumos despre modele. Trebuie să

spunem câte ceva şi despre “climatul” în care sunt elaborate aceste modele. Prima afirmaţie pe care am mai făcut-o undeva şi în Capitolul 1, este că putem elabora modelel folosind un

“arsenal”propriu de elemente-suport. Teoretic, însă, avem de înfruntat, cel puţin trei probleme:

����vom avea, precis, dificultăţi în a ne face modelele înţelese de alţi specialişti; ����probabilitatea de a eşua în ceea ce priveşte calitatea modelului poate fi destul de mare; ����este extrem de redusă şansa de a beneficia de toate avantajele pe care le oferă un mediu de dezvoltare. Dacă “limbajul de modelare propriu” este extrem de valoros, mai avem o şansă în

recunoaşterea lui de o comunitate cât mai largă de specialişti. Şi, astfel, se face trecerea la al doilea tip de “climat” propriu elaborării modelelor: cel în care se folosesc limbaje de modelare, recunoscute ca atare de comunitatea utilizatorilor, purtând, eventual, girul mediilor academice, beneficiind, în cel mai fericit caz şi de recunoaşterea ca standard.

Într-o lume a IS un limbaj de modelare care nu este un standard este condamnat la supliciul anonimatului ceea ce echivalează cu “moartea clinică” a ideilor lansate de acel limbaj. Din fericire, chiar şi aflat în moarte clinică, un limbaj de modelare propus la un moment dat poate dăinui, prin ideile lui valoroase, dacă acestea au fost fixate convingător într-o lucrare de specialitate care a ajuns într-o bibliotecă adevărată.

Abandonând aceste consideraţii care riscă să provoace un veritabil derapaj tematic, voi

încerca să explic cititorului ce este un limbaj de modelare în general şi ce este un limbaj de modelare în IS.

În general vorbind, un limbaj de modelare poate fi definit ca o ierarhie de concepte, principii şi procedee de operaţionalizare a acestora în vederea abstractizării soluţiilor problemelor care fac parte dintr-o anumită clasă tipologică.

Această definiţie poate fi considerată satisfăcătoare pentru utilizatorii limbajelor de

modelare. În fond, aceştia trebuie să fie buni “mânuitori” ai conceptelor, principiilor şi procedeelor de operaţionalizare a acestora pentru a realiza modele cărora li se poate aplica sintagma “profesionale”.

Pentru cei care specifică limbaje de modelare sau pentru cei care realizează sisteme soft suport în procesul de modelare orientate pe un anumit limbaj de modelare, definiţia de mai sus este insuficientă.

����Utilizatorul unui limbaj de modelare este asemenea muncitorului care trebuie să ştie să

mânuiască o trusă de scule, într-un context anume. Persoana care specifică un limbaj de modelare este asemenea inginerului care a proiectat

trusa de scule, abstractizând o familie de contexte în care poate fi utilizată trusa. “Scoaterea pe piaţă” a unui limbaj de modelare înseamnă rezolvarea “cu brio” a două

probleme majore: - Specificarea universului conceptual al limbajului -Identificarea formalizmului de prezentare a universului conceptual Amândouă problemele sunt dificil de rezolvat astfel încât beneficiarii potenţiali ai

limbajului de modelare să devină beneficiari efectivi în număr cât mai mare. Semnalez, în

continuare, câteva dintre dificultăţile şi antagonismele cu care se confruntă un specificator de limbaje de modelare (SLM).

�Primul obstacol pe care trebuie să-l depăşească un SLM este reprezentat de problema

delimitării tipologice a sistemelor care urmează a fi modelate cu ajutorul limbajului. Demersul pentru rezolvarea acestei probleme poate eşua graţios dacă SLM implicat nu reuşeşte să oprească la timp elanul generalizării sau dacă, din contră, nu găseşte suficiente resurse pentru a extinde rezonabil oferta de aplicabilitate a limbajului.

�A doua problemă cu care se confruntă un SLM este, evident, specificarea universului

conceptual. Este, se poate spune, cea mai dificilă dintre numeroasele probleme cu care se confruntă un SLM. Aceasta deoarce, universul conceptual trebuie structurat astfel încât să poată fi utilizat, indiferent de complexitatea sistemului modelat. În cazul problemelor de complexitate mică, amploarea efortului de abstractizare este redusă; relativ redusă este, în general, şi semantica pe care trebuie să o codificăm cu ajutorul limbajului.

Aşa cum, probabil, cititorul a dedus deja, confruntat cu exigenţele unei probleme,

adecvată tipologic, limbajul de modelare trebuie să facă faţă la două “comandamente” esenţiale:

-asigurarea de suport pentru cel care modelează în vederea rafinării treptate a soluţiei;

-asigurarea de suport pentru cel care modelează în vederea captării semanticii

sistemului modelat. Amândouă comandamentele “apasă” greu pe umerii celor care vor să specifice limbaje de

modelare. Pentru mai multă rigoare în exprimare, de fapt, trebuie să spun cititorului că problema rafinării treptate a soluţiei unei probleme arbitrare este greu de algoritmizat.

Acest fapt ar putea fi motivat, oarecum, de includerea aptitudinii de a rafina soluţia unei probleme printre abilităţile de bază ale unei persoane inteligente.

Astfel că, nu avem algoritmi de rafinare treptată a soluţiei unei probleme, indiferent ce limbaj de modelare discutăm; în schimb, orice limbaj de modelare încearcă să propună un "background" pentru alegerea celei mai bune variante de rafinare.

“Răutatea” unei probleme de rafinare a soluţiei unui enunţ dat este dublă: algoritmizarea schemei de rafinare agreată de un limbaj nu poate fi realizată decât în linii mari; pe această bază apare al doilea factor de răutate: găsirea schemei de rafinare este o problemă de alegere dintr-o mulţime, uneori inepuizabilă, de variante.

Ca exemple de elemente suport pentru rafinarea treptată a soluţiei unui sistem soft putem

indica: �Descompunerea sistemelor în subsisteme şi agregarea subsistemelor în sisteme

(două procedee de abstractizare din teoria generală a sistemelor care operează cu înţelesul originar la nivele înalte de abstractizare).

�Utilizarea modularizării pentru obţinerea soluţiei unui sistem soft; este un procedeu

care extinde utilitatea principiului descompunerii din teoria generală a sistemelor la specificul problemelor de modelare din IS. La fel cum descompunerea sistemelor în subsisteme este

consecinţa unui anumit mod de a înţelege sistemul modelat, modularizarea se poate baza pe abordarea top-down sau bottom-up. Indiferent de alegere avem nevoie de criterii. Ca un exemplu, în cazul abordării top-down putem avea descompunere bazată pe: -criterii funcţionale; -criterii de organizare a datelor; -abstractizarea fluxurilor de date; -tipuri abstracte de date.

Fiecare dintre cerinţele de mai sus propune, de fapt, o anumită manieră de trecere de la domeniul problemei către domeniul soluţiei.

Comentând, pe scurt, doar descompunerea funcţională, putem semnala faptul că aceasta a

apărut şi s-a consolidat ca metodă în perioada de glorie a programării structurate. Dintre autorii remarcabili care au abordat descompunerea funcţională, amintesc pe câţiva mai reprezentativi: De Marco, Yourdon şi Constantine, Jackson, Page-Jons, Warnierr-Orr.

Descompunerea funcţională este cea care premerge, în IS, analiza şi proiectarea structurată. La limită, descompunerea funcţională a fost introdusă cu scopul de a permite controlul complexităţii problemelor operând cu tehnici de tipul divide et impera. Aşadar, fiecare funcţie este descompusă în subfuncţii ş.a.m.d până când se obţin componente (unităţi de prelucrare) uşor de transpus în instrucţiunile limbajului de programare ales.

Descompunerea funcţională (DF) poate fi înţeleasă, reţinând esenţialul, ca o “ecuaţie” de tipul:

DF = FUNCŢII + SUBFUNCŢII + INTERFEŢE FUNCŢIONALE Evident, în cadrul descompunerii funcţionale, preocuparea de bază a specialistului în IS

este să identifice prelucrările necesare în sistem şi interfeţele funcţionale asociate. Avantaje ale utilizării DF: -simplitate în utilizare – întrucât, orice s-ar spune, este o cale naturală de rezolvare a unei probleme. -obţinerea, cu destulă lejeritate, a cerinţelor utilizatorului. -generarea de soluţii pe diferite nivele de abstractizare (sistem, subsistem, funcţie, subfuncţie), fapt benefic pentru controlul complexităţii problemelor în diferite ipostaze. Dezavantaje ale utilizării DF: -concentrarea eforturilor asupra aspectelor funcţionale conduce la acumularea naturală a multor date redundante. -nu există reguli precise pentru operaţionalizarea DF.

-interacţiunile non-ierarhice dintr-o soluţie orientată pe funcţii sunt dificil de evidenţiat. Pentru eliminarea acestor dezavantaje au fost propuse o serie de principii suplimentare

(în contextul modularizării în genere) care urmăresc un control sporit asupra coeziunii modulelor şi cuplării lor.

Termenul coeziune se referă la gradul de “înrudire” a componentelor interne ale unui modul ceea ce, în termeni mai precişi, măsoară gradul de specializare al modulului. O apreciere corectă a importanţei coeziunii este posibilă dacă privim evoluţia unui proiect de-a lungul întregului ciclu de viaţă. Dacă, deci, în perspectiva apropiată sau mai îndepărtată sunt necesare modificări ale unui modul, acestea sunt mai uşor de controlat şi de localizat dacă modulele sunt înalt coezive.

Coeziunea poate avea mai multe forme de exprimare. Fundamentale în procesul de abstractizare a soluţiei unui sistem soft sunt coeziunea

logică şi coeziunea funcţională. Coeziunea logică a unui modul rezultă ca urmare a faptului că elementele lui interne

permit realizarea unor activităţi de aceeaşi natură. De exemplu, putem presupune că am proiectat un modul care se ocupă de comunicarea sistemului soft cu lumea exterioară. Ceea ce uneşte componentele unui astfel de modul este faptul că toate activităţile au legătură cu ideea de comunicare.

Evident, însă, comunicarea se poate referi la multe lucruri diferite (preluarea datelor, afişarea datelor, raportarea unor erori, etc.).

O formă mai puternică de coeziune este coeziunea funcţională care măsoară gradul de integrare al componentelor unui modul în vederea realizării unei singure activităţi. Problema care apare aici este: “Ce se înţelege prin ideea de activitate?”. Răspunsul depinde, în mare măsură, de contextul în care se pune întrebarea.

Termenul cuplare este introdus în modularizare pentru a măsura gradul de interconectare

a modulelor. Interconectarea modulelor este obligatorie pentru ca acestea să formeze un sistem coerent. Însă, raţiunile de dezvoltare şi întreţinere ne pun din nou în faţa unei cerinţe de tipul “o modificare efectuată într-un modul nu trebuie să afecteze imprevizibil comportarea celorlaltor module”. Simplu şi firesc. Pentru ca să fie şi adevărat este clar că un obiectiv constant al modularizării trebuie să fie maximizarea independenţei modulelor, ceea ce se obţine prin minimizarea cuplării acestora.

Cuplarea modulelor se poate realiza prin control şi prin date. Cuplarea prin control apare atunci când unul dintre module cedează controlul către alt

modul. Cuplarea prin date se referă la partajarea datelor de către modulele unui sistem soft. Indiferent de tipul cuplării este important ca aceasta să fie cât se poate de vizibilă deoarece

cuplarea implicită (ascunsă) este cauza multor erori, îndeosebi de programare. Prin incursiunea făcută sper că am reuşit să atrag atenţia cititorului asupra complexităţii

decizilor cu care se confruntă un limbaj de modelare şi, în egală măsură, un specialist IS în relaţia cu o problemă de modelare.

Singura certitudine în procesul de modelare a soluţiei 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 influenţele nedorite ale acestor probleme.

De fapt, întreaga evoluţie în materie de modelare merge pe ideea de înlocuire a unei paradigme vechi de modelare cu o paradigmă nouă, atenuând sau eliminând “defecţiunile” vechii paradigme, introducând probleme noi care, asumate corect de către specialistul în IS, nu pot afecta semnificativ calitatea sistemului soft.

Să mai facem o precizare necesară: apariţia unei paradigme noi de modelare nu înseamnă negarea tuturor ideilor vechilor paradigme.

Astfel, de la descompunerea funcţională la modelarea obiect-orientată este, sincer vorbind, cale lungă. Aceasta nu înseamnă, însă, că elementele de abordare funcţională au dispărut cu totul. Ele sunt în continuare prezente dar la un anume nivel de abstractizare a soluţiei.

Reluăm o idee pe care am mai vehiculat-o în acest capitol:

suportul oferit de o MDS pentru abstractizarea soluţiei unui sistem soft trebuie să îl ajute pe specialistul în IS să facă trecerera de la domeniul problemei către domeniul soluţiei conservând cât mai multe dintre avantajele pe care experienţa în materie de modelare le-a certificat.

Pentru efectuarea unei treceri, specialistul în IS trebuie să găsească în limbajul de

modelare universul conceptual adecvat. Deoarece sistemele reale, supuse modelării suportă adeseori modificări, uneori

strructurale, ceea ce crează premize pentru apariţia, în timp, a unor semnificaţii particulare la nivelul sistemului real este evident că limbajul de modelare trebuie să posede, atât cât este posibil şi mecanisme pentru extinderea controlată a semanticii limbajului de modelare (a se vedea exemplul oferit de UML în această privinţă).

Închei aici consideraţiile pe marginea celei de-a doua probleme cu care se confruntă un SLM.

�A treia problemă în atenţia unui SLM se referă la notaţia prin intermediul căreia se face

transfer de semantică dinspre limbajul de modelare către utilizatorul limbajului de modelare. Este o problemă care, rezolvată nesatisfăcător, poate compromite intenţiile conceptuale

ale limbajului. De regulă, o notaţie inspirată permite: -vizualizarea procesului de modelare; -specificarea soluţiei unei probleme; -realizarea soluţiei; -documentarea soluţiei. Vizualizarea procesului de modelare Este o calitate care contribuie hotărâtor la rezolvarea a două probleme importante: - sporirea semnificativă a accesibilităţii limbajului de modelare; în opoziţie totală cu

limbajele de modelare vizuale se află limbajele de modelare care se bazează pe o sintaxă exclusiv formală.

- asigurarea unui cadru sistematic pentru realizarea de medii CASE pentru promovarea

modelării vizuale asistată de calculator. Impactul pe care îl are caracterul vizual al modelării asupra productivităţii muncii este

uriaş, dacă adăugăm precizarea că mediile de dezvoltare asistată iau asupra lor mare parte din sarcinile de rutină sau susceptibile de a fi automatizate.

Există specialişti care pun în “cârca” vizualizării o anumită tendinţă de depreciere a specificării soluţiei unei probleme (datorită oportunităţii pe care o reprezintă un mediu CASE pentru a prototipiza, de exemplu).

Chestiunea este discutabilă deoarece, dacă se lucrează sub presiunea timpului, un mediu de dezvoltare nu poate decât să ne ajute să scurtăm termenele de execuţie realizând componente cu înalt grad de standardizare. De asemenea, dacă timpul “nu presează”, atunci ţine oricum de liberul arbitru dacă înainte de a ne repezi la tastatură am reflectat suficient la problemele etapei în care ne aflăm.

Specificarea soluţiei unei probleme Orice limbaj de modelare trebuie să posede în cel mai înalt grad însuşirea de a permite

specificarea corectă şi completă a soluţiei unei probleme. Cititorul care s-a confruntat, ca specialist IS, cu efectele devastatoare (asupra existenţei

unui sistem soft) ale unei specificări incorecte şi/sau incomplete înţelege pe deplin “greutatea” acestei cerinţe. Raza de acţiune a calităţii procesului de specificare a soulţiei unui sistem soft aduce atingere atât factorilor interni cât şi factorilor externi ai calităţii unui sistem soft.

Privind această cerinţă şi din perspectiva exigenţelor unui potenţial mediu de dezvoltare, asociat limbajului, adăugăm o nouă dimensiune înţelegerii capabilităţilor unui limbaj de specificare a soluţiei unui sistem soft.

Atrag atenţia cititorului asupra utilităţii unei dezbateri mai ample pe teme de corectitudine şi completitudine.

Astfel, un specialist IS poate opera cu cel puţin două sensuri ale conceptului de corectitudine:

-corectitudinea de mapare -corectitudinea formală. Corectitudinea de mapare caracterizează modul în care cerinţele beneficiarului sunt

specificate în soluţie. Orice diferenţă între mesajul corespunzător unei cerinţe din domeniul problemei şi mesajul aceleiaşi cerinţe în domeniul soluţiei trebuie interpretată ca un exemplu de specificare incorectă.

Corectitudinea formală răspunde de acurateţea formală a specificării. Mesajul de bază al specificării poate fi prezent, deci avem corectitudine de mapare, dar acurateţea specificării din punct de vedere formal poate fi un obstacol în comunicare sau în generarea automată corectă a unor piese ale sistemului soft de către mediul de dezvoltare.

În materie de specificare corectă este cunoscut “duelul” dintre sistemele formale de specificare (Z, Z++, VDM, VDM++) şi sistemele intuitive de specificare.

În timp ce sistemele formale de specificare sunt puternic matematizate, ceea ce restrânge serios numărul celor interesaţi de această abordare, sistemele intuitive încearcă să cultive rigoarea utilizând masiv semantici exprimate cu ajutorul limbajelor naturale.

Valenţele semantice ale noţiunii de completitudine a specificării sunt, de asemenea, variate.

Analog corectitudinii, putem vorbi de completitudine de mapare, prin care înţelegem prezenţa în sistemul de cerinţe a tuturor elementelor vitale în momentul dezvoltării softului, precum şi a unor elemente-cadru care să permită redefinirea, la nevoie, a sistemului de cerinţe.

Putem vorbi, de asemenea, de o completitudine structurală, prin care desemnăm finalizarea corectă a tuturor intenţiilor de specificare ale proiectului.

Evident, efortul de specificare corectă şi completă are determinări adânci în structura ciclului de viaţă şi a ciclului de abstractizare. Acest lucru va fi mai clar pentru cititor în

momentul în care va trece de la înţelegerea “pe bucăţi” a unei MDS la o viziune sistemică asupra utilităţii ei.

Realizarea softului O notaţie chibzuit aleasă trebuie să aibă calitatea de a permite relativ uşor transpunerea

soluţiei tehnice în limbajul de programare ales. Ceea ce, probabil, pare simplu ca teorie este însă o sarcină dificilă pentru SLM. Pentru ca notaţia unei MDS să faciliteze realizarea softului, la specificarea limbajului de modelare trebuie depuse eforturi de unificare, pe cât posibil, a lumii conceptelor din domeniul soluţiei tehnice cu lumea conceptelor din domeniul programării.

Această unificare este extrem de dificilă cât timp în lumea limbajelor de programare se menţin încă deosebirile de abordări în ceea ce priveşte structura soluţiei unei probleme.

Într-o oarecare măsură este chiar scuzabilă o astfel de stare de lucruri. Să ne gândim că în programare există nu doar variaţiuni pe o anumită temă ci chiar teme diferite.

Programatorii cu experienţă ştiu că într-un fel este să programezi într-un limbaj procedural, alta este optica într-un limbaj de esenţă funcţională, aproape cu totul alta este abordarea într-un limbaj suport pentru programarea logică. De asemenea, este o lume principial nouă şi programarea obiect-orientată; plină de surprize este şi lumea limbajelor paralele.

Deosebirile de natură conceptuală dintre limbajele prezentate mai sus (care nu au epuizat

lista tipurilor de limbaje existente!) sunt suficient de pregnante pentru a provoca derută, la primul contact, unui programator crescut într-o altă paradigmă.

De ce ne-am aştepta să fie mai uşoară soarta SLM în ceea ce priveşte încercarea lor de unificare a semanticilor diferitelor limbaje de programare într-o notaţie cât mai robustă.

Pentru a da un exemplu concret de încercare în această direcţie recomand atenţiei cititorului notaţia UML care reuşeşte un lucru demn de toată lauda: aducerea la numitor comun a numeroaselor MDS autoproclamate obiect-orientate prin propunerea unei notaţii în care îşi fac loc concepte fundamentale ale modelării obiect-orientate (clasă, obiect, asociere, agregare, generalizare, moştenire, mesaj, metaclasă, metodă, signatură, pachet, şablon, stereotip, etc.), precum şi o serie de concepte care ţin de reprezentarea diferitelor tipuri de arhitecturi ale unui sistem soft în genere, modelarea în mediile de calcul paralele, etc.

Deşi ambiţia oricărui SLM în IS este de a vedea modelele obţinute independente de limbajul în care va fi transcris modelul, nu înseamnă neaparat că are şi susţinere efectivă.

Revenind la cazul UML-ului, autorii lui clamează independenţa faţă de limbaje de programare, dar, în sinea lor ştiu că maparea soluţiei tehnice pe soluţia programată este perfectă doar dacă principiile fundamentale ale limbajelor de modelare şi programare sunt în rezonanţă.

Pentru ca lucrurile să progreseze mai sunt de înfăptuit numeroase reforme în ceea ce priveşte:

-impunerea de standarde tehnologice în domeniul sistemelor de operare; -definirea şi implementarea unor standarde în ceea ce priveşte structura sistemelor soft. Mediile vizuale de programare (de genul DELPHI, VISUAL C++, C-Builder, etc.) sunt

exemple grăitoare de abordări compatibile cu o paradigmă de modelare importantă cum este UML.

Documentarea soluţiei Notaţia unui limbaj de modelare trebuie să dispună de resursele necesare pentru a permite: -reprezentarea şi documentarea arhitecturii sistemului; -reprezentarea şi documentarea cerinţelor faţă de sistemul soft; -reprezentarea şi documentarea soluţiei tehnice la diferite nivele de abstractizare; -reprezentarea şi documentarea activităţilor specifice managementului dezvoltării sistemelor soft. Sistemele soft adevărate (în sensul că au complexitate medie sau mare) trebuie să adauge

lângă codul sursă (izomorf, practic, cu codul executabil al sistemului soft) o serie de alte produse tipice ingineriei softului care, laolaltă, alcătuiesc documentaţia constructivă şi de prezentare a sistemului soft.

Documantarea completă a unui sistem soft este o probă de profesionalism pe care firmele de soft mari au transformat-o într-un veritabil bussines pe seama cererii de documantaţie, în creştere, din partea utilizatorilor diverselor tehnologii informaţionale lansate pe piaţă.

�A patra problemă în atenţia unui SLM se referă la stabilirea limbajului cu care este

definit limbajul de modelare. Cărţile care popularizează limbajele de modelare apelează, de regulă, la o combinaţie între

limbajul natural şi elemente de descriere formală pentru a realiza compromisul optim între rigoare şi accesibilitate. Documentaţia de referinţă a unui limbaj de modelare poate apela la un limbaj special pentru descrierea proprietăţilor limbajului de modelare.

Situaţia este similară cu cea întâlnită în domeniul limbajelor de programare, unde se cunosc formalizme de descriere a anumitor proprietăţi ale limbajelor de tipul:

-diagrame de sintaxă -sintaxa BNF Evident, există şi excepţii interesante în ceea ce priveşte alegerea limbajului cu ajutorul

căruia se specifică un limbaj de modelare. Este vorba de sistemele formale de specificare a softului (Z, Z++, VDM, VDM++) care apelează, esenţial, la un formalizm matematic care poate veni dinspre teoria mulţimilor, logică, calculul lambda, etc.

Poate fi, de asemenea, vorba despre limbajele de modelare, gen UML, care conţin în ele însele resursele pentru specificarea semanticii lor.

4.2. Arhitectura unui limbaj de modelare Un limbaj de modelare care se respectă îşi propune (cel puţin din cauza cerinţelor

formulate în paragraful 4.1.) să se prezinte în faţa utilizatorilor cu o concepţie arhitecturală clară.

Înţelegerea arhitecturii unui limbaj de modelare este benefică atât pentru utilizatorii limbajului cât şi pentru cei care îi studiază fundamentele.

Efectul cunoaşterii arhitecturii unui limbaj de modelare asupra unui utilizator al acestui limbaj este similar efectului pe care îl are, în general vorbind, structurarea asupra unui demers de cunoaştere a unui sistem. Arhitectura unui sistem este datoare să explice tuturor celor interesaţi:

-care sunt subsistemele fundamentale ale sistemului; ce semantică încapsulează

aceste subsisteme? -care sunt dependenţele fundamentale între subsistemele evidenţiate mai sus; care

este semantica esenţială a acestor dependenţe? -care este formalizmul utilizat pentru descrierea şi reprezentarea elementelor

prezentate mai sus? Este evident faptul că, prin clarificarea aspectelor arhitecturale ale unui limbaj de

modelare, SLM defineşte orizontul strategic al posibilităţiilor de operare cu capabilităţile de modelare ale limbajului.

Este posibil ca, pentru mulţi utilizatori, cunoaşterea acestui orizont să nu fie deloc o prioritate. Aceasta deoarece alţii decid pentru ei ce limbaj de modelare trebuie să folosească iar utilizarea efectivă a limbajului nu trebuie să treacă neaparat prin înţelegerea subtilităţilor asociate perspectivei arhitecturale. Pentru a ne forma o idee asupra utilităţii cunoaşterii arhitecturii unui limbaj de modelare ne putem inspira din obişnuinţa pe care şi-au făcut-o unii producători de soft de a scoate pe piaţă manuale de utilizare şi manuale de referinţă pentru sistemele soft pe care le produc.

Manualele de referinţă manifestă o atenţie sporită faţă de elementele arhitecturale şi faţă de, să-i spunem, evoluţia universului conceptual al obiectului descris.

Manualele de utilizare încearcă, mai degrabă, să prezinte utilizatorului scenarii pe baza cărora se poate utiliza semantica obiectului respectiv.

O astfel de abordare este prezentă şi în politica firmei Rational Software Corporation de promovare a limbajului de modelare UML, de exemplu.

Aşa cum se întâmplă, î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ă specialiştii 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 funcţii îndeplinesc ele se poate vedea în Figura 4.1.

Specialiştii în IS, interesaţi de utilizarea intensă a limbajelor de modelare preferă să înlocuiască abordarea arhitecturală cu o abordare pragmatică. Pentru un utilizator de limbaj de modelare scenariul cel mai plauzibil este următorul:

1. Dintr-un motiv anume, în atenţia specialistului IS, ajunge o anumită realitate informaţională, cu veleităţi sistemice şi structurale obiective. 2. Specialistul IS stabileşte determinarea obiectivă şi subiectivă a realităţii informaţionale respective. În determinarea obiectivă includem acele aspecte ale realităţii informaţionale care există şi se manifestă independent de atitudinea specialistului IS. În determinarea subiectivă intră în joc exact atitudinea specialistului IS faţă de aspectele obiective ale realităţii informaţionale. Din momentul în care atitudinea specialistului faţă de realitatea informaţională începe să

se structureze, practic, începe procesul de modelare a realităţii informaţionale. Acest proces presupune:

Nivel Descriere nivel Exemple de

concepte Meta-metamodel Reprezintă

infrastructu-ra necesară pentru meta-modelarea arhitecturii. Defineşte limbajul pentru specificarea metamodelelor.

Meta clase, Meta operaţii, meta atribute, etc.

Metamodel Este o instanţă a unui meta-metamodel. Defineşte limbajul pentru specificarea unui model.

Clasă, atribut, Operaţie, etc.

Model Este o instanţă a unui metamodel. Defineşte limbajul necesar pentru descrierea unui anumit domeniu informaţional.

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 informaţional.

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 când schiţăm elementele arhitecturale ale modelului, ceea ce înseamnă generalizare. Se face abstractizare atunci când optăm pentru o soluţie alternativă în procesul de rafinare a modelului, ceea ce înseamnă specializare. �permanente şi obligatorii eforturi de reprezentare a diferitelor nivele de abstractizare, scopurile urmărite fiind: -rezolvarea problemelor de comunicare; -obţinerea specificaţiilor complete ale modelului. Foarte bine! Nu s-ar putea să mă exprim şi mai concret în legătură cu cele două

dimensiuni ale procesului de modelare semnalate mai sus?

Voi încerca acest lucru în continuare. Aşadar, dată o problemă adevărată (= volum mare de informaţii, stabilitate structurală în

mod nativ perisabilă), specialistul în IS execută sarcini de genul: ����Identificarea fluxurilor informaţionale esenţiale; este ştiut faptul că multe dintre

creaţiile omului, inclusiv limbajele naturale, apelează la redundanţă pentru a-şi consolida virtuţile semantice.

Excesul de semantică se justifică dacă există beneficiari imediaţi pentru acest exces. Dacă beneficiarii nu există, atunci excesul de semantică întemeiat pe redundanţă trebuie eliminat. În această “încleştare” pentru identificarea fluxurilor informaţionale, specialistul IS trebuie să fie, în egală măsură, un culegător harnic de date despre fluxurile informaţionale dar şi un abil mânuitor al procedeelor de clasificare, ierarhizare, codificare, abstractizare şi documantare a acestor fluxuri informaţionale.

Rezultatul acestui demers: un tablou cât se poate de complet al tipurilor de date considerate importante pentru rezolvarea problemei.

����Identificarea cerinţelor faţă de sistemul soft care soluţionează problema. Acest tip de

demers este complementar celui semnalat mai sus. Odată enunţate aceste cerinţe, specialistul IS trece la definirea lor.

Din nou se pune mare accent pe abstractizare pentru a alege din mulţimea alternativelor calea cea mai apropiată de cerinţele imediate dar şi cea mai potrivită din punct de vedere al posibilităţilor de evoluţie.

Rezultatul demersului: o perspectivă de nivel de abstractizare înalt asupra proprietăţilor esenţiale ale soluţiei:

-date -funcţii -componente -resurse angajate. ����Proiectarea soluţiei sistemului soft. Numeroasele obiective şi restricţii asumate până la

începerea proiectării reprezintă cadrul de valorificare a acumulărilor din activităţile specificate generic mai sus.

Un bun proiectant înţelege rolul însemnat jucat de abilitatea de a-şi impune şi gestiona o sumedenie de factori de constrângere, inerenţi în procesul de realizare a unui soft de calitate.

Nenumărate sunt momentele de cumpănă în realizarea unui sistem soft. Şi aceasta se întâmplă 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 având competenţe în analiză, proiectare sau implementare rămâne capacitatea de a abstractiza metodic.

Este o abilitate care se formează prin exerciţiu autoimpus şi autocenzurat. Dorinţa de a obţine bijuterii în IS, transformată în exerciţiu de plăcere, iată secretul

evoluţiei profesionale şi în materie de paradigme în IS.

4.3. Complemente. Elemente de teoria generală a sistemelor Am mai făcut referiri scurte la importanţa, consider eu, majoră a teoriei generale a

sistemelor (TGS) în cunoaştere, în modelare, în economie, politică, etc. Greu de găsit un colţ în lume căruia să nu i se potrivească ceva din abordarea TGS. În acest paragraf voi încerca să explicitez o serie de idei care, sub presiunea necesităţii, se manifestă şi implicit.

Pentru început să observăm că, în general vorbind, noţiunea de sistem, în jurul căreia vom articula discursul acestui paragraf, are un dublu înţeles. Cu mai mult sau mai puţin discernământ, numim sistem: un obiect, fenomen sau proces cu existenţă materială – îl vom numi sistem real (SR) – supus la un moment dat atenţiei unui observator oarecare; tot sistem numim şi un model care aproximează comportamentul unui SR. Aşadar, atragem atenţia vorbitorilor de TGS asupra acestei surse de ambiguitate pe care o pot activa cu mare uşurinţă, dacă nu îşi menţin atenţia trează.

Prima întrebare pe care ne-o punem în TGS este, evident, următoarea: “Ce este un sistem?”.

4.3.1. Definiţia şi caracteristicile unui sistem În TGS se numeşte sistem o colecţie de componente interconectate astfel încât se

poate spune că evoluează în comun pentru îndeplinirea unui obiectiv predefinit. La scara universului se poate vorbi, despre omniprezenţa unor variate tipuri de sisteme

care respectă definiţia de mai sus şi care se integrează în sisteme din ce în ce mai complexe deoarece, chiar şi filozofic vorbind, interdependenţele sunt esenţiale pentru a discrimina multe dintre proprietăţile unui sistem.

Dintre proprietăţile 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 înţelegerea omenească posibilitatea existenţei unui sistem fără nici o altă

conexiune cu alte sisteme. Noţiunea de sistem închis este o utopie teoretică. Conştientizarea mediului în care există un sistem real, de exemplu, poate fi esenţială

pentru calitatea modelării acestuia, dacă se urmăreşte acest lucru. ����Orice sistem este delimitat de mediul în care există de un anumit tip de frontieră. Frontiera unui sistem este o noţiune cu o semantică discutabilă. Nici într-un caz,

frontiera unui sistem nu este utilizată pentru a realiza închiderea acestuia. Frontiera este o noţiune cu ajutorul căreia se realizează o delimitare între dinamica internă a unui sistem şi dinamica relaţiilor sistemului cu mediul înconjurător. Avem nevoie de o cunoaştere exactă a frontierelor pentru a face raţionamente corecte relativ la proprietăţile unui sistem.

Interfaţa 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 intrări şi ieşiri. Intrările sunt semnale (mesaje) ale mediului către sistem. Ieşirile sunt răspunsuri pe care

sistemul le dă mediului în care se află. ����Orice sistem are interfaţă. Interfaţa permite comunicaţia între două sau mai multe sisteme. În IS, în jurul conceptului

de interfaţă s-au dezvoltat tehnologii soft importante pentru viitorul tehnologiilor informaţionale (COM, DCOM, CORBA, etc.).

����Orice sistem poate avea, potenţial, subsisteme. Este o constatare care, sub lupa filozofilor este asociată cu posibilităţile de observare ale

omului, inerent limitate atât în perspectivă microscopică cât şi în perspectivă macroscopică. Cert este că orice subsistem poate fi, la rândul lui, înţeles 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 discernământ. Afirmaţia de bun simţ în ceea ce priveşte acest “operator” este că nu se descompune ceea ce din perspectiva intereselor imediate de modelare sau cunoaştere este invizibil.

����Orice sistem care rezistă în timp are un mecanism de control. Problema durabilităţii în timp a sistemelor are legătură nemijlocită cu problema stabilităţii

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 informaţiilor despre ieşirile sistemului către subsistemul de control. Controlul pe bază de feed-before presupune colectarea permanentă de date despre intrări şi transmiterea acestora către subsistemul de control. Deşi nu am spus explicit acest lucru, cititorul înţelege faptul că subsistemul de control poate modifica comportamentul sistemului (în condiţiile menţinerii unei anumite stabilităţi structurale) pentru a asigura o relaţie scontată între intrări şi ieşiri.

Sistemele pe bază de feedback reacţionează mai lent la semnalele mediului. Sistemele pe bază de feed-before sunt mai sensibile la schimbările de mediu ceea ce le măreşte capacitatea de adaptare.

Problema principală o reprezintă costurile proiectării sistemelor de control de tipurile mai sus menţionate.

Sistemele de control orientate feed-before sunt mai scumpe şi mai dificil de implementat. ����Ultima remarcă pe care o adăugăm noţiunii de sistem este următoarea: un sistem are

întotdeauna proprietăţi care nu sunt deductibile direct din proprietăţile părţilor. Aceste proprietăţi le putem numi proprietăţi integratoare (emergent properties, în engleză). Cu cât aceste proprietăţi integratoare se manifestă mai pregnant cu atât mai mare este gradul de organizare a sistemului.

Iată, aşadar, alt subiect de care specialiştii în IS sunt cât se poate de interesaţi: gradul de organizare a sistemelor. Dacă am continua am ajunge la consideraţii savante privind măsurarea entropiei unui sistem din perspectivă probabilist-informaţională ceea ce nu ne propunem, de fapt, în această lucrare.

Este momentul să atragem cititorului atenţia asupra puternicului impact pe care gândirea holistă (sistemică-integratoare) îl poate avea asupra calităţii modelelor elaborate în IS.

Ca un rezumat al ideilor prezentate în paragraful 4.3.1. vă invit să analizaţi semantica Figurii 4.2.

Aş încheia acest paragraf atrăgând atenţia cititorului asupra faptului că elementele introductive pe care le-am prezentat sunt, în mod sigur, un început de drum pentru specialiştii IS interesaţi în surprinderea şi modelarea proprietăţilor numeroaselor tipuri de sisteme informaţionale care populează învăţământul, lumea afacerilor, sistemele nuclearo-energetice, etc. ...

4.3.2. Structura unui sistem În definiţia dată unui sistem se face trimitere la relaţiile dintre componentele unui sistem.

Ştiu că printre filozofi există adevărate certuri în legătură cu problema clasificării şi individualizării acestor relaţii. Pentru exigenţele muncii în IS este important să ştim că

înţelegerea unui sistem este, pe lângă o problemă de delimitare în spaţiu şi o problemă de evoluţie în timp.

În evoluţia în timp a unui sistem se pot deosebi două tipuri fundamentale de relaţii între componentele unui sistem: relaţii stabile şi relaţii accidentale (întâmplătoare).

Ansamblul relaţiilor stabile dintre elementele unui sistem formează structura sistemului.

Figura 4.2. Componentele fundamentale ale unui sistem şi relaţiile dintre ele

Pentru un specialist în IS, mai important decât faptul că structura unui sistem poate fi

abstractizată de un sistem de ecuaţii de nu ştiu care tip, este cunoaşterea 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 întrezărească un anumit gen de stabilitate structurală. Zic un anumit gen de stabilitate structurală ca o recunoaştere 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 întâmplare faptul că una dintre primele cerinţe ale succesului în modelarea specifică IS o reprezintă specificarea corectă a binomului obiective+diagnostic stabilitate structurală relativ la dezvoltarea unui sistem soft.

Cu încredinţarea că cititorul care a ajuns în acest punct al cărţii a fost provocat la studierea mai atentă a utilităţii TGS în abstractizarea soluţiei sistemelor soft şi nu numai, pun punct paragrafului 4.3.

4.4. Complemente. Principii ale modelării cu impact deosebit în IS Deşi unii dintre cititori vor fi de părere că afirmaţiile pe care le voi face în continuare le

erau de mult cunoscute, acest fapt nu mă împiedică să le fac gândindu-mă la cei care nu au avut încă forţa necesară pentru a se ridica la nivelul acestor principii în deplină cunoştinţă de cauză.

Aşadar, este vorba de patru principii care, coroborate cu abilităţile de gândire sistemică şi cu abilităţile de modelare specifice IS, vă pot ajuta să traversaţi cu succes “jungla” de obstacole care se dezvoltă, în mod natural, între enunţul problemei şi soluţia acesteia.

Ce face sistemul Intrări Ieşiri

Cum este controlat sistemul

Fluxuri de control

Feed-back Feed-before

Frontieră sistem

Mediul înconjurător al sistemului

Primul principiu Alegerea tipului de model pe care urmează să îl creaţi are o influenţă profundă asupra modului în care abordaţi problema şi deci asupra caracteristicilor soluţiei acesteia.

Aşa cum insinuam şi în alt context al prezentului capitol, acest principiu atrage atenţia explicit asupra efectelor pe care le pot produce, asupra soluţiei în ultimă fază, diferitele opţiuni făcute de specialistul IS pe parcursul abstractizării soluţiei.

Pentru a convinge cititorul asupra “greutăţii” acestui principiu în IS, trebuie să îl informăm că, pornind de la o aceeaşi problemă într-un fel arată soluţia dacă este tributară obişnuinţelor de abordare specifice unui dezvoltator de baze de date, altfel arată soluţia dacă este tributară obişnuinţelor de abordare ale analizei structurate ş.a.m.d.

Alegerea tipului de model poate influenţa semnificativ calitatea sistemului soft, costurile şi beneficiile datorate utilizării acestuia.

Al doilea principiu Fiecare model poate fi exprimat la diferite nivele de abstractizare (precizie).

Mesajul exact al acestui principiu poate fi înţeles dacă privim lucrurile din interiorul exigenţelor 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 conţine informaţiile aşteptate de o anumită categorie de participanţi la dezvoltarea softului şi reprezintă un element-suport pentru gestiunea complexităţii 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: modelaţi “transfigurând” realitatea modelată cât mai puţin. Problema “transfigurării” realităţii modelate este înţeleasă mai uşor dacă ne punem întrebări asupra modului în care domeniul problemei se mapează peste domeniul soluţiei. 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 instituţionalizează, aproape, cerinţa conjugării 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 căror complexitate trebuie structurată pentru ca modelul rezultat să încapsuleze toată semantica relevantă a sistemului modelat. Structurarea complexităţii sistemului modelat poate să însemne şi necesitatea ca sistemul modelat să fie descris din mai multe perspective, obţinându-se astfel descrieri cu relativă autonomie semantică, care suprapuse (combinate) permit obţinerea unei imagini “holografice” asupra sistemului modelat.

���

Pun punct Capitolului 4 cu speranţa că cititorul a înţeles care sunt problemele în domeniul

abstractizării soluţiei unui sistem soft şi, de ce nu, va pune chiar umărul la clarificarea, la alt nivel de abstractizare, a acestor probleme.

Capitolul 5

Managementul proiectelor în industria softului

…Succesul unei acţiuni depinde, esenţial, de modul în care îi sunt gestionate problemele. Încă mai există manageri care visează cu ochii deschişi că subalternii lor (ruşinaţi, automotivaţi, din patriotism şi pe mai nimic) sunt gata în orice clipă să meargă până la sacrificiul suprem pentru salvarea incompetenţei şefilor. Iertată fie nedumerirea îngrămădită în acest preambul de capitol. Un om se poate schimba învăţând şi luptând împotriva obişnuinţei. O echipă, ai cărei membri nu sunt clone ale unui aceluaşi prototip uman (deosebit din punct de vedere al calităţilor), are nevoie de conducător pentru a ajunge să funcţioneze, cât de cât, ca un tot. În industria softului este nevoie de conducători care ştiu managementul unei afaceri în genere şi încă ceva pe deasupra. Acel “încă ceva pe deasupra” ne va interesa, cu predilecţie, în Capitolul 5.

5.1. Scurtă introducere Nu este în intenţia acestei cărţi 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, aceleaşi probleme şi aceleaşi principii de bază pentru rezolvarea lor. De aceea nu mi se pare deloc o glumă introducerea în planurile de învăţământ ale instituţiilor de învăţământ superior care pregătesc specialişti IS a unor cursuri de iniţiere în teoria managementului. Există cel puţin două motive pentru care este nevoie de o astfel de abordare.

�Aceste cunoştinţe îi ajută pe managerii din industria softului să aibă succes în afacerile pe care le conduc; �Cunoaşterea principiilor după care se structurează şi se operaţionalizează managementul în cazul unei afaceri oarecare, este de mare utilitate pentru cei care, în definitiv, produc tehnologii informaţionale pentru a întâmpina o cerinţă de bază al actului de management: optimizarea fluxurilor informaţionale (viteză, calitate, spectru problematic). Practica demonstrează destul de convingător faptul că un specialist IS care lucrează la

soluţia 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ă înveţe cât mai multe dacă nu vrea să “bâjbâie” până la obţinerea soluţiei tehnice. Cei păţiţi, dar şi nepăţiţii, conştientizează faptul că este greu să modelezi temeinic bazându-te doar pe inspiraţia de moment.

Concretizând, în faţa problemei realizării unui sistem soft, managementul “se loveşte”, în mod natural, de întrebări de tipul: “Cât va costa sistemul?”, “Când va fi terminat?”. Acestea sunt doar două din întrebările la care un răspuns corect este destul de dificil.

Foarte multe proiecte "şi-au dat bugetul iniţial de mai multe ori peste cap" şi au fost finalizate mult timp după termenul estimat al predării. De aceea, printre obiectivele de bază ale MPS vom regăsi:

���� Planificarea sarcinilor proiectului;

���� Estimarea succesului sau a eşecului proiectului, raportat la planul de dezvoltare adoptat; ���� Estimarea timpului şi a forţei 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

preocupărilor fundamentale ale unei persoane implicate în MPS. Aşadar, pe lista subiectelor MPS vom regăsi, în mod necesar, consideraţii referitoare la: -dezvoltarea sistemelor soft (procese, activităţi, management); -managementul riscului; -tehnici de reprezentare a MPS; -estimarea mărimii proiectelor;

-managementul calităţii. Fiecare dintre aceste subiecte încearcă să abstractizeze o categorie deosebită de probleme,

abilitatea managerului fiind cea care va rezolva problema convertirii cunoştinţelor despre aceste subiecte într-o strategie coerentă de conducere a proiectelor soft.

Cititorul informat intuieşte, probabil, că în industria sofutlui, la fel ca în orice alt domeniu de activitate, managementul se structurează atât pe verticală (ca urmare vom avea mai multe nivele de management) cât ş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 activităţilor desfăşurate şi de atitudinea managementului de top faţă de delegarea structurală a competenţelor manageriale.

Ca de obicei, în IS, nu există reţete 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 relaţia dintre anumite tipuri de procese şi managementul asociat acestora.

Aceste date pot fi valorificate efectiv dacă se operaţionalizează, 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 iniţiale limitate.

Management cu structură simplificată.

Diversificare/complexificare a activităţii de dezvoltare a softului.

Există indicii că performanţele 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 dezvoltării softului care

devin obiect de activitate pe toată durata dezvoltării unui sistem soft. Astfel, din perspectivă MPS, dezvoltarea softului înseamnă:

-Produsele realizate; -Procesele desfăşurate; -Factorul uman implicat. ����Produsele realizate în timpul dezvoltării softului În ceea ce priveşte produsele realizate în timpul dezvoltării unui sistem soft,

managementul are o atitudine, evident pragmatică, fiind preocupat de: ����cerinţele pe care acestea trebuie să le îndeplinească; ����structura pe care acestea se bazează în timpul funcţionării. În ceea ce priveşte cerinţele, acestea pot fi: -cerinţe funcţionale (ce trebuie să facă sistemul?) -cerinţe de calitate (cât de bine va lucra sistemul?) -cerinţe în ceea ce priveşte resursele (cât va costa sistemul, în ultimă analiză). Primele două cerinţe sunt şi în atenţia MPS dar îi preocupă îndeosebi pe cei care lucrează

în analiză, proiectare şi/sau programare. Al treilea tip de cerinţă este de competenţa managementului, folosind, evident, datele

furnizate de specialiştii 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 însoţesc realizarea unui sistem soft. Aşadar, 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 cerinţele faţă de sistemul soft, cerinţe care sunt rezultatul unui consens al tuturor celor interesaţi, într-o formă sau alta, în dezvoltarea sistemului soft; -documentul care descrie specificarea cerinţelor, structurate la nivel de sistem şi, respectiv la nivel de componente; -documentul care descrie soluţia tehnică a sistemului soft, elaborată în faza de proiectare, de obicei. Schematizând, un astfel de document va conţine informaţii structurate astfel: �descrierea soluţiei sistemului soft ca întreg; �descrierea colecţiilor de date; �descrierea interfeţei cu utilizatorul;

�descrierea prelucrărilor asociate funcţiilor sistemului soft. -codul sursă al sistemului soft; -datele de test ale sistemului soft, structurate pe module şi la nivelul sistemului ca întreg; -documentaţia utilizator care însoţeşte 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 doreşte menţinerea sistemului soft pe o traiectorie ascendentă în topul preferinţelor clienţilor.

Este momentul să spunem că, vorbind despre clienţi, din punct de vedere managerial aceştia pot fi:

�clienţi pentru care dezvoltăm un sistem soft dedicat; �clienţi pentru care dezvoltăm un sistem soft de interes general. Să mai adăugăm faptul că, dintre toate documentele care însoţesc realizarea unui sistem

soft unele sunt destinate a fi livrate clientului, altele sunt pentru uzul intern al firmei producătoare de soft.

����Procesele desfăşurate în timpul dezvoltării softului Dacă doreşte să se implice în găsirea unui răspuns cât mai bun la întrebarea “Cum este

realizat sistemul soft?”, MPS trebuie să exercite un control metodic asupra modului în care se desfăşoară activităţile pe baza cărora sunt realizate documentele menţionate mai sus, în acest paragraf. Ideea de control metodic poate avea înţelesuri diferite pentru manageri diferiţi. Aş sugera cititorului să privească această idee din perspectivă pragmatică: cel care investeşte în dezvoltarea unui sistem soft este preocupat ca procesul de dezvoltare a softului să fie structurat pe principii de eficienţă şi calitate. Eficienţa micşorează costurile de producţie, calitatea micşorează costurile cu întreţinerea sau dezvoltarea.

Iată motive destul de puternice pentru ca un manager să fie preocupat de conţinutul unui proces de dezvoltare a softului.

Din punct de vedere al managerului, problemele care apar în dezvoltarea softului se văd astfel:

1.Deoarece producerea unui document este posibilă ca urmare a unei activităţi specifice, întregul proces de dezvoltare a softului va fi întotdeauna o sumă de activităţi care de fapt formează un sistem de activităţi, dacă luăm în seamă nenumăratele interdependenţe dintre acestea.

2.Activităţile de dezvoltare tipice pentru un sistem soft ar putea fi considerate: �analiza cerinţelor; �specificarea formală a sistemului şi a părţilor 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 documentaţii utilizator; �instalare sistem; �întreţinerea sistemului pe timpul exploatării. Deducem că este sarcina MPS să definească procesele de dezvoltare pentru a indica: -care sunt documentele şi produsele care urmează a fi realizate; -ce activităţi vor fi desfăşurate; -când va primi clientul documentele şi produsele pe care le aşteaptă; -când vor fi desfăşurate activităţile. De aceea este imperios necesar ca activităţile de dezvoltare să fie organizate, ceea ce

implică desfăşurarea unor activităţi adiţionale procesului de dezvoltare a softului. Aceste activităţi adiţionale dau consistenţă unui proces paralel cu procesul de dezvoltare a softului: procesul de management al proiectului de realizare a unui sistem soft.

Am văzut că activităţile de dezvoltare au ca rezultat o mare varietate de documente. Activităţile de management au ca rezultat esenţial planurile pe baza cărora se desfăşoară activităţile de dezvoltare. Prevederile şi implicaţiile acestor planuri sunt negociate cu clientul, deoarece conţin multe elemente de interes pentru acesta (resurse, termene de execuţie, 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 rând, la specialiştii în IS care se implică în desfăşurarea activităţilor de dezvoltare. Atunci când se lucrează în echipă la rezolvarea unei probleme, gestiunea relaţiilor dintre membrii echipei devine o problemă importantă. Aşa cum ne învaţă tratatele de management între membrii unei echipe de dezvoltare pot apare: relaţii profesionale (de colaborare sau de subordonare), relaţii de natură general-umană (simpatie, antipatie, indiferenţă, etc.), relaţii legate de partajarea unor resurse comune (încăperile în care se lucrează, grupurile sanitare, biblioteca, etc.) ş.a.m.d.

Este sarcina managerului să găsească soluţiile cele mai simple pentru optimizarea funcţionării acestui complex de relaţii.

Evident, managementul este interesat, în primul rând, de eficientizarea relaţiilor profesionale. De aceea, managementul proiectelor soft va propune un model de organizare a

membrilor unei echipe de dezvoltare. Cu toate că mai există şi visători care văd o echipă de proiectare ca o sumă naturală de preocupări convergente, practica recunoaşte 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 activităţilor într-o echipă de dezvoltare. Tot managementul este cel care trebuie să găsească cea mai corectă dimensionare a structurii birocratice a unui proiect, în funcţie de mărimea proiectului şi priorităţile 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ă înţelegere 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ă informaţionială.

Figura 5.2 Model ierarhic, ipotetic, de organizarea a membrilor unei echipe de proiectare 5.2.2.2. Informaţie şi management Sistemele informaţionale pot îmbunătăţi considerabil procesul de elaborare a deciziilor

manageriale. Veritabila industrie de sisteme informaţionale bazate pe calculator a impus concepte precum: sisteme de management informaţional (SMI) şi sisteme informaţionale executive (SIE). Semnificaţia precisă a acestor concepte o voi prezenta în cele ce urmează.

����Informaţia şi funcţiile managementului Managementul este, în general, descris ca un proces de conducere care implică

următoarele funcţii: planificarea, organizarea, coordonarea şi controlul. Aceste funcţii ale managementului au fost identificate şi expuse pentru prima dată de către Henri Fayol, un pionier al teoriei managementului din Franţa.

Planificarea Ca funcţie a managementului, planificarea presupune estimarea evoluţiei 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 pregăti din timp strategii şi scenarii de acţiune pentru minimizarea riscurilor şi maximizarea gradului de realizare a obiectivelor urmărite.

Manager de proiect

Colec-tiv de asigu-rare a calităţii

Colectiv de verifi-care şi validare

Colectiv de mode-lare a soluţiei

Colec-tiv de progra- mare

Colectiv pentru a-sigurarea suportu-lui hard

Integrare Subsistem 1 Subsistem n .......

Organizarea Ca funcţie a procesului de management, organizarea defineşte ansamblul proceselor de

conducere prin intermediul cărora se divizează activitatea sistemului condus, stabilindu-se şi delimitându-se subactivităţile şi sarcinile corespunzătoare acestora.

Altfel spus, organizarea înseamnă gruparea după criterii de funcţionalitate şi eficienţă a sarcinilor şi delegarea responsabilităţii necesare îndeplinirii lor.

Coordonarea Ca funcţie a procesului de management, coordonarea constă în ansamblul proceselor

prin care se sincronizează deciziile şi acţiunile personalului unui sistem organizaţional (în cadrul previziunilor şi organizării anterior stabilite), cu scopul asigurării resurselor necesare, în timp util, de calitatea stabilită şi în cantitatea dorită, pentru atingerea obiectivelor sistemului organizaţional. Îndeplinirea acestei funcţii a sistemului de management este posibilă cu ajutorul unui sistem de comunicare adecvat la toate nivelele de management.

Controlul Prin control desemnăm ansamblul proceselor de urmărire a modului în care se desfăşoară

diferite acţiuni sau întreg procesul de management, cât şi de reglare a activităţilor organizaţiei prin găsirea unor metode eficiente de identificare şi eliminare a efectelor perturbaţiilor apărute în funcţionarea sistemului.

Schematizând şi dezvoltând puţin subiectul avem Figura 5.3. Cititorul are ocazia să-şi formeze o imagine ceva mai cuprinzătoare asupra dificultăţilor

meseriei de manager. Pe lângă faptul că pretinde competenţă, uneori interdisciplinară, pentru a menţine în echilibru diferitele tendinţe care se pot manifesta la nivelul sistemului condus şi la diferite niveluri de management, meseria de manager este marcată de numeroase responsabilităţi, atât faţă de indivizii sau grupurile profesionale conduse cât şi faţă de organizaţie în ansamblu.

Poate că, în acest moment, cititorul şi-a modificat oarecum atitudinea şi faţă de MPS. Pentru a nu eşua, un proiect soft are nevoie de un management eficient, elastic,

corect dimensionat. Toate aceste calităţi ale actului de management(eficient, elastic, corect dimensionat)

depind de virtuţile sistemelor informaţionale pe care se bazează managementul. Dintre componentele sistemelor informaţionale un rol esenţial îl joacă, după cum am ami spus SMI, SAD, SIE.

SMI (Sistemele de management informaţional) Numite în diferite lucrări şi sisteme de raportare a informaţiilor, aceste sisteme au fost

primul tip de sistem informatic-suport pentru actul de management. SMI produc date şi informaţii necesare pentru fundamentarea multora dintre deciziile

zilnice ale managerilor. Beneficiari obişnuiţi ai SMI: managerii de nivel tactic şi operaţional. SAD (Sistem de asistare a deciziilor) Sunt sisteme de informare bazate pe calculator care furnizează suport informaţional

interactiv managerilor în timpul procesului de elaborare a deciziilor. Astfel de sisteme pot folosi: modele analitice, baze de date specializate, sisteme expert, etc. Beneficiari obişnuiţi 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 acţiunilor de interes general; competenţa managerului de top

Planificare şi control al acţiunilor la nivelul subunităţilor componente; competenţa managerului mediu

Planificare şi control al operaţiilor zilnice; competenţa managerilor care au contact direct cu nivelul operativ

Date şi informaţii

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 performanţelor organizaţionale

Figura 5.3.a Funcţiile managementului

Interpersonal

• Leader profesional • Legătură cu mediul • Leader formal

Informaţional

• Supervizor • Difuzor • Leader de opinie

Decizional

• Antreprenor • Gestiune conflict • Alocare resurse • Negociere

Figura 5.3.b Rolurile managementului

SIE (Sisteme informaţionale executive) Sunt sisteme informaţionale care combină multe dintre însuşirile SIM şi SAD. Atunci

când au fost dezvoltate pentru prima dată, SIE au fost focalizate pe ideea de asigurare a managerilor de nivel top cu informaţii strategice. Astfel de sisteme trebuie să permită managerilor de top un acces rapid la informaţii despre factorii de succes critici din perspectiva îndeplinirii obiectivelor asumate de organizaţie.

Î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ă înţeleagă mai bine relaţia dintre informaţie şi management care, în alt plan este nimic altceva decât relaţia dintre informaţie şi putere. Închei aici “mica incursiune” în lumea managementului, invitând cititorul să-şi completeze cultura şi cu o serie de cunoştinţe care ar putea să facă lumină într-o zonă în care, altfel, poate bântui improvizaţia.

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. Esenţial şi la obiect despre MPS Aşadar, MPS este un caz particular de management de proiect, care la rândul lui este un

caz particular de management în genere. Prin urmare, putem defini MPS răspunzând la întrebările:

1. Ce activităţi desfăşoară managerii în industria softului? 2. Ce rol joacă managerii ca şi componente ale MPS? Răspunsul la aceste întrebări îmi cere să precizez următoarele: Activităţi desfăşurate/competenţe ale managerilor: -Planificarea (=stabilire obiective şi organizarea modului de îndeplinire a acestora); -Urmărirea evoluţiei proiectului prin măsurarea progreselor realizate în raport cu planul; -Efectuarea corecţiilor necesare pentru ca evoluţia proiectului să aibă o curbă ascendentă, în limitele planului stabilit; -Tratarea excepţiilor, adică efectuarea unor corecţii majore la planul de execuţie pentru a evita un posibil eşec al proiectului. Aceste tipuri de activităţi sunt desfăşurate la diferite nivele de management: -la nivel strategic (privesc întreaga firmă de dezvoltare a softului, pe o perioadă de câteva luni sau chiar mai mult); -la nivel de proiect (privesc derularea unui proiect, în acord cu termenele de execuţie asociate); -la nivel de echipă de proiectare (privesc o fază în dezvoltarea unui sistem soft); -la nivel individual (privesc desfăşurarea activităţilor la nivel individual de pe o zi pe alta).

Aspectele fundamentale pe care se structurează aceste activităţi sunt: ����resursele; este vorba, în principal, de utilizarea celei mai importante resurse în IS, timpul de lucru al specialiştilor 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 urmărite din acest punct de vedere şi care sunt modalităţile de îndeplinire a acestor obiective. ����riscurile; este vorba de apariţia unor situaţii care pot afecta evoluţia corectă a proiectului; din punctul de vedere al managementului, problema este: -cum pot fi identificate aceste situaţii? şi -cum pot fi prevenite aceste situaţii? ����Dezvoltarea sistemelor soft foloseşte intens capacităţile explicative şi de reprezentare ale modelelor: -diferite modele pentru structura şi proprietăţile produselor realizate în timpul dezvoltării sistemului soft;

-diferite modele pentru structura şi proprietăţile 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 relaţii între componente. Modelele calitative pot admite mai multe tipuri de reprezentări (de tip diagramă – cazul

UML, matematizate – grafuri sau arborescenţe, formale – codul sursă într-un limbaj de programare). Sunt posibile, dacă se plăteşte tributul necesar rigorii, transformări de la o reprezentare la alta, dacă acest lucru este în beneficiul evoluţiei spre succes a proiectului.

Modelele cantitative îşi propun cuantificarea atributelor măsurabile ale produselor sau

proceselor, precum şi a interacţiunilor dintre acestea. Efectiv, aceste modele se reduc la diferite tipuri de ecuaţii matematice.

În managementul proiectelor, modelele calitative sunt folosite pentru a descrie: -cum este compus procesul de dezvoltare din activităţi; -ce documente produce un proces şi ce documente sunt necesare pentru a desfăşura un proces; -cum se constituie într-o fază activităţile care cooperează pentru a produce un produs livrabil către un anume tip de client;

-cum se înlănţuie 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 măsoară 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 derulării proiectului pentru a menţine un trend favorabil îndeplinirii obiectivelor proiectului. Putem aborda acum şi subiectul numit în MPS “Planificarea iniţială 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 planificării iniţiale. Abordarea corectă a acestui subiect presupune:

10 Stabilirea obiectivelor Obiectivul fundamental al unui proiect de dezvoltare a softului este realizarea unui

sistem care corespunde cel puţin cerinţelor clienţilor. Spun “cel puţin clienţilor” (care corespund, după cum am văzut în Capitolul 1, factorilor

externi ai calităţii unui sistem soft şi nu numai) deoarece există şi cerinţe faţă de sistemele soft care ţin de exigenţele de natură internă, asumate de specialiştii IS în procesul de modelare.

În mod uzual, obiectivul fundamental descris mai sus are trei subobiective importante: • obiective sistem – ce servicii aşteaptă clientul de la sistem astfel încât să rezulte şi nişte

beneficii; • costurile asociate dezvoltării şi folosirii sistemului soft; • efectele secundare ale utilizării 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

următoarea: de multe ori clientul nu poate defini exact propriile lui cerinţe, ceea ce, mai devreme sau mai târziu, poate afecta proiectul.

De asemenea, la stabilirea obiectivelor nu trebuie uitat faptul că este dreptul clientului să aştepte beneficii din utilizarea sistemului soft care depăşesc costurile de dezvoltare şi utilizare.

20 Planificarea iniţială În acord cu cele spuse relativ la “stabilirea obiectivelor”, planificarea iniţială va încerca să

determine cât mai exact: -ce produse trebuie livrate clientului pentru a garanta îndeplinirea obiectivelor asumate; -ca urmare, ce activităţi sunt necesare; -în consecinţă, ce documente trebuie realizate în aceste activităţi; -în sfârşit, ce alte activităţi sunt necesare pentru a produce aceste documente.

Oriunde există dubii, acestea pot fi tratate în această etapă prin categorisirea articolelor (documente, activităţi, funcţii, etc.) ca fiind:

-imperative (aceste articole sunt neaparat necesare pentru întâmpinarea cerinţelor clientului); -de dorit (aceste articole ar putea fi foarte folositoare, dar este posibilă satisfacerea cerinţelor clientului şi fără producerea lor); -opţionale (aceste articole pot fi folositoare, dar, în mod sigur, este posibilă satisfacerea cerinţelor importante ale clientului fără ele. Rezultatul planului iniţial va fi o listă care cuprinde: -activităţile posibile; -documentele care vor fi livrate clientului; -documentele interne; -clasificarea acestora după importanţa 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 activităţii de factori aleatori pot provoca dereglări (incidente, disfuncţii) ale acestei activităţi.

Voi numi dereglare orice situaţie care poate apare în desfăşurarea unei activităţi şi care dacă nu este combătută de management poate aduce prejudicii desfăşurării activităţii conform planului.

Trivial, dar trebuie spus că orice dereglare are circumstanţe care o produc (=cauze) şi rezultate în caz de ignorare a dezvoltării dereglării (=efecte).

Evident, este de competenţa managerului să identifice cauzele dereglării pentru a acţiona asupra lor. Este cunoscut prostul exemplu dat de unii manageri care se luptă cu efectele deoarece înţelepciunea şi competenţa pe care o au nu îi ajută să obţină o reprezentare cât mai precisă asupra cauzelor dereglării.

Se numeşte risc în procesul de management orice dereglare care reprezintă o ameninţare la adresa îndeplinirii obiectivelor esenţiale ale unui proiect.

În IS, obiectivele esenţiale ale unui proiect pot fi: cerinţele faţă de sistem, costurile

estimate ale întregului ciclu de viaţă, etc. În acest moment putem observa că, odată apărut un risc în procesul de management,

atunci acesta implică: -o dereglare a unei activităţi;

-probabilitatea ca dereglarea să apară (altfel spus, probabilitatea de manifestare a cauzelor apariţiei dereglării); -impactul pe care dereglarea îl va avea asupra succesului proiectului, dacă apare (cu alte cuvinte, măsura efectelor dereglării asupra activităţii). 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 dereglărilor asociate pot varia pe o scală valorică dată); deci sunt riscuri cu manifestare gradată după circumstanţele în care apare şi se dezvoltă o anumită dereglare. Motivul pentru care managementul unui proiect este pândit de riscuri are o explicaţie

foarte simplă: lipsa informaţiilor sau cunoştinţelor relativ la ceea ce urmează să se întâmple în evoluţia proiectului.

Altfel spus, în timpul dezvoltării unui proiect putem să ne confruntăm cu evenimente, practic, nepredictibile dar şi cu evenimente care pot fi puse pe seama lipsei de informare. Aşadar, putem vorbi despre evenimente incerte sau despre estimarea incertă a proprietăţilor evenimentelor.

Ca un exemplu, în IS este uzual ca specialiştii să vorbească astfel: -S-ar putea ca cerinţele 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 găsească pe piaţă un anume echipament, la preţul scontat. Toate aceste posibilităţi descriu nişte evenimente incerte. Tot aşa de bine, specialiştii IS se pot exprima astfel: -Nu ştim cât poate dura iniţierea utilizatorilor în folosirea sistemului soft; -Nu avem date despre performanţele echipamentului cutare. În ambele situaţii prezentate mai sus, datele există pe undeva dar nu au ajuns singure la

urechea celor interesaţi. 5.3.2.2. Identificarea riscurilor în IS Atât teoreticienii (care înainte de a ajunge teoreticieni au fost buni practicieni) cât şi

marea parte a practicienilor sunt conştienţi de numeroasele riscuri pe care le presupune dezvoltarea unui sistem soft.

În IS, am mai spus-o şi altundeva în carte, ne aflăm pe un teren minat. Bucuria de a izbuti în faţa unei provocări a proiectului poate fi uşor umbrită de o încercare

neaşteptată. Faptul că multe proiecte importante au eşuat datorită modului superficial în care au identificat şi cuantificat riscurile arată importanţa cunoaşterii acestor riscuri.

Cauze comune ale riscurilor în dezvoltarea sistemelor soft sunt: �cerinţele faţă de sistemul soft sunt neclare sau susceptibile de a fi modificate;

�utilizarea unor tehnologii noi fără a avea cunoştinţele şi deprinderile necesare; �dificultăţi în estimarea timpului de execuţie şi a altor resurse necesare; �dificultăţi în estimarea performanţelor sistemului; �încrederea oarbă în furnizorii de componente şi în posibilitatea de a termina proiectul cu indivizi cu abilităţi îndoielnice; �lipsa standardelor şi a unor reguli minimale de urmat în procesul de dezvoltare a softului. Încercând o clasificare a acestor cauze, oarecum, după originea lor, avem: Cauze care pot fi puse pe seama clientului -necunoaşterea cerinţelor proprii faţă de sistemul soft; -neimplicarea corectă şi efectivă în efortul de dezvoltare a proiectului; -necunoaşterea 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 schimbări majore. Cauze care pot fi puse pe seama tehnologiei folosite -aceasta nu furnizează facilităţile 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 implicaţi în proiect sunt insuficienţi; -echipamentele disponibile pentru proiect sunt insuficiente sau uzate moral. Cauze care pot fi puse pe seama echipei de dezvoltare -necunoaşterea tehnologiilor; -necunoaşterea metodologiei de dezvoltare; -incapacitatea de a rezolva probleme punctuale; -dependenţa exagerată de anumiţi 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ă:

-identificând riscurile şi clasificându-le; -descriind riscurile până la un nivel la care cauzele care le produc devin clare; -cuantificând riscurile (probabilitatea de apariţie şi mărimea impactului în caz de apariţie).

5.2.3.3. Reducerea riscului în MPS Evident că în faţa ameninţărilor de tot felul la adresa succesului unui proiect,

managementul trebuie să ia măsuri de reducere a riscului de manifestare a acestor ameninţări. 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ă desfăşoare o activitate metodică pentru reducerea riscurilor care pot prejudicia succesul proiectului.

Ce poate face managementul în acest scop? Câteva direcţii de acţiune ar putea să fie: �Obţinerea de informaţii pentru a diminua impactul necunoscutului asupra

şanselor de reuşită ale proiectului prin: -organizarea de experimente şi efectuarea de măsurători; -efectuarea de cercetări şi construirea de modele; -construirea şi evaluarea unor prototipuri, etc. �Încercarea de a preveni evoluţia riscurilor prin: -conştientizarea oamenilor-cheie ai proiectului asupra ameninţărilor la adresa proiectului; -proiectarea şi implementarea unor procedee de monitorizare a activităţilor; -perfecţionarea profesională a membrilor echipei. �Mandatarea către 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 atenţiei 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 funcţia de gestiune a riscurilor care pot ameninţa succesul unui proiect. Dacă managementul unui proiect înţelege rolul “conducerii preventive” printre ameninţările 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 înţeles, probabil, faptul că unul dintre rezultatele importante ale activităţii managementului în IS este reprezentat de planurile de dezvoltare.

Pentru reprezentarea acestor planuri se folosesc modele de tip reţea sau diagrame Gantt. Toate aceste tipuri de reprezentare urmăresc, în esenţă, acelaşi lucru: identificarea aspectelor critice ale planurilor de dezvoltare cu scopul de a focaliza atenţia 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 asistării 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 sfârşitul 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 reţea, fiind folosită intens în nenumărate proiecte. Istoricul CPA şi PERT arată că PERT este mai elaborată decât CPA. În esenţă, însă, ambele abordări folosesc pentru reprezentarea proiectelor concepte precum activităţile şi evenimentele.

Terminarea unei activităţi 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 activităţi care sunt direct dependente de terminarea activităţilor precedente. Deoarece pentru prezentarea ideilor de bază ale analizei de tip reţea mă voi limita la semantica CPA, voi mai spune că CPA se bazează pe analiza dependenţelor secvenţiale între activităţi şi foloseşte durata estimată pentru fiecare activitate cu scopul de a deduce o estimare a duratei proiectului. De asemenea, CPA permite identificarea dependenţelor dintre activităţi care sunt critice pentru evoluţia proiectului.

Etapele care trebuie parcurse pentru a elabora o analiză CPA sunt prezentate mai jos. Etapa 1 Tabelarea tuturor activităţilor şi reperelor proiectului Această etapă presupune întocmirea de tabele care conţin informaţii similare celor

prezentate în Figura 5.4.

Activitate Descriere Reper Activităţi

precedente Durata

estimată Personal necesar

A Interviuri utilizator 2 – 5 u.t. 2 B Pregătire 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 relaţiilor

dintre clase 8 F 4 u.t. 3

H Schiţare 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 activităţi în IS

Etapa 2 Determinarea dependenţelor dintre activităţi Anumite activităţi nu pot începe până când altele nu s-au terminat. Predecesorii activităţilor sunt reprezentaţi î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 fiecărei activităţi Pentru rezolvarea acestei probleme există mai multe abordări datorită elementelor incerte

implicate în estimarea duratei activităţilor. Una dintre cele mai mult folosite formule este:

6

)*4( MPTMLTMOTED

++=

unde: -ED – este durata estimată a activităţii (Expected Duration); -MOT – este aprecierea cea mai optimistă asupra duratei activităţii (Most Optimistic Time); -MLT – este aprecierea cea mai probabilă asupra duratei activităţii (Most Likely Time); -MPT – este aprecierea cea mai pesimistă asupra duratei activităţii (Most Pessimistic Time). Odată calculată durata estimată a unei activităţi, aceasta este trecută în coloana 5 a unui

tabel asemănător celui din Figura 5.4. Etapa 4 Elaborarea diagramelor CPA Există două stiluri principale de notaţii utilizate în elaborarea diagramelor CPA,

desemnate prin “activităţi în nod” sau “activităţi pe muchii”. Amândouă tipurile de notaţii folosesc acelaşi tip de informaţii deşi arată diferit. În cele ce

urmează voi adopta soluţia “activităţi pe muchii”. În această variantă fiecare reper este reprezentat printr-un cerc cu trei compartimente.

Un compartiment este etichetat cu numărul reperului iar celelalte două vor indica termenul cel mai devreme de începere a activităţii (TDI), şi, respectiv, termenul cel mai întârziat de începere a activităţii (TII). Ilustrăm cele spuse în Figura 5.5.

11

15 7

18

24 8

D 7

Număr reper Termenul cel mai devreme de începere pentru activitatea D

Termenul cel mai întârziat de începere pentru activitatea D

Durată activitate

Etichetă activitate

Figura 5.5. Exemple de notaţie CPA

Diagrama CPA, parţial completată, relativ la datele indicate în Figura 5.4. este prezentată în Figura 5.6.

Voi face câteva observaţii relativ la Figura 5.6. Mai întâi, acolo unde apar săgeţi punctate spunem că avem activităţi fictive, a căror durată este 0. Astfel de activităţi fictive sunt dictate de raţiuni de tipul:

�Conform datelor din Figura 5.4. activităţile G şi H depind de terminarea activităţii 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 acelaşi timp, fiecare activitate are nevoie de reper separat.

Figura 5.6. Diagrama CPA parţial completată pentru un exemplu din Figura 5.4. Practic, activitatea fictivă în discuţie face legătura 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 foloseşte procedeul mersului

înainte prin diagramă, de la reperul considerat de start până la reperul final şi completarea cu date astfel:

1) TDI pentru reperul de start, în mod convenţional este 0. 2) Pentru reperele care au un singur predecesor valoarea TDI se obţine prin însumarea la

valoarea TDI a predecesorului, a duratei estimate a activităţii acestor repere; 3) Pentru reperele care au mai mulţi predecesori valoarea TDI se obţine prin însumarea la

valoarea TDI cea mai mare (din lista valorilor TDI ale predecesorilor) a duratei estimate a activităţii asociate alegerii respective. 4) Evident, înainte de a calcula valoarea TDI pentru un reper, valorile TDI pentru toţi

predecesorii trebuie să fie deja calculate. Urmând o astfel de procedură s-au obţinut valorile TDI în diagrama CPA din Figura 5.6. Pentru completarea cu date de tip TII a diagramei CPA se foloseşte procedeul mersului

înapoi prin diagramă, de la reperul considerat final până la reperul de start şi completarea cu date astfel:

1) TII pentru reperul final este considerat, convenţional, 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 obţine scăzând din valoarea TII a succesorului (deja calculată) durata activităţii corespunzătoare; 3) Pentru reperele care au mai mulţi succesori se fac toate diferenţele dintre TII ale

succesorilor şi duratele activităţilor asociate, alegându-se ca valoare pentru TII ale reperelor în cauză, diferenţa cea mai mică; 4) Din nou se presupune că, ajungând să calculăm valoarea TII a unui reper, toţi succesorii

au fost deja examinaţi. 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 aşteptare al reperelor ca diferenţă dintre TDI şi TII. Această diferenţă reprezintă timpul cu care o activitate poate fi întârziată fără a provoca probleme de încadrare în grafic celorlaltelor activităţi ale proiectului.

O succesiune de repere pentru care diferenţele între TDI şi TII sunt 0 se numeşte drum critic. În Figura 5.7. activităţile care aparţin unui drum critic au muchiile marcate cu o bară verticală dublă. Drumurile critice reţin, în mod deosebit atenţia managementului unui proiect, datorită faptului că orice întârziere pe o traiectorie critică poate afecta evoluţia 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 eşalonării în timp a activităţilor unui proiect.

Tehnica foloseşte barele orizontale pentru a reprezenta activităţile proiectelor. Într-o astfel de diagramă axa orizontală reprezintă timpul, fiind etichetată cu repere de tip unităţi de timp (ore, zile, săptămâni) făcând mai uşoară urmărirea evoluţiei proiectului în timp. Activităţile sunt aşezate pe verticală, imediat în stânga diagramei, de sus în jos. Lungimea barei asociate fiecărei activităţi în diagramă este proporţională cu durata activităţii.

Să mai adăugăm faptul că diagramele Gantt arată în mod foarte sugestiv care sunt timpii de aşteptare asociaţi activităţiilor şi pot, de asemenea, da informaţii cu privire la alocarea în timp a resursei personal. Prezentăm 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 precizări asupra problemei reprezentării planurilor de dezvoltare a sistemelor soft MPS are nevoie de o logistică de calitate pentru a monitoriza evoluţia activităţilor unui

proiect din mai multe considerente, dintre care voi enumera câteva în continuare: 1.Prin utilizarea tehnicilor de reprezentare de tip CPA sau diagrame Gantt (DG) funcţia

de control a managemenrului are o foarte solidă fundamentare metodologică. Se elimină controlul “după ureche” sau “bazat pe intuiţia 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 măsuri 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ă influenţează hotărîtor costurile unui proiect.

5.Utilitatea acestor tehnici depinde de acurateţea instrumentelor cu ajutorul cărora se stabilesc duratele activităţilor şi necesarul de personal pe activitate.

Aceste elemente se obţin cu ajutorul altor tehnici (metrici), a căror importanţă o subliniez, dar informez cititorul că în această carte nu voi dezvolta acest subiect.

ZILE

4

3

3

3

2

2

3

3

Număr angajaţi

Activităţi

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

Număr de angajaţi

Figura 5.8. Diagramă Gantt a activităţilor şi pentru alocarea angajaţilor pe activităţile proiectului

Voi atrage, totuşi, atenţia cititorului că este vorba despre metode de estimare a mărimii proiectelor (gen COCOMO), încă controversate, deci încă insuficiente din punct de vedere al obiectivităţii ştiinţifice.

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

…Fără aplicaţii orice teorie moare repede. Fără exemple de aplicare orice paradigmă rămâne o vorbă goală. Deşi î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 cărţii, o serie de elemente preluate după Object Modelling Technique (OMT) în contextul unei probleme pretext. Complexitatea problemei puse în discuţie nu este devastatoare; adevărul este că nici nu caut aşa ceva în această carte. Problema are, însă, destule elemente care necesită din partea celui care le abordează reflecţie , metodă şi spirit creator, înainte de a se repezi la tastatură, cum au obiceiul mulţi dintre softiştii zilelor noastre.

\

6.1 Intenţiile acestui capitol Pentru specialistul în IS aflat în faţa unei probleme întrebarea cea mai importantă rămâne :

"Cum se poate abstractiza enunţul respectivei probleme astfel încât soluţia obţinută să aibă măcar o parte din însuşirile unui sistem soft de calitate?".

Atrag atenţia cititorului că nu vreau să minimalizez cu nimic rolul celorlaltor pârghii 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) soluţiei unui sistem soft este un exerciţiu de maximă seriozitate care, eventual, poate face obiectul altei cărţi.

De aceea, soluţia problemei-pretext pe care o voi aborda în acest capitol va fi reprezentată folosind limbajul natural şi, eventual, reprezentări grafice uşor de înţeles sau care fac parte din categoria convenţiilor de reprezentare cunoscute de marea majoritate a specialiştilor în IS.

Să mai precizăm, în sfârşit, că problema este interesantă tipologic, fapt care, sper eu, va menţine trează atenţia cititorului.

6.2 Problemă pretext pentru modelarea orientată obiect Pledoaria acestui paragraf are două motivaţii: 10 Din ce în ce mai mulţi specialişti în IS ar vrea să adere la "religia OO" dar, mai întâi, trebuie ca cineva să-i convingă. Câştigarea de aderenţi autentici (nu formali) ai "religiei OO" înseamnă să faci din aceşti aderenţi practicanţi din convingere. Ştiu că nu este simplu, dar voi încerca. 20 Modelarea OO este o ocazie de a abstractiza de o manieră care poate sensibiliza şi încânta chiar şi pe specialiştii în IS recunoscuţi pentru îndârjirea cu care îşi apără vechile principii. Problema pretext asupra căreia mă opresc are următorul enunţ preliminar: Modelarea orientată obiect a unei stive generice

Odată cu mine, înţelege şi cititorul că, înainte de a trece la rezolvarea propriuzisă a

problemei, trebuie să desluşim, măcar î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 răspuns care să mulţumească pe toată

lumea. În IS, de exemplu, se vorbeşte despre orientare obiect în modelarea informaţiilor, 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 îngăduită exprimarea.

Mai întâi, îi voi reaminti cititorului că, indiferent dacă se află în domeniul problemei(DP) sau în domeniul soluţiei (DS), specialistul în IS se confruntă, în esenţă, cu două tipuri de probleme:

�organizarea datelor; �organizarea prelucrărilor.

Din perspectivă clasică, pentru rezolvarea acestor două probleme există modele şi metode de abordare specifice. Aşa se face că vor exista modele de organizare a datelor (relaţional, reţea, ierarhic, fişiere clasice) şi metode de organizare a prelucrărilor (orientate pe funcţii, 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 obţinere a soluţiei tehnice a unei probleme Obiecţia fundamentală adusă paradigmei ilustrată de Figura 6.1 se referă la sensibilitatea

deosebită a soluţiei tehnice în faţa modificărilor de orice tip. Originea acestei sensibilităţi se află în autonomia relativă a celor două modele, benefică pentru dezvoltarea separată, de calitate, a modelelor, având în vedere o serie de cerinţe pe termen scurt faţă de soluţie ca întreg, dar generatoare, în mod natural, de dependenţe între modele, care nu favorizează continuitatea modulară, extensibilitatea, portabilitatea, reutilizabilitatea, aspecte ale calităţii unui sistem soft relevante pe termen lung.

Foarte sintetic spus domeniul problemei se mapează slab pe domeniul soluţiei. Atât din interiorul laboratoarelor IS cât şi din afara acestora s-a exercitat o presiune

permanentă pentru aşezarea pe baze noi a relaţie dintre date şi prelucrări. O variantă, validată practic ca eficientă, de reaşezare a relaţiei date-prelucrări o reprezintă modelarea orientată obiect.

Imperativul cheie al paradigmei OO pare a fi asigurarea unor condiţii naturale de mapare sporită a domeniului problemei pe domeniul soluţiei.

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 esenţial.

Aşa cum rezultă din Figura 6.2 modelarea OO a soluţiei unei probleme se face pe trei

nivele de abstractizare. Conceptele esenţiale (şi specifice) ale modelării OO se regăsesc la primul nivel de abstractizare, numit în majoritatea metodologiilor OO modelul claselor. Să mai semnalez cititorului că suportul pentru maparea DP pe DS se regăseşte, în principal, la primele două nivele de abstractizare.

Problema Determinare cerinţe faţă de sistemul soft

Modelul datelor

Modelul prelucrărilor

Soluţia tehnică

Figura 6.2 Maniera OO de obţinere a soluţie tehnice a unei probleme Concepte fundamentale în elaborarea modelului claselor Am afirmat în mai multe rânduri faptul că sistemele reale care suportă un proces de

modelare informaţională reprezintă punctul de plecare în demersul de dezvoltare a unui sistem soft care deserveşte un anumit sistem real.

Obiectele care populează sistemul real şi sunt importante din punct de vedere al cerinţelor formulate faţă de sistemul soft pot fi caracterizate informaţional şi comportamental. În limbaj IS se spune că un obiect din lumea reală poate fi abstractizat de o listă de atribute informaţionale şi de o listă de atribute comportamentale.

Conceptul de clasă Toate obiectele care sunt abstractizate de aceeaşi listă de atribute informaţionale şi de aceeaşi listă de atribute comportamentale formează o clasă. Punând în valoare afirmaţia de mai sus este evident că obiectele care populează sistemul

real sunt partiţionate în funcţie de raportarea lor la o anumită listă de atribute informaţionale şi comportamentale.

Paradigma OO merge mai departe şi afirmă că a defini o clasă în spirit OO înseamnă: 10 A stabili lista de atribute informaţionale (necesare şi suficiente atât din punct de

vedere al logicii interne a obiectelor abstractizate de această clasă cât şi din punct de vedere al cerinţelor de reprezentare a relaţiilor cu obiecte având alte clase definitoare).

20 A declara această listă ca fiind privată(=ascunsă) faţă de clienţii clasei. 30 A stabili lista de atribute comportamentale (necesare şi suficiente atât din punct de

vedere al logicii interne a obiectelor abstractizate de această clasă cât şi din punct de vedere al solicitărilor formulate de către obiecte având alte clase definitoare).

40 Declararea ca publice a acelor atribute comportamentale care abstractizează mulţimea serviciilor adresate obiectelor având alte clase definitoare (mulţimea acestor atribute se numeşte interfaţă).

Aplicarea consecventă a conceptului de clasă astfel formulat înseamnă, în paradigma OO,

promovarea sistematică a principiului încapsulării.

Problema

Determinare cerinţe faţă de sistemul soft

Abstractizarea soluţiei ca o colecţie de clase, interconectate (asocieri, generalizări, agregări)

Abstractizarea structurii de control a fiecărei clase

Abstractizarea transformărilor suportate de fluxurile de date

După cum se poate deduce, încapsularea are două obiective precise: �abstractizarea similarităţilor informaţionale şi comportamentale ale unei colecţii de obiecte; �abstractizarea serviciilor oferite clienţilor de către obiectele din colecţia menţionată mai sus. Conceptul de obiect În paradigma OO se numeşte 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 informaţionale; �mulţimea atributelor comportamentale partajate împreună cu alte obiecte având aceeaşi clasă definitoare. Din punct de vedere al identităţii, un obiect are o identiate fizică, asigurată de sistemul

care monitorizează procesul de declarare a obiectelor, cât şi o identitate logică, datorată protocoalelor pe baza cărora, pentru fiecare obiect cu identitate fizică, recunoscută, se atribuie nişte valori atributelor informaţionale aferente.

Conceptul de atribut informaţional În modelarea OO există deja consens în ceea ce priveşte sintaxa de principiu şi semantica

unui atribut informaţional, în sensul că un atribut informaţional se specifică prin: <nume_atribut_informaţional> : <tip>[=<Valoare_implicită>] Aşadar, orice atribut informaţional are nume, tip şi, eventual, valoare implicită.

Semantica atributului informaţional depinde, evident, de contextul în care acesta este utilizat. Operaţii şi metode Descrierea comportamentului obiectelor unei clase este realizată, la cel mai înalt nivel de

abstractizare de operaţii. Există un consens relativ şi în ceea ce priveşte specificarea unei operaţii în modelarea OO.

Sintaxa de specificare a unei operaţii este, în general: [<Tip_returnat>] <Nume_operaţie>([<Lista_de_parametri>]) Aşadar, o operaţie 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 conştient de faptul că, specificând o operaţie (nu implementând-o), descriem, practic, utilitatea acestei operaţii şi modul de folosire a acesteia.

În această fază a expunerii este cazul să pregătesc cititorul pentru noi dezvăluiri în ceea ce

priveşte potenţialul modelării OO. Din nenumărate motive (nevoia de rafinare treptată a soluţiei, nevoia de reutilizare a

efortului de modelare, nevoia de specificare a unor contexte polimorfice) soluţia orientată obiect a unei probleme poate fi rezultatul unor eforturi de abstractizare care se desfăşoară pe trei direcţii:

�pe orizontală, obţinându-se clase având aproximativ acelaşi nivel de abstractizare şi structuri informaţionale şi comportamentale dizjuncte;

�pe verticală, obţinându-se lanţuri de derivare, prin intermediul cărora se gestionează similarităţile partajate de clase;

�în adâncime, obţinându-se, dacă este cazul, alternative (replici) la o soluţie dată. Deşi, formulată ca idee şi încă nefolosită, abstractizarea în adâncime, cu un suport adecvat la nivelul limbajelor de programare ar putea constitui soluţia sistematică pentru o problemă mai veche :problema polimorfismului de nivel sistemic.

Revenind la ideea abstractizării OO pe verticală (deoarece problema de care ne vom ocupa

va fi abordată din această perspectivă), voi prezenta, cu intenţia de a comenta, situaţia din Figura 6.3.

Figura 6.3 O ierarhie de clase Figura 6.3 ne sugerează următoarele: 10 Clasa referită cu 1 abstractizează similarităţile provenind de la cele două lanţuri de

derivare. Abstractizarea, după cum spune şi psihologia gândirii, este o operaţie tipică de generalizare. De aceea, în procesul de abstractizare pe verticală, o relaţie posibilă între clase este relaţia de generalizare (privită de jos în sus) sau relaţia de derivare (spacializare) dacă privim de sus în jos. Conform Figurii 6.3 clasa referită de 2 generalizează clasa referită de 4 şi în acelaşi timp specializează clasa referită de 1, într-o anumită direcţie. Cititorul este invitat să dea dovadă de multă răbdare din punct de vedere al apetitului pentru comunicarea ideilor în modelarea OO. Există un exces de limbaj, în mare parte scuzat de dorinţa celor care comunică, de a surprinde noi faţete ale unui fenomen atât de complex cum este modelarea OO. Ca un exemplu, într-un lanţ de derivare, o clasă care generalizează se numeşte superclasă, clasă de bază sau clasă părinte iar o clasă care specializează se numeşte clasă derivată, clasă moştenitoare sau clasă urmaş. Oarecum îngrijorat de amploarea pe care o ia această "scurtă prezentare" a fenomenului OO, trebuie totuşi să mai adaug că specializarea se poate realiza în două moduri:

� prin adăugarea de noi atribute; �prin redefinirea unor atribute comportamentale.

A

A B

A C

A B D

1

2 3

4

Atunci când este prezent fenomenul de redefinire a atributelor comportamentale, versiunea unui atribut comportamental la nivelul clasei rădăcină se numeşte operaţie, versiunile situate în clasele derivate direct sau indirect din clasa rădăcină se numesc metode.

Paradigma OO abstractizează eforturile de gestiune a similarităţilor în relaţiile dintre clase ridicând la rang de principiu ideea de moştenire. Pentru cititorul atent moştenirea reprezintă o poartă larg deschisă către utilizarea efortului de dezvoltare, dacă principiul moştenirii este judicios aplicat şi în deplin respect faţă de încapsularea OO.

Evident că, cititorul curios va dori să afle şi ce alte tipuri de relaţii se mai pot concepe între clase. Îi voi spune că aceste relaţii mai pot fi: de asociere, de agregare, de asociere ca şi clase, etc.). Tot cititorului curios îi voi mai spune că modelarea OO mai susţine fervent încă un principiu important, principiul polimorfismului, a cărui înţelegere este, parţial, condiţionată de înţelegerea conceptului de mesaj.

Conceptul de mesaj În modelarea OO se numeşte mesaj apelul unei metode a unui obiect, formulat de către

un client al obiectului respectiv. Evidente sunt următoarele două lucruri: �orice mesaj trebuie să primească un răspuns; �obiectele comunică între ele cu ajutorul mesajelor. Acum suntem în măsură să spunem că, în condiţii tehnice dependente de limbajul de

programare un mesaj având aceeaşi structură sintactică poate primi răspunsuri diferite, în funcţie de contextul în care s-a creat obiectul care este destinatar al mesajului. O operaţie care se poate comporta astfel se numeşte operaţie polimorfică.

Nu-i rămâne cititorului decât dorinţa de a alege o paradigmă OO pentru a se familiariza cu toate exigenţele ei în ceea ce priveşte: notaţia 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 operaţiile de

inserare şi extragere a elementelor sunt restricţionate în sensul că: 10 Operaţia de inserare (numită şi PUSH în majoritatea implementărilor) 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ă vârf sau top. Dacă stiva este vidă, atunci vârful stivei (care are o valoare specială ) este actualizat astfel încât să refere elementul introdus. De remarcat că la inserarea unui element în stivă putem avea depăşire superioară, în situaţia în care capacitatea predefinită a stivei este saturată. 20 Operaţia de extragere (numită şi POP în majoritatea implementărilor) se referă la elementul din vârful stivei, dacă acesta există. În urma unei operaţii de extragere, vârful stivei este actualizat. De remarcat, de asemenea, că în situaţia în care se forţează o extragere de element dintr-o stivă vidă, spunem că avem depăşire inferioară.

Exprimându-ne în limbaj OO, operaţiile obligatorii pentru o stivă sunt operaţiile PUSH() şi POP(). Evident, când modelăm comportamentul unei stive, ne pot fi de folos şi alte operaţii a căror natură depinde de contextul în care este folosită stiva. Exemple de astfel de alte operaţii voi prezenta în propunerea de soluţie la această problemă.

Stiva pe care vrem s-o modelăm trebuie să fie generică Cititorul a înţeles, probabil, că o structură de date este un tip de dată structurat, prin

urmare este viabilă în momentul în care cunoaştem, 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 aşa fel încât să permită

aplicarea aceloraşi operaţii asupra unor tipuri diferite de date Dacă la cerinţa genericităţii adăugăm şi cerinţa de a putea avea drept suport pentru

păstrarea stivei memoria RAM sau o specie adecvată de memorie externă, problema începe să-şi contureze un enunţ consistent.

Sunt în măsură (poate cititorului o să i se pară prea devreme, dar mă va înţelege după ce va aborda singur o astfel de problemă) să formulez următoarele cerinţe faţă de sistemul soft pe care vreau să-l dezvolt:

10 Codul rezultat trebuie gândit astfel încât să poată fi partajat de orice client

(programator) interesat; 20 Fiecare client să poată opera cu un tip de dată propriu; 30 Fiecare client să poată opta pentru suportul adecvat pentru stivă (RAM sau memorie

externă); 40 Protocolul de lucru cu stiva să fie cât mai simplu; 50 Se vor avea, pe cât posibil, în vedere, cerinţe precum: structurarea, modularizarea,

orientarea pe obiect, lizibilitatea, documentarea, etc. Ultimele două cerinţe se referă, evident, la cod. Inventarul faptic al enunţului problemei în cauză, împreună cu cerinţele mai sus formulate

ne îngăduie să evidenţiem, din perspectivă orientare-obiect, următoarele clase candidate (Figura 6.4).

Figura 6.4 Clase candidate la soluţia OO a problemei Este clar că aceste clase prezintă similarităţi de comportament. Intenţia în acest moment

este de a schiţa soluţia problemei ca o ierarhie de clase, având aliura din Figura 6.5.

Stiva_RAM

Stiva_M_Externă

Figura 6.5 Ierarhia de clase asociată soluţiei problemei

După cum se vede, s-a introdus o clasă abstractă (TAbsStiva) a cărei menire este de a colecta similarităţile venind pe cele două ramuri:

Ramura din stânga TRamStiva �modelează stiva RAM �se derivează din TAbsStiva TVideoStiva

�modelează stiva utilizând ca sursă de date pentru stivă memoria video în mode text; �se derivează din TRamStiva

Ramura din dreapta TMVStiva �modelează stiva păstrată 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 treacăt 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 prezentăm, în extenso, definiţiile claselor (rezultate în urma unui proces de abstractizare-încapsulare uşor 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 definiţia clasei TabsStiva, toate operaţiile fac parte din interfaţă,

nefiind declarate ca private. De asemenea, cititorilor care au încercat gustul programării OO în Pascal, C++ sai Java

trebuie să le atrag atenţia asupra operaţiilor speciale (marcate cu asterisc) , Init (constructor de clasă) şi Done (destructor de clasă), operaţii care joacă un rol important în alocarea dinamică a memoriei pentru obiecte, iniţializarea lor şi a tabelelor cu metode virtuale în caz că este cazul.

Să mai adăugăm faptul că unele operaţii ale clasei sunt urmate de clauza virtual ceea ce atrage atenţia asupra intenţiei redefinirii acestor operaţii în descendenţi.

Se observă că atributele informaţionale care au putut fi incluse în lista de atribute informaţionale a clasei TAbsStiva sunt:

-Lungime_Element; un întreg pozitiv care va păstra lungimea în octeţi a elementului stivei; -Numar_curent_de_elemente; un întreg pozitiv care păstrează numărul de elemente din stivă; la crearea unei instanţe valoarea este 0. -Eroare_de_alocare_memorie: camp boolean care ajută la monitorizarea erorilor de alocare. Invit cititorul la refelecţie pe tema implicaţiilor pe care le are genericitatea asupra

procesului de modelare şi, în final să urmărească 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_fişier_asociat stivei :şir de caractere atribute private Hfişier :Handle de fişier *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ă" intenţiile de proiectare prezentate

mai sus voi mai adăuga o serie de observaţii de interes pentru cititor. 10 Utilizatorul ierarhiei de clase poate beneficia de comportamentul polimorfic al întregii

ierarhii. Singura lui obligaţie este să facă joncţiunea cu codul aferent ierarhiei, în programul client.

20 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 comparaţie cu prelucrările asumate în ierarhie.

30 Utilizatorul ierarhiei beneficiază, totodată şi de facilităţile oferite de ierarhie penru depistarea posibilelor erori. Evident, tratarea unei erori este de competenţa clientului.

40 Alegerea limbajului este o sarcină relativ comodă pentru problema noastră. Am ales limbajul Pascal pentru a mă face mai uşor înţeles. În realitate această alegere înseamnă că mi-am pus codul obţinut la dispoziţia comunităţii programatorilor de Pascal şi, eventual, Delphi. Cunoscătorii de C++ ştiu, însă, că suportul oferit de C++ pentru programare OO şi programarea în genere este mult mai interesant.

În sfârşit, despre semantica ierarhiei, cel mai mult ne vorbeşte codul Pascal, încapsulat

într-un unit, pe care îl prezint în continuare.

6.2.3 Implementarea modelului Cititorul are la dispoziţie în acest paragraf unit-ul Pascal care încapsulează toate

specificaţiile convenite în paragraful 6.2.2 precum şi o mică aplicaţie care foloseşte una dintre capabilităţile unit-ului. Artificiile Pascal folosite pentru a rezolva problema genericităţii pot fi uşor înţelese urmărind comentariile incluse în codul sursă şi având cunoştinţe elementare de lucru cu structurile dinamice în Pascal. Cititorul poate trage învăţăminte şi din analiza atentă a modului în care conceptele OO din modelare îşi gâsesc suport în Pascal, limbaj care s-a născut, iniţial cu alte scopuri decât promovarea principiilor OO.

unit StivaGen;

{

----------------------------------------------------

Unit-ul încapsulează soluţia orientată obiect pentru

stiva avand ca suport:

-Memoria RAM;

-Hard disc-ul;

Autor: Dorin Bocu

Ianuarie 2001

----------------------------------------------------

}

{

----------------------------------------------------

Interfaţa 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

{

----------------------------------------------------

Declaraţii 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 operaţii 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;

{

---------------------------------------------------

Funcţie utilizator care forţează sistemul să

returneze nil în caz de apel new sau getmem

nesoluţionat. Soluţie 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;

{

---------------------------------------------------

Secvenţa de initializare a unit-ului in care variabila

unitului SYSTEM HeapError este forţată la valoarea <adresa

functiei HeapErrorHandler> care

ar putea trata excepţiile la alocarea dinamică a memorie.

De asemenea se stabileşte 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 numărul 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 moştenit de la TRamStiva

---------------------------------------------------

}

S.Init(Screen_Bytes);

NumarEcran := 0;

{

---------------------------------------------------

Pregăteşte trei ecrane cu informaţii ş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 calităţii în cadrul unei firme

producătoare de soft

...Există oameni sau naţiuni pentru care teoria lucrului bine făcut poate fi un motiv de băşcălie individuală sau, de ce nu, naţională. Defecţiunea provine de la înţelegerea greşită a importanţei detaliilor (care nu necesită anvergură spirituală deosebită, ci comportament binevoitor) asupra chestiunilor paradigmatice (care sunt un prilej de etalare a profunzimii potenţelor intelectuale). Problema ar suna cam aşa: <Presupunând că suntem inteligenţi, cum putem dobândi înţelepciunea necesară pentru a folosi decent această inteligenţă?!>

(Extras din monologul pronunţat de autor, în surdină, cu prilejul unei călătorii, neaşteptate, într-un autoturism Mercedes)

7.1 Introducere Aşa cum am mai spus şi în Capitolul 1, este nevoie de soft de calitate, produs în timp util

şi la preţuri competitive, pentru a face faţă rigorilor supravieţuirii pe piaţa concurenţială. Expresia în timp util înseamnă respectarea termenelor convenite pentru livrarea produselor. Expresia la preţuri competitive înseamnă încadrarea proiectului în restricţiile bugetare convenite.

Este evident faptul că cele două cerinţe pot fi îndeplinite prin crearea tuturor condiţiilor pentru creşterea continuă a productivităţii muncii.

Preocuparea sistematică pentru creşterea productivităţii muncii poate, însă, intra în conflict cu cerinţa de a menţine calitatea la standarde înalte, dacă nu se studiază cu atenţie impactul oricărei inovaţii în procesul de dezvoltare, asupra calităţii.

Metoda clasică pentru a face faţă posibilelor conflicte dintre cele două cerinţe se bazează pe delegarea competenţelor în materie de calitate, către 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 calităţii

Mi se pare o abordare total depăşită în condiţiile actuale. Calitatea trebuie să fie, în esenţă, creaţia operativului.

Majoritatea mijloacelor de promovare efectivă a calităţii este concentrată în mâinile celor care lucrează nemijlocit la dezvoltarea softului (analişti, proiectanţi, programatori, etc). De aceea, alternativa corectă la Figura 7.1 mi se pare a fi cea prezentată în Figura 7.2.

Căteva consideraţii pe marginea strategiei schiţate în Figura 7.2, în cele ce urmează. �Activităţile în ingineria softului (IS) se deosebesc mult de activităţile din alte domenii

de activitate. În locul muşchilor se foloseşte mult gândirea. Rutina există, dar nu în prim plan, cum se întâmplă în alte industrii. În prim plan se află creativitatea specialistului în IS, care, în fiecare proiect este obligat să facă faţă la cerinţe noi, indiferent de faza în care se află dezvoltarea unui sistem soft. Pentru a se manifesta, creativitatea are nevoie de libertate de acţiune. Pentru a nu produce sub nivelul standardelor, creativitatea trebuie să se raporteze conştient la standarde.

Figura 7.2. Metoda propusă pentru managementul calităţii într-o firmă modernă de soft

�Factorii care determină calitatea în IS sunt din ce în ce mai sofisticat distribuiţi şi

articulaţi în câmpul de acţiune al unui specialist IS. Multe probleme din IS pot fi rezolvate optim prin alegerea tehnologiei (tehnologiilor) adecvate exigenţelor proiectului. Am vrut să subliniez, încă odată, faptul că asigurarea calităţii este o problemă de strategie, dacă discutăm despre principii de promovare a standardelor de calitate şi este o problemă de competenţa operativului, dacă discutăm despre mijloacele de operaţionalizare 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 competenţe, pentru asigurarea calităţii, către nivelul...

Operativ

Dacă se doreşte, neapărat, implicarea managementului în rezolvarea problemelor de calitate (ceea ce este imperativ pentru o firmă care se respectă), abordarea ideală este următoarea: ���� Stabilirea principiilor fundamentale care trebuie respectate în procesul de dezvoltare a softului (la nivelul conducerii firmei); ����Convenirea mijloacelor de operaţionalizare a principiilor; aceste mijloace pot fi independente de proiect sau, dacă este cazul, dependente de proiect. Din perspectivă obiect orientată, situaţia se reprezintă ca în Figura 7.3. Făcând analogie cu o abordare clasică din ingineria softului, competenţele în materie de

asigurare a calităţii 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, repartizaţi pe proiecte)

Figura 7.3. Propunere de abordare, la nivel sistemic, a problemei calităţii într-o firmă de soft

�Managementul calităţii la nivelul conducerii firmei -Conceptualizarea factorilor generici care determină calitatea unui

sistem soft; -Conceptualizarea factorilor de calitate identificaţi de firmă; -Modalităţi de acţiune.

�Managementul calităţii la nivelul coordonatorilor de proiecte -Specificarea factorilor generici care determină calitatea unui sistem

soft; -Specificarea factorilor de calitate identificaţi de firmă; -Modalităţi de acţiune.

�Managementul calităţii la nivelul colectivelor de dezvoltare

(La nivelul conducerii firmei) Principii fundamentale în asigurarea calităţii

(La nivelul coordonatorilor de proiecte)

Mijloace de operaţionalizare a principiilor independente de proiect

(La nivelul colectivului de proiectare 1)

Mijloace de operaţionalizare specifice Proiect_1

(La nivelul colectivului de proiectare k)

Mijloace de operaţionalizare specifice Proiect_k

-Implementarea factorilor generici care determină calitatea unui sistem soft;

-Implementarea factorilor de calitate identificaţi de firmă; -Modalităţi de acţiune.

7..2 Idei pentru programul de asigurare a calităţii în cadrul unei firme oarecare de soft

7.2.1 Nivelul conceptual (Conducerea firmei) Ori de câte ori este nevoie, la acest nivel trebuie reflectat asupra următoarelor trei tipuri de

probleme:

-factori socotiţi, în genere, ca fiind importanţi pentru calitatea softului, pe care firma vrea să îi monitorizeze. Descrierea lor la nivel conceptual.

-factori identificaţi de conducerea firmei ca fiind importanţi pentru calitatea unui proiect anume. Descrierea lor la nivel conceptual.

-modalităţi de acţiune la nivel conceptual.

Observaţie Problema calităţii softului este condiderată în literatura de specialitate o problemă dificilă, deoarece enunţul ei se modifică odată cu tehnologiile folosite pentru dezvoltarea softului. Marea diversitate a abordărilor din punct de vedere tehnologic m-a determinat să propun cele două tipuri de factori ai calităţii, în vederea monitorizării.

����FACTORII GENERICI AI CALITĂŢII Literatura de specialitate distinge trei categorii de factori generici ai calităţii.

-factori care se referă la comportarea unui sistem soft după ce a fost dat în exploatare: -Corectitudinea; -Fiabilitatea; -Performanţa; -Eficienţa; -Securitatea.

-factori care se referă la comportarea unui sistem soft în cazul în care apar modificări: -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

Înţelesul dat la nivel conceptual acestor factori îl prezentăm, în reluare, pe scurt, în

continuare.

Corectitudinea se referă la abilitatea unui sistem soft de a executa toate sarcinile convenite

la specificarea cerinţelor.

Fiabilitatea se referă la capacitatea sistemului soft de a-şi conserva calitatea în timpul exploatării. În unele cărţi, fiabilitatea sistemelor soft se mai numeşte şi robusteţe în exploatare.

Performanţa se referă la modul în care sistemul soft, în format executabil, satisface cerinţele de performanţă convenite (timpii de răspuns la interogări, în medie sau minimali şi maximali, etc.).

Eficienţa se referă la abilitatea sistemului soft de a utiliza eficient posibilităţile maşinii fizice pe care acesta este executat.

Observaţie În condiţiile în care resursele hard critice ale sistemelor de calcul îşi îmbunătăţesc

permanent indicii de performanţă, s-ar părea că performanţa şi eficienţa nu mai sunt nişte priorităţi, potrivit opiniei unor specialişti. Opinia mea este că trebuie să monitorizăm, în continuare, aceşti factori deoarece, oricând pot ajuta un proiect să câştige bătălia 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 încercări de utilizare neautorizată.

Modularitatea este un atribut de importanţă majoră al oricărui sistem soft de complexitate medie şi mare. Modularitatea trebuie planificată şi urmărită judicios deoarece de realizarea ei în condiţii optime depinde esenţial disponibilitatea unei soluţii de a se adapta la condiţii noi de execuţie şi de a face faţă la cerinţe noi (reutilizabilitatea şi exetnsibilitatea). Modularizarea corectă este, practic, visul oricărui specialist în ingineria softului şi mai ales al oricărui programator iscusit. Practic, a modulariza corect înseamnă : arhitectură simplă a soluţiei + descentralizarea optimă a capabilităţilor acesteia.

Stilul de codificare şi documentare poate susţine sau compromite evoluţia unui sistem soft, atât în faza de proiect cât şi în perioada de utilizare efetctivă. Stabilirea unui set minimal de reguli şi elemente suport pentru activităţile de codificare şi documentare trebuie să fie o prioritate pe agenda celor care urmăresc calitatea softlui în cadrul firmei.

Portabilitatea soluţiei unui sistem soft “măsoară” capacitatea sistemului soft de a face

faţă, cu “eforturi” minimale, la exerciţii de migrare pe alte platforme hard şi de operare. În condiţiile în care varietatea arhitecturilor hard existente pe piaţă este în creştere 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 atenţie şi acest factor al calităţii.

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

����FACTORI DE CALITATE IDENTIFICAŢI DE FIRMĂ

<De studiat problema cu întregul “echipaj” al firmei>

����MODALITĂŢI DE ACŢIUNE LA NIVEL CONCEPTUAL.

S-ar putea sugera, de exemplu, următoarele direcţii de acţiune.

1. Pentru fiecare proiect se va alege procesul de dezvoltare cel mai adecvat. Putem, de exemplu adopta următoarea atitudine: “Mărimea ş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ă direcţie sugerăm o anumită constanţă a opţiunilor deoarece învăţarea unui limbaj de modelare este o problemă de timp şi de bani. Ultimele evoluţii în domeniu mă determină să sugerez utilizarea UML-ului, în combinaţie cu tools-uri carre îl promovează, precum: Rational Rose, ObjectiF, etc..

3. Evaluarea lunară a calităţii soluţiei unui proiect, indiferent de nivelul de abstractizare la care s-a ajuns.

7.2.2 Nivelul specificare (Coordonatorii de proiecte)

�Specificarea corectitudinii Atenţia coordonatorilor de proiecte se va focaliza pe:

-Completitudinea listei cerinţelor; -Claritatea formulării cerinţelor; -Identificarea relaţiilor dintre cerinţe; -Identificarea conflictelor dintre cerinţe si explorarea soluţiilor de

compromis.

�Specificarea performanţei Atenţia coordonatorilor de proiecte se va focaliza pe:

-completitudinea listei indicatorilor de performanţă; -Claritatea formulării indicatorilor de performanţă; -Identificarea relaţiilor dintre indicatori -Identificarea conflictelor dintre indicatori şi explorarea soluţiilor de

compromis.

�Specificarea eficienţei Atenţia coordonatorilor de proiecte se va focaliza pe:

-Selectarea indicatorilor de performanţă ai soluţiei, 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 fiabilităţii Atenţia şefilor de proiecte se va focaliza pe:

-Identificarea componentelor (interne şi externe sistemului soft) care pot afecta siguranţa în funcţionare a acestuia; -Stabilirea strategiei de asigurare a fiabilităţii 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, repartizaţi pe proiecte) La acest nivel se impun măsuri care să asigure un feed-back permanent pe traseul

calitatea la nivel conceptual�calitatea specificată�calitatea la nivel de operativ�calitatea la nivel conceptual.

Măsurile preconizate sunt de doua tipuri:

-punctuale; -anticipative.

�Măsurile punctuale Constituie un ansamblu de activităţi, convenite de management, pentru a verifica modul în

care se realizează transferul de competenţe în domeniul calităţii de la nivel de management spre nivelul operativ. Pentru ca aceste activităţi să se poată desfăşura corect este necesar să se accepte următoarele condiţii minimale:

-un proces de dezvoltare, care va permite implementarea feed-back-ului în domeniul calităţii;

-un limbaj de modelare şi reprezentare adecvat, ceea ce va facilita procesul de urmărire a calităţii.

�Măsurile anticipative Constituie ansamblul activităţilor de informare şi formare sistematică a tuturor

partenerilor unui proiect, în acord cu reponsabilităţile curente şi de perspectivă.

�Măsuri concrete pentru promovarea calităţii la nivel operativ

-Elaborarea riguroasă a documentaţiei sistemelor soft -documentaţie tehnică; -documentaţie de utilizare -documentaţie de prezentare

Persoana care răspunde de calitate va defini şabloanele pe baza cărora se vor elabora aceste tipuri de documentaţii. Şefii de proiecte vor furniza toate datele necesare pentru elaborarea documentaţiilor. Tools-ul folosit va fi ObjectiF, de exemplu.

-Planificarea riguroasă a procedurilor de testare (de urmărit paragraful 7.3 pentru mai multe detalii relativ la rolul testării în asigurarea calităţii softului)

-Încadrarea efortului de dezvoltare într-un model de dezvoltare convenabil; -Utilizarea, pentru elaborarea şi reprezentarea soluţiei, a unui limbaj de modelare adecvat

Pentru testare, practica recomandă combinarea tehnicilor top-down şi bottom-up. Ca model de dezvoltare, la mărimea şi natura aplicaţiilor de la firma de soft XXXXX

recomand prototipizarea. Ca limbaj de modelare propun UML-ul.

-Accentuarea preocupărilor pentru managementul proiectelor şi pe alte coordonate care influenţează 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 Consideraţii preliminare Activitatea de testare nu generează direct calitate, dar, planificată judicios, poate contribui la realizarea softului de calitate.

Una dintre formulările care au făcut carieră în dezbaterile pe tema calităţii softului

sună, sec, astfel: “Testarea completă a componentelor unui sistem soft poate fi considerată strategia de bază pentru asigurarea calităţii softului”.

În această secţiune a cărţii nu voi relua discuţia pe marginea factorilor care determină calitatea unui sistem soft. Este esenţial, însă, să constatăm că factori precum corectitudinea, robusteţea şi performanţa, evaluaţi cu superficialitate, pot compromite şansele de reuşită 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 proiectării.

De aici, al doilea principiu care ar trebui să fie încorporat obligatoriu în orice strategie de testare: “Procesul de testare a soluţiei unui sistem soft trebuie să înceapă, dacă se poate, încă din fazele timpurii ale proiectării”. Admiţând ca fiind, realmente posibilă, implementarea acestui ultim principiu, se pune întrebarea: “Cum trebuie organizat procesul de testare a soluţiei unui sistem soft de-a lungul diferitelor stadii de abstractizare prin care aceasta trece”. Întrebarea este destul de complicată, fie că o abordăm din perspectivă istorică, fie că încercăm să punem cap la cap ultimele idei relativ la topic.

Se cuvine să adăugăm o remarcă banală, de altfel: “Testarea nu este o activitate paralelă cu procesul de dezvoltare. Organizarea judicioasă a testării 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 cunostinţele absolut necesare pentru a organiza testarea soluţiei 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 aplicaţii este “capturat” cu ajutorul modelelor vizuale de la diferite nivele de abstractizare. În jurul acestor modele se pot dezvolta, ulterior, componente, a căror testare şi integrare progresivă este absolut naturală. Există, însă, o condiţie esenţială pentru ca lucrurile să meargă pe acest făgaş:

Soluţia trebuie dezvoltată orientat pe componente. Experienţa arată că dezvoltarea orientată pe componente asigură numeroase avantaje dezvoltatorilor (reutilizabilitate, fiabilitate, manevrabilitate în timpul testării) dar solicită o atenţie deosebită în timpul proiectării interfeţelor componentelor, în principal.

Se impune din ce în ce mai pregnant ideea că dezvoltarea softului trebuie să devină o

activitate în care improvizarea unei soluţii tinde să fie înlocuită, sistematic, cu un efort planificat de abstractizare şi verificare a soluţiei. În sprijinul unei astfel de atitudini poate veni accesul constant la noutăţile în materie de metode de abstractizare şi introducerea, pe

acest temei, a obişnuinţei de a utiliza instrumentele CASE pentru a optimiza diferitele tipuri de activităţi care contribuie la asigurarea calităţii soluţiei unui sistem soft.

Aşadar, problemele de calitate în ingineria softului sunt de natură sistemică şi, în consecinţă, necesită o abordare sistemică. Fiind o problemă al cărei enunţ are “geometrie variabilă”, problema calităţii va avea rezolvări nuanţate, în funcţie de: tipul proiectului, viziunea managementului asupra calităţii, tipul de proces utilizat în dezvoltare, metoda de abstractizare folosită,etc. .

Simplificând, în mod voluntar, lucrurile, calitatea soluţiei unui sistem soft poate fi asigurată dacă managementul proiectului a reuşit să specifice clar modul în care, pe parcursul dezvoltării se va verifica aderenţa soluţiei la factorii de calitate monitorizaţi.

Beneficiarul principal al unui soft de calitate este clientul. Din punctul lui de vedere calitatea înseamnă “regăsirea cerinţelor” şi “implementarea optimă a acestor cerinţe”.

Beneficiarul unui soft de calitate poate fi şi firma producătoare de soft, pentru care calitatea înseamnă tot ceea ce aşteaptă clientul plus cerinţe precum: adaptarea flexibilă la cerinţe noi, localizarea şocurilor provocate de modificări ale soluţiei, etc..

După acest scurt tur de orizont în problematica calităţii softului, este cazul să fixăm nişte idei concrete relativ la posibilitatea de a asigura efectiv calitatea într-un proces de dezvoltare.

7.3.2 Despre prototipizare, testare şi asigurarea calităţii Modelarea obiect orientată a soluţiei unui sistem soft permite integrarea unor metode

variate de asigurare a calităţii. Aşa 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ă evidenţiez virtuţile prototipizării în materie de asigurare a calităţii.

Reordonând 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 cerinţe faţă de sistemul soft. Acest tip de prototipizare poate fi folosit şi pentru a evalua(=testa) eventualele soluţii 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 soluţiei dezvoltate. Criteriile de calitate urmărite, în principal, sunt: performanţa şi ceea ce am putea numi, implementabilitatea în genere.

Ambele tipuri de prototipizare se desfăşoară, în principiu, după regulile evoluţiei iterative şi incrementale a seriilor de prototipuri către produsul complet.

Este evident faptul că, înainte de elaborarea fiecărui prototip este necesară formularea explicită şi documentarea atât a aspectelor referitoare la modificări sau extinderi cât şi a aspectelor referitoare la testarea prototipului.

Testarea trebuie organizată (ce date se folosesc, cum se obţin aceste date, ce strategie de testare folosim, admiţând că soluţia 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 urmărită, asigurarea calităţii trebuie să devină o preocupare permanentă, eventual susţinută 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 soluţiei unui proiect ar trebui să se structureze pe două tipuri fundamentale de activităţi: planificarea logică a testării şi planificarea calendaristică a testării. Ca un exemplu, planificarea logică a testării soluţiei unui proiect oarecare ar putea cuprinde: ����Testarea modulului XXXX

-Testare funcţionalitate; -verificarea corectitudinii specificării şi modelării cerinţelor; -verificarea eficienţei şi a performanţei; -verificarea integrităţii bazei de date în situaţia în care baza de date este utilizată în mod concurent;

-Testare robusteţe (=verificarea comportării modulului în situaţii anormale de utilizare);

-Testare protocoale de securitate(dacă este cazul); -Stress testing-ul (urmărirea implicaţiilor acestuia asupra corectitudinii şi performanţei);

����Testarea modulului YYYY

-Elaborare de aplicaţii pentru evaluarea funcţiilor modulului YYYY; ���� Testarea modului în care cooperează tehnologiile folosite la în cadrul aplicaţiei XXXX. ����Realizarea feed-back-ului între echipa de dezvoltare şi echipa de testare, respectiv, echipa de dezvoltare şi utilizatori.

În ceea ce priveşte planificarea calendaristică, aceasta va lua în calcul testarea care va fi efectuată de către programatori şi testarea care va fi efectuată de către 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 utilizând limbajul Pascal, Editura Albastră, 1999 [4] Bocu, D., Iniţiere în ingineria sistemelor soft, Editura Albastră, 2001 [5] Bocu, D., Iniţiere î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] O’Brien, J., A., Management Information Systems, Mc Grow-Hill Companies, 1996

[14] Oprea, D. , Analiza şi proiectarea sistemelor informaţionale 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 programării 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 programării obiectuale, Editura Albastră, 1996

Precizări cu privire la evaluarea pregătirii studenţilor La această disciplină evaluarea va consta în: 1. Verificarea cunoştinţelor teoretice acumulate, printr-o lucrare

scrisă, pentru care se acordă note de la 1 la 10. 2. Elaborarea unui proiect în cadrul activităţilor de laborator Fiecare proiect va conţine obligatoriu următoarele secţiuni: 1. Enunţul problemei. 2. Specificarea cerinţelor faţă de sistemul soft elaborat în cadrul proiectului. 3. Elemente de proiectarea soluţiei:

a) Diagrama claselor b) Interfeţe c) Funcţiile sistemului soft d) Consideraţii relativ la implementarea funcţiilor

4. Ghid de utilizarea a sistemului soft 5. Ghid de instalare a sistemului soft 6. Consideraţii relativ la stabilitatea / exetensibilitatea soluţiei

Prof. univ. dr. Dorin Bocu