Ingineria soft

105
Universitatea TRANSILVANIA din Braşov Facultatea de Matematică şi Informatică Catedra de Informatică Aplicată INGINERIA SOFTULUI Dorin Bocu

Transcript of Ingineria soft

Page 1: Ingineria soft

Universitatea TRANSILVANIA din BraşovFacultatea de Matematică şi InformaticăCatedra de Informatică Aplicată

INGINERIA SOFTULUI

Dorin Bocu

Page 2: Ingineria soft

Cuvânt înainte

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

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

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

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

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

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

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

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

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

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

Braşov30 septembrie 2008

Page 3: Ingineria soft

1 PROBLEME A CĂROR REZOLVARE DEPINDE ESENŢIAL DE INGINERIA SISTEMELOR SOFT

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

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

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

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

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

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

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

Care sunt, totuşi, acele activităţi specifice realizării sistemelor soft care cad sub incidenţa IS?Le putem rezuma astfel:10 Abstractizarea soluţiei unui sistem soft, prin care desemnăm demersul conceptual în urma căruia

specialistul în IS trece de la enunţul problemei la soluţia acesteia.20 Organizarea procesului de abstractizare (modelare) a soluţiei unui sistem soft. Îndeosebi în cazul

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

30 Reprezentarea soluţiei unui sistem soft de-a lungul întregului proces de modelare; documentarea completă a soluţiei sistemului soft.

Este vorba, în esenţă, de rezolvarea eficientă a unor probleme de comunicare între participanţii la realizarea unui sistem soft, precum şi de rezolvarea unor probleme de comunicare între realizatorii sistemului şi diferitele categorii de beneficiari ai sistemului soft.

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

Sloganul – cheie în IS ar trebui să fie: ”Cum se poate sistematiza ,eventual automatiza, procesul de realizare a unui sistem soft de calitate, ieftin şi obţinut în timp util?”.

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

de dezvoltare a softului (MDS).Istoria MDS este lungă şi destul de dificil de sintetizat fără a omite numeroase aspecte interesante. Firul

călăuzitor al acestei istorii ar putea fi, totuşi, definit astfel:

10 Fiecare metodologie doreşte să instaureze o anumită rigoare în procesul de elaborare a soluţiei unui sistem soft.

20 Fiecare metodologie se individualizează prin accentul pe care îl pune pe un anumit element definitor (unul sau mai multe concepte de bază, unul sau mai multe principii de bază, formalizmul de reprezentre, etc.).

30 Fiecare metodologie doreşte să ofere suport cât mai consistent pentru realizarea de sisteme soft de calitate.

Page 4: Ingineria soft

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

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

Firme/Persoane implicate în realizarea de sisteme soft

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

Laboratoare de cercetare

MDS nouă

Page 5: Ingineria soft

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.

Page 6: Ingineria soft

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 ISFamiliarizaţ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”

Page 7: Ingineria soft

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 ISNu este decât o confirmare a regulii faptul că IS este un univers ale cărui probleme sunt inventate,

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

Cele mai dificile probleme care pot apare în timpul realizării unui sistem soft sunt, totuşi, problemele care îşi au originea în ”laboratoarele IS” sau se reflectă în activitatea acestor “laboratoare”. Vom prezenta, în continuare, enunţul problemelor fundamentale pe care trebuie să le aibă în vedere orice specialist în IS.

Pentru nenumărate motive (dintre care, unele le vom prezenta în continuare) procesul de realizare a unui sistem soft trebuie sistematizat.

Această nevoie de sistematizare acoperă mai multe dimensiuni:concepţie, eşalonarea în timp, reprezentarea soluţiei, documentarea, conducerea proiectului, etc.

Sistematizarea înseamnă, în esenţă, introducerea de reguli de urmat pentru a asigura, teoretic, succesul unui proiect. Nevoia de sistematizare intră în conflict cu tendinţa multor specialişti în IS de a se exprima ignorând protocoalele, normele, regulile adoptate de colectivele din care fac parte.

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

Page 8: Ingineria soft

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.2Cele 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.3Schema 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

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

Page 9: Ingineria soft

Figura 1.3 Piramida managementului din perspectivă sistemică.

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

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

Este momentul să facem o scurtă incursiune în semantica deosebit de complexă a sintagmei “calitatea sistemelor soft”.

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

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

Calitatea sistemelor soft şi proprietăţile externeDintre 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.CorectitudineaEste abilitatea unui sistem soft de a executa toate sarcinile convenite cu utilizatorii şi beneficiarii în faza de

specificareCorectitudinea 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ţeaEste 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:

Page 10: Ingineria soft

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.

ExtensibilitateaEste abilitatea unui sistem soft de a se adapta uşor la modificări în faza de specificareProblema 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ăriiIdeea 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).

DescentralizareaDacă 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.

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

Page 11: Ingineria soft

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

PortabilitateaEste o măsură a uşurinţei cu care un sistem soft poate fi transferat pe diferite platforme hard şi medii de

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

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

Uşurinţa în folosireSe 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.

Page 12: Ingineria soft

2 CE ESTE O METODOLOGIE DE DEZVOLTARE A SOFTULUI?

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

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

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

Procedând astfel legitimăm o stare de lucruri întâlnită şi în alte domenii ale cunoaşterii.Structura discursului în IS este determinată atât de cerinţe epistemologice specifice cât şi de nevoia de organizare a diferitelor forme de manifestare a existentului în procesul de realizare a sistemelor soft.

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

de realizare a sistemelor soft.Trecerea de la enunţ la soluţie, în cazul problemelor de complexitate mijlocie sau mare (în care, de regulă,

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

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

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

Dacă s-a pus punct analizei informaţionale, trebuie să se treacă la elaborarea soluţiei tehnice (un fel de documentaţie constructivă a sistemului soft). Deşi elaborarea soluţiei tehnice înseamnă descrierea până la detaliu a componentelor sistemului soft şi a legăturilor dintre acestea, ceea ce înseamnă infuzie treptată de elemente concrete în soluţie, în paralel se desfăşoară şi activităţi cu pronunţat caracter de abstractizare (pentru a elimina redundanţele, pentru a optimiza prelucrările, pentru a optimiza legăturile dintre date, pentru a spori rezistenţa sistemului la modificări, etc.).De foarte multe ori se poate spune că obiectul analizei informaţionale ca şi obiectul activităţii de obţinere a soluţiei tehnice au afinităţi cu nisipurile mişcătoare. Ce-i de făcut? Trebuie multă răbdare şi abilitate pentru a sesiza invarianţii procesului ceea ce ar permite începerea efortului de modelare.

În situaţia în care “calvarul” obţinerii soluţiei tehnice a fost depăşit începe activitatea de transpunere a soluţiei tehnice în acord cu exigenţele de sintază, semantică şi pragmatică specifice unui limbaj de programare.

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

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

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

-studiul teoretic al proprietăţilor algoritmilor: formalizare a reprezentărilor; clasificarea algoritmilor;-studiul teoretic al unor metode generale de elaborare a algoritmilor (Backtracking, Greedy, Divide et Impera, Programarea dinamică);-elaborarea unor metode de programare (programarea structurată, programarea obiect-orientată);-elaborarea unor metode de analiză a sistemelor informaţionale (procedee de investigare, mod de reprezenatare, concepte utilizate, etc.);-elaborarea unor metode de elaborare a soluţiei tehnice (Top-down, HIPO, Warnierr-Orr, etc.);

-dezvoltarea unor elemente suport pentru specialiştii în IS (sisteme de documentare, generatoare de programe, medii de dezvoltare a soluţiei cu ajutorul calculatorului, etc.);

Page 13: Ingineria soft

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

Page 14: Ingineria soft

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

În format utilizator datele sunt organizate supralicitând redundanţa, prelucrările, fiind aplicate unor date în care “musteşte” redundanţa, nu sunt automat cea mai fericită alegere.

Tot atât de delicată este şi problema “organizării” interfeţelor deoarece în elaborarea acestora trebuie gestionată optim contradicţia dintre dorinţa de a oferi utilizatorului confort şi pornirea naturală a specialistului în IS de a raţionaliza interfaţa cu utilizatorul.

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

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

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

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

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

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

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

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

În ceea ce priveşte capacitatea unei MDS de a oferi suport pentru rezolvarea problemelor de tip OPA.

Oferta MDS privind rezolvarea problemelor de tip OPA este desemnată în literatura de specialitate prin sintagma ciclul de viaţă al sistemelor soft.

Ciclul de viaţă al sistemelor soft este, alături de ciclul de abstractizare, o caracteristică fundamentală a MDS. Este evident faptul că, la detaliu, fiecare MDS are propria propunere de ciclu de viaţă. Făcând abstracţie de metodologie, o primă perspectivă asupra semanticii noţiunii de ciclu de viaţă o obţinem în Figura 2.1.

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

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

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

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

Analiza

Analiza Proiectarea Implementarea Testarea

Etape de dezvoltare

Page 15: Ingineria soft

Este etapa în care se constată că este necesar un sistem soft şi se iau decizii în consecinţă. Fie că se constată existenţa unei pieţe pentru un produs de uz general, fie că o anumită organizaţie are

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

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

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

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

Fireşte, se pot pune întrebările: “Care sunt regulile care guvernează procesul de identificare şi reprezentare a cerinţelor faţă de sistemul soft?”

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

Răspunsul este simplu: metodologia oferă suport de tip ASS şi suport de tip RDS care se foloseşte în această etapă a ciclului de viaţă cât mai eficient cu putinţă.

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

ImplementareaEste 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.TestareaEste etapa strâns legată de etapa anterioară deoarece, în mod normal, fiecare modul al sistemului este testat

în timpul implementării.Într-un sistem bine proiectat (ceea ce ar face trimitere directă la o serie de posibili factori interni ai calităţii

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

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

Page 16: Ingineria soft

Î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).

Page 17: Ingineria soft

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.

Page 18: Ingineria soft

3 CICLUL DE VIAŢĂ AL UNUI SISTEM SOFT

3.1 Ciclul de viaţă al sistemelor soft. Încă o introducereSă 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. Câteva exemple.Schimbările care s-au produs, în timp, în ceea ce priveşte tehnologiile informaţionale şi MDS s-au reflectat

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

Un studiu comparativ al diferitelor exemple de MDS evidenţiază o serie de elemente interesante.Numărul fazelor ciclului de viaţă specific unei MDS poate varia de la trei (analiză, proiectare,

implementare) până la douăzeci sau mai multe.Este evident faptul că, şi în acest domeniu, concurenţa, beţia teoretică şi ruperea contactului cu realitatea

zămislesc, din când în când, adevăraţi monştri metodologici. Pentru a trece cu brio examenul practicii, o MDS trebuie să manifeste o preocupare deosebită pentru două dintre trăsăturile ciclului de viaţă asociat:

-numărul de faze să fie justificat atât de o analiză punctuală cât şi de consideraţii de ansamblu în ceea ce priveşte versatilitatea operaţionalizării ciclului de viaţă;-fiecare fază a ciclului de viaţă să fie “acoperită” satisfăcător de elemente suport pentru rezolvarea problemelor de tip ASS, RDS, OMP.

Specificarea cerinţelor

Implementare

Specificarea cerinţelor

Diagrama de structură

Implementare

Page 19: Ingineria soft

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ă

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.

Definirea cerinţelor

Utilizarea şi instruirea

Analiza

Proiectarea

Testarea

Implementarea

Page 20: Ingineria soft

Nu am considerat necesar să mai insist asupra conţinutului fazelor prezentate în Figura 3.3. Paragraful 2.2 al acestei lucrări conţine suficiente informaţii lămuritoare în acest sens.

Cu toate că are destui critici, modelul cascadă a fost şi este folosit, integral sau parţial, ori de câte ori se doreşte un ciclu de viaţă cu o structură echilibrată.

3.2.2 Modelul V (MV)Acest model preia ideile de bază ale modelului cascadă, integrându-le într-o concepţie ierarhică de

controlare a modului în care sunt parcurse fazele de dezvoltare. (A se vedea Figura 3.4)Modelul, prezentat în Figura 3.4, descrie o strategie de organizare a procesului de abstractizare în care se

propune o perspectivă mai clară asupra elementelor de feed-back ale procesului, o abordare mai modernă a relaţiei sistem-componente, o delimitare mai precisă a interferenţelor procesului cu utilizatorul sistemului soft rezultat.

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

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

Aş mai sublinia faptul că în cadrul MV se face o distinţie clară între verificare şi validare, ca activităţi specifice laturii din dreapta a V-ului modelului.

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

Menţionăm faptul că MV, în forma consacrată aparţine lui Ould, care l-a adus în faţa comunităţii specialiştilor în IS în 1990.

Figura 3.4. Modelul V

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

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

Deşi promite un cadru mai realist de dezvoltare a softului o astfel de abordare poate fi uşor “descumpănită” de constatarea că, în zilele noastre utilizatorul final sau indirect ştie să folosească sistemul odată ce acesta a

Definirea cerinţelor Validare

Proiectare sistem

Testare sistem

Proiectare subsisteme

(componente)

Testare subsisteme (componente)

Codificare/ asamblare

componente

Page 21: Ingineria soft

fost livrat, ceea ce creează foarte repede împrejurările necesare pentru ca acesta (utilizatorul) să observe eventualele neconcordanţe între cerinţele lui faţă de sistem şi cele implementate efectiv.

MP oferă o abordare care, potenţial, poate contribui la eliminarea omisiunilor şi ambiguităţilor care pot exista în cerinţe. În IS se numeşte prototip un sistem sau un sistem parţial finisat care este construit rapid pentru a explora anumite aspecte ale cerinţelor faţă de sistem şi care nu este considerat sistem gata de livrarea finală la utilizator.

Un sistem soft aflat în faza de prototip se deosebeşte de un sistem soft gata de livrare prin o serie de omisiuni asumate sau strecurate involuntar în faza de codificare (implementare).

Astfel că un prototip are, în mod obişnuit, o funcţionalitate incompletă (capacitate limitată de procesare a datelor, performanţe reduse în timpul execuţiei, siguranţă în funcţionare problematică, etc.).

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

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

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

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

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

sau a unei infrastructuri de comunicaţie.O perspectivă mai clară asupra proprietăţilor modelului MP putem obţine şi din Figura 3.5.

Figura 3.5. Dezvoltarea rapidă a softuluiutilizâ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.

Analiza iniţială

Definire obiective prototip

Specificare prototip

Construire protoip

Evaluare prototip şi stabilire schimbări

Prototip complet

Page 22: Ingineria soft

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 prototipuluiPrototipizarea este de dorit să aibă obiective clar stabilite. Un exerciţiu de prototipizare poate implica multe

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

Specificarea prototipuluiDeş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 prototipuluiDeoarece 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 efectuatMotivul principal pentru care realizăm un prototip este testarea şi explorarea anumitor aspecte ale sistemului

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

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

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

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

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

incomplet.

Probleme:Clientul poate percepe prototipul ca parte a sistemului final dar nu poate înţelege amploarea efortului

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

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

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

viaţă.

3.2.4 ConcluziiDeş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.

Page 23: Ingineria 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ă.

Page 24: Ingineria soft

4 ABSTRACTIZAREA SOLUŢIEI UNUI SISTEM SOFT

4.1 Modelarea. Limbaje de modelareDupă 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.

Page 25: Ingineria soft

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 conceptualAmâ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.

Page 26: Ingineria soft

Amândouă comandamentele “apasă” greu pe umerii celor care vor să specifice limbaje de modelare. Pentru mai multă rigoare în exprimare, de fapt, trebuie să spun cititorului că problema rafinării treptate a soluţiei unei probleme arbitrare este greu de algoritmizat.

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

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

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

Ca exemple de elemente suport pentru rafinarea treptată a soluţiei unui sistem soft putem indica:Descompunerea sistemelor în subsisteme şi agregarea subsistemelor în sisteme (două procedee de

abstractizare din teoria generală a sistemelor care operează cu înţelesul originar la nivele înalte de abstractizare).Utilizarea modularizării pentru obţinerea soluţiei unui sistem soft; este un procedeu care extinde

utilitatea principiului descompunerii din teoria generală a sistemelor la specificul problemelor de modelare din IS. La fel cum descompunerea sistemelor în subsisteme este consecinţa unui anumit mod de a înţelege sistemul modelat, modularizarea se poate baza pe abordarea top-down sau bottom-up. Indiferent de alegere avem nevoie de criterii. Ca un exemplu, în cazul abordării top-down putem avea descompunere bazată pe:

-criterii funcţionale;-criterii de organizare a datelor;-abstractizarea fluxurilor de date;-tipuri abstracte de date.

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

A treia problemă în atenţia unui SLM se referă la notaţia prin intermediul căreia se face transfer de semantică dinspre limbajul de modelare către utilizatorul limbajului de modelare.

Este o problemă care, rezolvată nesatisfăcător, poate compromite intenţiile conceptuale ale limbajului.De regulă, o notaţie inspirată permite:

-vizualizarea procesului de modelare;-specificarea soluţiei unei probleme;-realizarea soluţiei;-documentarea soluţiei.

Vizualizarea procesului de modelareEste 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 problemeOrice 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:

Page 27: Ingineria soft

-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 softuluiO 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ţieiNotaţia unui limbaj de modelare trebuie să dispună de resursele necesare pentru a permite:

Page 28: Ingineria soft

-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 BNFEvident, 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 modelareUn 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.

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.

Page 29: Ingineria soft

Din momentul în care atitudinea specialistului faţă de realitatea informaţională începe să se structureze, practic, începe procesul de modelare a realităţii informaţionale. Acest proces presupune:

permanente şi obligatorii procese de abstractizare.Se face abstractizare atunci când schiţăm elementele arhitecturale ale modelului, ceea ce înseamnă generalizare.Se face abstractizare atunci când optăm pentru o soluţie alternativă în procesul de rafinare a modelului, ceea ce înseamnă specializare.permanente şi obligatorii eforturi de reprezentare a diferitelor nivele de abstractizare, scopurile urmărite fiind:

-rezolvarea problemelor de comunicare;-obţinerea specificaţiilor complete ale modelului.

Page 30: Ingineria soft

5 MODELAREA OBIECT ORIENTATĂ CU UML5.1 Ce este UML(fără a intra în detalii)?

Cititorul bănuieşte, deja, că UML este rezultatul unor acumulări cu un istoric destul de zbuciumat, în materie de modelare a soluţiilor sistemelor soft.

Aşadar, să remarcăm faptul că UML este un limbaj de modelare, nu o metodologie. Ca limbaj de modelare, UML oferă o notaţie, în spatele căreia se află o semantică adecvată. Notaţia este în mare parte grafică, astfel că este cât se poate de nimerit să reproducem caracterizarea de ansamblu a UML-ului, făcută în documentaţia pusă la dispoziţie în site-ul www . rational.com :

“UML este un limbaj pentru specificarea, vizualizarea, construirea şi documentarea componentelor (artifacts) unui sistem soft sau, la fel de bine, pentru modelarea organizaţională şi a altor sisteme, nu neapărat din lumea IS.”Cele mai puternice şi recente rădăcini ale limbajului UML se află în metodologiile, patronate spiritual de

Grady Booch, James Rumbaugh şi Ivar Jacobson.UML a unificat şi standardizat oferta metodologiilor Booch, OMT şi OOSE, precum şi a altor metodologii

cu abordări remarcabile, în spatele cărora se află autori precum Odell, Shaeler-Mellor, Meyer, Wirfs-Brock etc.Prima versiune publică a UML a fost lansată în octombrie 1995 sub forma versiunii 0.8. Reacţia marelui

public a fost evaluată şi inclusă în versiunea 0.9, în iulie 1996 şi în versiunea 0.91, în octombrie 1996. Versiunea 1.0 a fost prezentată pentru standardizare membrilor OMG (Object Management Group) în iulie 1997. O serie de îmbunătăţiri aduse UML au fost incluse în versiunea 1.1, care a fost prezentată OMG în septembrie 1997. UML a fost adoptat ca standard, în unanimitate, de către membrii OMG, în noiembrie 1997. OMG este actualmente implicat, cu responsabilităţi precise, în dezvoltarea viitoare a standardului UML. Versiunea 1.3 a fost făcută publică în 1999 şi prin contribuţia grupului RTF (Revision Task Force), etc.

Să încercăm acum o explicaţie a sintagmei “unified” din denumirea UML.Aşadar, pentru UML, atributul “unified” poate fi înţeles în raport cu următoarele topici IS. Metodologiile şi notaţiile asociate lor privite din punct de vedere istoric

UML combină conceptele, folosite intens şi cu acelaşi înţeles, în mai multe metodologii obiect orientate, impunând definiţii clare pentru fiecare concept şi o notaţie adecvată. Ca urmare, UML este capabil să reprezinte cele mai multe dintre modelele existente, la fel de bine sau chiar mai bine decât metodologiile originale.

Ciclul de viaţă al dezvoltării sistemelor softUML operează cu aceleaşi concepte şi notaţii în diferite etape ale procesului de abstractizare a soluţiei. Prin

urmare, nu este necesar un efort de translatare semantică şi sintactică a soluţiei, de la un nivel de abstractizare la altul. Această situaţie este absolut convenabilă din perspectiva modelului iterativ şi incremental de dezvoltare, cu care UML se potriveşte cel mai bine.

Tipuri de aplicaţiiUML este pregătit să ofere suport pentru modelarea unui număr mare de tipuri de aplicaţii, incluzând

sisteme cu volum mare de date şi prelucrări, sisteme de mare complexitate, sisteme de timp real, sisteme distribuite, etc. Este posibil să existe tipuri de probleme în care un limbaj de modelare specializat este mai folositor, dar UML este de aşteptat să fie la fel de bun sau chiar mai bun decât orice alt limbaj de interes general, în multe tipuri de aplicaţii.

Limbaje şi platforme de implementareUML este gândit să fie util pentru sisteme soft implementate pe diferite platforme, incluzând limbaje de

programare, SGBD-uri, 4GLs, documente organizaţionale, medii firmware, etc. Modul de lucru este acelaşi sau prezintă multe similarităţi în toate tipurile de aplicaţii, rezultatul fiind dependent de mediul în care se lucrează.

Procesul de dezvoltareAşa cum am mai spus, UML este un limbaj de modelare, nu o descriere a unui proces de dezvoltare detaliat.

UML este gândit să fie utilizat independent de proces, dar oferă suport complet pentru procesele de dezvoltare iterative şi incrementale (a se vedea. Rational Unified Process - RUP).

Să precizăm, în sfârşit, faptul că UML a fost dezvoltat de Rational Software Corporation şi partenerii ei, precum: OMG, Digital Equipment Corporation, HP, i-Logix, IntelliCorp, IBM, Microsoft, Oracle, etc.

Cititorului amator de elemente de referinţă referitoare la UML să-i mai spunem că, din perspectivă formală, UML are o arhitectură structurată pe patru nivele de abstractizare: obiecte utilizator, model, meta-model şi meta-metamodel. Astfel că, specialiştii obişnuiesc să spună că UML are o arhitectură de metamodelare pe 4 nivele, cum rezultă şi din Figura 5.1.

Page 31: Ingineria soft

Nivel Descriere ExempleMeta-metamodel Desemnează infrastructura

conceptuală, necesară pentru o arhitectură de metamodelare.Defineşte limbajul pentru specificarea metamodelelor.

MetaClase, MetaAtribute, MetaOperaţii

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

Clasă, Atribut, Operaţie, Componentă

Model Desemnează o instanţă a unui metamodel. Defineşte un limbaj pentru descrierea domeniilor informaţionale.

CodProdus, DenumireProdus, Cantitate, etc.

Obiecte(dată) utilizator

Desemnează o instanţă a unui model. Defineşte un domeniu informaţional concret.

<1111>, <Ţeavă PVC>, 30

Figura 5.1. Arhitectura UML

Pe bună dreptate, cititorul se va intreba: “La ce îmi foloseşte să ştiu atâtea despre arhitectura UML?”. Un răspuns moderat la această întrebare, mai jos.

Aşa cum se prezintă la ora actuală, UML oferă utilizatorilor o notaţie şi un meta-model.Notaţia desemnează acele elemente de sintaxă (preponderent grafice) cu ajutorul cărora se specifică soluţia

UML a unui sistem soft. De exemplu, pentru a reprezenta soluţia UML a unei probleme, în mod normal ne vom folosi de notaţia aferentă diagramelor de clase, în care se operează cu concepte precum: clase, asocieri, generalizări, multiplicitate, etc. Utilizatorul “grăbit” prinde din zbor semantica unor astfel de concepte. Utilizatorul care are obsesia rigorii, vrea un răspuns precis la întrebări de genul: “Ce este o clasă?”.

Producătorii de tools-uri de dezvoltare pentru specialiştii IS sunt chiar interesaţi, în mod obiectiv, de clarificarea răspunsurilor la astfel de întrebări. Ideea unor limbaje de specificare şi proiectare riguroase este bine reprezentată în lumea metodelor formale (în care singurele enunţuri acceptate sunt în spiritul calculului propoziţional sau al calculului predicatelor).

Metodele formale reprezintă cea mai bună armă cu care putem stăvili insinuarea ambiguităţilor în enunţurile noastre.Din păcate, “omul în genere ”, nu a fost “proiectat” spre a fi un adorator al limbajelor formale.Pentru a comunica, “omul în genere” foloseşte cel mai bine limbajul natural sau derivaţi simplificaţi ai

acestuia. La urma urmei, această înclinaţie naturală are o explicaţie destul de profundă: Capacitatea lilmbajelor naturale de a opera cu semnificaţii noi este mult mai mare decât a limbajelor formale.Pentru a împăca pe toată lumea, UML oferă utilizatorilor un meta-model, cu ajutorul căruia se dau

răspunsuri riguroase la întrebări de genul: “Ce este o clasă?”. Această caracteristică face din UML un limbaj interesant, deoarece resursele pentru specificarea conceptelor lui se găsesc în el însuşi (limbajele de programare, de exemplu, folosesc metalimbaje de tip notaţie BNF sau diagrame de sintaxă, pentru specificare).

5.2 Date esenţiale pentru înţelegerea UMLÎn acest paragraf voi trece în revistă coordonatele esenţiale pentru înţelegerea UML. Aşadar, UML este un limbaj pentru: vizualizarea, specificarea, construirea şi documentarea componentelor unui sistem soft.UML – limbaj pentru vizualizareUML pune accent pe vizualizarea soluţiei unui sistem soft pentru a elimina cea mai mare parte a

problemelor de comunicare care pot să apară între diferitele categorii de participanţi la dezvoltarea unui sistem soft. Evident, fără a renunţa în totalitate la text, UML propune o manieră preponderent grafică de reprezentare şi documentare a unui sistem soft.

UML – limbaj pentru specificareÎn ingineria softului, specificarea înseamnă elaborarea de modele precise, complete şi fără ambiguităţi. O

specificare vizuală, cum este specificarea UML, este expusă riscului de a genera ambiguităţi în procesul de comunicare, într-un grad mai mare decât în cazul specificării formale. Şi totuşi, o specificare vizuală a soluţiei în toate fazele de dezvoltare a unui sistem soft, este de preferat, dată fiind importanţa unei comunicări cât mai ample între specialiştii IS, utilizatori şi beneficiari, ca parteneri în cadrul aceluiaşi proiect.

Page 32: Ingineria soft

UML – limbaj pentru construireProbabil, a fost înţeles faptul că UML nu este un limbaj de programare vizuală, dar, ceea ce trebuie reţinut

este faptul că modelele elaborate în UML pot fi uşor “translatate” în numeroase limbaje de programare. Această stare de fapt ne sugerează posibilitatea mapării naturale a unui model UML în limbaje precum Java, C++, Vizual Basic, Ada, etc.

Posibilitatea efectivă a acestei mapări stă la baza generării automate a codului asociat unui model UML, în conformitate cu o anumită opţiune de limbaj. Generarea automată a codului, pornind de la modelul UML, sau invers, regăsirea modelului UML asociat unei implementări date, sunt posibile utilizând instrumente CASE, precum Rational Rose, ObjectiF, etc.

UML – limbaj pentru documentareO firmă de soft adevărată produce toate genurile de componente adiţionale obţinerii codului executabil al

unui sistem soft, precum: Cerinţele faţă de sistemul soft; Descrierea arhitecturii sistemului; Specificaţiile de proiectare; Codul sursă; Planurile de dezvoltare, etc.UML posedă resurse adecvate pentru specificarea cerinţelor faţă de un sistem soft, reprezentarea arhitecturii

unui sistem şi a tuturor detaliilor de proiectare, modelarea activităţilor de management al proiectului, etc. Unde putem folosi UML?Înainte de orice, UML a fost gândit să fie utilizat în dezvoltarea de sisteme soft în domenii precum:- Sistemele informaţionale ale întreprinderilor;- Servicii financiare şi bancare;- Telecomunicaţii;- Transporturi;- Electronica medicală;- Servicii distribuite bazate pe WEB, etc.Să mai adăugăm faptul că UML este suficient de expresiv pentru a permite şi modelarea sistemelor de altă

natură decât soft (fluxuri de lucru în sistemul justiţiei şi sănătate, etc.). Arhitectura sistemelor soft din perspectivă UMLUn specialist în IS cunoaşte bine faptul că, sistemele de mare complexitate, nu pot fi modelate satisfăcător

dacă paleta criteriilor de observare şi analiză nu este adecvat structurată. Învăţând din greşelile altor limbaje de modelare, UML propune o formulă de arhitectură comprimată în sintagma “perspectiva arhitecturală 4+1”.

Această formulă este binevenită, atât pentru lucrul în echipă la un proiect (deci în sprijinul managementului) cât şi pentru procesul de obţinere a unei soluţii de calitate şi cât mai complete. Perspectiva arhitecturală 4+1 este reprezentată, în sinteză grafică, în Figura 6.2, care ne sugerează faptul că identificarea arhitecturii unui sistem soft este o activitate pentadimensională, dacă mi se îngăduie exprimarea. Fiecare perspectivă focalizează atenţia echipei de dezvoltare asupra unui gen de probleme, a căror rezolvare influenţează în mod specific calitatea soluţiei, în ansamblu. Atrag atenţia asupra rolului pe care îl joacă perspectiva context de utilizare în contextul celorlaltor 4 perspective.

Perspectiva logică sistem (Structural view)Această perspectivă a arhitecturii uni sistem soft se referă la cerinţele funcţionale ale acestuia. Altfel spus,

ce servicii asigură sistemul soft pentru utilizatorii lui? Arhitectura logică este încapsulată în diagramele claselor, care conţin clasele şi relaţiile dintre ele (socotite abstracţii fundamentale ale sistemului în curs de dezvoltare). Mare parte din notaţia UML este dedicată reprezentării arhitecturii logice (clase, asocieri, generalizări, agregări, pachete, etc.).

Elementele care definesc arhitectura logică încep să fie precizate încă de la începutul fazei de elaborare (a se vedea RUP), când se stabilesc clasele şi pachetele socotite abstracţii majore ale domeniului problemei. În timp, alte şi alte clase şi pachete sunt adăugate modelului UML al soluţiei pentru a reflecta deciziile luate privitor la mecanismele cheie ale sistemului soft.

Prin urmare, putem spune că arhitectura logică a unui sistem soft poartă amprenta abilităţii echipei de dezvoltare, de a armoniza gestiunea abstracţiilor majore ale sistemului soft cu gestiunea mecanismelor cheie ale sistemului soft.

Această abilitate este transpunerea, într-un context particular, a relaţiei dintre strategie (=abstracţiile majore) şi tactică (=mecanismele cheie). Deciziile tactice greşite, în timpul proiectării, pot compromite uşor o arhitectură logică robustă. Pentru a implementa, cu succes, deciziile referitoare la mecanismele cheie ale unui sistem soft, în IS a apărut o ramură de cercetare nouă, cea care se referă la proiectarea şi utilizarea soluţiilor-şablon (patterns, în literatura anglo-saxonă).

Page 33: Ingineria soft

Figura 5. 2 Perspectiva arhitecturii 4+1

Perspectiva componente sistem (Implementation view)Această perspectivă asupra unui sistem soft trebuie să precizeze diferitele componente ale unui sistem soft,

împreună, eventual, cu relaţiile dintre acestea.Prin componentă a unui sistem soft vom înţelege, cel mai adesea, un modul fizic de cod. O componentă poate coincide cu un pachet, dar cel mai adesea poate diferi. Ca un exemplu, care subliniază

diferenţa între pachet şi componentă putem observa faptul că în Java clasa String este parte a pachetului java.lang.package, dar poate să fie utilizată în nenumărate componente ale unei aplicaţii Java.

Să mai atragem atenţia cititorului şi asupra faptului că între componente pot exista dependenţe (care, în terminologia UML, arată cum pot influenţa schimbările de stare ale unei componente starea alteia sau a mai multor componente). Este evident faptul că perspectiva componente sistem a arhitecturii unui sistem soft este importantă pentru rezolvarea corectă a problemelor de reutilizare a codului, portabilitate a codului şi de management eficient al pieselor fizice ale unui sistem soft.

Evident, există o anumită mapare a perspectivei structurale pe perspectiva implementaţională a unui sistem.Perspectiva procese sistem (Behavioral view)Această perspectivă are în vizor structura executabilelor sistemului soft (procese, fire de execuţie,

mecanisme de concurenţă şi sincronizare, etc.)Specificarea acestui tip de arhitectură ia în calcul cerinţe precum: performanţa, fiabilitatea, utilitatea, etc. Perspectiva componente sistem şi perspectiva procese sistem folosesc pentru reprezentare diagrame de

componente care indică componentele (procesele), interfeţele acestora şi dependenţele dintre acestea.Diagramele de componente asociate perspectivei proces indică, de fapt, modul de mapare a claselor pe

bibliotecile run-time, gen applet-uri Java, DLL-uri, componente ActiveX.Perspectiva topologie-hard (Enviromental view)O astfel de perspectivă va trebui să precizeze nodurile care formează topologia hard care asigură execuţia

sistemului soft. În aceste noduri se vor executa diferitele procese, indicate în perspectiva procese sistem. Topologia hard este reprezentată cu ajutorul unor diagrame de noduri, purtând etichete care sugerează repartizarea, pe tipuri de activităţi şi informaţii despre procesele executate în aceste noduri. Evident, o bună topologie hard trebuie să asigure viteze de execuţie rezonabile, resurse suficiente în noduri, fiabilitate, etc.

Perspectiva contexte de utilizare (User view)Această perspectivă demonstrează şi validează oarecum celelalte patru perspective. De fapt, perspectiva

contexte de utilizare se bazează pe folosirea contextelor de utilizare (use case) pentru a descrie comportamentul

Perspectivalogică sistem (structurală)Funcţionalitate

Perspectivacomponenete sistem (implementaţională)Managementul softuluiReutilizarePortabilitate

Perspectivatopologie sistem (desfăşurare în mediul de execuţie)PerformanţăUtilitateToleranţă la eroriLivrare şi instalareAccesibilitate

Perspectivaprocese sistem (comportamentală)PerformanţăUtilitateToleranţă la erori

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

Page 34: Ingineria soft

sistemului soft, aşa cum este acesta văzut de diferite categorii de utilizatori şi, prin intermediul acestora, de diferiţi membri ai echipei de proiectare. Aspectele statice ale acestui tip de perspectivă sunt reprezentate cu ajutorul diagramelor de contexte de utilizare. Aspectele dinamice sunt încapsulate în diagrame de interacţiune, diagrame de stare, diagrame de activitate.

Scurta trecere în revistă a modelului “4+1” ne atenţionează, încă o dată, asupra complexităţii abordării propuse de UML, precum şi asupra necesităţii de a începe explorarea notaţiei UML care permite materializarea abordării “4+1”.

5.3 Scurtă incursiune în universul conceptual al UMLDupǎ ce am fǎcut atâtea promisiuni relativ la utilitatea UML în diferite contexte, este cazul sǎ facem o

primǎ încercare de ridicare a vǎlului care mai acoperǎ încǎ, în acest punct al demersului nostru, universul conceptelor utilizate în modelarea UML. Procedând top-down (aşa cum se întâmplǎ de multe ori în IS) sǎ precizǎm, pentru început, cǎ vocabularul UML opereazǎ cu trei tipuri de elemente constitutive:

Entitǎţi; Relaţii; Diagrame. Observaţie

Entitǎţile desemneazǎ o serie de abstracţii care pot fi socotite “cetǎţeni de prim rang” într-un model UML.Relaţiile abstractizeazǎ diferitele tipuri de legǎturi care pot exista între entitǎţi.Diagramele sunt folosite pentru a grupa colecţiile de entitǎţi, cu scopul de a evidenţia mai bine diferitele nivele de abstractizare ale soluţiei unui sistem soft.

Tipuri de entitǎţi în UMLUML opereazǎ cu patru tipuri de entitǎţi:

Entitǎţi cu funcţii structurale; Entitǎţi cu funcţii comportamentale; Entitǎţi cu funcţii de grupare; Entitǎţi cu funcţii de documentare.Aceste tipuri de entitǎţi reprezintǎ fundamentul oricǎrei soluţii obiect orientate, în UML. Ele sunt utilizate

intens pentru a realiza modele corect specificate (corectitudinea specificǎrii, în UML, acoperǎ atât aspectele de sintaxǎ ale modelelor, cât şi cerinţa de a încapsula semantica eficient în aceste metode).

Entitǎţile cu funcţii structurale (EFS)Foarte sintetic, EFS sunt substantivele modelelor UML. De cele mai multe ori, EFS reprezintǎ pǎrţi statice

ale unui model, reprezentând elemente care sunt de naturǎ conceptualǎ sau fizicǎ. În total, în UML existǎ şapte genuri de EFS, pe care le voi prezenta, pe scurt, în continuare.

1. Clasa - este o abstractizare a unei mulţimi de obiecte care partajeazǎ aceleaşi atribute informaţionale, acelaşi comportament, aceleaşi relaţii şi aceeaşi semanticǎ.

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

2. interfaţa - abstractizeazǎ o colecţie de operaţii care specificǎ serviciile furnizate de o clasǎ sau componentǎ.

În general vorbind, o interfaţǎ poate sǎ reprezinte comportamentul complet al unei clase / componente sau doar o parte a acestui comportament. Este important sǎ subliniem faptul cǎ o interfaţǎ se specificǎ printr-o listǎ de signaturi de operaţii, nicidecum prin lista implementǎrilor acestor operaţii. Este o chestiune de nuanţǎ prin care în modelarea softului se face distincţia necesarǎ între interfaţǎ şi implementarea acesteia.

Error: Reference source not found

Figura 5.3. Reprezentarea unei clase în UML

Atribute informaţionale

Pacient

CNPNume_I_Prenume…

creare()eliberare()adaugare()…

Nume clasǎ

Operaţii

Page 35: Ingineria soft

Ca şi notaţie vizualǎ, o interfaţǎ este redatǎ printr-un cerc cǎruia i se ataşeazǎ numele interfeţei (Figura 5.4).

Figura 5.4. Reprezentarea unei interfeţe în UML

3. colaborare - abstractizeazǎ o familie de clase, interfeţe şi alte elemente care, prin cooperare, reuşesc sǎ asigure un comportament care înseamnǎ mai mult decât “suma mecanicǎ” a comportamentelor pǎrţilor. De remarcat faptul cǎ, o colaborare are atât dimensiune structuralǎ cât şi dimensiune comportamentalǎ.

Dintr-o perspectivǎ ceva mai largǎ privind, o colaborare reprezintǎ implementarea unui şablon care abstractizeazǎ o anumitǎ funcţie a unui sistem soft. Notaţia pentru colaborare este o elipsǎ al cǎrei contur este realizat cu o linie întreruptǎ, în interiorul cǎreia se trece numele colaborǎrii.

Figura 5.5. Reprezentarea unei colaborǎri în UML

4. Un context de utilizare (use case, în limba englezǎ) - abstractizeazǎ o colecţie de secvenţe de acţiuni pe care trebuie sǎ le execute un sistem pentru a produce un rezultat care trebuie observat de un actor particular. Contextele de utilizare sunt folosite pentru a structura entitǎţile comportamentale într-un model UML.

Sǎ mai precizǎm cititorului faptul cǎ un context de utilizare este realizat de cǎtre o colaborare.Semantica realizǎrii va fi discutatǎ tot în acest paragraf. Notaţia pentru context de utilizare este o elipsǎ

al cǎrei contur este o linie continuǎ, în interiorul cǎreia se trece numele contextului de utilizare (Figura 5.6).

Figura 5.6. Reprezentarea unui context de utilizare în UML

Urmǎtoarele trei tipuri de EFS (clasele active, componentele şi nodurile) sunt, într-o oarecare mǎsurǎ, asemǎnǎtoare claselor, în sensul cǎ sunt descrise ca mulţimi de obiecte care partajeazǎ aceleaşi atribute, operaţii, relaţii şi semantici. Şi totuşi, existǎ suficiente elemente care deosebesc aceste trei tipuri de EFS de tipul clasǎ, şi între ele însele, motiv pentru care sunt tratate distinct de cǎtre notaţia UML.

5. clasǎ activǎ - este o clasǎ ale cǎrei obiecte posedǎ unul sau mai multe procese sau fire de execuţie, ceea ce înseamnǎ cǎ obiectele pot iniţia activitǎţi de control. Aşadar, o clasǎ activǎ este întocmai ca o clasǎ obişnuitǎ, exceptând faptul cǎ obiectele sale reprezintǎ

elemente al cǎror comportament este concurent cu comportamentul altor elemente.Notaţia UML pentru o clasǎ activǎ se deosebeşte de notaţia pentru clasǎ prin linia îngroşatǎ a

conturului. De observat, Figura 5.7.Cititorul bǎnuieşte, probabil, faptul cǎ avem nevoie de clase active pentru a modela soluţiile problemelor în

care se apeleazǎ la multitasking şi, în consecinţǎ, apar probleme noi legate de sincronizarea proceselor sau firelor de execuţie.

Figura 5.7. Reprezentarea unei clase active în UML

IPacient

Programare pacient

Planificare pacient

Supervizor pacient

CNP…

Iniţiere()Suspendare()…

Page 36: Ingineria soft

6. componentǎ - este o parte a unui sistem soft, reprezentatǎ de un anumit gen de cod fizic, dedicatǎ, în general, realizǎrii uneia sau mai multor interfeţe. Exemple de componente: unit-uri Pascal, ierahii de clase C++ specializate în lucrul cu octeţii de şiruri,

DLL-uri din lumea Windows, pachetele din Java etc.Notaţia UML pentru o componentǎ este ilustratǎ în Figura 6.8.

Figura 5.8. Notaţia UML pentru o componentǎ

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

UML, simplificatǎ, pentru un nod este prezentatǎ în Figura 5.9.

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

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

Entitǎţile cu funcţii comportamentale (EFC)EFC abstractizeazǎ aspectele dinamice ale unui sistem în cadrul modelelor UML. Prin urmare, EFC

sunt verbe ale modelelor UML (având şi o reprezentare graficǎ sugestivǎ) care încearcǎ reprezentarea comportamentului unui sistem, în timp şi în spaţiu. UML opereazǎ cu douǎ tipuri fundamentale de EFC.

1. interacţiune - abstractizeazǎ un comportament care cuprinde o mulţime de mesaje schimbate între obiectele unui sistem, într-un context particular, în vederea îndeplinirii unui obiectiv specific.

Prin urmare, la un anumit nivel de abstractizare, comportamentul unei familii de obiecte sau al unei operaţii individuale poate fi specificat ca o interacţiune. O interacţiune implicǎ o serie de alte elemente, precum mesaje, secvenţe de actiuni (comportamentul invocat de mesaje) şi legǎturi între obiecte.

Notaţia UML pentru mesaj este prezentatǎ în Figura 5.10.

Figura 5.10. Notaţia UML pentru mesaj

Dupǎ cum se vede din notaţia prezentatǎ în Figura 5.10, sǎgeata care indicǎ un mesaj între douǎ obiecte are asociat şi numele operaţiei invocate.

2. maşină de stare (în engleza americanǎ, state machine) abstractizeazǎ, de data aceasta , comportamentul unui singur obiect sau al unei interacţiuni dintre obiecte, pe timpul vieţii acestora, ca succesiune de acţiuni-rǎspuns la anumite evenimente.Aşadar, comportamentul unei clase sau al unei colaborǎri între clase (cadrul natural de reprezentare al

interacţiunilor) poate fi specificat cu ajutorul unei maşini de stare. O maşină de stare implicǎ o serie de alte elemente, precum: stǎri, tranziţii, evenimente (fapte ce pot declanşa o tranziţie) şi activitǎţi (rǎspunsuri la tranziţii). Notaţia UML pentru o stare este prezentatǎ în Figura 5.11 (dreptunghi cu colţurile rotunde, în interiorul cǎruia se aflǎ numele stǎrii şi, eventual, substǎrile asociate.

Figura 5.11. Notaţia UML pentru stare

Evid_Pacient.java

Server

afişeazǎ()

Aşteptare

nume componentă

Page 37: Ingineria soft

Interacţiunile şi maşinile de stare sunt elemente comportamentale fundamentale, care pot fi incluse într-un model UML. Semantic vorbind, aceste elemente sunt, în mod uzual, conectate cu alte elemente structurale, îndeosebi clasele, colaborǎrile şi obiectele.

Entitǎţi cu funcţii de grupare (EFG) EFG reprezintǎ elemente utile în organizarea modelelor UML, reprezentate ca nişte casete în care un

anumit model poate fi descompus în ceea ce se considerǎ a fi pǎrţile lui componente. Specia fundamentalǎ de EFG este pachetul.

Un pachet este un mecanism de interes general al limbajului UML, utilizat pentru organizarea elementelor în grupuri de elemente. La diferite nivele de abstractizare, într-un pachet pot fi grupate EFS, EFC şi chiar alte EFG, dacǎ este nevoie.

Spre deosebire de componente (care se manifestǎ, cumva, în timpul execuţiei unui sistem soft), EFG au o valoare de întrebuinţare pur conceptualǎ (în timpul procesului de dezvoltare a sistemului). Notaţia UML pentru un pachet este ilustratǎ în Figura 5.12. Problematica EFG necesitǎ o discuţie mai amplǎ pentru a înţelege întreaga semanticǎ a subiectului.

Entitǎţi cu funcţie de documentare (EFD)EFD reprezintǎ pǎrţile explicative ale modelelor UML. De fapt, acestea sunt comentarii pe care le puteţi

folosi în descrierea modelelor UML pentru a lǎmuri anumite aspecte neclare ale acestora sau pentru a adǎuga informaţii suplimentare despre proprietǎţile acestor modele. EFD sunt reprezentate în UML ca note. Reprezentarea aferentǎ notelor în UML este ilustratǎ în Figura 5.13.

Figura 5.12. Notaţia UML pentru conceptul de pachet

Figura 5.13. Notaţia UML pentru conceptul de notǎRelaţii în UMLUML utilizeazǎ patru tipuri de relaţii pentru a descrie aspectele de naturǎ relaţionalǎ ale modelelor:

Dependenţele; Asocierile; Generalizǎrile; Realizǎrile.Aceste tipuri de relaţii reprezintǎ nucleul conceptelor de bazǎ propuse de UML pentru descrierea relaţiilor

dintre diferitele tipuri de entitǎţi ale modelelor UML.1. dependenţa - abstractizeazǎ o relaţie semanticǎ între douǎ entitǎţi, caracterizatǎ prin faptul cǎ o

schimbare în una dintre ele poate afecta semantic cealaltǎ entitate. Într-o astfel de relaţie, despre entitatea în care se poate produce schimbarea se spune cǎ este independentǎ,

iar despre entitatea afectatǎ se spune cǎ este dependentǎ. În lumea IS, o astfel de relaţie se întâlneşte foarte des, în diferite ipostaze. Notaţia UML pentru relaţia de dependenţǎ este reprezentatǎ în Figura 6.14.

Figura 5.14. Notaţia UML pentru relaţia de dependenţǎ2. asocierea - abstractizeazǎ o relaţie structuralǎ prin care se descriu legǎturile dintre obiecte, de

tipuri diferite sau de acelaşi tip. Asocierea (şi diferitele variaţiuni pe tema asocierii) sunt esenţiale pentru descrierea relaţiilor statice

dintre obiectele unei aplicaţii. Notaţia UML pentru asociere înseamnǎ, în mod necesar, o linie continuǎ (vezi Figura 6.15), un nume şi, eventual, restricţii de cardinalitate şi nume de roluri, direcţionate sau nu.Error: Reference source not found

Figura 5.15. Notaţia UML pentru asociere

Gestiune pacienţi

Funcţia calculeazǎ vârsta pacientului

Page 38: Ingineria soft

3. generalizarea - este abstractizarea unei relaţii dintre două concepte UML, compatibile, a cărei semantică este exprimată astfel:

Unul dintre concepte este concept tată, celălalt este concept fiu Orice element din categoria conceptuală tată poate fi substituit de un element din categoria

conceptuală fiu. Acest lucru este posibil deoarece un element fiu moşteneşte structura şi comportamentul elementului părinte asociat.

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

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

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

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

Figura 5.17. Notaţia UML pentru realizare

Diagrame în UMLÎn UML, diagramele sunt reprezentări grafice ale unor colecţii de elemente (entităţi şi relaţii).

Diagramele UML sunt grafuri ale căror noduri sunt entităţi şi ale căror arce sunt relaţii. Permiţând asamblarea diferitelor tipuri de entităţi şi relaţii pentru a obţine descrieri ale sistemelor modelate din diferite perspective, diagramele UML sunt elemente suport puternice pentru abstractizarea şi vizualizarea soluţiei unui sistem soft.

Deşi în teorie se susţine că o diagramă poate conţine orice combinaţie de entităţi şi relaţii, în practică se recomandă utilizarea unui set restrâns de tipuri de diagrame, care încearcă să acopere toate cerinţele legate de acceptarea pentru sistemele soft a arhitecturii “4+1”.

De aceea, cei care popularizează UML-ul recomandă următoarele nouă tipuri de diagrame: Diagrame de clase; Diagrame de obiecte; Diagrame de contexte de utilizare; Diagrame de secvenţă; Diagrame de colaborare; Diagrame hărţi de stare; Diagrame de activitate; Diagrame de componente; Diagrame de desfăşurare.Descrierea şi exemplificarea modului de utilizare a acestor diagrame, sarcină de care urmează să ne ocupăm

în continuare, va lămuri problemele esenţiale care apar într-un exerciţiu de modelare UML.

Reguli UML pentru elaborarea de modele UML corecteUn model corect este semantic autoconsistent şi în armonie cu modelele cu care intră în relaţie. Regulile UML care susţin elaborarea de modele corecte se referă la:

Numele entităţilor – cum putem denumi entităţile, relaţiile şi diagramele; Domeniul – contextul care dă înţeles specific unui nume; Vizibilitatea – cum poate un nume să fie văzut şi folosit de alte nume; Integritatea – cum interacţionează entităţile complet şi consistent cu alte entităţi; Execuţie – ce se înţelege prin execuţia sau simularea unui model dinamic.Modelele elaborate pe timpul dezvoltării unui sistem soft fiind în atenţia mai multor categorii de participanţi,

apar situaţii în care modelele sunt afectate de: Omisiuni - anumite aspecte sunt ascunse pentru a simplifica procesul de înţelegere al modulului; Incomplete - anumite elemente pot lipsi cu desăvârşire; Inconsistente - nu este garantată integritatea unui model.

Page 39: Ingineria soft

Obţinem astfel modele care sunt, în mod deliberat, la nivele diferite de detaliere pe timpul ciclului de viaţă al sistemelor soft. Regulile UML încurajează – dar nu obligă – abordarea celor mai importante aspecte care ţin de analiză, design şi implementare pentru a obţine modele perfectibile în timp.

Mecanisme comune în modelarea UMLO construcţie, de orice natură, este realizată mai simplu şi mai armonios dacă sunt respectate anumite

şabloane în ceea ce priveşte modelarea aşa-ziselor însuşiri comune.De exemplu, dacă atunci când vrem să construim o casă, optăm pentru un anumit stil (bucovinean,

maramureşean etc.), putem spune că am rezolvat o problemă importantă, în ceea ce priveşte arhitectura casei.Această situaţie se întâlneşte şi în modelarea UML, care propune patru mecanisme comune pentru utilizarea

lui consistentă: Specificaţiile; Ornamentele; Separările comune; Mecanismele de extindere.SpecificaţiileProbabil, a fost înţeles faptul că UML este mai mult decât o notaţie vizuală. În spatele fiecărui tip de notaţie

vizuală există întotdeauna o specificaţie care furnizează, sub forma unui enunţ textual, sintaxa şi semantica blocului constructiv asociat notaţiei.

În practică, elementele grafice ale notaţiei UML sunt folosite pentru a vizualiza sistemul. Specificaţiile UML sunt folosite pentru a exprima detaliile sistemului.

OrnamenteleCele mai multe entităţi au, în UML, o notaţie grafică directă şi unică, care asigură o reprezentare

vizuală a celor mai importante aspecte ale elementelor. De exemplu, notaţia grafică pentru o clasă este, în mod deliberat, uşor de realizat, dat fiind faptul că la temelia oricărei soluţii obiect-orientate se află modelul claselor. Notaţia UML pentru o clasă ocazionează, de asemenea, descrierea celor mai importante aspecte: numele clasei, atributele şi operaţiile ei. Specificarea unei clase poate, însă, include şi alte detalii, precum: caracterul abstract al clasei, vizibilitatea atributelor şi operaţiilor, etc. Astfel că, fiecare element al notaţiei UML începe cu un simbol de bază, la care se pot adăuga o serie de ornamente, specifice acelui simbol. Se va reveni asupra problemei ornamentelor chiar în acest capitol.

Separările comuneÎn modelarea sistemelor obiect-orientate este uzuală împărţirea (separarea) produselor efortului de

modelare în perechi de abordare.Mai întâi, este foarte importantă separarea de tipul clasă – obiect. Situaţia caracterizată de această separare

este: în timp ce clasa este o abstractizare, un obiect este o manifestare concretă a acestei abstractizări . Astfel, în UML putem întâlni tandemul clase – obiecte, ca în Figura 5.18.

Figura 5.18. Clasă şi obiecteÎn Figura 6.18 este prezentată clasa Student, împreună cu trei obiecte având ca tip definitor această

clasă: Ion, marcat explicit ca fiind obiect de tip Student, :Student, prin care se desemnează un student anonim şi Maria, care în specificarea completă este indicat ca fiind un obiect de tip Student, folosind dependenţa stereotip <<instance Of>>.

Aproape fiecare bloc constructiv UML suportă genul de abordare prezentat pe relaţia clasă / obiect. Astfel, putem vorbi de contexte de utilizare, componente şi instanţe ale componentelor, noduri şi instanţe ale nodurilor etc. În Figura 6.18 s-a putut observa şi modul în care se obţin numele obiectelor într-un model UML. În al doilea rând, este extrem de importantă separarea dintre interfaţă şi implementare.

O interfaţă declară “un contract” de furnizare a unor servicii iar o implementare a unei interfeţe reprezintă o realizare concretă a contractului asumat de interfaţă. Un exemplu de utilizare a acestei separări, în Figura 5.19.

Student

matricol…

Ion : Student

: Student

Maria

Maria Student<<instance Of>>

DatePersStud.dllISecretar

IDecan

Page 40: Ingineria soft

Figura 5.19. Interfeţele şi implementarea lorAşa cum, probabil că aţi ghicit, în Figura 5.19 sunt prezentate două interfeţe implementate de o componentă

DLL. Multe dintre blocurile constructive UML suportă genul de abordare prezentat pe relaţia interfaţă / implementare. De exemplu, colaborările realizează contextele de utilizare, metodele implementează operaţiile.

Mecanismele de extindere UMLUn limbaj de modelare, închis din punct de vedere al notaţiei, poate ajunge uşor în situaţia de a nu putea

exprima, cu mijloace recunoscute de toţi utilizatorii lui, o anumită semantică din domeniul problemei sau din domeniul soluţiei.

Pentru acest motiv, UML a fost gândit ca un limbaj de modelare deschis-închis (open-closed), prin specificarea unor mecanisme de extindere care includ:

Stereotipurile (stereotypes); Valorile etichetate (tagged values); Constrângerile (constraints).Un stereotip extinde vocabularul UML, permiţând specialiştilor să creeze noi genuri de blocuri constructive,

pornind de la unele existente deja.O valoare etichetată extinde proprietăţile unui bloc constructiv UML, permiţând specialiştilor să adauge

informaţii noi în procesul de specificare a blocului constructiv.O constrângere extinde semantica unui bloc constructiv UML, permiţând specialiştilor să adauge reguli noi

sau să le modifice pe cele existente.

Figura 5.20. Mecanismele UML de extindere, pe un exemplu

În figura 5.20 este prezentat un exemplu de clasă – stereotip (Overflow), aflată în relaţie de dependenţă cu clasa EventQueue, căreia i-au fost adăugate informaţii referitoare la versiune şi autor folosind sintaxa specifică valorilor etichetate şi care are o metodă (add()), pentru care obiectele cu care lucrează (evenimentele) sunt supuse constrângerii {ordered}.

<<exception>>Overflow

EventQueue{ version=3.2 author=ma}

add()remove()flush()

{ordered}

Page 41: Ingineria soft

6 MODELAREA ASPECTELOR STRUCTURALE. ELEMENTE-SUPORT FUNDAMENTALE

6.1 ClaseClasele sunt elementele constructive cele mai importante ale unui sistem obiect orientat. În general vorbind,

o clasă este abstractizarea unei colecţii de obiecte care partajează aceleaşi atribute, aceleaşi operaţii, aceleaşi relaţii şi aceeaşi semantică. UML oferă un formalizm grafic pentru reprezentarea unei clase, asemănător celui din Figura 6.1.

Figura 6.1. Notaţia UML pentru clasă.

După cum se poate vedea, notaţia propusă în Figura 6.1 permite vizualizarea unei abstractizări, independent de limbajul de programare şi de o manieră care permite evidenţierea celor mai importante părţi ale abstractizării: numele, atributele şi operaţiile clasei.

Numele unei claseFiecare clasă trebuie să aibă un nume care o identifică în mod unic, printre alte clase. Un nume de clasă este

un şir de caractere care se poate prezenta în două moduri: nume simplu sau nume cu cale. Un nume simplu de clasă se poate observa în Figura 6.2a. Un nume cu cale, asociat unei clase, se poate observa în Figura 6.2b, el indicând, ca un prefix la numele clasei, pachetul în care este rezidentă clasa.

Figura 6.2. Specificarea numelui unei clae în UML

Un nume de clasă poate fi un şir de caractere de orice lungime, care conţine litere, cifre şi semne de punctuaţie, cu excepţia simbolului ”::”, utilizat pentru a separa numele clasei de pachetul sau lanţul de pachete care o include. Evident, este necesar un compromis rezonabil între lungimea numelui şi puterea lui de sugestie. În practică, numele unei clase se obţine prin juxtapunerea mai multor cuvinte care pot dezvălui semantica clasei respective. De exemple, PoligonAbstract, TriunghiEchilateral, FereastraDeDialog, etc. Se observă cum, pentru mai multă lizibilitate, fiecare cuvânt din structura numelui începe cu literă mare.

Atributele unei claseUn atribut este numele unei proprietăţi ( a unei clase) care abstractizează un domeniu de valori pe care

instanţele proprietăţii le pot lua.O clasă poate avea orice număr de atribute sau, la limită, nici un atribut.Un atribut desemnează, astfel, o anumită proprietate a realităţii modelate, proprietate partajată de toate

instanţele realităţii respective. Ca formalizm de reprezentare, atributele sunt listate în compartimentul situat imediat sub numele clasei, ca în Figura 6.3.

În funcţie de nivelul de abstractizare al clasei (conceptualizare, specificare, implementare), atributele pot fi listate doar ca nume, dar pot fi listate şi ca nume, împreună cu tipul definitor şi, eventual, o valoare iniţială. ca în Figura 6.4.

Poligon

coordonate

perimetru()aria()afisare()

nume clasă

atribute

operaţii

Client java::awt::Rectangle

(a) (b)

Page 42: Ingineria soft

Figura 6.3. Atributele unei clase

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

Figura 6.4. Atribute, complet caracterizate

Operaţiile unei claseO operaţie este abstractizarea unui serviciu, care poate fi solicitat oricărui obiect al unei clase. Este

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

Figura 6.5. Operaţiile unei clase

În practică, regulile de formare şi reprezentare a numelor operaţiilor sunt asemănătoare celor folosite în cazul atributelor. O operaţie poate fi reprezentată şi la nivel de signatură, care se poate referi la: nume, tipul returnat, lista parametrilor şi valorile lor implicite, ca în Figura 6.6. În Figura 6.6 am folosit secvenţa “...” pentru a indica faptul că lista operaţiilor este, în mod conştient, incompletă. Această secvenţă, împreună cu posibilitatea de a organiza listele de atribute sau operaţii, prea lungi, în categorii descriptive, folosind stereotipurile, contribuie la o mai bună mapare a potenţialului de descriere al unei clase peste nevoile de reprezentare specifice unui punct de vedere al specialistului în IS.

Student

natricolnumePrenumeadresadataNasterii

Lista atributelor

Student

natricol : string[4]numePrenume: string[40]adresa: TAdresadataNasterii: TDatasex: char=’F’

Lista atributelor

Lista operaţiilor

Student

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

Page 43: Ingineria soft

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

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

Figura 6.7. Utilizarea stereotipurilor

Se cuvine să reamintim faptul că stereotipul este unul dintre mecanismele de extensie, de bază, ale UML-ului, cu ajutorul căruia putem îmbogăţi, progresiv, însăşi semantica limbajului. Asupra acestui mecanism de extensie vom mai reveni.

Responsabilităţile unei claseO responsabilitate este abstractizarea textuală a unui serviciu furnizat de o clasă. Este deja lămurit

faptul că, la definirea unei clase, este foarte importantă supoziţia că toate obiectele acestei clase au acelaşi comportament.

Această afirmaţie, la un nivel de abstractizare mai înalt, înseamnă că atributele şi operaţiile sunt doar nişte elemente-suport pentru îndeplinirea responsabilităţilor clasei. Responsabilităţile unei clase, în cazul în care sunt definite, sunt listate într-un compartiment situat la baza simbolului grafic al clasei, ca în Figura 6.8

În practică, elaborarea modelului claselor poate începe prin specificarea responsabilităţilor entităţilor candidate, înregistrate în vocabularul realizat în faza de analiză a cerinţelor. În acest scop se pot folosi tehnici precum card-urile CRC1 sau analiza bazată pe contexte de utilizare. În procesul de rafinare a modelului claselor, responsabilităţile sunt traduse într-un set de atribute şi operaţii care asigură îndeplinirea optimă a responsabilităţilor.

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

Lista operaţiilor

Student

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

Student

<<constructor>>student()student(m:string[4])

<<proces>>modificAdresa(a:Adresa)...

<<query>>esteValid():booleanafisez()

<<iterator>>pentruToti(as:^Student)...

Page 44: Ingineria soft

Figura 6.8. Responsabilităţile unei clase

6.2 RelaţiiÎn modelarea obiect-orientată există trei tipuri de relaţii care sunt considerate foarte importante:

dependenţele, care abstractizează relaţiile de utilizare existente între clase (rafinarea, versionarea, legarea); generalizările, care leagă clasele generalizate de specializările lor şi asocierile, care reprezintă relaţiile structurale dintre obiecte. Formalizmul UML pentru reprezentarea acestor trei tipuri de relaţii, precum şi maniera de utilizare, pot fi urmărite, pentru început, în Figura 6.9. Error: Reference source not found

Figura 6.9. Reprezentarea relaţiilor în UMLRelaţia de dependenţăAşa cum am mai precizat, o dependenţă este o relaţie de utilizare care exprimă faptul că o schimbare în

specificarea unei entităţi (de exemplu, clasa Event) poate afecta altă entitate care o foloseşte ( de exemplu, clasa Window). După cum vom vedea în Capitolul 3, există un număr semnificativ de stereotipuri, aplicabile relaţiilor de dependenţă dintre entităţile unui model UML.

Dacă se consideră necesar, relaţia de dependenţă poate avea un nume, care ajută la discriminarea ei într-un context în care mai sunt şi alte dependenţe, ceea ce ajută la referirea mai uşoară a dependenţei, în caz de nevoie.

Relaţia de generalizareO generalizare este o relaţie între o entitate generală (numită superclasă sau clasă părinte) şi o varietate

specifică a acelei entităţi (numită subclasă sau clasă copil)). În literatura de specialitate, generalizarea mai este desemnată şi prin sintagma „relaţie is a kind of”. Generalizarea înseamnă că obiectele copil pot fi folosite oriunde pot apare obiecte părinte. Altfel spus, generalizarea ne asigură de faptul că un copil poate fi un substitut al părintelui său, nu şi invers. Trivial, dar trebuie să reamintim (pentru cei care nu sunt documentaţi suficient asupra paradigmei obiect-orientate) faptul că un copil moşteneşte toate proprietăţile părintelui (în mod esenţial, atributele şi operaţiile). Adesea, dar nu întotdeauna, copilul are atribute şi/sau operaţii adiţionale. O operaţie a unui copil care are aceeaşi signatură cu o operaţie a părintelui se spune că suprascrie (redefineşte) operaţia părintelui, procedeu prin care se pun bazele polimorfismului.

Relaţia de asociereO asociere este o relaţie structurală care specifică faptul că instanţele unei clase sunt conectate la

instanţele altei clase. Conectarea de care am vorbit mai sus, trebuie înţeleasă astfel: dată o instanţă a a clasei A, în clasa B poate fi găsită cel puţin o instanţă b, astfel încât perechea (a,b) abstractizează o anumită cerinţă a modelului în curs de elaborare. Într-un anumit sens putem vorbi de navigare de la un obiect al unei clase către un obiect al altei clase şi invers, dacă cele două clase sunt în relaţie de asociere. O asociere la care participă exact două clase se numeşte asociere binară. Deşi nu este o situaţie uzuală, pot exista şi asocieri la care participă mai mult de două clase. Astfel de asocieri se numesc asocieri n-are. Formalizmul pentru reprezentarea unei asocieri poate fi dedus analizând Figura 6.10.

În practică, numele unei asocieri nu este obligatoriu, fiind folosit pentru a spori claritatea modelului.

Lucrează pentruPersoana Firma

asociere

sensul navigăriinume asociere

Student

Responsabilities

creare studenţiactualizare date personale studenţivalidare date personale studenţi

...

Page 45: Ingineria soft

Figura 6.10. Numele unei asocieriRelaţia de agregareO asociere obişnuită între două clase reprezintă, aşa cum am spus, o relaţie structurală între egali,

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

Figura 6.11. Exemplu de agregareDupă cum sugerează şi Figura 6.11, agregarea este o relaţie care, în esenţă, înseamnă că un obiect al

clasei întreg constă din unul sau mai multe obiecte ale clasei parte în relaţia de agregare. Evident că, putem întâlni şi situaţii în care clasa întreg agregă mai multe clase parte. Cred, de asemenea, că este în folosul cititorului să afle faptul că o agregare nu reprezintă nimic altceva decât o potenţială relaţie întreg-parte, neprecizând nimic în ceea ce priveşte competenţele instanţelor întreg relativ la crearea şi distrugerea instanţelor parte.

6.3 Mecanisme comuneAnunţată în Capitolul 1, reluăm în acest paragraf problema mecanismelor comune. Să ne amintim,

aşadar, faptul că UML este mai uşor de înţeles şi aplicat dacă înţelegem importanţa celor patru mecanisme comune: specificaţiile, ornamentele, separările comune şi mecanismele de extindere. Voi prezenta, în cele ce urmează, modul de utilizare în procesul de modelare a două dintre aceste mecanisme comune: ornamentele şi mecanismele de extindere.

OrnamenteleForţând puţin exprimarea, dată fiind şi lipsa unui cuvânt nou pentru o semantică parţial nouă, pentru a

conţine cât mai multă semantică şi pentru a transmite, diferitelor persoane interesate, cât mai mult din această semantică, modelele UML sunt „împodobite” cu o serie de elemente adiţionale formalizmului de bază. Ornamentele asociate modelelor UML sunt de două tipuri: note şi ornamente pentru vizualizarea şi detalierea specificării.

Ne amintim că o notă este un simbol grafic folosit pentru redarea constrângerilor sau comentariilor ataşate unui element sau unei colecţii de elemente. Formalizmul pentru o notă UML poate fi revăzut în Figura 6.12.

*

1

Companie

Departament

întregul

agregarea

partea

multiplicităţi

legătură la document

încapsulare URLtext simplu

Această componentă va fi livrată cel mai târziu în 13/02/04

A se vedeahttp://www.rational.com

A se vedea Heap.doc pentru detalii asupra acestui algoritm

Page 46: Ingineria soft

Figura 6.12. Moduri de utilizare a notelor

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

Mecanismele UML de extindereStereotipurileDupă cum am văzut, UML furnizează un limbaj pentru capturarea şi reprezentarea semanticii următoarelor

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

StereotipurileReferindu-ne la aria claselor, un stereotip nu este similar cu o clasă părinte într-o relaţie de generalizare

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

Figura 6.13. Exemple de stereotipuri utile în modelarea claselorDupă cum reiese din Figura 6.13, un stereotip este recunoscut după numele lui, situat între simbolurile

<<...>>, dedesubtul căruia se află numele concret al modelului.

<<Boundary>>

PreluareDateStudent

<<Entity>>

PrelucrareDateStudent

<<Control>>

SupervizareBE

Page 47: Ingineria soft

Valorile etichetateFiecare entitate UML are propriul set de proprietăţi: clasele au nume, atribute şi operaţii; asocierile au

nume şi două sau mai multe capete cu propriile lor proprietăţi, etc. După cum am văzut, folosim stereotipurile pentru a adăuga soluţiei noastre entităţi noi. Pentru a adăuga proprietăţi noi entităţilor, folosim valorile etichetate. În practică, valorile etichetate pot fi folosite pentru a păstra diferite informaţii despre proprietăţile entităţilor. Astfel, informaţii de interes pentru managementul unui proiect (data creării unui model, starea dezvoltării lui, autorul, etc.) sau informaţii de interes în procesul de instalare a unei aplicaţii (memoria internă necesară, memoria externă necesară, limita inferioară a frecvenţei procesorului, etc.) sunt două exemple uzuale de utilizare a valorilor etichetate. Formalizmul de prezentare a valorilor etichetate este , transparent prezentat în Figura 6.14.

După cum se poate observa în Figura 6.14, valorile etichetate apar între acolade ca secvenţe de tipul:

{<etichetă>=<valoare>}

dacă informaţiile sunt adăugate direct pe entitatea vizată, sau, folosind ca suport nota ataşată, urmând aceeaşi sintaxă, dacă este vorba de informaţii care se referă la mai multe entităţi, de exemplu.

ConstrângerileEste de domeniul evidenţei, probabil, faptul că orice construcţie sintactică în UML are propria ei

semantică. De exemple, într-o relaţie de generalizare operează principiul substituţiei care afirmă că un obiect al clasei copil poate substitui un obiect al clasei părinte, dar nu şi invers. Acest „dar nu şi invers” este o constrângere, de care trebuie să fim conştienţi când lucrăm cu o ierarhie de clase.

Utilizând constrângerile, putem, de asemenea, să adăugăm semantici noi modelelor sau să modificăm regulile fundamentale după care operează modelele. În ultimă analiză, o constrângere specifică o serie de condiţii care trebuie îndeplinite pentru ca modelul să fie corect. Formalizmul după care adăugăm constrângeri modelelor este deductibil din Figura 6.15.

În general, specificarea constrângerilor poate fi realizată folosind un limbaj textual, liber în expresie. Dacă se doreşte mai multă rigoare în specificarea constrângerilor se poate apela la OCL (Object Constraint Language), un standard care însoţeşte specificarea completă a UML-ului. Acest standard poate fi găsit în documentaţia pusă la dispoziţie de firma Rational pe site-ul www.rational.com.

Error: Reference source not found

Page 48: Ingineria soft

Figura 6.14. Utilizarea valorilor etichetateError: Reference source not found

Figura 6.15. Exemple de constrângeri

6.4 DiagrameIntroducere

În paragraful 5.3 am precizat deja rolul diagramelor (ca entităţi cu funcţii de grupare) în organizarea şi vizualizarea blocurilor constructive ale unui model UML. În practică s-a dovedit, deja, faptul că realizarea unor diagrame de calitate contribuie la o mai bună înţelegere, atât a soluţiei cât şi a sistemului modelat. Necesitatea diagramelor în modelarea UML are o justificare mult mai profundă decât cea prezentată mai sus. Una dintre provocările importante în procesul de modelare a comportamentului unui sistem se numeşte stăpânirea complexităţii. Există motive de natură conceptuală dar şi motive de natură managerială pentru care, în ingineria softului, se practică abordarea sistemică, cu necesara infuzie de elemente specifice. Aşa se face că, la anumite nivele de abstractizare a soluţiei UML a unei probleme, se va vorbi în termeni de sisteme, subsisteme, modele şi diagrame care grupează aceste modele după principii şi reguli specifice diferitelor perspective întâlnite în arhitectura soluţiei UML a unui sistem soft. Aşa cum am mai spus, în UML există nouă tipuri de diagrame, utilizate pentru gruparea modelelor care descriu aspectele statice sau dinamice ale unui sistem.

Pentru descrierea aspectelor statice avem:

1. Diagrame ale claselor2. Diagrame ale obiectelor3. Diagrame ale componentelor4. Diagrame de desfăşurare

Pentru descrierea aspectelor dinamice avem:

1. Diagrame ale contextelor de utilizare2. Diagrame de secvenţă3. Diagrame de colaborare4. Diagrame de hărţi de stare5. Diagrame de activitate

*

*

* 0..1

ContPersonal

Şef

lucrator

angajat angajator

* ContFirma 1Cont Firma

Persoana

{XOR}

Persoana Firma

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

Page 49: Ingineria soft

Abilitatea de a realiza diagrame de tipurile mai sus precizate, coerente, corecte şi eficiente este tot ceea ce îşi doreşte, în ultimă instanţă, un specialist în IS, în relaţia cu UML. Fără această abilitate, mânuirea, cu randament, a tool-urilo precum Rational Rose, ObjectiF, etc. este un vis imposibil. Diagrame structurale

Cele patru tipuri de diagrame structurale UML servesc la vizualizarea, specificarea, construirea şi documentarea aspectelor statice ale unui sistem. Prin aspecte statice ale unui sistem înţelegem relaţiile invariante dintre componentele sistemului. Referindu-ne la ingineria softului, din perspectivă UML, aspecte statice ale soluţiei unui sistem soft sunt: relaţiile dintre clase, interfeţele, colaborările, ansamblul structurat al componentelor, topologia hard care susţine execuţia sistemului. Odată definite relaţiile dintre clase, introducem un element de stabilitate, necesară pentru a putea continua efortul de realizare a soluţiei. Odată specificate interfeţele, clienţii lor se pot ocupa, în linişte, de aspectele legate de utilizarea lor, etc..

Diagrame ale claselorO diagramă a claselor expune un ansamblu de clase, interfeţe şi colaborări, împreună cu relaţiile dintre

ele. Diagramele claselor reprezintă tipul de diagramă cel mai des întâlnit în modelarea sistemelor obiect orientate. Folosim diagramele claselor pentru a evidenţia perspectiva design (structurală) a sistemului . De asemenea, putem observa faptul că diagramele claselor care includ clase active sunt utile pentru a evidenţia aspectele statice ale perspectivei proces a unui sistem.

Diagrame ale obiectelorO diagramă a obiectelor expune un ansamblu de obiecte, împreună cu relaţiile dintre ele. Folosim

diagramele obiectelor pentru a ilustra structuri de date, instantanee statice ale instanţelor entităţilor din diagramele claselor. Într-o oarecare măsură, se subânţelege faptul că diagramele obiectelor sunt destinate evidenţierii perspectivei design (statică) sau perspectivei proces (statică) a unui sistem, cum se întâmplă şi în cazul diagramelor claselor, dar luând în obiectiv instanţe din lumea reală. Scopul unor astfel de diagrame este de a sublinia, prin infuzia aferentă de concret, semantica diagramelor claselor la care se raportează.

Diagrame ale componentelorO diagrama a componentelor expune un ansamblu de componente, împreună cu relaţiile dintre ele.

Folosim acest tip de diagramă pentru a ilustra aspectele statice ale perspectivei implementaţionale a unui sistem. Diagramele componentelor se află în legătură cu diagramele claselor, datorită faptului că, în mod normal, o componentă se mapează pe una sau maai multe clase, interfeţe sau colaborări.

Diagrame de desfăşurareO diagramă de desfăşurare expune un ansamblu de noduri, împreună cu relaţiile dintre ele. Folosim

acest tip de diagramă pentru a ilustra aspectele statice ale perspectivei desfăşurare a hard-ului care susţine execuţia unui sistem soft. Diagramele de desfăşurare se află în legatură cu diagramele componentelor, datorită faptului că, în mod uzual, un nod conţine una sau mai multe componente.

Diagrame comportamentaleDupă cum am văzut, există cinci tipuri de diagrame care pot fi folosite pentru a modela dinamica

(comportamentul) unui sistem soft.

1. Diagramele contextelor de utilizare (use case)Acestea sunt diagrame care organizează comportamentul sistemului2. Diagramele de scevenţă (sequence diagram)Acestea sunt diagrame care se focalizează pe ordonarea în timp a mesajelor schimbate între obiecte.3. Diagramele de colaborare (collaboration diagram)Acestea sunt diagrame care se focalizează pe organizarea structurală a obiectelor, care trimit şi primesc mesaje.4. Diagramele hărţi de stare (statechart diagram)Acestea sunt diagrame care se focalizează pe schimbările de stare ale unui sistem dirijat de evenimente.5. Diagramele de activitate (activity diagram)Acestea sunt diagrame care se focalizează pe fluxul de control în procesul de trecere de la o activitate la alta.

Diagramele contextelor de utilizare

Page 50: Ingineria soft

O diagramă context de utilizare expune un ansamblu de contexte de utilizare şi actori (care pot fi socotiţi un gen special de clasă), împreună cu relaţiile eferente. Putem folosi diagramele context de utilizare pentru a ilustra aspecte statice ale contextelor de utilizare a unui sistem (diferite tipuri de relaţii între contextele de utilizare) dar, mai ales, pentru a prefigura organizarea şi modelarea comportamentului unui sistem.

Diagrame de secvenţăO diagramă de secvenţă este o diagramă de interacţiune, care evidenţiază ordonarea în timp a mesajelor

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

Diagrame de colaborareO diagramă de colaborare este o diagramă de interacţiune care pune accent pe organizarea structurală a

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

Diagrame hărţi de stare (DHS)O DHS este o maşină de stare în structura căreia intră elemente precum: stările obiectelor, tranziţiile,

evenimentele şi activităţile care pot fi asociate acestor obiecte. Evident, şi DHS sunt importante pentru a reprezenta perspectiva dinamică a unui sistem. Mai mult, putem spune că DHS sunt utile pentru a accentua comportamentul dirijat de evenimente al unui obiect, lucru absolut necesar în modelarea sistemelor reactive.

Diagrame de activitateO diagramă de activitate expune fluxul activităţilor din interiorul unui sistem (flux care poate fi

secvenţial sau ramificat) precum şi obiectele asupra cărora acţionează, sau de care sunt demarate aceste activităţi. Diagramele de activitate sunt importante pentru modelarea funcţiei unui sistem, ca flux de control, în dinamica activităţilor unui obiect sau a unui ansamblu de obiecte-partenere la rezolvarea unei probleme.

Diagrame ale claselorDiagrama claselor este tipul de diagramă care nu poate lipsi din soluţia obiect orientată a unui sistem

soft. Cum am mai spus, o diagramă a claselor este o diagramă care expune un ansamblu de clase, interfeţe şi colaborări precum şi relaţiile dintre acestea. Formalizmul grafic de reprezentare al unei diagrame a claselor se exprimă sintetic în formula „colecţie de noduri şi arce”. O diagramă de clase are un nume (ca orice alt tip de diagramă UML) şi o reprezentare grafică, care depinde de structura entităţilor conţinute:

clase (prezenţă obligatorie şi esenţială în orice diagramă a claselor);interfeţe (prezenţă strict necesară când se modelează în spiritul obiectelor (componentelor)

programabile, care separă net interfeţele de implementarea lor;colaborări (este vorba de colaborări din perspectivă structurală, care pot fi numite „piesele mari” ale

unei diagrame a claselor);dependenţe, generalizări, relaţii de asociere.

Asemenea altor tipuri de diagrame, diagramele claselor pot conţine note şi constrângeri. Dacă necesităţile de abstractizare o impun, diagramele claselor pot conţine pachete sau subsisteme, fiecare dintre acestea fiind utilizate pentru a grupa elemente ale modelului în curs de elaborare, obţinându-se blocuri constructive cu o semantică specifică, accesibilă unui anumit tip de „beneficiar”. Uneori, diagramele claselor pot conţine şi instanţe.

Încercând un răspuns la întrebarea „Pentru ce elaborăm diagramele claselor?”, reamintesc faptul că intenţia lor declarată este de a modela aspectele statice ale perspectivei design (structurale). Mergând ceva mai departe, trebuie să subliniez faptul că cerinţele funcţionale ale unui sistem soft trebuie să se mapeze convenabil peste ansamblul modelelor care compun perspectiva design. De aceea se obişnuieşte să se afirme că stabilitatea structurală a design-ului static este esenţială pentru longevitatea şi calitatea unei soluţii.

Din punctul de vedere al practicii, utilizăm diagramele claselor în una din situaţiile următoare:

Page 51: Ingineria soft

Suntem preocupaţi de modelarea vocabularului sistemului Dorim să modelăm o colaborare Dorim să modelăm schema logică a unei baze de date

Modelarea vocabularului unui sistemAceastă activitate implică o serie de decizii relativ la abstracţiile care sunt părţi componente ale sistemului

în curs de modelare şi care vor rămâne în afara frontierei sistemului. Folosim diagrame de clase pentru a vizualiza şi specifica aceste abstracţii şi responsabilităţile lor în cadrul sistemului.

Modelarea unei colaborăriO colaborare este o comuniune de clase, interfeţe şi alte elemente care lucrează împreună pentru a asigura

un comportament, care înseamnă mai mult decât suma mecanică a comportamentelor elementelor care participă la colaborare (putem vorbi, astfel, despre necesitatea valenţelor sinergetice ale unei colaborări). Folosim diagrame de clase pentru a vizualiza şi specifica astfel de colaborări. Un exemplu de colaborare, simplă, poate fi urmărit în Figura 6.16. Figura 6.16 prezintă un set de clase, considerate esenţiale pentru implementarea unui robot autonom. Figura se focalizează asupra claselor implicate în mecanismul de deplasare a robotului pe un traseu. Evident, există mai multe clase implicate în simularea comportamentului unui robot autonom. Diagrama din Figura 36 se concentrează asupra abstracţiilor care sunt direct implicate în deplasarea robotului. Ne putem, lesne, imagina că există şi abstracţii preocupate, de exemplu, de gestiunea conflictelor care pot apare în timpul deplasării robotului, în anumite condiţii de mediu. Vor exista, prin urmare, şi alte colaborări în mulţimea claselor care descriu, din punct de vedere static, comportamentul unui robot autonom. Pentru a simplifica procesul de înţelegere a sistemului, este recomandabil procedeul separării mai multor colaborări, cu relativă coeziune internă şi obiective specifice de îndeplinit.

Modelarea schemei logice a unei baze de datePrin schemă logică a unei baze de date înţelegem rezultatul proiectării conceptuale a bazei de date (De

exemplu, modelul relaţional al unei baze de date, adus la o formă normală convenabilă). Sunt numeroase aplicaţiile în careavem nevoie de asigurarea persistenţei informaţiilor, utilizând baze de date relaţionale sau baze de date obiect orientate. Schema logică a unei baze de date poate fi modelată folosind diagrame de clase, ca în Figura 6.17.În Figura 6.17 se poate observa utilizarea valorii etichetate {persistent} pentru a indica faptul că obiectele claselor în cauză sunt persistente. Totodată, se poate observa strategia de definire a comportamentului claselor, care presupune amplasarea operaţiilor utile în manipularea obiectelor unei clase, în clasa de nivel de persistenţă imediat superioară (cum este cazul în relaţia dintre clasa Facultate şi clasa Catedra).

Error: Reference source not found

AgentTraseu

Responsabilitiescăutare traseuevitare obstacole

SenzorColiziuni

Driver

Motor de Cârmă MotorPrincipal

Motor

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

Page 52: Ingineria soft

Figura 6.16. Modelarea unei colaborări simple între clase, în UMLError: Reference source not found

Figura 6.17. Modelarea schemei logice a unei baze de date

Câteva observaţii de luat în seamă când elaborăm o diagramă a claselorO diagramă a claselor bine structurată va ţine cont de următoarele cerinţe:

Focalizarea pe un anumit aspect al perspectivei design view; este ştiut faptul că perspectiva design view a întregului sistem poate fi reprezentată în mai multe diagrame ale claselor;

Cuprinderea doar a elementelor care sunt esenţiale pentru a înţelege respectivul aspect; Furnizarea de detalii, conforme nivelului de abstractizare şi ataşarea doar a ornamentelor strict

necesare; Nu va avea niciodată atâtea omisiuni încât să rişte informarea greşită a cititorului asupta semanticii

importante a clasei.Complementar cerinţelor de mai sus putem accepta următoarele reguli de stil:

Asocierea unei diagramei de clase cu un nume sugestiv (care să deconspire semantica diagramei); Expunerea elementelor diagramei astfel încât să reducem la minimum liniile care se intersectează; Folosirea notelor şi a culorilor, ca pârghii vizuale de dirijare a atenţiei asupra aspectelor importante ale

diagramei.

Page 53: Ingineria soft

7 MODELAREA ASPECTELOR COMPORTAMENTALE. ELEMENTE-SUPORT FUNDAMENTALE

7.1 InteracţiuniÎntr-un sistem, interesant din punct de vedere comportamental, obiectele interacţionează între ele utilizând ca tehnică de bază transmiterea de mesaje.Se numeşte interacţiune un comportament care se exprimă printr-o serie finită de mesaje, schimbate între obiectele situate în interiorul unui anumit context, pentru îndeplinirea unui anumit scop.

În practica modelării vom folosi interacţiunile pentru a modela aspecte dinamice ale colaborărilor, care reprezintă uniuni de obiecte jucând roluri specfice, cooperând pentru realizarea unui anumit comportament, despre care putem spune, cu rezerva de rigoare, că este mai mare decât suma mecanică a elementelor.

Aceste roluri reprezintă instanţe prototipice ale claselor, interfeţe, componente, noduri şi contexte de utilizare. Aspectele lor dinamice sunt vizualizate, specificate, construite şi documentate ca fluxuri de control care pot cuprinde fire de execuţie secvenţiale, precum şi fluxuri mai complexe, care implică ramificări, iteraţii, recursii sau concurenţă.

Putem modela o interacţiune în două moduri: prin accentuarea ordonării în timp a mesajelor (obţinând modele numite diagrame de secvenţă) sau prin accentuarea secvenţării mesajelor în contextul unor colecţii structurate de obiecte (obţinând modele numite diagrame de colaborare).

Este evident faptul că interacţiunile bine structurate sunt asemenea algoritmilor bine structuraţi: eficiente, simple, adaptabile şi inteligibile.

Să mai subliniem faptul că putem folosi interacţiunile pentru a modela fluxuri de control în interiorul unor operaţii, clase, componente, contexte de utilizare sau la nivelul sistemului ca întreg. Utilizând diagramele de interacţiune, putem reflecta asupra acestor fluxuri în două moduri. Mai întâi, ne putem focaliza atenţia asupra modului în care sunt expediate mesajele în timp. În al doilea rând, ne putem concentra atenţia asupra relaţiilor structurate dintre obiectele aflate într-o interacţiune şi, pe acest temei, să considerăm modul în care mesajele circulă între componentele contextului structurat.

UML furnizează o reprezentare grafică a mesajului, aşa cum se poate vedea în Figura 7.1.

7.2 Concepte vehiculate în modelarea interacţiunilor7.2.1 Contextul în care se manifestă interacţiunile

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

Cel mai adesea, descoperim interacţiuni în colaborarea obiectelor care există în contextul sistemului sau subsistemului modelat.

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

De exemplu, subsistemul Planificarea activităţii didactice din cadrul sistemului informaţional al unei facultăţi este contextul în care instanţe ale unor clase, precum StatDeFuncţii, PlanDeÎnvăţământ, FormaţieDeLucru vor interacţiona pentru a „contribui” la rezolvarea problemei orarului semestrial al grupelor de la fiecare specializare şi, de ce nu, al fiecărui profesor în parte.

Interacţiuni între obiecte descoperim şi în procesul de implementare a unei operaţii. Parametrii unei operaţii, orice variabilă obiect locală operaţiei şi orice obiecte globale (dar încă vizibile operaţiei) pot interacţiona pentru a materializa algoritmul corespunzător implementării operaţiei.

CitesteUrmNote()

{ordered}

1:PrelNotMat(n)

f:Foaia_Matricola n:Note

număr de secvenţă mesaj

obiect legătură obiect

Page 54: Ingineria soft

Astfel, invocarea operaţiei suma() care simulează adunarea a două numere mari, fiecare număr fiind o instanţă a clasei NumarMare, este evident că poate fi implementată astfel încât invocarea să aibă sintaxa:

nr1.suma(nr2)ceea ce inseamnă interacţiune între obiectul global nr1, obiectul transmis prin lista de parametrii ( nr2 ) şi

un obiect local operaţiei, folosit pentru a genera obiectul sumă pe care îl va returna operaţia suma().În al treilea şi ultimul rând, descoperim interacţiuni în contextul unei clase. Altfel spus, putem folosi

interacţiunile pentru a vizualiza, specifica, construi şi documenta semantica unei clase. Revenind la exemplul clasei NumarMare, pentru a ilustra comportamentul obiectelor acestei clase, putem imagina interacţiuni care arată cum colaborează atributele acestei clase pentru a permite îndeplinirea responsabilităţilor asumate de clasă, la specificare.

Obiecte şi roluriObiectele care participă într-o interacţiune sunt sau lucruri concrete sau lucruri prototipice. În calitate de

lucru concret, un obiect reprezintă un aspect din lumea reală. De exemplu, p, o instanţă a clasei Persoana poate desemna o persoană particulară, ca lucru concret, sau o instanţă oarecare a clasei Persoana, ca lucru prototipic.

LegăturiO legătură este o conexiune semantică între obiecte. În general, o legătură este o instanţă a unei asocieri.

Aşa cum rezultă şi din Figura 68, în momentul în care o clasă are o asociere cu altă clasă, putem avea şi o legătură între instanţele celor două clase; odată ce există o legătură între două obiecte, unul dintre ele poate trimite un mesaj celuilalt.

O legătură specifică o cale de-a lungul căreia un obiect poate trimite un mesaj altui obiect sau chiar lui însuşi.

De cele mai multe ori, este suficient să specificăm faptul că o astfel de cale există. Dacă este nevoie de mai multă precizie în ceea ce priveşte această cale, putem ornamenta capătul potrivit al legăturii cu unul din următoarele stereotipuri standard:

<<association>> - specifică faptul că obiectul corespunzător este vizibil prin asociere; <<self>> - specifică faptul că obiectul corespunzător este vizibil deoarece el este executantul operaţiei; <<global>> - specifică faptul că obiectul corespunzător este vizibil deoarece aparţine unui domeniu

acoperitor; <<local>> - specifică faptul că obiectul corespunzător este vizibil deoarece aparţine unui domeniu

local; <<parameter>> - specifică faptul că obiectul corespunzător este vizibil în calitate de parametru.

Figura 7.2 Asociere şi legătură

MesajePresupunem că avem o colecţie de obiecte şi un set de legături care conectează aceste obiecte. Un astfel de

model este un model static care poate fi asimilat cu o diagramă de obiecte. Diagramele de obiecte modelează starea colecţiei de obiecte, la un moment dat şi sunt folositoare atunci când dorim să vizualizăm, să specificăm, să construim sau să documentăm o structură statică de obiecte.Să presupunem, acum, că dorim să modelăm schimbarea stării unei colecţii de obiecte de-a lungul unei perioade de timp.Dacă, prin absurd, am putea imagina un procedeu de „fotografiere” a colecţiei de obiecte, la intervale succesive de timp, atunci ar trebui să observăm: obiecte care schimbă mesaje între ele, provoacă evenimente şi invocă operaţii. În plus faţă de perspectiva asociată scenariului de mai sus, ne putem propune vizualizarea explicită a stării curente şi a rolului instanţelor individuale.

afectare(financiar)

*1..*

angajatorangajat

Persoana

afectare (d:Departament)

Firma

p:Persoana :Firma

Page 55: Ingineria soft

Un mesaj este specificarea unei comunicări între obiecte, care transmite informaţia necesară pentru producerea unei activităţi. Primirea unei instanţe mesaj poate fi considerată o instanţă a unui eveniment. Ca urmare a formulării unui mesaj, o acţiune răspuns va fi declanşată. O astfel de acţiune poate produce o schimbare de stare.

În UML pot fi modelate următoarele tipuri de acţiuni: Call – invocarea unei operaţii a unui obiect; un obiect îşi poate transmite lui însuşi un mesaj, ceea ce

este interpretat ca invocare locală a unei operaţii; Return – întoarcerea unei valori la apelant; Send – expedierea unui semnal către un obiect; Create – crearea unui obiect; Destroy – distrugerea unui obiect; un obiect se poate, la nevoie, autodistruge.

UML oferă o notaţie care permite deosebirea, sub aspect vizual, a acestor tipuri de acţiuni, care pot fi asociate unui mesaj. O primă prespectivă asupra acestei notaţii poate fi observată în Figura 7.3, care este, anticipând, o diagramă de secvenţă.

Error: Reference source not found

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

Figura 7.3, deşi ipotetică conţine elementele fundamentale pentru a înţelege importanţa noţiunii de mesaj în reprezentarea interacţiunilor dintre obiecte. Obiectul c (de tip Client) creează un obiect anonim de tip AgentBilete (folosind un mesaj asociat cu o acţiune stereotipizată create); obiectul c apelează metoda setItinerar() a obiectului anonim de tip AgentBilete (care primeşte ca parametru, un obiect i de tip Itinerar); obiectul anonim apelează propria metodă calculRuta() pentru a determina elementele caracteristice ale rutei. Următorul mesaj este asociat cu o acţiune de tip return, după care urmează distrugerea obiectului anonim de către obiectul i. În sfârşit, avem şi un exemplu de trimitere a unui semnal de la c la p.Cititorul atent şi curios simte infuzia de semantică dintr-o astfel de diagramă, precum şi numeroasele probleme, încă neclare, asupra cărora va trebui să revenim în continuare.

SecvenţareÎn practica descrierii interacţiunilor dintre obiecte, un obiect trimite un mesaj altui obiect; receptorul, la

rândul lui, trimite un mesaj altui obiect ş.a.m.d. Acest potenţial flux de mesaje formează o secvenţă. Orice secvenţă are un început, care este localizat într-un proces sau fir de execuţie. Secvenţa poate să fie activă, cel mult cât timp este activ procesul sau firul de execuţie.

Fiecare proces şi fir de execuţie din interiorul unui sistem defineşte un flux de control distinct şi în interiorul fiecărui flux mesajele sunt ordonate în secvenţe care ţin cont de succesiunea lor în timp. Pentru o mai bună vizualizare a scevenţelor de mesaje, în UML putem modela explicit „ordinea de intrare” a mesajului, relativ la începutul secvenţei din care face parte, prin prefixarea mesajului cu un număr de secvenţă, separat cu simbolul „:” de mesaj. De domeniul uzualului este să specificăm fluxuri de control procedurale, redate folosind o săgeată de tipul celei din Figura 7.4.

ruta

create

call

notificare()

<<destroy>>

calculRuta()setItinerar(i)

<<create>>

c:Client p:AsistentPlanificare

:AgentBilete

send

call (invocare locală)

return

destroy

Page 56: Ingineria soft

Error: Reference source not found

Figura 7.4. Secvenţă procedurală

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

Error: Reference source not found

Figura 7.5. Secvenţă plata

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

Crearea, modificarea şi distrugerea obiectelorÎn majoritatea cazurilor, obiectele care participă într-o interacţiune există atâta timp cât există şi

interacţiunea. Totuşi, în anumite interacţiuni, obiectele pot fi create şi/sau distruse în intervale de timp cuprinse strict între începutul şi terminarea interacţiunii. La fel stau lucrurile şi în cazul legăturilor dintre obiecte. Pentru a indica faptul că un obiect sau o legătură intră într-o interacţiune şi/sau părăseşte interacţiunea, putem ataşa elementului vizat una din următoarele constrângeri:

new - specifică faptul că instanţa sau legătura este creată pe timpul execuţiei inetracţiunii care o include;

destroyed - specifică faptul că instanţa sau legătura este distrusă înainte de terminarea execuţiei interacţiunii care o include;

transient - specifică faptul că instanţa sau legătura este creată pe timpul execuţiei interacţiunii care o include, dar este distrusă înainte de terminarea execuţiei.

În sfârşit, dacă într-o interacţiune, un obiect suportă modificări ale valorilor atributelor lui, modificări de stare sau de rol, fiecare variantă a obiectului poate apare pe aceeaşi linie a vieţii, variantele diferite putând fi, eventual, conectate cu mesaje marcate de stereotipul become.

Reprezentarea unei interacţiuniAm vazut deja faptul că o interacţiune pune probleme de semantică şi de notaţie. Din punct de vedere

semantic, o interacţiune poate pune accent pe ordonarea în timp a mesajelor (ceea ce ne conduce la realizarea de diagrame de secvenţă) sau pe accentuarea organizării structurale în interiorul interacţiunii, ceea ce conduce la realizarea digramelor de colaborare.

Aceste două tipuri de diagrame sunt, în mare parte izomorfe, conversia de la un tip la altul făcându-se fără pierdere de informaţie.

Din punct de vedere al notaţiei este important să semnalăm prezenţa şi semnificaţia liniei vieţii unui obiect într-o diagramă de secvenţă, element care oferă suport pentru reprezentarea în timp a existenţei unui obiect.

De asemenea, diagramele de colaborare permit modelarea legăturilor structurale care există între obiecte.

2.2:Insert(m)

2.2

2:selectN(S)

2.1:m=CalcMed()

s:Student n:Note f:FoaieMa-ricola

2:generare(o)

1:procesare(p)

p:Persoana o:OreLucrate

f:Fluturas

Page 57: Ingineria soft

7.3 Contexte de utilizare7.3.1 Elemente introductive

Deşi nu au explicitat întotdeauna acest lucru, specialiştii în ingineria softului au acţionat conform principiului: „Înainte de a realiza un lucru nou, trebui să hotărăşti cum îl vei folosi (= care este valoarea lui de întrebuiţare)”?

Pare de neconceput, dar adevărul este că multă vreme nu s-a sesizat importanţa covărşitoare a problematizării şi formalizării temeinice a principiului mai sus formulat. Specificare de cerinţe s-a făcut, într-o formă sau alta, dintotdeauna în industria softului. Ceea ce separă optica UML, în ceea ce priveşte specificarea cerinţelor, de alte limbaje de modelare este „unghiul din care se face specificarea cerinţelor”. UML spune răspicat: „înainte de a gândi la soluţia unui sistem soft, determină, cu maximum de acurateţe, tipul utilizatorului acestui sistem soft”.

Încerc să sugerez faptul că tipul utilizatorului este o abstracţie în care se reflectă o serie de cerinţe funcţionale specifice dar şi o serie de cerinţe aşa zis nefuncţionale. Un sistem soft „burduşit” cu cerinţe funcţionale, expuse ignorând cele mai elementare reguli de proiectare a unor interfeţe ergonomice, nu va putea înfrunta niciodată un sistem echivalent funcţional dar cu interfaţa ergonomică.

După cum sugerează şi perspectiva UML asupra arhitecturii unui sistem soft, în centrul efortului de dezvoltare a soluţiei unui sistem soft, utilizând UML, se află perspectiva context de utilizare (use case). Perspectiva context de utilizare va descrie comportamentul unui sistem soft aşa cum este el văzut de către „end-user-i”, analişti şi „tester-i”.

Un element cheie în crearea contextelor de utilizare este abilitatea de a spune ce face contextul de utilizare fără a specifica nimic despre implementarea lui. Astfel că putem concluziona faptul că un context de utilizare specifică un comportament dorit (de end-user-i), fără a impune nimic relativ la modul în care va fi implementat acest comportament. Marele câştig al unui astfel de demers constă în faptul că un context de utilizare permite, în egală masură utilizatorilor finali şi experţilor în domeniu, să comunice cu specialiştii în ingineria softului, care lucrează la soluţia sistemului soft, în cadrul căreia a fost specificat contextul de utilizare.

Pentru moment, un context de utilizare descrie un set de secvenţe, în care fiecare secvenţă reprezintă interacţiunea entităţilor din afara sistemului (actorii lui) cu sistemul însuşi (şi abstracţiile lui eseţiale) . De fapt, comportamentele astfel specificate sunt funcţii de nivel sistem, utilizate pentru a vizualiza, specifica, construi şi documenta comportamentul scontat al sistemului în timpul fazei de identificare şi analiză a cerinţelor.

Un context de utilizare reprezintă o cerinţă funcţională a sistemului ca întreg. Ca un exemplu, un context de utilizare important într-o firmă care produce automobile este Gestiunea vânzărilor.

Un context de utilizare implică interacţiunea dintre actori şi sistem. Un actor reprezintă un set coerent de roluri, pe care utilizatorii contextului de utilizare le joacă în timp ce interacţionează cu acesta . Poate fi actor o fiinţă umană, un alt sistem soft sau un anumit tip de sistem automat, capabil de interacţiune.

În majoritatea proceselor de dezvoltare a unor sisteme soft găsim contexte de utilizare care sunt versiuni specializate ale altor contexte de utilizare, contexte de utilizare care sunt considerate ca părţi ale altor contexte de utilizare şi contexte de utilizare care extind comportamentul unor contexte de utilizare, care definesc „miezul/coloana vertebrală” a comportamentului sistemului. Pentru a clasifica şi organiza comportamentele contextelor de utilizare, în spiritul reutilizării, apelăm la cele trei tipuri de relaţii, mai sus precizate: generalizarea, includerea şi extinderea.

Un context de utilizare îndeplineşte, în mod normal, o sarcină concretă. Din perspectiva unui actor dat, un context de utilizare poate efectua nişte calcule, poate furniza nişte rezultate, poate prelua nişte date de intrare, etc.

Contextele de utilizare pot fi identificate la nivelul întregului sistem, dar şi la nivelul componentelor sistemului (subsisteme, clase, interfeţe).

În fiecare caz este important să reţinem următoarea idee: „Contextele de utilizare reprezintă comportamentul scontat al sistemului sau al componentelor acestuia, furnizând, în acelaşi timp, elemente fundamentale pentru testarea acestor componente în timpul procesului de dezvoltare. Contextele de utilizare aplicate la nivelul subsistemelor sunt surse ideale pentru testele desfăşurate asupra soluţiei în curs de elaborare.

Aplicate la nivelul întregului sistem, contextele de utilizare sunt surse excelente pentru efortul de integrare şi testare a sistemului.

UML furnizează o reprezentare grafică simplă pentru actori şi contextele de utilizare. Această notaţie permite vizualizarea unui context de utilizare separat de realizarea lui şi în comuniune cu alte contexte de utilizare. Fundamentele notaţiei aferente contextelor de utilizare sunt prezentate în Figura 7.6.

Page 58: Ingineria soft

Error: Reference source not found

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

7.3.2 Concepte UML din sfera contextelor de utilizareDupă cum am menţionat deja, un context de utilizare este o descriere a unui set de secvenţe de acţiuni,

incluzând variante, pe care sistemul le execută pentru a produce un rezultat observabil, aşteptat de un actor; reprezentarea grafică a unui context de utilizare este realizată cu ajutorul unei elipse.

Numele contextelor de utilizareFiecare context de utilizare trebuie sa aibă un nume, care îl distinge de alte contexte de utilizare. Acest

nume este un şir de caractere care poate fi asimilat cu un nume simplu, dacă apare singur. Dacă numele apare prefixat de numele pachetului în care contextul de utilizare este rezident, atunci vom vorbi despre un nume cu cale. Exemple în Figura 7.7.

Figura 7.7. Numele contextelor de utilizare UML

Contextele de utilizare şi actoriiUn actor reprezintă un set coerent de roluri pe care utilizatorii unui context de utilizare le joacă când

interacţionează cu acesta. În mod obişnuit, un actor reprezintă un rol pe care o fiinţă umană, un dispozitiv periferic sau chiar alt sistem îl joacă în relaţia cu sistemul căruia îi este asociat contextul de utilizare cu care comunică actorul. De exemplu, un lucrător la o bancă ar putea, abstractizat ca actor, să joace rolul de Agent-de-Împrumuturi; dacă, pe de altă parte, suntem interesaţi să abstractizăm rolul unui client în relaţia cu banca, putem reflecta asupra unui actor numit Client. O instanţă a unui actor reprezintă o interacţiune individuală specifică cu sistemul în cauză. Deşi în modelele UML apar actori, aceştia nu sunt consideraţi părţi ale sistemului, fiind rezidenţi în afara sistemului. Reprezentaţi grafic sub forma unor omuleţi stilizaţi, actorii suportă, atunci când este cazul relaţia de generalizare, ca în Figura 7.8.

Actorii pot fi conectaţi la un context de utilizare numai prin asociere. O asociere între un actor şi un context de utilizare precizează faptul că între aceste entităţi există o relaţie de comunicare, în sensul că fiecare poate trimite sau primi mesaje.

Să mai subliniem faptul că, apelând la mecanismele UML de extensie putem stereotipiza un actor pentru a introduce o notaţie diferită, în ideea că aceasta reprezintă o replică vizuală mai adecvată scopurilor noastre de moment.

Contextele de utilizare şi fluxurile de evenimenteUn context de utilizare descrie ce face un sistem dar nu specifică cum face sistemul ceea ce are de făcut. În

general, în procesul de modelare a soluţiei unei probleme, este foarte importantă abilitatea de a distinge interfaţa unui sistem ( ce face? ) de implementarea lui (cum face?).

context de utilizare

Decan

actor

nume actor

Consultare planuri de invatamant

nume context de utilizare

Validare utilizator

Financiar::PreluarePontaj

nume simplu nume cu cale

Page 59: Ingineria soft

Error: Reference source not found

Figura 7.8. Actorii în UML

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

Exemplificăm cu un scenariu asociat contextului de utilizare ValidareUtilizator, din cadrul unui sistem soft care gestionează o reţea de bancomate.

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

Flux excepţional de evenimente: Clientul poate anula o tranzacţie în orice moment prin apăsarea butonului Cancel, fapt care restartează contextul de utilizare. Într-o astfel de situaţie nu se efectuează nici o modificare asupra contului Clientului.

Flux excepţional de evenimente: Clientul poate şterge codul PIN, în orice moment care precede terminarea introducerii prin apăsarea tastei Enter având astfel posibilitatea să reia introducerea codului PIN.

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

Contextele de utilizare şi scenariileÎn practică există obişnuinţa de a descrie, la început, textual, fluxul de evenimente asociat unui context de

utilizare. Pe măsură ce înţelegerea cerinţelor faţă de sistem se rafinează (=intră în detalii), se pot utiliza diagrame de interacţiune pentru a specifica vizual acest flux de evenimente. De regulă, se poate apela la diagrame de secvenţă pentru specificarea fluxurilor principale de evenimente şi variaţiuni ale acestor diagrame pentru a specifica fluxurile excepţionale de evenimente ale unui context de utilizare.

Este de dorit să separăm fluxurile principale de fluxurile alternative deoarece un context de utilizare descrie un set de secvenţe, nu doar o singură secvenţă şi de cele mai multe ori este destul de dificil să surprindem toate detaliile unui context de utilizare complex într-o singură secvenţă.

De exemplu, sistemul informaţional al unei instituţii de învăţământ superior poate include contextul de utilizare ÎnmatriculareStudenţi. În practică, însă, se ştie că operaţia de înmatriculare se poate derula în mai multe ipostaze:

ClientPersoanaJuridicaClientPersoanaFizica

Clientgeneralizare

actor

actor

Page 60: Ingineria soft

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

2. Studenţii admişi la aceeaşi specializare în alte universităţi, pot fi înmatriculaţi, în anumite condiţii;

3. Studenţii admişi la specializări înrudite ca profil, în aceeaşi universitate, pot fi înmatriculaţi, în anumite condiţii, etc.

Este evident faptul că descrierea contextului de utilizare ÎnmatriculareStudenţi trebuie să ia în consideraţie mai multe variante, fiecare variantă având asociată propria secvenţă de acţiuni. În acest caz, fiecare secvenţă se numeşte scenariu. Vom numi scenariu o secvenţă specifică de acţiuni care ilustrează o variantă de comportament a unui context de utilizare. Din altă perspectivă privind lucrurile, un scenariu este, în relaţia cu contextul de utilizare gazdă, ceea ce este un obiect în relaţia cu clasa lui definitoare.

Contextele de utilizare şi colaborărileAşa cum am menţionat deja, un context de utilizare reprezintă comportamentul unui sistem (al unui

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

La nivel înalt de abstractizare , putem specifica explicit realizarea unui context de utilizare de către o colaborare ca în Figura 7.9.Error: Reference source not found

Figura 7.9. Realizarea unui context de utilizare

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

Organizarea contextelor de utilizareContextele de utilizare pot fi organizate prin gruparea lor în pachete, în acelaşi mod în care procedăm cu

clasele.Organizarea contextelor de utilizare poate fi realizată şi apelând la relaţiile de generalizare, includere şi

extindere.În esenţă, toate aceste tipuri de relaţii sunt utilizate pentru a partaja comportamente comune.

Relaţia de generalizareGeneralizarea între contexte de utilizare este asemănătoare generalizării dintre clase. Mai exact, aceasta

înseamnă că orice context de utilizare copil moşteneşte comportamentul şi semantica contextului de utilizare părinte; copilul poate adăuga elemente de comportament noi sau poate suprascrie comportamentul părintelui. De asemenea, părintele poate fi substituit de oricare dintre copii lui (dacă ne exprimăm în termeni de instanţe).

De exemplu, în sistemul informaţional al unei bănci putem avea un context de utilizare Validare utilizator (responsabil de verificarea identităţii unui utilizator). Putem, de asemenea, avea doi copii specializaţi ai acestui context de utilizare (Verificare parolă şi Scanare retină). Fiecare dintre aceste două contexte se comportă la fel ca Validare utilizator, putând fi aplicate oriunde apare Validare utilizator, în plus, fiecare putând adăuga propriul comportament (primul, prin verificarea unei parole textuale, al doilea prin verificarea şablonului retiniar unic al utilizatorului).

Gestiune planuri

Consultare planuri de învăţământ

colaborare realizare context de utilizare

Page 61: Ingineria soft

Notaţia pentru relaţia de generalizare este cunoscută de la generalizarea între clase.

Relaţia de includereO relaţie de includere între contexte de utilizare se referă la faptul că un context de utilizare de bază

încorporează explicit comportamentul unui alt context de utilizare la o locaţie specificată în bază. Contextul de utilizare inclus nu poate opera singur niciodată, ci doar instanţiat ca parte a unui context de utilizare de bază, care îl include.

Folosim relaţia de includere pentru a evita descrierea aceluiaşi flux de evenimente de mai multe ori, prin descrierea comportamentului comun într-un context de utilizare separat, care va fi inclus în unul sau mai multe contexte de utilizare de bază. O relaţie de includere se reprezintă ca o relaţie de dependenţă marcată cu stereotipul include. În descrierea asociată contextului de utilizare de bază, includerea este marcată ca în exemplul de mai jos.

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

Relaţia de extindereO relaţie de extindere într contexte de uilizare se referă la faptul că un context de utilizare de bază

încorporează implicit comportamentul unui alt context de utilizare, la o locaţie specificată indirect de contextul de utilizare care realizează extinderea.

Folosim relaţia de extindere pentru a modela o parte a unui context de utilizare pe care utilizatorul o percepe ca fiind un comportament opţional al sistemului. În acest mod, separăm comportamentul opţional de comportamentul imperativ.

O relaţie de extindere este redată ca o relaţie de dependenţă, marcată cu stereotipul extend. Punctele de extensie pot fi precizate ca simple etichete în fluxul principal de evenimente, ca mai jos:

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

În exemplul de mai sus setare_drepturi_suplimentare este un punct de extensie. Ideea este că, pentru un utilizator obişnuit se face validarea parolei, configurarea standard a sesiunii şi începerea sesiunii. Pentru un utilizator cu privilegii, va fi executat un context de utilizare care permite stabilirea resurselor suplimentare necesare utilizatorului.

7.4 Diagrame de contexte de utilizareDiagramele de contexte de utilizare sunt unul din cele cinci tipuri de diagrame folosite în UML pentru

modelarea aspectelor dinamice ale sistemelor (celelalte patru tipuri sunt: diagramele de colaborare, diagramele de secvenţă, diagramele hărţi de stare, diagramele de activitate). Diagramele de contexte de utilizare sunt esenţiale pentru modelarea comportamentului unui sistem, subsistem sau al unei clase. Fiecare diagramă de contexte de utilizare expune un set de contexte de utilizare, împreună cu actorii asociaţi lor, precum şi relaţiile dintre aceste elemente.

Concepte UML utilizate în sfera diagramelor de contexte de utilizareO diagramă de contexte de utilizare este un tip de diagramă care afişează proprietăţi comune altor tipuri de

diagrame: asocierea cu un nume şi un conţinut grafic care realizează un anumit tip de proiecţie într-un model. Conţinutul grafic deosebeşte diagramele de contexte de utilizare de alte tipuri de diagrame.

Conţinutul unei diagrame de contexte de utilizareÎn mod uzual, diagramele de contexte de utilizare conţin:

Contexte de utilizare Actori Relaţii de dependenţă, generalizare şi/sau asociere.

Ca oricare alt tip de diagramă, ele mai pot conţine note şi constrângeri.

Page 62: Ingineria soft

În sfârşit, diagramele de contexte de utilizare mai pot conţine pachete, folosite pentru a grupa elementele modelului în unităţi mai mari, cu scopul de a mări lizibilitatea modelului.

Uneori, diagramele de contexte de utilizare pot conţine şi instanţe ale contextelor de utilizare, îndeosebi când dorim să vizualizăm un sistem specific de execuţie.

Scurtă notă, relativ la ingineria directă şi inversă a diagramelor UMLIngineria directă este procesul de transformare a unui model în cod, în conformitate cu limbajul ales pentru

implementare, transformare realizată de către un „tools” care „înţelege” modelarea UML.Ingineria inversă este operaţia prin care, pornind de la cod, putem obţine modelul UML asociat.Ambele operaţii urmăresc asigurarea unei mapări benefice a soluţiei UML a unei probleme, peste soluţia-

limbaj de implementare ţintă şi invers. Avantajele sunt evidente, atât în cazul ingineriei directe cât şi în cazul ingineriei inverse.

Revenind la lumea contextelor de utilizare, trebuie să spunem că, spre deosebire de alte tipuri de diagrame (diagrame de clase, diagrame de stare, etc., candidate evidente la ingineria directă şi inversă, având corespondenţe la nivelul sistemului executabil), diagramele de contexte de utilizare sunt puţin diferite, în sensul că ele mai mult reflectă decât specifică implementarea unui sistem, subsistem, etc. Un context de utilizare descrie cum se comportă un element, nu cum este implementat comportamentul, motiv pentru care nu poate fi supus, în mod natural unei operaţii de inginerie directă sau inversă.

7.5 Diagrame de interacţiuneDiagramele de secvenţă şi diagramele de colaborare – numite, împreună, diagrame de interacţiune, sunt,

după cum am mai spus, două din cele cinci tipuri de diagrame folosite de UML pentru modelarea aspectelor dinamice ale sistemelor.

Diagramele de interacţiune sunt importante nu doar pentru modelarea aspectelor dinamice ale unui sistem ci şi pentru obţinerea codului executabil, atât prin inginerie directă cât şi prin ingineria inversă.

Conceptele vehiculate în procesul de elaborare şi înţelegere a diagramelor de interacţiuneO diagramă de interacţiune expune o interacţiune, determinată de o mulţime de obiecte, împreună cu

relaţiile dintre ele, inlcuzând şi mesajele care pot fi schimbate între aceste obiecte.O diagramă de secvenţă este o diagramă de interacţiune care pune accent pe ordonarea în timp a mesajelor. Ca formalism de reprezentare, o diagramă de secvenţă poate fi asimilată cu un tabel care expune obiectele aranjate de-a lungul axei absciselor şi mesajele ordonate după evoluţia în timp de-a lungul axei ordonatelor.O diagramă de colaborare este o diagramă de interacţiune care pune accent pe organizarea structurală a obiectelor care trimit sau recepţionează mesaje. Ca formalism de reprezentare, o diagramă de colaborare este o colecţie de noduri şi arce.Să mai precizez, în această fază a prezentării, faptul că, asemenea tuturor tipurilor de diagrame, diagramele de interacţiune au un nume şi un conţinut grafic, care, de altfel, face distincţia între diagramele de interacţiune şi alte tipuri de diagrame.

Conţinutul unei diagrame de interacţiuneÎn mod uzual, o diagramă de interacţiune conţine:

obiecte legături mesaje

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

Diagrame de secvenţăCum am mai spus, o diagramă de secvenţă pune accent pe ordonarea în timp a mesajelor. Cum se poate

vedea şi în Figura 7.10, realizarea unei diagrame de secvenţă presupune, plasarea, pentru început, a obiectelor care participă la interacţiune, în partea de sus a diagramei, de-a lungul axei absciselor, figurată simbolic.

Page 63: Ingineria soft

Error: Reference source not found

Figura 7.10. Diagramă de secvenţă

În mod normal, obiectul cel mai din stânga va fi obiectul care declanşează interacţiunea, urmat, spre dreapta, de celelalte obiecte, în ordinea participării la interacţiune. Urmează, precizarea mesajelor pe care aceste obiecte le expediază şi le receptează, de-a lungul axei ordonatelor, figurată, de asemenea, simbolic.

Alinierea mesajelor se face, de sus în jos, în ordinea crescătoare a timpului în care sunt emise, obţinându-se o redare vizuală clară a fluxului de control, în timp.

Diagramele de secvenţă au două caracteristici care le deosebesc de diagramele de colaborare.Mai întâi, este vorba despre linia vieţii obiectului. O linie a vieţii unui obiect este o linie verticală

întreruptă, care reprezintă existenţa unui obiect de-a lungul unei perioade de timp. Majoritatea obiectelor care apar într-o diagramă de interacţiune vor avea durata de viaţă cât timp există interacţiunea, prin urmare, aceste obiecte vor fi aliniate în partea de sus a diagramei; pentru aceste obiecte linia vieţii acoperă toată verticala diagramei, începând de la obiect în jos. Pot exista şi obiecte care sunt create pe timpul interacţiunii, la primirea unui mesaj purtând marca stereotipului create. Pentru aceste obiecte linia vieţii începe din momentul receptării mesajului (a se observa linia vieţii pentru obiectul m, în Figura 76). Obiectele pot fi distruse pe timpul interacţiunii. Linia vieţii pentru un astfel de obiect se termină odată cu primirea mesajului purtând marca stereotipului destroy, moment marcat prin prezenţa unui X lărgit, care punctează terminarea liniei vieţii (a se observa linia vieţii pentru obiectul m, în Figura 7.10).

În al doilea rând, este vorba despre focalizarea controlului pe un obiect. Focalizarea controlului pe un obiect este indicată printr-un dreptunghi înalt şi de lăţime mică, prin care se figurează perioada de timp în care un obiect execută o acţiune, directă sau dintr-o procedură subordonată. Partea de sus a dreptunghiului coincide cu startul acţiunii; partea de jos este asociată cu terminarea acţiunii şi poate fi însoţită de un mesaj de tip return (cum se întâmplă în Figura 7.10, la terminarea acţiunii obiectului n; de observat şi forma particulară a săgeţii în cazul unui mesaj de tip return).

Imbricarea focalizării controlului (datorită apelurilor recursive, apelului unei self-operaţii, etc.) poate fi redată cu ajutorul unor dreptunghiuri desenate uşor la dreapta focus-ului părinte, ca în Figura 7.11.Error: Reference source not found

Figura 7.11. Imbricarea focalizării controlului

Tim

pul

return

<<destroy>>

insert(m)

prelNote(m)setDatePer()

<<create>>

s:Student m:FoaieMatricola n:Note

linia vieţii

f:FluxFoiMatricole

Obiecte

Page 64: Ingineria soft

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

Diagrame de colaborareO diagramă de colaborare pune accent pe organizarea obiectelor care participă la o interacţiune. După cum

se poate vedea şi în Figura 7.12, realizarea unei diagrame de colaborare poate începe prin reprezentarea obiectelor care participă la interacţiune, în calitate de vârfuri ale unui graf. În al doilea rând, se adaugă legăturile dintre obiecte, în calitate de arce ale grafului. În sfârşit, legăturile în cauză sunt îmbogăţite semantic prin ataşarea de mesaje pe care obiectele le trimit sau le primesc.

În acest fel, persoana care urmăreşte o diagramă de colaborare beneficiază de indicaţii vizuale clare relativ la fluxul de control al interacţiunii, fără a pierde din vedere organizarea structurală a obiectelor care colaborează.Error: Reference source not found

Figura 7.12. Diagramă de colaborare

Diagramele de colaborare au două caracteristici care le deosebesc de diagramele de secvenţă. Mai întâi, este vorba de indicarea modului în care un obiect este legat de altul (=calea de acces la obiect).

În acest scop, putem ataşa legăturii un stereotip de cale la capătul unei legături, indicând natura vizibilităţii obiectului vizat, pentru obiectul care expediază mesajul. În Figura 7.12, f este global pentru m, de exemplu.

În al doilea rând, este vorba de sistemul de secvenţare prin ataşare de numere de secvenţă explicite. Pentru a specifica ordonarea în timp a mesajelor, mesajul este prefixat cu un număr (începând cu mesajul numărul 1), incrementând cu o unitate prefixul fiecărui mesaj nou (2,3,...).

În situaţia în care avem imbricare de mesaje, se apelează la numerotarea zecimală Dewey (ceea ce înseamnă că, dacă 1 este primul mesaj, atunci 1.1 poate fi primul mesaj imbricat în 1, 1.2 este al doilea mesaj imbricat în 1, etc. ). Se poate vizualiza imbricarea mesajelor pe oricâte nivele dorim. După cum se vede şi în Figura 7.12, de-a lungul aceleeaşi legături putem reprezenta mai multe mesaje (eventual cu direcţii de expediere diferite) dar având numere de secvenţă unice.

De cele mai multe ori, în practică modelăm fluxuri de control secvenţiale. Atunci când este cazul , putem modela şi fluxuri de control mai complexe (iteraţii sau ramificări). O iteraţie înseamnă o secvenţă repetată de mesaje. Pentru a modela o iteraţie, trebuie să prefixăm numărul de secvenţă al mesajului cu o expresie iteraţie de tipul [i:=1..n] sau, pur şi simplu * dacă dorim să semnalăm prezenţa iteraţiei fără a specifica alte detalii.

O iteraţie indică faptul că mesajul vizat şi orice mesaj imbricat vor fi repetate în conformitate cu expresia asociată iteraţiei.

Pentru a indica mesaje cu execuţie condiţionată, mesajele în cauză pot avea numărul de secvenţă prefixat cu o clauză de condiţie, de tipul [x0]. Un mesaj alternativ va avea acelaşi număr de secvenţă, dar prefixat de o condiţie în relaţia de SAU EXCLUSIV cu celelalte mesaje având acelaşi număr de secvenţă.

UML nu impune o anumită sintaxă pentru expresiile din interiorul parantezelor drepte. Putem folosi convenţii pseudocod sau sintaxă specifică unui anumit limbaj de programare.

Page 65: Ingineria soft

Scurtă notă relativ la ingineria directă şi inversă a diagramelor de interacţiune.Ingineria directa (=obţinerea codului pornind de la model) este posibilă pentru ambele tipuri de diagrame

de interacţiune, îndeosebi, atunci când contextul diagramei este o operaţie. Cantitatea şi acurateţea codului generat depinde atât de „inteligenţa” softului care procesează modelul (în cazul nostru diagrama de interacţiune) cât şi de cantitatea şi acurateţea informaţiei conţinută de model.

Este previzibil faptul că ne aflăm într-un stadiu de abstractizare în care mai sunt încă mulţi paşi de făcut pentru a mapa eficient modelul pe codul care îl implementează.

Ingineria inversă (=crearea modelului pornind de la cod) este, de asemenea, posibilă, pentru ambele tipuri de diagrame de interacţiune, îndeosebi atunci când codul în cauză este implementarea unei operaţii.

7.6 Diagrame de activitate O diagramă de activitate este, în esenţă, o schemă care descrie fluxul de control, în procesul trecerii de la

o activitate la alta. Folosim diagrame de activitate pentru a modela aspecte dinamice ale sistemelor. În cele mai multe situaţii, aceasta înseamnă modelarea paşilor secvenţiali (uneori concurenţiali) ai unui proces de calcul.

De asemena, putem folosi diagrame de activitate pentru a modela trecerea unui obiect dintr-o stare în alta, prin punctele specifice fluxului de control.

Diagramele de activitate pot fi utilizate pentru a vizualiza, specifica, construi şi documenta aspecte dinamice ale unei societăţi de obiecte sau pentru a modela fluxul de control specific unei operaţii . În vreme ce diagramele de interacţiune pun accent pe fluxul de control fundamentat pe trecerea, într-o anumită ordine, de la un obiect la altul, diagramele de activitate pun accent pe fluxul de control care urmăreşte trecerea, într-o anumită ordine, de la o activitate la alta. Prin activitate desemnăm o prelucrare neatomică, în curs de desfăşurare în interiorul unei maşini cu stări. Calculatoarele reale sunt exemple remarcabile de maşini cu stări, privite, de exemplu, din punct de vedere al modului în care funcţionează procesorul. Ideea de neatomic subliniază faptul că din punct de vedere al maşinii cu stări pe care se mapează activitatea, aceasta poate fi descompusă. În ultimă analiză, activităţile sunt secvenţe de acţiuni atomice (neîntreruptibile din punct de vedere al modului în care funcţionează maşina cu stări) care au ca rezultat schimbări în starea sistemului sau returnarea unei valori. Diagramele de activitate sunt importante nu doar pentru modelarea aspectelor dinamice ale unui sistem ci şi pentru construirea sistemelor executabile prin inginerie directă sau inversă.

Concepte folosite în realizarea diagramelor de activitatePrin cele spuse mai sus am anticipat, deja, faptul că o diagramă de activitate expune un anumit flux de

activităţi. Am menţionat deja ce se înţelege prin activitate şi prin acţiune.Din punct de vedere al reprezentării, o diagramă de activitate poate fi privită ca o colecţie de noduri şi arce. Pentru conformitate, să menţionăm şi faptul că o diagramă de activitate, asemenea celorlaltor tipuri de

diagrame, are un nume şi un conţinut grafic specific.

Conţinutul unei diagrame de activitateÎn mod vizual, o diagramă de activitate conţine:

stări de activitate şi stări de acţiune; tranziţii; obiecte.

În esenţă, o diagramă de activitate este o proiecţie a elementelor care pot fi găsite într-un graf de activitate, care este un caz particular de maşină de stare, în care toate tranziţiile sunt declanşate de terminarea activităţiilor în starea sursă.

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

Evident, asemenea tutror celorlaltor diagrame, diagramele de activitate mai pot conţine şi constrângeri.

Stări de acţiune şi stări de activitateÎn fluxul de control modelat de o diagramă de activitate, se întâmplă diferite lucruri. Se pot evalua expresii

pentru a seta valorile unor atribute sau pentru a returna o valoare. Se poate apela o operaţie a unui obiect, se poate trimite un semnal unui obiect, se poate crea sau distruge un obiect.

Aceste operaţii atomice, executabile pe un calculator real, se numesc stări de acţiune deoarece sunt stări ale sistemului, fiecare dintre ele reprezentând execuţia unei acţiuni.

O stare de acţiune se reprezintă ca în Figura 7.13.Stările de acţiune nu pot fi descompuse. Mai mult chiar, stările de acţiune sunt atomice, ceea ce, la modul

consistent, înseamnă că chiar dacă apar evenimente, ele nu pot fi întrerupte.

Page 66: Ingineria soft

Error: Reference source not found

Figura 7.13. Stări de acţiune

Pe de alta parte, stările de activitate pot fi, ulterior descompuse, activitatea lor putând fi reprezentată de alte diagrame de activitate. Stările de activitate nu sunt atomice, ceea ce înseamnă că pot fi întrerupte şi execuţia lor are durată în timp.

După cum se vede în Figura 80, nu există deosebire de notaţie esenţială între stările de acţiune şi activitate, cu excepţia faptului că starea de activitate poate conţine elemente adiţionale, precum: acţiunile iniţiale şi finale sau specificările de submaşini.

TranziţiileÎn momentul în care o acţiune sau o activitate este terminată fluxul de control este preluat de următoarea

acţiune sau activitate. Trecerea de la o stare la alta se numeşte tranziţie şi se reprezintă ca o linie simplă orientată (a se vedea Figura 7.14).

Semantic vorbind, acest gen de tranziţii, se numesc tranziţii fără declanşator sau de terminare, deoarece controlul trece de la starea sursă la starea destinaţie de îndată ce acţiunea/activitatea din starea sursă este terminată.

Error: Reference source not found

Figura 7.14. Reprezentarea tranziţiilor în UML

În momentul în care acţiunea unei stări sursă date este terminată, se va executa acţiunea specifică ieşirii, dacă există vreuna. După care, necondiţionat, are loc tranziţia către următoarea acţiune sau activitate. Urmează executarea acţiunii specifice intrării în noua stare (dacă există) şi executarea acţiunii/activitaţii asociate noii stări, etc. Există situaţii în care fluxul de control evoluează nedefinit, dar există şi foarte multe situaţii în care acesta încetează la întâlnirea unei stări finale.

Notaţiile pentru starea iniţială şi starea finală pot fi observate în Figura 7.14.Ramificarea (branching) şi unirea (merge)Tranziţiile secvenţiale, simple, sunt destul de obişnuite, dar nu sunt singurele întâlnite în procesul de

modelare a fluxurilor de control. La fel ca în cazul schemelor logice (hărţile de fluxuri – flowchart-uri), putem apela la ramificări pentru a specifica tranziţii alternative, ghidate de o anumită expresie booleană. O ramificare, se introduce, din punct de vedere al notaţiei, ca un romb; poate avea o singură tranziţie la intrare şi două sau mai multe tranziţii la ieşire. Pe fiecare tranziţie de ieşire se indică o expresie booleană, evaluată la intrarea în ramificare. Evident, expresiile boolene asociate tranziţiilor care ies dintr-o ramificare (numite şi expresii de gardă) trebuie să fie mutual exclusive. Un exemplu, în Figura 7.15.

Se mai adaugă şi faptul că simularea unei iteraţii este destul de simplă, folosind ramificarea.Diagrama din Figura 7.15 poate fi completată, ca semantică şi din punct de vedere al notaţiei, ca în Figura

7.16.

starea de start

starea finală

stări de acţiune tranziţii

Page 67: Ingineria soft

Error: Reference source not found

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

Error: Reference source not found

Figura 7.16. Un exemplu complet de ramificare

Bifurcare (fork) şi imbricare (join)Tranziţiile secvenţiale şi ramificările sunt elementele cel mai frecvent întâlnite în diagramele de activitate.

Cu toate acestea, atât în modelarea fluxurilor de lucru dintr-o organizaţie, cât şi în anumite tipuri de aplicaţii, care mizează pe multitasking, apare problema fluxurilor de activităţi concurente. În UML, putem utiliza o bară de sincronizare pentru a specifica bifurcarea şi imbricarea fluxurilor de control paralele. O bară de sincronizare se redă ca o linie orizontală sau verticală, îngroşată, după cum se vede şi în Figura 7.17, în care prezint un exemplu dintr-o lucrare de licenţă a unui fost student.

Diagrama din Figura 7.17 ne indică posibilitatea ca activităţiile GătirePizza, PreparareSos şi DestupareSticlăVin să se desfăşoare în paralel, deci sunt introduse folosind bifurcaţia. Dintre aceste trei activităţi, care pot avea fire de execuţie paralele (ca să mai colorăm puţin expunerea), două dintre ele (GătirePizza şi PreparareSos) trebuie să fie terminate înainte de a se trece la combinare (de aici necesitatea primei îmbinări).

Tot în Figura 7.17 se mai observă şi posibilitatea, naturală, de altfel, de a introduce fire de execuţie condiţionate.

Participarea la ospăţ poate să aibă succes şi cu sau fără vin, conform diagramei din Figura 7.17.

unire (merge, în engleză)

[else]

[există suma]

Do verificareCont(s)

Do afisareStareCont()

Do tranzactie(s)

ramificarea(branch, în engleză)

expresii de gardă

Page 68: Ingineria soft

Error: Reference source not found

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

[se doreşte vin]

bifurcaţia

GătirePizza PreparareSos

DestupareSticlăVin

Combinare

îmbinări

Page 69: Ingineria soft

Teme pentru proiecte la disciplina Ingineria softului

1. Folosind sintaxa UML, specificaţi cerinţele faţă de un sistem soft care automatizează fluxurile informaţionale ale unei case de schimb valutar.

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

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

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

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

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

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

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

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

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

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

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

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

14. Elaboraţi arhitectura UML a soluţiei problemei informatizării fluxurilor informaţionale ale unui birou notarial.

Page 70: Ingineria soft

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

[2] Bocu, D., Bocu, R., Modelare obiect orientată cu UML. Fundamentele modelării cu UML. Inițiere în șabloane de proiectare utilizând sintaxă UML, Editura Albastră, Cluj Napoca, 2006[3] Bocu, D., Inițiere în ingineria sistemelor soft, Editura Albastră, Cluj Napoca, 2002 [4] Booch, G., Rumbaugh, J., Jacobson, I., The Unified Modeling Language User Guide, Addison-Wesley, 1999

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

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

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

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

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

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

Page 71: Ingineria soft

CUPRINS 1 Probleme a căror rezolvare depinde esenţial de ingineria sistemelor soft........................................................3

1.1 Ce este ingineria sistemelor soft?...............................................................................................................31.2 Ce este un sistem soft?................................................................................................................................41.3 Probleme cu care se confruntă specialiştii în IS.........................................................................................6

2 Ce este o metodologie de dezvoltare a softului?.............................................................................................122.1 De ce avem nevoie de MDS?....................................................................................................................122.2 Încercare de caracterizare a unei metodologii generice de dezvoltare a softului.....................................13

3 Ciclul de viaţă al unui sistem soft...................................................................................................................183.1 Ciclul de viaţă al sistemelor soft. Încă o introducere................................................................................183.2 Ciclul de viaţă al sistemelor soft. Câteva exemple...................................................................................18

3.2.1 Modelul cascadă( MC)....................................................................................................................193.2.2 Modelul V (MV).............................................................................................................................203.2.3 Modelul prototipizării (MP)............................................................................................................203.2.4 Concluzii.........................................................................................................................................22

4 Abstractizarea soluţiei unui sistem soft...........................................................................................................244.1 Modelarea. Limbaje de modelare.............................................................................................................244.2 Arhitectura unui limbaj de modelare........................................................................................................28

5 Modelarea obiect orientatĂ cu UML..............................................................................................................305.1 Ce este UML(fără a intra în detalii)?........................................................................................................305.2 Date esenţiale pentru înţelegerea UML....................................................................................................315.3 Scurtă incursiune în universul conceptual al UML..................................................................................34

6 Modelarea aspectelor structurale. Elemente-suport fundamentale.................................................................416.1 Clase.........................................................................................................................................................416.2 Relaţii........................................................................................................................................................446.3 Mecanisme comune..................................................................................................................................456.4 Diagrame...................................................................................................................................................48

Introducere......................................................................................................................................................48Diagrame structurale.......................................................................................................................................49Diagrame comportamentale............................................................................................................................50Diagrame ale claselor......................................................................................................................................50

7 Modelarea aspectelor comportamentale. Elemente-suport fundamentale......................................................547.1 Interacţiuni................................................................................................................................................547.2 Concepte vehiculate în modelarea interacţiunilor....................................................................................54

7.2.1 Contextul în care se manifestă interacţiunile..................................................................................54Obiecte şi roluri...............................................................................................................................................55Legături...........................................................................................................................................................55Secvenţare.......................................................................................................................................................56Crearea, modificarea şi distrugerea obiectelor................................................................................................57Reprezentarea unei interacţiuni.......................................................................................................................57

7.3 Contexte de utilizare.................................................................................................................................587.3.1 Elemente introductive.....................................................................................................................587.3.2 Concepte UML din sfera contextelor de utilizare...........................................................................59Numele contextelor de utilizare......................................................................................................................59Contextele de utilizare şi actorii......................................................................................................................59Contextele de utilizare şi fluxurile de evenimente..........................................................................................59Contextele de utilizare şi scenariile.................................................................................................................60Contextele de utilizare şi colaborările.............................................................................................................61Organizarea contextelor de utilizare...............................................................................................................61Relaţia de generalizare....................................................................................................................................61Relaţia de includere.........................................................................................................................................62Relaţia de extindere.........................................................................................................................................62

7.4 Diagrame de contexte de utilizare............................................................................................................62Concepte UML utilizate în sfera diagramelor de contexte de utilizare..........................................................62Conţinutul unei diagrame de contexte de utilizare..........................................................................................62Scurtă notă, relativ la ingineria directă şi inversă a diagramelor UML..........................................................63

7.5 Diagrame de interacţiune..........................................................................................................................63Conţinutul unei diagrame de interacţiune.......................................................................................................63Diagrame de secvenţă.....................................................................................................................................63Diagrame de colaborare..................................................................................................................................65

Page 72: Ingineria soft

7.6 Diagrame de activitate..............................................................................................................................66Conţinutul unei diagrame de activitate...........................................................................................................66Stări de acţiune şi stări de activitate................................................................................................................66Tranziţiile........................................................................................................................................................67

Teme pentru proiecte la disciplina Ingineria softului........................................................................................70BIBLIOGRAFIE SELECTIVĂ...........................................................................................................................71CUPRINS.............................................................................................................................................................72