Universitatea Transilvania din Braov Facultatea de Matematic i Informatic Catedra de Informatic aplicat

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

proiectare i programareproiectare i programareproiectare i programareproiectare i programare

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

Dorin BocuDorin BocuDorin BocuDorin Bocu

Motto-ul cursului

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

Autorul

Cuvnt nainte

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

Fundamentarea teoretic a universului informaional aflat n zona de impact cu calculatorul este un exemplu de demers n spiral a crui dinamic i profunzime este greu de egalat n alte domenii.

Permanenta schimbare a infrastructurilor informaionale orientate pe calculator menine la cote de alert maxim efortul de redefinire a paradigmelor teoretico-aplicative din lumea softului.

Aproape toate tipurile de activitate uman pot fi organizate i desfurate cu totul altfel n prezena calculatorului. Motivul acceptrii calculatorului n preajma omului sau n locul acestuia? Operativitate, precizie, obiectivitate.

Despre consecinele n plan estetic i moral ale rtcirii omului n sofisticata jungl a universului informaional planetar (n curs de configurare) este, probabil, prematur s discutm i nici nu ne propunem aa ceva n aceast lucrare.

Desprinderea omului de condiiile lui naturale de via a nceput de mult, n preistorie, odat cu descoperirea focului. n zilele noastre aceast desprindere continu cu o vitez (sau grab) care, uneori, ne pune pe gnduri.

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

Acest joc n care s-au angajat energii uriae are toate ansele s dureze deoarece multe dintre abilitile omului sunt greu de modelat i, spre deliciul cercettorilor, unele dintre ele aproape insurmontabile.

Aceast lucrare ncearc un lucru destul de dificil (innd cont de marea diversitate a abordrilor n literatura de specialitate) i anume identificarea bazelor ingineriei sistemelor soft.

Adresndu-se tuturor celor interesai de tiina i, n egal msur, arta de a realiza sisteme soft, prezenta lucrare poate fi nceputul unui drum lung, uneori complicat i, de ce nu, interesant.

Capitolul 1 Probleme a cror rezolvare depinde esenial

de ingineria sistemelor soft

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

1.1 Ce este ingineria sistemelor soft? Mai nti, s observm frecvena destul de mare cu care ntlnim sau vom ntlni sintagma

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

Ingineria softului este o ramur a tiinei calculatoarelor, n permanent evoluie, care fundamenteaz teoretic o parte din activitile specifice realizrii sistemelor soft.

Spunem o parte deoarece realizarea unui sistem soft are, de regul, n spate, cunotine din multe alte ramuri ale tiinei calculatoarelor precum i din alte domenii (algoritmic, programarea calculatoarelor, limbaje formale, cercetri operaionale, psihologie, teoria general a sistemelor, etc.).

Tentant i interesant problema definirii riguroase a sintagmei tiina calculatoarelor. Autorul acestei lucrri vede n spatele acestei sintagme domenii precum: algoritmica,

teoria matematic a algoritmilor (calculabilitate i decidabilitate), bazele matematice ale sistemelor de calcul, bazele logice ale sistemelor de calcul, teoria formal a specificrii limbajelor de programare, problematica limbajelor de programare, bazele contructive ale sistemelor de calcul (un domeniu de mare complexitate i cu o dinamic remarcabil), inteligena artificial (un domeniu n care cutrile sunt din ce n ce mai ramificate i mai profunde), ingineria softului, teoriile dezvoltate n jurul problematicii bazelor de date, teoriile dezvoltate n jurul arhitecturilor de tip reea, etc.

Este clar, sper i pentru cei care nc mai vd n informatic un exerciiu de utilizare inspirat a tastaturii, faptul c tiina calculatoarelor este variat ca preocupri, solicit intens intelectul i, nc un amnunt important, viteza cu care afirmaiile din informatic devin istorie este mult mai mare dect viteza cu care se ntmpl acelai lucri n fizic, sau matematic, de exemplu.

Care sunt, totui, acele activiti specifice realizrii sistemelor soft care cad sub incidena IS?

Le putem rezuma astfel:

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

20 Organizarea procesului de abstractizare (modelare) a soluiei unui sistem soft. ndeosebi n cazul sistemelor soft de complexitate mare i medie modul de organizare a efortului de modelare poate influena hotrtor calitatea unui sistem soft.

30 Reprezentarea soluiei unui sistem soft de-a lungul ntregului proces de modelare; documentarea complet a soluiei sistemului soft.

Este vorba, n esen, de rezolvarea eficient a unor probleme de comunicare ntre participanii la realizarea unui sistem soft, precum i de rezolvarea unor probleme de comunicare ntre realizatorii sistemului i diferitele categorii de beneficiari ai sistemului soft.

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

Sloganul cheie n IS ar trebui s fie: Cum se poate sistematiza ,eventual automatiza, procesul de realizare a unui sistem soft de calitate, ieftin i obinut n timp util?.

IS ncearc (n diferite chipuri i de mai mult timp) s ne nvee cum poate deveni realitate acest slogan. Modalitatea prin care IS rezolv aceast problem este (simplificnd lucrurile) propunerea de metodologii de dezvoltare a softului (MDS).

Istoria MDS este lung i destul de dificil de sintetizat fr a omite numeroase aspecte interesante. Firul cluzitor al acestei istorii ar putea fi, totui, definit astfel:

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

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

30 Fiecare metodologie dorete s ofere suport ct mai consistent pentru realizarea de sisteme soft de calitate.

Dup unele aprecieri exist, nc, o diversitate prea mare de metodologii de dezvoltare a softului, fapt care nu stimuleaz neaprat productivitatea specialitilor n IS. n jurul marilor firme productoare de soft se cristalizeaz, progresiv, elemente i idei cu ajutorul crora se alimenteaz procesul de fundamentare a unor noi MDS. Aceste MDS primesc, de regul, girul mediilor academice, dup care se ntorc la utilizatori, care le consider adecvate pentru rezolvarea problemelor lor. Schematiznd, avem situaia din Figura 1.1, adic un fel de circuit al apei n natur. Privind mai atent, ns, observm c este vorba de un proces cu conexiune invers pozitiv care, pe termen lung, are ca scop optimizarea suportului de care au nevoie specialitii n IS pentru a realiza sisteme soft.

Astfel se prezint IS dac privim lucrurile din avion. n realitate situaia este mult mai complex. Acest fapt va iei la iveal n cele ce urmeaz, cnd aplicnd descompunerea top-down n conjuncie cu un permanent efort de abstractizare, vom nelege mai bine structura i specificul unui demers IS.

Figura 1.1 Binomul cercetare-aplicaii n evoluia MDS

Firme/Persoane implicate n realizarea de sisteme soft

Idei, cerine, soluii pariale noi

Laboratoare de cercetare

MDS nou

1.2 Ce este un sistem soft? Destul de dificil un rspuns de tip definiie la aceast ntrebare deoarece diversitatea

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

De fapt, cnd vine vorba de tehnologiile soft de ultim or (ndeosebi cele promovate de Microsoft) noiunea de sistem soft face fa unor conotaii cu totul remarcabile (DLL-urile, controalele OLE, obiectele programabile, ali derivai ai tehnologiilor COM i DCOM, etc.).

Evident, se poate ncerca, pentru a face mai mult ordine n prezentare, o clasificare a aplicaiilor recunoscute de platforma Microsoft/Win32. Aceste tipuri de aplicaii sunt:

aplicaia de tip consol; este aplicaia care aduce n lumea Windows caracteristicile de baz ale unei aplicaii cu interfa orientat pe text.

aplicaii Win32 tradiionale; o astfel de aplicaie are toate elementele care sunt prezente ntr-o aplicaie Windows complet (fereastr de afiare, bar de meniuri, bar cu instrumente, bar de stare, etc.). O stfel de aplicaie, spre deosebire de aplicaia de tip consol are mari disponibiliti de cooperare cu sistemul de operare Windows.

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

Controalele ActiveX; sunt un gen de mini-aplicaii care pot fi ncapsulate n orice obiect de tip container. Container poate fi fereastra cadru a unei aplicaii, sau un document HTML. Reprezentnd, de fapt, extinderea tehnologiei OLE la cerinele universului INTERNET, ActiveX permite programatorilor s sporeasc gradul de funcionalitate al programelor fr prea mult efort. Prin utilizarea tehnologiei ActiveX, programatorul consimte s respecte o serie de reguli, s surmonteze o serie de obstacole, dar are i avantajul de a beneficia de efortul de modelare al altor specialiti n IS, n caz de convergen de interese cu acetia.

Am terminat, astfel, scurta trecere n revist a tipurilor de aplicaii suportate suportate de platforma Windows. Evident, am pus n discuie elemente noi care ne-ar putea ajuta la definirea noiunii de sistem soft.

Continund mica noastr investigaie, ne putem ntreba dac un document HTML poate fi considerat sistem soft? ntrebri asemntoare ne putem pune relativ la creaii precum: coleciile de fonturi utilizate de editoarele de texte, aa zisele fiiere cu resurse promovate de mediile vizuale de programare, coleciile de clase gen MFC (Microsoft Foundation Class), etc.

Este clar, sper, motivul pentru care, la nceputul acestui paragraf, am afirmat c este dificil de dat o definiie viabil noiunii de sistem soft. Nu ar fi acesta singurul caz (Biblia opereaz cu noiunea de Dumnezeu fr s ne-o defineasc. Cu toate acestea exist oameni care consider biblia o capodoper att din punct de vedere al tipului de scriitur ct i din punct de vedere al modului de organizare a argumentaiei).

Contnd, mai ales pe valoarea ei didactic, propun urmtoarea definiie a noiunii de sistem soft.

Se numete sistem soft orice produs al IS care poate fi utilizat pentru a fundamenta sau realiza protocoale efective i relativ autonome de prelucrare sau comunicare a datelor i informaiilor ntr-un context informaional dat.

Aadar, atributele eseniale ale unui sistem soft sunt:

10 Capacitatea de a fundamenta / realiza protocoale efective de prelucrare / comunicare a datelor / informaiilor.

Exemple. -MFC poate fundamenta protocoale efective de prelucrare / comunicare date i informaii; -Un sistem expert realizeaz un protocol efectiv de prelucrare / comunicare date / informaii; -Un document HTML realizeaz un protocol efectiv de prelucrare / comunicare date / informaii, etc.

20 Protocolul fundamentat sau realizat are o autonomie relativ. Ideea de baz a acestei autonomii relative const n faptul c protocolul este capabil, n

anumite mprejurri, de iniiativa n relaia cu mediul de interpretare sau de execuie a protocolului.

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

30 Protocolul opereaz ntr-un context informaional dat. Nu prea avem motive s acceptm ca sistem soft o creaie IS care nu opereaz ntr-un

context informaional specific. Chiar dac nu este ntotdeauna evident, acest context informaional exist. De exemplu, un mediu vizual de realizare a sistemelor soft este, el nsui, un sistem soft care opereaz cu un context informaional specific, abstractizat de conceptele i principiile de utilizare a acestor concepte pentru a modela vizual soluia unei probleme date.

Cititorul, mai mult sau mai puin avizat, ntrezrete, probabil, faptul c noiunea de sistem soft are un coninut discutabil. Mai presus de orice discuie, ns, se afl faptul c n IS denumirea generic a produselor finite este sistem soft.

Actualmente, omenirea triete un moment de cotitur din punct de vedere al modului de procesare a informaiilor care o intereseaz. Acest moment de cotitur ar putea fi numit revoluie informaional.

Dup ce o mare parte din istoria omului a fost dedicat cuceririi redutelor substaniale i energetice, a sosit timpul unor modificri importante n ceea ce privete valorificarea dimensiunii informaionale a tuturor activitilor omului.

Diversificarea pe orizontal i pe vertical a produciei de sisteme soft nseamn modificarea permanent a ofertei de tehnologii informaionale (TI), tot mai mult cerute de societatea informaional n curs de cristalizare.

Circuitul producie TI - utilizare TI - redefinire cerine fa de TI producie TI are o dinamic a crei trstur principal pare a fi efectul de autoaprindere.

Tvlugul informatizrii societii omeneti pare a fi n faza n care rostogolirea lui nu mai poate fi oprit fr a prejudicia grav progresul metodelor de investigare i complexificare a realitilor substaniale i energetice, fr s mai vorbim de cele informaionale.

Nu peste mult timp, o mare parte din locuitorii planetei vor fi nevoii s nvee meteugul utilizrii i producerii TI.

Dup cum se poate observa i n alte domenii de activitate i n industria softului exist tendina de a:

-extinde permanent capabilitile interactive i de procesare ale sistemelor soft, innd cont de cerinele concrete ale utilizatorilor dar i formnd la utilizatori obinuina de a nva tehnologii informaionale noi, destinate modificrii comportamentului;

-crete sistematic calitatea sistemelor soft;

-diminua permanent costurile de producie.

Manifestarea efectiv a acestor trei tendine este posibil numai printr-un efort permanent de mbuntire a elementelor suport n procesul de realizare a sistemelor soft.

Studiul critic al elementelor suport n procesul de realizare a sistemelor soft este de competena disciplinei prezentat n literatura anglo-saxon sub denumirea Software engineering, care n limba romn s-ar traduce convenabil prin Ingineria softului.

Dup ce am ncercat o scurt incursiune n lumea preocuprilor IS, voi prezenta, n continuare, o serie de probleme care (de la nceputurile erei informaticii sau mai recent) menin treaz interesul specialitilor n IS pentru regndirea permanent a paradigmelor.

1.3 Probleme cu care se confrunt specialitii n IS Familiarizai oarecum cu ncrctura semantic de baz a noiunilor discutate n

paragrafele 1.1 i 1.2, n acest paragraf vom analiza unele dintre problemele care au jucat i joac un rol important n evoluia IS.

De menionat faptul c i acesta este un subiect n care abordrile abund deoarece universul problemelor IS poate fi analizat din mai multe puncte de vedere iar n interiorul unui punct de vedere utiliznd formalizme diferite. De exemplu, problema elaborrii soluiei unui sistem soft poate fi discutat, la un nivel de formalizm socotit convenabil, n scopul dezvoltrii abilitilor unui specialist n IS sau n vederea informrii exacte a managerilor cu privire la particularitile i utilitatea unui astfel de demers.

Specialistul n IS vrea s nvee ct mai multe detalii despre arta de a realiza sisteme soft de calitate. Managerul care se instruiete pe probleme de IS este interesat de cunoaterea invarianiilor unui astfel de demers pentru a decide n cunotin de cauz modul n care, cu minimum de resurse se pot obine maximum de rezultate (att pe termen scurt ct i, eventual, pe termen mediu sau lung) prin automatizarea fluxurilor informaionale ale afacerii n conducerea creia este implicat.

Pentru a clarifica unele probleme de limbaj care ar putea s apar n continuare, s precizm faptul c n literatura de specialitate anglo-saxon se consider c trei categorii de indivizi sunt foarte importani pentru succesul sau eecul unui proiect de realizare a unui sistem soft. Aceste categorii sunt:

-utilizatorii direci (end-users) ai sistemelor soft; -utilizatorii indireci (clients) ai sistemelor soft; -specialitii n IS.

Probleme datorate perspectivei utilizator direct Opernd la extreme, utilizatorul direct al unui sistem soft este sau un individ avnd

afiniti cu lumea IS sau un individ a crui cultur informatic este structurat, modest, n jurul abilitilor necesare pentru utilizarea sistemului soft.

n primul caz este vorba de un utilizator a crui prere despre calitile sistemului soft poate fi deosebit de activ i pertinent. Al doilea tip de utilizator este, n general, sensibil la confortul oferit de utilizarea sistemului soft. Ambele categorii de utilizatori, ntr-o form sau alta, se pot considera la originea revendicrii pernanente: sporirea interactivitii sistemului soft cu utilizatorul direct, promovnd mijloace de comunicare ct mai ergonomice.

n mod evident, interactivitatea sistem soft-utilizator direct n sensul de mai sus presupune proiectarea i realizarea efectiv a unor interfee ergonomice.

ntr-o interfa ergonomic, utilizatorul direct gsete funcionalitatea dorit de o manier care nu pune la ncercare nici nelegerea, nici rbdarea i nici sntatea acestuia.

Practica a demonstrat i demonstreaz faptul c este o art s proiectezi interfee inteligibile, este o sarcin mult mai complicat s realizezi interfee care rspund operativ i dau dovad de maxim ngduin fa de capriciile utilizatorului direct; n sfrit, destul de pretenioas este i misiunea de a realiza interfee care nu numai c nu duneaz facultilor psihice ale utilizatorului direct, ba chiar, ncearc reconfortarea lor.

Muli factori care determin calitatea unui sistem soft (problem asupra creia vom reveni, pe larg, n acest capitol) i gsesc o form de manifestare i n modul n care se exprim o interfa n relaia cu utilizatorul.

De exemplu, robusteea unui sistem soft, considerat un factor extern de calitate, msoar abilitatea unui sistem soft de a rezista la iniiative din partea utilizatorului direct (transmise prin intermediul interfeei) care depesc cerinele specificate ale sistemului soft.

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

furnizate de un anumit sistem soft) dac se manifest constructiv este un partener cu care specialistul n IS trebuie s coopereze strns deoarece soluia multora dintre problemele care pot s apar pe timpul realizrii unui sistem soft depinde de acesta.

Utilizatorul indirect decide nceperea/nenceperea finanrii proiectului de realizare a unui sistem soft; tot el este i cel care, n urma analizelor periodice cu privire la evoluia proiectului, poate decide abandonarea/continuarea proiectului. Absolut trivial este faptul c ntr-o economie de pia fr finanare nu se poate materializa nici o idee de proiect, orict de generoas i ambiioas ar fi aceasta. Acesta este motivul pentru care managementul proiectului de realizare a unui sistem soft trebuie s trateze cu maximum de profesionalism relaia cu utilizatorii indireci-variabile importante n ecuaia finanrii unui proiect.

Utilizatorul indirect i asum, n mod normal i rolul de furnizor de date cu privire la structura proceselor informaionale modelate i, ca o prelungire fireasc, rolul de

furnizor de elemente cu privire la cerinele fa de sistemul soft n curs de realizare. Dac utilizatorul indirect nu i asum aceste dou roluri de pe o poziie corect, specialistul n IS este n faa unei probleme al crei enun are geometrie variabil:

Utilizatorul indirect nu este capabil s descrie corect procesele informaionale modelate; cineva din echipa de proiectare trebuie s fac acest lucru i, evident, nota de plat a proiectului se ncarc;

Utilizatorul indirect indic cerinele fa de sistemul soft derivate din poziia pe care el (utilizatorul indirect) o are n ierarhia utilizatorilor indireci.

Apare, n acest fel, o problem nou i important pentru specialitii n IS, anume distilarea i asamblarea viziunilor unilaterale ale utilizatorilor indireci pentru a obine o perspectiv sistemic asupra proceselor modelate.

Utilizatorul indirect are, statistic vorbind, toate calitile unui om obinuit: poate face omisiuni, poate emite judeci inconsistente, poate avea probleme n comunicarea datelor i informaiilor pe care le deine, etc. Aceast posibilitate ar trebui s sporeasc semnificativ ncordarea cu care specialitii n IS culeg de la utilizatorii direci date i informaii necesare evoluiei pozitive a proiectului.

Oricare ar fi situaia, specialitii n IS trebuie s acorde o atenie deosebit utilizatorilor indireci; prerea lor fa de calitile unui sistem soft poate determina nmormntarea acestuia nainte de a se nate, sau asigurarea condiiilor pentru ca sistemul soft s aib un ciclu de via pozitiv.

Noiunea de ciclu de via bate la u, dar de semantica aflat n spatele ei (destul de polimorf) vom discuta mai multe n Capitolele 2 i 3..

Deocamdat, ciclul de via al unui sistem soft, conform unei metodologii date, descrie etapele prin care trece un proiect de la faza de enun al problemei pn la soluia executabil pe calculator .a.m.d dac se pune problema dezvoltrii, ntreinerii, etc.

Probleme generate sau descoperite de specialitii n IS Nu este dect o confirmare a regulii faptul c IS este un univers ale crui probleme sunt

inventate, inventariate i rezolvate datorit dorinei specialitilor n IS de a optimiza procesul de realizare a sistemelor soft.

Simbolic vorbind, funcia obiectiv care st la baza optimizrii are multe variabile i o expresie necunoscut. De aceea nu se poate vorbi serios despre o optimizare n sens matematic ci despre efortul permanent de a imagina procedee de stpnire a complexitii problemelor care apar n timpul realizrii unui sistem soft. Cele mai dificile probleme care pot apare n timpul realizrii unui sistem soft sunt, totui, problemele care i au originea n laboratoarele IS sau se reflect n activitatea acestor laboratoare. Vom prezenta, n continuare, enunul problemelor fundamentale pe care trebuie s le aib n vedere orice specialist n IS.

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

Aceast nevoie de sistematizare acoper mai multe dimensiuni:concepie, ealonarea n timp, reprezentarea soluiei, documentarea, conducerea proiectului, etc.

Sistematizarea nseamn, n esen, introducerea de reguli de urmat pentru a asigura, teoretic, succesul unui proiect. Nevoia de sistematizare intr n conflict cu tendina multor

specialiti n IS de a se exprima ignornd protocoalele, normele, regulile adoptate de colectivele din care fac parte.

Pentru a menine n echilibru pozitiv nevoia de sistematizare i tendina unor specialiti n IS de a ajunge la soluie dnd cu tifla sistematizrii, este nevoie de mult abilitate din partea celor care specific paradigme de modelare a softului (dac cititorul mi ngduie aceast exprimare).

Istoria a reinut de-a lungul erei informaticii exemple de paradigme n care normarea i formalizmul au descurajat pe muli amatori de sistematizare, exemple de paradigme care au soluionat satisfctor doar o parte din probleme, lsnd la latitudinea specialitilor n IS rezolvarea altora, exemple de paradigme care mbin elegant formalizmul cu puterea de sugestie n rezolvarea unui numr ct mai mare de probleme, etc. Din pcate (sau poate din fericire) universul IS, la capitolul probleme posibile, este deschis.

Este din ce n ce mai greu de inut evidena tipurilor de sisteme soft cunoscute, pentru a valorifica creator experiena acumulat prin realizarea lor, specificnd MDS infailibile i atotcuprinztoare. Dei la ora actual au fost edificate MDS care impresioneaz puternic prin obiectivele propuse i mijloacele de atingere a acestor obiective, omul rmne n continuare singurul n msur s nsufleeasc aceste MDS sau s le adauge capabiliti noi n situaii problematice deosebite (A se vedea, de exemplu, OM,T i UML, dou MDS relativ recente, cu aspiraii interesante pentru orice gnditor care nelege lumea orientat pe obiecte).

Prin sistematizarea procesului de realizare a sistemelor soft se urmrete crearea unor condiii avantajoase pentu gestiunea complexitii problemelor specifice unui proiect. Oferirea de suport pentru gestiunea complexitii este benefic pentru diviziunea muncii (dac se lucreaz n echip) i calitatea soluiei. Exist o mare varietate de abordri care propun i elemente suport explicite pentru gestiunea complexitii. Dintre aceste abordri s enumerm i noi cteva care au ca numitor comun modularizarea. Putem modulariza orientat pe proceduri, putem modulariza orientat pe date, putem modulariza orientat pe obiecte. Rezultatul trebuie s fie de fiecare dat acelai: Soluia=o colecie de module care coopereaz pentru rezolvarea unei probleme date.

Prin sistematizarea procesului de realizare a sistemelor soft se pun bazele reutilizrii efortului de modelare, n anumite circumstane. Astfel, aa dup cum vom vedea, ndeosebi n Capitolele 2 i 4, soluia unei probleme poate fi elaborat pe mai multe nivele de abstractizare, fiecare nivel fiind dedicat descrierii unor proprieti specifice ale soluiei. Regulile de baz n organizarea unei soluii pe nivele de abstractizare pare simpl: nivelul de abstractizare al unei soluii scade odat cu creterea infuziei de informaie static i dinamic n soluie.

Creterea infuziei de informaie static i dinamic nseamn trecerea soluiei de la o arhitectur cu o anumit stabilitate structural la o arhitectur cu stabilitate structural diminuat. Este o legitate care poate fi combtut constructiv doar prin utilizarea unei scheme de rafinare a soluiei care s limiteze diminuarea stabilitii structurale a nivelului de abstractizare.

Teoretic vorbind, cu ct avem mai multe nivele de abstractizare, cu att mai mic este efortul de regndire a unui anumit nivel de abstractizare. Practic, ns trebuie gsit un compromis eficient ntre numrul de nivele de abstractizare propuse i efortul depus de specialiti n IS pentru obinerea soluiei n acest context.

Astfel stnd lucrurile, o soluie obinut, s spunem, pe trei nivele de abstractizare (conceptual, logic, operaional, a se vedea Figura 1.2) are cea mai mic stabilitate la nivel operaional. Dac apar modificri care afecteaz acest nivel (i ele sunt cele mai plauzibile), atunci soluia este regndit, refcnd, n principal, nivelul operaional. Aceasta nseamn c soluia are o rezisten structurat la modificri i c specialitii n IS fac reutilizare de efort de modelare n obinerea unei soluii.

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

teoria managementului asupra actului de conducere, analizat pe vertical.

Comentariu la Figura 1.3 Schema din Figura 1.3 ilustreaz componentele managementului, structurat pe nivele; dei

nu sunt vizibile, ntre aceste componente exist relaii foarte interesante pentru cineva care proiecteaz sistemul informaional al unei afaceri.

Figura 1.2 Exemplu de ciclu de abstractizare a soluiei unui sistem soft

Figura 1.3 Piramida managementului din perspectiv sistemic.

Managementul de TOP, dac este specificat corect trebuie s aib cea mai mare stabilitate structural. Managementul TACTIC formuleaz politicile necesare pentru ndeplinirea obiectivelor managementului de TOP. Dac este necesar, stabilitatea structural a acestor politici poate fi schimbat. n sfrit, managementul OPERATIV face tot ceea ce este necesar pentru a operaionaliza politicile stabilite de managementul TACTIC. Nivelul operativ al managementului este supus, cu prioritate, schimbrilor atunci cnd se pune problema adaptrii sistemului condus la condiii de performan noi.

Nivel conceptual (Ce face sistemul soft)

Nivel logic (Cine, cnd i unde

execut prelucrrile)

Nivel operaional (Cum se efectueaz

prelucrrile)

Soluia conceptual

Soluia logic

Sistem soft operaional

Prin sistematizarea procesului de realizare a sistemelor soft se urmrete creterea permanent a calitii acestora.

Este momentul s facem o scurt incursiune n semantica deosebit de complex a sintagmei calitatea sistemelor soft. Punctul de vedere pe care l prezentm reprezint o sintez a expunerii fcut pe aceast tem n [10].

Att n teorie ct i n practic se accept faptul c softul de calitate este rezultatul lurii n consideraie a o serie de factori interni i externi procesului de configurare a soluiei finale a unui sistem soft.

n limbaj comun se vorbete despre necesitatea de a realiza sisteme soft fiabile, uor de folosit, structurate, etc. Astfel de epitete asociate unui sistem soft caracterizeaz dou tipuri de proprieti ale sistemelor soft:proprieti externe i proprieti interne.

Calitatea sistemelor soft i proprietile externe Dintre proprietile externe care decid calitatea unui sistem soft, le considerm ca fiind

foarte importante pe urmtoatele: -corectitudinea; -robusteea; -extensibilitatea; -reutilizabilitatea; -compatibilitatea; -eficiena; -portabilitatea; -uurina n folosire.

Corectitudinea Este abilitatea unui sistem soft de a executa toate sarcinile convenite cu utilizatorii i

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

care face altceva dect s-a stabilit de comun acord cu beneficiarii i utilizatorii lui este obligatoriu s fie corectat (dac efortul necesar pentru a face acest lucru este asumat de cei care au greit) sau abandonat pentru a relua efortul de a gsi o soluie care s aib, printre altele i atributul corectitudinii.

Dei se poate vorbi uor i mult despre corectitudine, este o prob de rezisten i de ndemnare profesional specificarea corect a sistemelor soft.

Pentru teoreticienii IS corectitudinea, dincolo de acceptarea rutinei, este sinonim cu rigoarea n specificare i proiectare, ceea ce nu este agreat de specialitii n IS adepi ai utilizrii unor limbaje cu suport natural n specificare i proiectare.

Robusteea Este abilitatea unui sistem soft de a reaciona adecvat n condiii anormale de utilizarea. Este evident faptul c robusteea completeaz corectitudinea. n timp ce corectitudinea se

refer la comportamentul unui sistem relativ la o anumit specificare corect, robusteea apreciaz ce se ntmpl cu sistemul soft n situaii care, n chiar procesul de specificare ar trebui identificate ca excepii.

Realizarea de sisteme soft robuste este o sarcin care ncepe n faza de specificare i se ntinde pn n faza de programare. Pe acest traseu specialitii n IS trebuie s nfrunte dou clase mari de execpii:

Excepiile externe sistemului soft; Excepiile interne sistemului soft.

Frontiera dintre aceste dou clase de excepii trebuie privit cu mult circumspecie deoarece, n realitate este oricnd posibil ca, potenial, o excepie extern s induc o excepie intern i invers.

De asemenea, s mai observm c n timp ce excepiile externe pot fi nfruntate descurajnd iniiativele nespecificate ale utilizatorului, problematica excepiilor interne este mult mai complicat.

n cazul sistemelor care gestioneaz relaia cu utilizatorul prin intermediul unei interfee cu o semantic deosebit de complex, excepiile externe, nainte de a fi inhibate trebuie identificate.

Iat, deci, nc o problem de care specialitii n IS se lovesc dac doresc s scoat pe pia sisteme soft care rmn pe picioare la apariia unor excepii. Se poate formula i un fel de principiu relativ la odiseea tratrii excepiilor ntr-un sistem soft:

n timp ce interfaa unui sistem soft i sporete receptivitatea fa de curiozitatea i comoditatea utilizatorilor, efortul de tratare complex i corect a posibilelor excepii crete astfel nct poate deveni o problem care nu poate fi rezolvat dect prin metoda aproximaiilor succesive.

Este cazul sistemelor de operare, de exemplu, a cror robustee este, adeseori, rezultatul unui proces de ajustare pe banii i pe rbdarea diferitelor categorii de utilizatori.

Extensibilitatea Este abilitatea unui sistem soft de a se adapta uor la modificri n faza de specificare Problema extensibilitii este o problem de situare pe scala complexitii: programele

mici sunt uor de modificat; sistemele soft din ce n ce mai mari devin tot mai dificil de adaptat la modificri. Rmnnd n sfera afirmaiilor valabile, dar generale, putem aduga c dou principii sunt utile n realizarea de sisteme soft extensibile. Acest principii sunt:

Simplitatea proiectrii Ideea de baz este c o arhitectur simpl este ntotdeauna mai uor de modificat dect o

arhitectur complex. Inevitabil, ns, vine ntrebarea: cnd spunem c un sistem soft are o arhitectur simpl? Un rspuns complet i precis la aceast ntrebare nu ncape n paginile acestei cri. Simplitatea este un deziderat urmrit de orice creator care se respect. Faptul c exist destule creaii ale omului care uimesc prin dificultatea cu care i transmit mesajul (inepii literare, subproduse cinematografice, discursuri politice sterile, etc.) dovedete caracterul imprevizibil al modului n care un creator ajunge s opereze cu avantajele simplitii n munca sa. Nu se poate algoritmiza obinerea simplitii pentru c, n forma ei cea mai nalt de exprimare, este sinonim cu creaia. O creaie plsmuit cu talent va provoca ntotdeauna exclamaii de genul:Ce simplu era!, Foarte uor de neles!, Nici c se putea mai bine!, Cum de nu mi-a trecut prin cap?!, etc.

O creaie plsmuit doar pentru a umple fizic unul din multele goluri care exist n viaa oamenilor provoac exclamaii de tipul:Doamne, ce mbcseal!, Nu neleg mai nimic!, Mai bine lips!, Aa ceva puteam i eu s fac!, etc.

Nu este pierdere de vreme s urmrim simplitatea i n IS. Doar c, i aici, obinerea ei cere timp, pentru a lefui soluia unei probleme, astfel nct s putem obine un sistem soft care este, cel puin:

-lizibil; -corect modularizat; -eficient n timpul execuiei.

Sunt nenumrate motive, ns, pentru care n IS se sacrific simplitatea, asigurndu-se, de exemplu, corectitudinea i robusteea. Enumerm cteva dintre aceste motive: necesitatea scurtrii termenelor de execuie, modificarea paradigmelor de modelare, modificarea limbajelor de programare, modificarea sistemelor de operare, creterea puterii de calcul a sistemelor hard (frecven de lucru foarte mare+ dimensiuni, de vis altdat, ale memoriei RAM).

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

obine un sistem soft cu arhitectur simpl, atunci mai avem un punct de sprijin n descentralizare: cu ct autonomia modulelor care compun sistemul soft este mai mare cu att mai mare este probabilitatea ca o schimbare simpl s afecteze un numr redus de module.

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

multor aplicaii diferite. Necesitatea reutilizrii unor componente soft se ntemeiaz pe observaia c, adeseori,

sisteme soft diferite pot fi construite pe baza unor soluii-ablon similare. Promovarea sistematic a reutilizrii influeneaz ali factori de apreciere a calitii sistemelor soft, precum corectitudinea i fiabilitatea.

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

Compatibilitatea Este o msur a uurinei cu care componentele unui sistem soft se combin cu alte

componente pentru a forma aplicaii noi. Firete, compatibilitatea este important deoarece, n general, sistemele soft nu pot fi

dezvoltate n vid; ele vor interaciona cu alte sisteme soft. Secretul compatibilitii se afl n omogenitatea proiectrii i n acceptarea unor

standarde de comunicare ntre programe. Aadar, pentru a realiza sisteme soft compatibile, efortul de proiectare trebuie s ia n

calcul i cele dou cerine formulate mai sus. Comunitatea IS nu se poate mndri cu impunerea unor standarde i principii de detaliu n acest sens. Exist fani Windows care promoveaz tehnologiile, trebuie s recunoatem remarcabile, ale Microsft-ului. Exist, ns, i fani Linux care promoveaz propriile lor idei i tehnologii n ceea ce privete caracteristicile mediilor de dezvoltare a sistemelor soft. Am dat dou exemple de medii de dezvoltare a softului. Mai sunt nenumrate altele al cror istoric nu este momentul s l facem; raiunea lor de a fi este urmtoarea:

Lumea IS i datoreaz remarcabila dinamic unui permanent efort de inovare teoretic i n plan aplicativ;

Lumea IS, n marea ei varietate, are nevoie de puncte de convergen pentru a face posibil interoperabilitatea crescnd ntre sistemele soft.

Este destul de dificil de fcut o predicie relativ la dezvoltarea prghiilor de compatibilizare a sistemelor soft n viitor. Actualmente, lumea aplicaiilor Internet se prefigureaz ca un cmp de desfurare a unor btlii importante pentru noua fa a

universului IS. Este nevoie de timp, rbdare i efort susinut pentru a gsi noi formule de specificare a proprietilor fundamentale ale sistemelor soft, printre care se afl i compatibilitatea.

Eficiena (Performana) Este abilitatea unui sistem soft de a minimiza cererile de resurse hard (timp UC, memorie

RAM, memorie extern, etc.). Comunitatea IS are dou atitudini tipice fa de eficien.

Exist softiti care fac o pasiune din optimizarea permanent a sistemelor la care lucreaz. Din minile unor astfel de specialiti ies adevrate bijuterii din punct de vedere al performanelor. Preul pltit mpingnd performana dincolo de un anumit prag logic este, n principal, diminuarea portabilitii softului respectiv. ntr-o lume care viseaz la compatibilizarea sistemelor soft este greu de crezut c portabilitatea poate fi sacrificat.

Exist i softiti care gndesc astfel: S facem sistemul soft corect nainte de a fi eficient cu orice pre. Un astfel de slogan merge n aplicaiile n care absena performanei nu este critic pentru funcionarea softului, mizndu-se pe un fapt absolut real n ultima vreme: Eficiena poate fi obinut pe seama progreselor n materie de tehnologii hard. Ca de obieci, adevrul trebuie s fie undeva la mijloc, ceea ce nseamn c specialistul IS trebuie s stpneasc arta de a obine performana cerut cu minimum de cheltuieli de resurse.

Portabilitatea Este o msur a uurinei cu care un sistem soft poate fi transferat pe diferite platforme

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

dificil de rezolvat. Esena acestei probleme const n faptul c orice sistem soft, ajuns n faza executabil, pe un calculator real, trebuie s se neleag cu calculatorul respectiv. Aceasta nseamn c un cod execuatbil are o anumit structur i instruciunile pe care le conine sunt recunoscute de procesorul mainii gazd. Structura codului executabil este important pentru sistemul de operare, care supervizeaz ncrcarea codului executabil n memorie i execuia acestuia, pas cu pas. Schema clasic n care apare problema portabilitii este prezentat n Figura 1.4.

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

se fac modificrile necesare n codul surs(uneori aceste modificri pot fi dramatice); Exist compilatorul care tie s genereze cod executabil pentru platforma int

(dac nu exist, trebuie cumprat, ceea ce nseamn c portabilitatea poate s coste). Orice dificultate n portarea unui sistem soft de pe o platform pe alta este surmontabil

dac :

se fac modificrile necesare n codul surs(uneori aceste modificri pot fi dramatice); Exist compilatorul care tie s genereze cod executabil pentru platforma int

(dac nu exist, trebuie cumprat, ceea ce nseamn c portabilitatea poate s coste).

Figura 1.4 Dependena de platform i efectele asupra portabilitii n varianta clasic

Evident, ar fi mult mai bine dac aceste dou probleme nu ar exista. Din pcate probelmele exist i specialitii n IS trebuie s ia n calcul la specificare i aspecte care afecteaz portabilitatea sistemului soft. O situaie aproape diametral opus celei prezentate n Figura 1.5 o reprezint soluia Java pentru asigurarea portabilitii aplicaiilor.

De remarcat faptul c situaia descris n Figura 1.5 este posibil n condiiile n care toat comunitatea recunote o anumit versiune de compilator Java. Trecerea de la o versiune la alta se face respectnd regulile de portare potrivit crora documentul neles de o versiune oarecare a unui sistem soft este totdeauna neles de o versiune mai nalt, nu i invers.

Figura 1.5 Soluia Java la problema portabilitilor sistemelor soft.

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

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

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

Cod Java

Compilator Java

Bytecode Java

(Independent de platform)

Interpreter Java (Pentium)

Interpreter Java (Power PC)

Interpreter Java (SPARC)

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

Uurina n folosire Se refer la modul n care oameni cu diferite nivele de instruire pot nva s foloseasc

sistemul soft pentru rezolvarea unor probleme reale. Se refer, de asemenea, la uurina instalrii i operrii sistemului soft.

nchei prezentarea proprietilor externe ale sistemelor soft cu precizarea c problematica proprietilor interne (structurare, modularizare, obiect orientare, etc.) reprezint un capitol la a crui scriere nc se lucreaz, neexistnd un consens deplin al specialitilor asupra modului de articulare a acestora ntr-o explicaie stabil structural. Despre unele dintre aceste subiecte vom avea un cuvnt de spus n Capitolul 4.

Capitolul 2 Ce este o metodologie de dezvoltare a

softului?

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

2.1 De ce avem nevoie de MDS? n Capitolul 1 am prezentat o serie de consideraii, a zice cu pretenii de stabilitate

structural, referitoare la universul IS. Este, ns, prea devreme pentru a-mi nchipui c ucenicii ntr-ale producerii softului sau creatorii de soft dup reete proprii au devenit adepi convini ai promovrii reetelor IS.

n acest paragraf vom inventaria o serie de probleme concrete de care, vrnd-nevrnd, specialistul n IS (afiliat sau nu la o metodologie) se lovete.

Procednd astfel legitimm o stare de lucruri ntlnit i n alte domenii ale cunoaterii.

Structura discursului n IS este determinat att de cerine epistemologice specifice ct i de nevoia de organizare a diferitelor forme de manifestare a existentului n procesul de realizare a sistemelor soft.

Evident, o parte din cerinele epistemologice specifice le-am surprins n Capitolul 1. n acest paragraf vom ncerca s evideniem o parte dintre formele de manifestare a

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

chiar aa. n matematic, o problem poate suna cam n genul:

Dat triunghiul oarecare ABC, s se afle locul geometric al punctelor M, interioare triunghiului, pentru care SABM=SACM.

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

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

20 Odat stabilit clasa tipologic, trebuie s avem control asupra semanticii noiunilor care intervim n enunul problemei.

n cazul nostru ne confruntm cu noiuni precum: loc geometric, interiorul unui triunghi, aria unui triunghi i, de ce nu, triunghi.

30 Pentru a gsi rezolvarea ne trebuie abilitatea de a valorifica avantajele prezentate la punctele 10 i 20 n vederea obinerii soluiei problemei.

n general, aceast abilitate o au persoanele care sunt capabile de inferen. Abilitatea de a comite inferene autentice o au oamenii inteligeni. Evident, cine rezolv o problem faceun fel de descoperire, deci este un fel de creator.

Folosesc sintagma un fel de deoarece face descoperire autentic cel care rezolv primul o problem sau propune i rezolv o problem nou.

n cazul problemei noastre, pentru a ne face mai bine nelei ne-ar prinde bine reprezentarea din Figura 2.1.

Figura 2.1.

Din enunul problemei, avem, n mod evident: -ABC oarecare; -M interiorului ABC; SABM=SACM .

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

Acum este momentul inferenei specifice problemei:

SAMB = 2

'BBAM

SAMC = 2

'CCAM

SAMB=SAMC BB=CC BBOCCO BO=CO Mmedianei din A a ABC, etc.

n IS situaia este puin modificat. Trecerea de la enun la soluie, n cazul problemelor de complexitate mijlocie sau mare (n care, de regul, se cere modelarea comportamentului unui anumit proces informaional) este mult modificat. Astfel, n forma iniial, enunul problemei poate sesiza nite carene ntr-o activitate care pot fi eliminate prin utilizarea calculatoarelor sau poate intui nite avantaje ntr-o activitate dac se apeleaz la suportul calculatoarelor.

n ambele cazuri, pentru a obine enunul complet al problemei se trece la analiza informaional a problemei. Scopul acestei activiti este obinerea unui enun complet al problemei care cuprinde cerinele fa de sistemul soft sub forma unei soluii cu nivel nalt de abstractizare.

Activitatea de analiz informaional este dificil i este primejdios ca, din diferite motive, s nu incluzi printre cerine un anumit aspect informaional.

Dac s-a pus punct analizei informaionale, trebuie s se treac la elaborarea soluiei tehnice (un fel de documentaie constructiv a sistemului soft). Dei elaborarea soluiei tehnice nseamn descrierea pn la detaliu a componentelor sistemului soft i a legturilor

dintre acestea, ceea ce nseamn infuzie treptat de elemente concrete n soluie, n paralel se desfoar i activiti cu pronunat caracter de abstractizare (pentru a elimina redundanele, pentru a optimiza prelucrrile, pentru a optimiza legturile dintre date, pentru a spori rezistena sistemului la modificri, etc.).

De foarte multe ori se poate spune c obiectul analizei informaionale ca i obiectul activitii de obinere a soluiei tehnice au afiniti cu nisipurile mictoare. Ce-i de fcut? Trebuie mult rbdare i abilitate pentru a sesiza invarianii procesului ceea ce ar permite nceperea efortului de modelare.

n situaia n care calvarul obinerii soluiei tehnice a fost depit ncepe activitatea de transpunere a soluiei tehnice n acord cu exigenele de sintaz, semantic i pragmatic specifice unui limbaj de programare.

N-a zice c nu exist nisipuri mictoare i n aceast ncercare! n mod cert, numitorul comun al problemelor de matematic cu problemele de informatic este complexitatea. n cazul matematicii predomin complexitatea structural; n cazul informaticii, de cele mai multe ori predomin complexitatea spaial.

Dac la aceste elemente se adaug altele, precum: necesitatea reprezentrii soluiei pentru a fi neleas de diferite categorii de utilizatori, necesitatea de a partaja anumite tipuri de resurse n procesul de elaborare a soluiei unui sistem soft, necesitatea de a armoniza efortul de dezvoltare n cazul n care se lucreaz n echip, etc. ne facem o imagine mai precis asupra amnuntelor care alctuiesc specificul unei probleme n IS.

Pentru a nfrunta toate aceste probleme i multe altele, comunitatea specialitilor n IS a ncercat nc din epoca de nceput a erei informaticii s ngrdeasc liberul arbitru n procesul de dezvoltare a softului, lsnd, totui, loc de manifestare spiritului creator, prin iniiative de genul:

-studiul teoretic al proprietilor algoritmilor: formalizare a reprezentrilor; clasificarea algoritmilor;

-studiul teoretic al unor metode generale de elaborare a algoritmilor (Backtracking, Greedy, Divide et Impera, Programarea dinamic);

-elaborarea unor metode de programare (programarea structurat, programarea obiect-orientat);

-elaborarea unor metode de analiz a sistemelor informaionale (procedee de investigare, mod de reprezenatare, concepte utilizate, etc.);

-elaborarea unor metode de elaborare a soluiei tehnice (Top-down, HIPO, Warnierr-Orr, etc.);

-dezvoltarea unor elemente suport pentru specialitii n IS (sisteme de documentare, generatoare de programe, medii de dezvoltare a soluiei cu ajutorul calculatorului, etc.);

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

-elaborarea unor metode de planificare a efortului de dezvoltare a sistemelor soft.

Acumulrile n direciile semnalate mai sus sunt impresionante; evoluia abordrilor n IS, att teoretice ct i practice, seamn, metaforic vorbind, cu evoluia populaiilor n sistemele genetice; clauzit de legiti, aparent stochastice, comunitatea specialitilor n IS produce generaii succesive de elemente suport n dezvolatrea softului, le evalueaz, n practic, reine ceea ce este valoros n ele i promoveaz ca parte component n generaiile urmtoare.

De la o perspectiv fragmentat sau incomplet asupra procesului de dezvoltare a softului s-a ajuns n ultimii ani la elaborarea unor metodologii unitare de dezvoltare a softului, creaii ale specialitilor n IS puse n slujba specialitilor n IS, cea mai mare parte din viaa unui sistem soft.

2.2. ncercare de caracterizare a unei metodologii generice de dezvoltare a softului n Capitolul 1, paragraful 1.1 am prezentat o list de activiti specifice realizrii

sistemelor soft. Aceste activiti sunt:

-abstractizarea soluiei unui sistem soft (ASS);

-desfurarea n timp a (=organizarea) procesului de abstractizare a soluiei unui sistem soft (OPA);

-reprezentarea i documentarea evoluiei unui sistem soft (RDS);

-optimizarea managementului procesului de realizare a unui sistem soft (OMP).

Putem s definim o metodologie generic de dezvoltare a softului astfel:

Un set finit de concepte, principii, norme, convenii i reguli de operaionalizare a acestora, pentru a da rspunsuri satisfctoare problemelor care apar n activitile de tip AAS, OPA, RDS, OMP.

S ncercm, n continuare, o serie de precizri relativ la semantica acestei definiii. (Despre pragmatica acestei definiii, nc nu putem spune mare lucru. Dac am fi vorbit despre o metodologie anume, alta era situaia n ceea ce privete pragmatica.)

Orice metodologie care urmrete priza la public trebuie s fac fa contradiciilor, inerente pentru semantica binomului MDS-specialist n IS.

Una dintre contradicii se refer la dorina de a oferi un set relativ restrns de concepte, principii i reguli de utilizare a acestora n opoziie cu aspiraia legitim a oricrui autor de MDS de a oferi sintax care s permit descrierea unei semantici, ct mai bogat posibil.

Alt contradicie se refer la nclinaia spre formalizm a spiritelor riguroase n opoziie cu nclinaia spre intuitiv a altora.

Nu n ultimul rnd (pentru c mai sunt i alte exemple) semnalez contradicia dintre necesitatea de a standardiza mare parte a procesului de dezvoltare a sistemelor soft i nevoia de exprimare liber resimit de unii specialiti. n alt plan ne ntlnim cu contradicia dintre nevoia de a crete productivitatea muncii i necesitatea de a realiza sisteme soft de calitate.

Cei care specific MDS se strduiesc s menin echilibrul ntre aceste contradicii prin diferite mijloace.

De exemplu, referitor la prima contradicie, metodologia UML ofer o semantic foarte bogat cu ajutorul unui set bine ales de concepte i principii, oferind i cteva mecanisme de extensie cu ajutorul crora semantica metodologiei poate fi mbogit.

n ceea ce privete capacitatea unei MDS de a oferi suport pentru rezolvarea problemelor de tip ASS, suntem datori cu o serie de precizri importante. Pentru o MDS recomandrile pe care aceasta le face pentru a transforma enunul unei probleme de informatic n soluie executabil pe un calculator real, practic definesc nsi substana metodologiei. Aceste recomandri desemneaz, conform literaturii de specialitate, ciclul de abstractizare al unei MDS.

Pentru un specialist n IS prima ntrebare pe care i-o pune n faa unei probleme noi este destul de lung.

Cum s derivez din datele problemei o soluie, respectnd termenele de execuie, fr s dezamgesc utilizatorul direct, ntmpinnd exigenele curente i de perspectiv ale utilizatorului indirect i, chiar dac pare un pic utopie, fr s m stresez peste msur?.

Fr ndoial, o astfel de ntrebare poate avea o serie de conotaii etice, filozofice, etc. dar nu acestea l preocup pe specialistul n IS.

Evideniind doar ingredientele eseniale ale unei probleme de IS, avem:

-Date -Prelucrri -Interfee

Toate aceste ingrediente exist n domeniul problemei n format utilizator. n domeniul problemei, pentru descrierea soluiei se folosesc concepte pe care le neleg, probabil, oricare dintre participanii la un proiect, dar, n orice caz, ar trebui s le neleag participanii din sfera utilizatorilor i clienilor.La cellalt capt al balanei se afl domeniul soluiei n care se vehiculeaz concepte pe care le nelesc specialitii n IS.

n format utilizator datele sunt organizate supralicitnd redundana, prelucrrile, fiind aplicate unor date n care mustete redundana, nu sunt automat cea mai fericit alegere.

Tot att de delicat este i problema organizrii interfeelor deoarece n elaborarea acestora trebuie gestionat optim contradicia dintre dorina de a oferi utilizatorului confort i pornirea natural a specialistului n IS de a raionaliza interfaa cu utilizatorul.

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

-organizarea optim a datelor utilizate de un sistem soft; -organizarea optim a prelucrrilor specifice unui sistem soft; -organizarea pe principii ergonomice i de eficien a interfeelor unui sistem soft.

Suportul oferit pentru rezolvarea problemelor semnalate mai sus depinde de metodologie. Rmnnd la ideea de metodologie generic, ar trebui s spunem c acest suport poate reprezenta un set de concepte, principii i reguli de operaionalizare a acestora cu ajutorul crora se reprezint proprietile de un anumit tip ale procesului n curs de modelare.

De exemplu, proprietile informaionale ale procesului modelat, odat ce au fost identificate, caracterizate i clasificate ne pot da o descriere a aspectelor statice ale procesului; n acest scop metodologiile ofer modele de organizare a datelor, eventual pe mai multe nivele de abstractizare.

Proprietile comportamentale ale procesului pot fi descrise utiliznd modele capabile s surprind diferite nuane ale dinamicii unui sistem.

Pare simplu, dar nu este aa. Pentru a obine o reprezentare ct mai exact a proprietilor informaionale i comportamentale ale unui proces, trebuie s elaborm:

-modele care reprezint statica unui sistem; -modele care reprezint dinamica unui sistem; -modele care reprezint fluxurile informaionale ntr-un sistem

.a.m.d.

Altfel spus, sistemul modelat este privit din mai multe perspective, fiecare perspectiv permind descrierea unui anumit tip de proprieti; laolalt, putem spune, fortnd puin lucrurile, perspectivele ne ajut s obinem o imagine holografic asupra sistemului modelat. Pn unde merge acurateea acestei imagini?! Iat o ntrebare cu mai mult de dou tiuri pentru cei care dezvolt softuri dar mai ales pentru cei care specific noi MDS.

n ceea ce privete capacitatea unei MDS de a oferi suport pentru rezolvarea problemelor de tip OPA.

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

Ciclul de via al sistemelor soft este, alturi de ciclul de abstractizare, o caracteristic fundamental a MDS. Este evident faptul c, la detaliu, fiecare MDS are propria propunere de ciclu de via. Fcnd abstracie de metodologie, o prim perspectiv asupra semanticii noiunii de ciclu de via o obinem n Figura 2.2.

Diagrama din Figura 2.2. surprinde elementele eseniale pe baza crora ncepe s aib sens noiunea de ciclu de via.

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

Pentru a obine date noi asupra semnificaiei noiunii de ciclu de via prezentm diagrama din Figura 2.3.

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

Analiza Proiectarea Implementarea Testarea

Etape de dezvoltare

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

Avnd ca pretext diagrama prezentat n Figura 2.3., pot prezenta comentariile de mai jos.

Analiza Este etapa n care se constat c este necesar un sistem soft i se iau decizii n consecin. Fie c se constat existena unei piee pentru un produs de uz general, fie c o anumit

organizaie are nevoie de un soft specializat, n mare msur aceast prim etap presupune mai degrab luarea unor decizii de management i marketing dect abordarea unor probleme legate de studiul algoritmilor, de exemplu.

Dup luarea deciziei de dezvoltare a sistemului soft ncepe analiza propriu-zis, al crei scop principal este identificarea necesitilor utilizatorului potenial al sistemului soft. De exemplu, n cazul unui produs de uz general, care urmeaz a fi vndut pe o pia concurenial, trebuie stabilit un public int. Dac se construiete un sistem soft de gestiune a stocurilor ce urmeaz a fi folosit n departamentul de aprovizionare al unei firme constructoare de maini, atunci trebuiesc identificate necesitile i ateptrile celor care lucreaz n cadrul acestui departament.

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

Dup ce au fost identificate cerinele, acestea sunt transformate n specificaii tehnice. Ca un exemplu, cerina ca accesul la datele sistemului s fie permis doar persoanelor autorizate se poate transforma n specificaia c sistemul nu trebuie s rspund dect dup introducerea unei parole de exact unsprezece caractere, confirmat de sistem.

Firete, se pot pune ntrebrile:

Problem

Dezvoltare

Utilizare

Abandonare soft

Modificare

Care sunt regulile care guverneaz procesul de identificare i reprezentare a cerinelor fa de sistemul soft?

i

Care sunt regulile care guverneaz domeniul de elaborare i reprezentare a specificaiilor tehnice?.

Rspunsul este simplu: metodologia ofer suport de tip ASS i suport de tip RDS care se folosete n aceast etap a ciclului de via ct mai eficient cu putin.

Proiectarea Este etapa n care soluia sistemului soft este specificat n detaliu. n termeni generali vorbind, sistemul soft imaginat n etapa de analiz este descompus,

progresiv, n componente mai uor de modelat, numite, generic, module. Implementarea sistemelor complexe devine posibil tocmai prin aceast descompunere modular. Astfel, mulimea detaliilor tehnice care trebuie luat n considerare ar fi imposibil de stpnit. Proiectarea modular creeaz, totodat condiii pentru lucrul n echip i vine n ntmpinarea efortului de ntreinere, dac acesta este reclamat.

Una dintre concluziile greu de combtut ale generaiilor de MDS poate fi formulat astfel:

O structur modular, chibzuit proiectat este benefic att pentru implementarea sistemului ct i pentru modificarea sa ulterioar.

Probabil, acesta este unul dintre principalele motive pentru care modelarea orientat spre obiecte ctig tot mai mult teren.

n faza de proiectare, ca i n cea de analiz suportul de tip ASS i RDS este esenial pentru a obine o soluie tehnic de calitate.

Implementarea Este etapa n care are loc scrierea efectiv a programelor, crearea fiierelor i, n

consecin, dezvoltarea bazei de date a sistemului soft astfel obinut.

Testarea Este etapa strns legat de etapa anterioar deoarece, n mod normal, fiecare modul al

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

interni ai calitii precum: decompozabilitatea modular, compozabilitatea modular, nelegerea modular, continuitatea modular i protecia modular, conform i celor specificate n [3]) fiecare modul poate fi testat n mod independent, utiliznd versiuni simplificate ale celorlalte module pentru a simula interaciunea modulului int al testrii cu restul sistemului. Evident, pe msur ce diferite module sunt finalizate i combinate, testarea individual face loc treptat testrii generale a ntregului sistem.

Practica dovedete c testarea i complementara acestei activiti, care este depanarea, sunt, ndeosebi n cazul sistemelor mari activiti greu de finalizat. Sistemele de mari dimensiuni pot conine foarte multe erori chiar i dup efectuarea celor mai complexe teste. Multe erori pot rmne neobservate pe toat durata vieii sistemului soft. Punerea la punct a unor strategii de eliminare a acestor erori este un obiectiv major al IS. Practica ne arat c n aceast direcie mai sunt nc multe probleme de rezolvat.

Mult vreme MDS s-au bazat pe secvenialitatea propus n Figura 2.3., care sugereaz c trecerea dintr-o etap nou este posibil numai dup trimiterea lucrului n etapa precedent. A rezultat astfel un proces de dezvoltare cunoscut sub numele modelul cascad (waterfall model).

Acest nume subliniaz faptul c procesul de dezvoltare poate decurge ntr-o singur direcie.

Studiile de specialitate arat c abordarea propus de modelul cascad este ntr-o contradicie flagrant cu nevoia de a tatona profunzimile soluiei unei probleme (prin ncercri), resimit de spiritul creativ al rezolvitorului.

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

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

n ceea ce privete capacitatea unei MDS de a oferi suport pentru rezolvarea problemelor de tip RDS, putem, de asemenea, s facem o serie de consideraii cu caracter general.

Pe tot parcursul elaborrii soluiei unei probleme, aceasta trebuie documentat i reprezentat.

Soluia trebuie documentat deoarece exist mai multe categorii de persoane interesate n utilizarea acestei documentaii (operatorii sistemului soft, cei care distribuie i instaleaz sistemul soft, programatorii care se ocup de ntreinerea sistemului soft, partenerii proiectului de realizare a sistemului soft, etc.).

Documentaia de utilizare poate fi realizat sub forma unor ghiduri de utilizare tiprite sau poate fi ncorporat n structura sistemului soft sub form de help interactiv. Spre binele autorilor sistemelor soft sau spre binele celor care ar trebui s modifice sistemul soft este bine ca nsui codul surs al sistemului soft s fie generos documentat.

Deoarece, de calitatea documentaiei depinde n mare msur i priza sistemului soft la segmentul de pia cruia i se adreseaz, marile firme productoare de soft au transformat documentarea unui sistem soft ntr-o activitate supus n mare msur standardelor, automatizrii, legilor pieei.

Se cunosc exemplele remarcabile oferite n aceast privin de firme precum Microsoft sau Borland.

Soluia trebuie reprezentat n fiecare etap a ciclului de via deoarece: -permite schimbul de informaii de natur tehnic ntre partenerii de proiect; -servete ca surs de documentare strict necesar celor care vor s aduc modificri

sau dezvoltri acestei soluii.

Att pentru documentarea ct i pentru reprezentarea soluiei se folosesc limbaje sau sisteme adecvate.

Astfel, pentru documentare se folosete, n esen, limbajul natural, manifestndu-se o grij deosebit pentru rigoarea, claritatea, sugestivitatea i uurina n utilizare a diferitelor tipuri sau sisteme de documentare. Programatorii, ndeosebi, sunt deja obinuii cu ncorporarea n mediile de programare sau n funcionalitatea diferitelor sisteme soft a unor help-uri interactive de mare complexitate sau a tutorialelor care asist nvarea operrii sistemelor soft. Ultima gselni n materie de documentare a sistemelor soft o reprezint capabilitile de tip wizards care scutesc utilizatorii de grija de a memora anumite protocoale de utilizare a sistemelor soft, lsndu-le ns ntotdeauna libertatea de a gndi care este cea mai bun alegere ntr-un anumit moment al utilizrii softului n cauz.

n ceea ce privete reprezentarea soluiei, aducem la cunotina cititorului faptul c lucrurile sunt mai puin aezate dect n cazul documentrii.

Limbajele alese pentru reprezentarea soluiei unui sistem soft pot fi:

-tributare cerinei de a fi intuitive, caz n care textul este combinat cu grafica conform unor reguli specificate riguros din punct de vedere sintactic (a se vedea notaia utilizat n UML!);

-tributare excesului de formalizm, indispensabil, spun teoreticienii pentru a asigura un spor de corectitudine n specificare, analiz, proiectare. Formalizmul excesiv este cerut i de, nc ipotetica, nzuin a IS de a implica sisteme soft specializate n generarea automat a codului executabil pornind de la soluia tehnic (a se vedea Z, Z++, VDM, VDM++, sisteme formale de reprezentare a soluiei unui sistem soft care au reuit cteva strpungeri experimentale n lumea practic a IS i att deocamdat).

Referitor la notaie (cum se mai numete limbajul de reprezentare a soluiei) s precizm c aceasta n manualele de prezentare a MDS este strns dependent de semantica metodologiei, adic limbajul de reprezentare a soluiei respir acelai aer cu limbajul de abstractizare a soluiei.

n ceea ce privete capacitatea unei MDS de a oferi suport pentru rezolvarea problemelor de tip OMP

Din cele expuse pn n acest punct al lucrrii s-a neles, presupun, faptul c lucrul n cadrul unui proiect de dezvoltare a unui sistem soft ridic probleme deosebite din punctul de vedere al managementului. Deja, practica lucrului n cadrul proiectelor de realizare a unor sisteme soft serioase a confirmat valabilitatea afirmaiei potrivit creia:

Un management slab poate compromite uor ansele de reuit ale unei echipe de proiectare redutabil profesional; un management bun poate gestiona eventualele probleme datorate nivelului profesional necorespunztor al unora dintre membrii echipei de proiectare.

Lumea n care trim este, fr s exagerm deloc, opera diferitelor tipuri de management. Specialiti sau nu n probleme de management, este bine s tim c exist discipline care

studiaz problemele fundamentale ale managementului, dar, complexitatea activitilor imaginate de om depind de mult capabilitile explicative i operaionale ale unui tratat de bazele managementului, asistm la apariia unor varieti noi de management cu obinuina cu care la un anumit timp dup apusul soarelui ne vine din ce n ce mai greu s rezistm tentaiei de a ne culca. Printre aceste varieti de management se afl i managementul proiectelor de realizare a sistemelor soft (MPRSS). Multe dintre principiile fundamentale ale teoriei managementului opereaz i n cadrul MPRSS. Mai mult, putem afirma c, cel puin n cazul

etapei de analiz din ciclul de via al unui sistem soft cunotinele de management sunt de mare utilitate (dac sistemul soft este realizat la cererea conducerii unei organizaii cu sau fr profit).

Multe din ntrebrile care se pun n etapa de analiz (ce obiective are de ndeplinit sistemul soft?, care sunt mijloacele de ndeplinire a acestor obiective?, cum i mapeaz sistemul soft funciile pe domeniul activitilor deservite?, etc.) primesc rspunsuri mult mai clare dac analistul are i cunotine de management. Spernd c v-am convins, oarecum, de utilizarea unui management adecvat al procesului de dezvoltare a unui sistem soft, s anticipm c n atenia MPRSS se afl trei tipuri fundamentale de activiti:

-gestiunea resurselor angajate n realizarea sistemului soft; -asigurarea calitii sistemului soft; -gestiunea riscurilor asociate procesului de realizare a sistemului soft.

Toate aceste trei tipuri de activiti se desfoar dup o planificare riguroas care presupune, n esen stabilirea cadrului optim din punct de vedere organizatoric i logistic care permite valorificarea suportului oferit de MDS pentru rezolvarea problemelor de tip ASS, OPA, RDS.

Nu ne va surprinde, aadar, s constatm c specialitii care depun eforturi pentru dezvoltarea suportului metodologic de tip OMP propun o serie de modele calitative i cantitative cu ajutorul crora se ncearc msurarea sau evaluarea rezultatelor activitilor mai sus precizate.

Date fiind particularitile acestor activiti n cazul proiectelor de realizare a unor sisteme soft, este de ateptat ca multe direcii de aciune ale managementului s se supun unor legiti specifice.

Orice patron de firm soft va scpa de multe probleme n ziua n care din laboratorul de cercetare va iei pe pia o metodologie care:

articuleaz att de bine contradiciile, certitudinile i incertitudinile din munca unui specialist n IS, nct toate merg ca ntr-o linie de fabricaie a unor echipamente necesare pentru dotarea unor capsule spaiale.

Fericire sau ghinion, cert este c mai avem cale lung pn acolo. Nu cred c este cazul s v spun explicit de ce. Doar att mai adaug: de vin este complexitatea unora dintre activitile specifice gndirii omeneti.

Nu ne rmne dect s alegem dintre nenumratele rele pe care le avem n fa pe cea mai puin costisitoare din toate punctele de vedere.

Capitolul 3 Ciclul de via al unui sistem soft

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

3.1 Ciclul de via al sistemelor soft. nc o introducere

S ne reamintim, la acest nceput de capitol, ideea de baz a capitolelor 1 i 2: nevoia de sistematizare a procesului de dezvoltare a sistemelor soft.

Nimeni nu contest faptul c se pot ntlni abordri de genul celor reprezentate n Figura 3.1 i n Figura 3.2.

Figura 3.1 Un model primitiv de dezvoltare a softului

Figura 3.2 Un model mbuntit de dezvoltare a softului

Tot ceea ce se poate spune despre modelele de dezvoltare sugerate de figurile de mai sus este faptul c abstractizeaz frumos, dar ineficient procesul de dezvoltare a sistemelor soft de mare i medie complexitate.

Conform Figurii 3.1, specialistul n IS trebuie s aib abiliti remarcabile care s-i permit s fac un salt uria de la cerine la codul care descrie, practic, n detaliu, soluia executabil a sistemului soft.

Exist oameni care pot face acest lucru. Diferitele nivele de abstractizare i faze de dezvoltare a softului se nfirip n creierele acestora i capt contururi suficient de clare pentru a permite alimentarea cu materie prim de calitate a procesului de codificare. Chiar i n cazul unor astfel de oameni, saltul de la cerine la cod este plin de riscuri.

mbuntirea sugerat de Figura 3.2 este real dar insuficient. Ani la rnd, n laboratoarele de cercetare ale IS s-au fcut eforturi extrem de diverse i uneori foarte originale, pentru gsirea celei mai bune formule de desfurare n timp a procesului de abstractizare a soluiei unui sistem soft.

Toate aceste formule se concretizeaz ntr-o list lung de propuneri de cicluri de via, din care vom analiza n continuare cteva exemple reprezentative.

Dei ciclul de via propus de o MDS funcioneaz optim n conjuncie cu o anumit strategie de abstractizare a soluiei, specific MDS, n analiza pe care o fac n paragraful 3.2 voi insista doar pe elementele care definesc particularitile unei MDS din punct de vedere al ciclului de via.

3.2. Ciclul de via al sistemelor soft. Exemple. Schimbrile care s-au produs, n timp, n ceea ce privete tehnologiile informaionale i

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

Specificarea cerinelor Implementare

Specificarea cerinelor

Diagrama de structur

Implementare

Un studiu comparativ al diferitelor exemple de MDS evideniaz o serie de elemente interesante.

Numrul fazelor ciclului de via specific unei MDS poate varia de la trei (analiz, proiectare, implementare) pn la douzeci sau mai multe.

Este evident faptul c, i n acest domeniu, concurena, beia teoretic i ruperea contactului cu realitatea zmislesc, din cnd n cnd, adevrai montri metodologici. Pentru a trece cu brio examenul practicii, o MDS trebuie s manifeste o preocupare deosebit pentru dou dintre trsturile ciclului de via asociat:

-numrul de faze s fie justificat att de o analiz punctual ct i de consideraii de ansamblu n ceea ce privete versatilitatea operaionalizrii ciclului de via;

-fiecare faz a ciclului de via s fie acoperit satisfctor de elemente suport pentru rezolvarea problemelor de tip ASS, RDS, OMP.

Avnd n vedere aceste dou exigene, voi trece la descrierea unor modele ale ciclului de via al sistemelor soft reprezentative, urmnd s degajez o serie de concluzii generale dup prezentarea acestor modele.

3.2.1. Modelul cascad( MC) Numit i water-fall, este un exemplu de ciclu de via care a fcut istorie. El afost lansat

la ap la nceputul deceniului 7 de ctre W. W. Royce i const ntr-o descompunere a ciclului de via al unui sistem soft n faze secveniale. Fazele sunt descompuse n activiti. Trecerea de la o faz la alta se realizeaz dup ce precedenta a fost parcurs integral.

S mai reinem i faptul c MC se aplic la nivel de sistem. Alte informaii cu privire la model n Figura 3.3.

Figura 3.3. Modelul cascad

Definirea cerinelor

Utilizarea i instruirea

Analiza

Proiectarea

Testarea

Implementarea

Avantaje recunoscute ale modelului cascad

Ofer un control total asupra fazelor, n sensul c acestea fiind ordonate devin previzibile, evideniindu-se clar ntinderea lor ca o colecie de activiti i subactiviti specifice;

Este uor de nsuit de ctre partenerii unui proiect, inclusiv de cei cu experien redus; Fiecare faz este acompaniat de o documentaie destul de bine structurat.

Dezavantaje ale modelului cascad

Aplicndu-se la nivel de sistem, evident c nu ofer suport prea consistent pentru controlul complexitii n cazul sistemelor mari;

Dei, dup cum reiese i din Figura 3.3, nu este descurajat abordarea iterativ a unor faze sau componente ale lor, restriciile de timp impuse de programarea calendaristic a fazelor limiteaz ofertele benefice ale posibilitii de revenire la o etap anterioar.

Acest fapt nu este tocmai convenabil dac inem cont de faptul c, n practic, nu numai c sunt necesare reluri ale fazelor, mai mult se simte nevoia lucrului n paralel la o scar mai mare dect o permite modelul cascad;

Evident, sistemul se pred doar dup parcurgerea etapelor anterioare, ceea ce nseamn o lung perioad de timp pn cnd utilizatorul vede sistemul la lucru, ceea ce nu este convenabil pentru nici una din faze (utilizatorul are destul timp s emit alte pretenii fa de sistemul soft);

MC nu ofer suport adecvat pentru abordarea dinamic a proceselor de modelat;

MC nu are protecie explicit fa de modificrile care pot interveni pe parcursul dezvoltrii sistemului soft.

Nu am considerat necesar s mai insist asupra coninutului fazelor prezentate n Figura 3.3. Paragraful 2.2 al acestei lucrri conine suficiente informaii lmuritoare n acest sens.

Cu toate c are destui critici, modelul cascad a fost i este folosit, integral sau parial, ori de cte ori se dorete un ciclu de via cu o structur echilibrat.

3.2.2 Modelul V (MV) Acest model preia ideile de baz ale modelului cascad, integrndu-le ntr-o concepie

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

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

Adevrul este c marile mutaii produse n lumea tehnologiilor informaionale orienteaz eforturile specialitilor n IS ctre posibilitatea abordrii unui sistem orientat pe componente, de o manier iterativ-incremental (ceea ce nseamn mai mult dect oferta modelului V) cu o atenie deosebit fa de utilizator.

n actuala etap de dezvoltare a IS utilizatorul a devenit un partener ale crui opinii trebuie luate n seam pentru ca sistemul soft s poat trece cu bine examenul pieei.

Figura 3.4. Modelul V

A mai sublinia faptul c n cadrul MV se face o distinie clar ntre verificare i validare, ca activiti specifice laturii din dreapta a V-ului modelului.

Verificarea se refer la testarea sistemului, n diverse faze de dezvoltare, din punct de vedere al corectitudinii logice. n schimb, validarea permite verificarea corectitudinii specificrii cerinelor iniiale fa de sistemul soft. Figura 3.4 ne arat c validarea stabilete dac sistemul, n forma lui final, corespunde sau nu cerinelor. Faptul c validarea este posibil doar cnd sistemul ajunge n forma final este un punct slab al modelului, ndeosebi n situaia n care procesul de modelat are afiniti structurale sau conjuncturale cu nisipurile mictoare.

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

3.2.3 Modelul incremental (MI) Putem considera c este o alt form a MC. ncercnd s repare unele dintre neajunsurile

criticate la MC i MV, MI se expune criticilor venind din alt direcie. S vedem, mai nti oferta MI sub form grafic (Figura 3.5).

Dup cum se observ n Figura 3.5, dup dou faze desfurate la nivel de sistem (definirea cerinelor i analiza) care permit obinerea unei perspective arhitecturale asupra sistemului modelat, MI propune, pe aceast baz, descompunerea proiectului n subproiecte care genereaz o cascad de activiti paralele care permit obinerea componentelor necesare sistemului final. Fa de MV, MI ofer posibilitatea atingerii scopului final n dou variante: sistem global livrat la sfrit sau componente livrate distinct.

n categoria avantajelor MI considerm:

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

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

Definirea cerinelor Validare

Proiectare sistem

Testare sistem

Proiectare subsisteme

(componente)

Testare subsisteme (componente)

Codificare/ asamblare

componente

Proiectul sau sistemul final poate fi realizat de mai multe echipe sau persoane datorit modularizrii lui.

Figura 3.5. Modelul incremental Dintre dezavantajele imediate considerm:

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

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

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

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

3.2.4 Modelul spiral (MS) A fost lansat de un specialist n IS cu preocupri ndelungate legate de ciclul de via al

dezvoltrii sistemelor soft, B.W.Boehm. La baza MS stau dou convingeri:

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

Definirea cerinelor

Analiza

Proiectare compo- nenta_1

Implementare compo- nenta_1

Instalare compo- nenta_1

ntreinere compo- nenta_1

Proiectare compo- nenta_n

Implementare compo- nenta_n

Instalare compo- nenta_n

ntreinere compo- nenta_n

Arhitectura sistemului

deficiena nregistrat la MV n care validarea se efectueaz prea trziu, l determin pe Boehm s propun realizarea acesteia ct mai devreme posibil, de ct mai multe ori, prin construirea de prototipuri, ca n Figura 3.6. n varianta Boehm, echipa de dezvoltare i utilizatorii se angajeaz treptat n proiect,

diminund riscurile la nivel de prototip. Interesant este i posibilitatea valorificrii experienei acumulate n planificarea activitilor din prototipul urmtor.

De precizat faptul c MC se regsete n fiecare iteraie. Ca elemente ce condiioneaz utilizarea cu succes a modelului semnalez:

-profesionalismul echipei de dezvoltare;

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

Figura 3.6. Modelul spiral

3.2.5 Modelul evolutiv (ME) Este cunoscut faptul c abordarea obiect orientat asigur un nalt grad de mapare a

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

START

Evaluare prototip 1

Evaluare prototip n

Evaluare prototip 2

STOP

Figura 3.7. Modelul evolutiv

La terminarea unui segment, clientul intr n posesia unei forme cvasi-finite a sistemului. Puternica orientare a modelului evolutiv ctre lumea utilizatorilor are un impact deosebit

asupra implicrii acestora n dezvoltarea segmentelor sistemului. Reuita utilizrii modelului evolutiv const n specificarea unei arhitecturi deschise, flexibile, prin implicarea tuturor prilor interesate, inclusiv a utilizatorilor, dar i a unor specialiti IS profesioniti.

ME preia caracteristica esenial a modelului circular, o form existent printre modelele tradiionale. Concepia modelului circular se baza pe ciclul unui sistem, realizat prin cercuri comp