Metode si tehnici de programare

Metode si tehnici de programare

Dupa cum rezulta din evolutia prezentata in paragraful anterior, exista mai multe metode de elaborare a produselor-program. In continuare vom prezenta caracteristicile principale ale acestor metode, deoarece multe din aceste caracteristici se regasesc in metodele si tehnicile utilizate in prezent.

Metoda programarii clasice

Prin programarea clasica se face referire la primii ani de dezvoltare a programelor, respectiv inceputul anilor '50, perioada in care existau putine reguli, majoritatea vizand scrierea programelor. De aceea, programarea clasica este impropriu numita metoda, insa se face delimitarea de evolutiile ulterioare din domeniul programarii calculatoarelor.

Programarea clasica presupune conceperea monolitica a programului prin parcurgerea unor etape[1]

analiza problemei in vederea stabilirii exacte a cerintelor informationale ale utilizatorilor;

elaborarea schemei logice a programului;

scrierea programului sursa;

compilarea si ansamblarea programului;

testarea si corectarea programului;

exploatarea programului.

Dezvoltarea programelor in aceasta perioada prezenta o serie de neajunsuri dintre care mai importante erau: elaborarea intuitiva sau artizanala a algoritmilor de rezolvare a problemei; existenta numeroaselor operatii de salt (instructiuni GOTO) ce conduc la un timp mare de executie a programului si fac dificila intelegerea programului si modificarea acestuia, chiar daca acesta dispune de documentatie; imposibilitatea desfasurarii activitatii de programare in echipa; ineficienta si slaba productivitate a activitatii de programare, mai ales in cazul programelor mai mari etc.

Acestea sunt doar cateva din motivele care au determinat progrmatorii sa identifice si sa formuleze reguli care sa-i ghideze in activitatea lor si care au condus la aparitia unor metode de programare.

Metoda programarii modulare

Programarea modulara poate fi considerata prima metoda de programare propriu-zisa. Premisele aparitiei ei au fost create odata cu aparitia limbajului FORTRAN, care oferea posibilitatea utilizarii subprogramelor si compilarii lor separate. Compilarea separata a dus la aparitia bibliotecilor de subprograme.

Programarea modulara este o metoda de concepere a programelor care presupune descompunerea problemei de rezolvat in mai multe subprobleme mai simple, conform preceptelor gandirii carteziene: orice problema, oricat de complexa ar fi, poate fi descompusa in subprobleme rezolvabile mai usor decat problema initiala. In acest mod, programatorii se pot concentra numai asupra unei subprobleme, considerand-o ca o problema de sine statatoare, dar care este mai simpla si mai usor de rezolvat.

Trebuie remarcat deja interesul pentru instituirea de reguli in conceperea programelor si nu doar pentru scrierea programelor, precum si considerarea lor ca activitati independente; proiectarea modulelor programului se face independent de limbajul de programare ales, doar la scrierea programelor tinandu-se cont de specificul fiecarui limbaj. Fiecarei subprobleme ii va corespunde, in principiu, un modul de program, iar produsul-program va fi constituit prin integrarea modulelor componente, dezvoltate separat. De aici deriva si numele metodei - programarea modulara.

Modulul este considerat o unitate structurala de sine statatoare, fie program, fie subprogram, fie o unitate de program[2]. Un modul poate fi format, la randul sau, din mai multe module. Modulele sunt relativ independente, ceea ce inseamna ca modificarea unui modul nu implica neaparat modificarea celorlalte module. Astfel, in cazul modificarii structurii unui program, daca functia pe care o realizeaza un modul nu este afectata, atunci acel modul va fi utilizat in continuare fara modificari. In fapt, obiectivul principal urmarit la proiectarea modulelor consta in identificarea unor module cat mai generale si mai independente intre ele, care sa permita reutilizarea lor in cazul modificarii programelor. De asemenea, modulele pot comunica intre ele prin transmiterea de date.

Fiecare modul are rolul sau bine precizat si realizeaza o functie in cadrul intregului program, in conformitate cu rezultatele descompunerii functionale a problemei de rezolvat, realizata prin aplicarea strategiei descendente ("top-down"). De fapt, din abordarea modulara s-a desprins scoala descompunerii functionale[3]. Metoda presupune identificarea functiilor pe care le va realiza programul in vederea rezolvarii problemei, asocierea unui modul pentru una sau mai multe din functiile identificate, stabilirea legaturilor dintre module, obtinandu-se astfel structura programului. Dupa ce structura programului este clar definita, se trece la transpunerea modulelor in constructii sintactice specifice limbajului de programare ales (scrierea programelor-sursa), compilarea acestora si realizarea celorlalte faze necesare obtinerii programelor executabile.

Avantajele programarii modulare sunt multiple, printre cele mai importante se numara:

cresterea calitatii programelor obtinute; ele contin mai putine erori, sunt mai usor de inteles si de modificat.

Sporirea productivitatii si eficientei in activitatea de programare, prin facilitarea lucrului in echipa si utilizarea bibliotecilor de subprograme.

Usurarea testarii programului prin efectuarea unei testari la nivelul modulelor.

Obtinerea unor produse-program extensibile, ceea ce permite adaugarea unor noi module in programul existent daca ulterior se doreste realizarea unei noi functii.

Metoda programarii structurate

Metoda programarii structurate reprezinta o dezvoltare a metodei programarii modulare prin introducerea unor noi principii, instrumente si tehnici, cu scopul unei mai bune stapaniri a complexitatii programelor mari. Complexitatea programului priveste dificultatea elaborarii produselor-program odata cu cresterea dimensiunii acestora. Complexitatea programelor creste exponential si nu liniar cu dimensiunea sa. De aceea, obiectivul principal al programarii structurate a fost acela de a introduce ordine si rigoare in elaborarea de produse-program, ca o cale de stapanire a complexitatii. Fara a intra in detalii, sa spunem ca pana in prezent metoda programarii structurate a reusit sa realizeze doar partial obiectivul propus.

Principiile programarii structurate au fost introduse de Bohm si Jacopini in 1966, atunci cand ei au demonstrat ca pentru a exprima logica interna a oricarui program sunt suficiente trei tipuri de structuri de control: structura secventiala, structura alternativa si structura repetitiva, iar fiecare din aceste structuri, ca parte dintr-un program, are o singura intrare si o singura iesire. Prin umare, programarea structurata ar putea fi definita ca programarea fara instructiunea GOTO.

Programarea structurata a fost consacrata la inceputul anilor '70 prin contributiile a numerosi autori: Dijkstra, Hoare, Mills, Baker, Wirth, Dahl, Warnier etc. In aceasta perioada, aplicarea tehnicilor structurate era limitata la activitatea de scriere a programelor, urmarindu-se oferirea unor solutii la urmatoarele probleme: Cum ar trebui sa arate un program? Care este legatura dintre structura statica si structura dinamica a unui program? Cum poate fi controlata complexitatea unui program atunci cand marimea lui creste?

Un alt obiectiv urmarit in programarea structurata priveste modul de scriere a unui program astfel incat el sa fie usor de inteles si modificat. Claritatea unui program poate fi obtinuta, in afara utilizarii celor trei structuri de control fundamentale, prin respectarea urmatoarelor doua reguli:

scrierea indentata a textului programului si

inserarea de comentarii in textul programului.

Metoda programarii structurate a evoluat continuu, in sensul introducerii disciplinei nu doar in scrierea programelor, ci si in celelalte faze ale elaborarii programelor: analiza, proiectarea, testarea etc. Astfel, programarea structurata poate fi definita intr-un sens restrans si unul larg[4]. In sens restrans, programarea structurata face referire la activitatea de codificare (scriere a programelor) si reprezinta o metoda de construire a programelor in conformitate cu un set de reguli care solicita utilizarea unui format strict, a structurilor de control standard si a unui set de constructii logice. In sens larg, programarea structurata reprezinta o metodologie care impune disciplina asupra formei programelor, in analiza, proiectarea, scrierea si testarea programelor; ea este o metodologie de programare pentru construirea de programe modulare, ordonate ierarhic, prin utilizarea structurilor de control standard. Astazi, prin programare structurata se face referire la sensul sau larg, motiv pentru care se vorbeste de filozofia structurata.

In concluzie, meritul principal al tehnicilor structurate este acela de a fi preluat toate practicile si experientele acumulate in programare si de a le fi formalizat si standardizat. Programarea structurata preia principiile programarii modulare pe care le dezvolta, dar se deosebeste de aceasta cel putin prin doua aspecte:

modularizarea ierarhica a programelor si

utilizarea structurilor de control fundamentale

Avantajele oferite de metoda programarii structurate sunt numeroase, retinand in continuare doar cateva dintre acestea:

cresterea calitatii programelor;

sporirea flexibilitatii programelor, ceea ce usureaza intretinerea lor;

organizarea rationala a intregului proces de dezvoltare a programelor;

cresterea productivitatii in dezvoltarea programelor de aplicatie prin specializarea activitatilor.

Metoda programarii orientata-obiect

Programarea orientata-obiect pune in centrul atentiei notiunea de obiect, considerata drept o entitate care se poate distinge de alte entitati si care are o semnificatie in contextul aplicatiei modelate. Obiectul asociaza datele si prelucrarile in cadrul aceleiasi entitati, ramanand vizibila doar interfata obiectului. Obiectele cu proprietati similare, comportament similar si relatii similare fata de alte obiecte constituie o clasa de obiecte.

Un obiect comporta un aspect static, reprezentat prin intermediul unor variabile de stare numite atribute si un aspect dinamic, reprezentat de comportamentul obiectului si implementat prin intermediul metodelor asociate obiectului respectiv. Aspectul static este ascuns de aspectul dinamic. In acest fel, abordarea orientata-obiect se distinge de abordarea structurata In locul unei structurari separate a datelor si a functiilor (reprezentate de prelucrari), se modeleaza entitati active formate din structuri de date ascunse de functii. Un program este privit intr-o maniera globala, ca un ansamblu de obiecte care interactioneaza prin intermediul mesajelor, fiecare obiect avand asociat propriul set de operatii.

Obiectul, in viziunea programarii orientate-obiect, are urmatoarele caracteristici:

identitate: obiectul este o entitate discreta care poate fi distinsa de alte entitati;

clasificare: obiectele cu aceleasi atribute si operatii sunt grupate in clase, iar un obiect este considerat o instanta a clasei din care face parte;

polimorfism: aceeasi operatie poate avea comportament diferit in functie de obiectul la care este atasata, implementarea concreta a unei operatii intr-o anumita clasa numindu-se metoda

mostenire: atributele si operatiile se transmit de la o clasa la alta de-a lungul unei relatii ierarhice.

Pentru transmiterea similaritatilor de la o clasa de obiecte la alta, in conditiile pastrarii diferentelor intre acestea, se utilizeaza generalizarea si mostenirea. Generalizarea este relatia dintre o clasa si una sau mai multe versiuni rafinate ale ei, in care clasa care se rafineaza se numeste superclasa, iar fiecare versiune mai rafinata se numeste subclasa. Atributele si operatiile comune sunt grupate in superclasa si se spune ca sunt mostenite de subclase.

Punctele forte ale abordarii orientata-obiect constau in capacitatea de a modela obiecte complexe, de a exprima intr-o maniera integrata dinamica obiectelor, incapsularea acestor obiecte pentru a ascunde implementarea lor, posibilitatea reutilizarii unor componente ale produsului-program. Punctele slabe sunt reprezentarea monolitica a aplicatiilor, ceea ce nu corespunde cu adevarat perceptiei ce o avem asupra realitatii si marele efort de abstractizare.

Preceptele abordarii orientata-obiect au fost aplicate cu succes mai intai in domeniul programarii, iar de la inceputul anilor '90, ca si in cazul tehnicilor structurate, s-au accentuat preocuparile specialistilor pentru implementarea lor si in celelalte faze ale elaborarii programelor. In consecinta, au aparut mai multe metode orientate-obiect de relizare a produselor-program.

In vederea simplificarii procesului de dezvoltare a programelor prin abordarea orientata-obiect, s-au inregistrat numeroase preocupari de integrare a diferitelor metode orientate-obiect existente. Dintre aceste incercari, cea mai cunoscuta si mai reusita s-a concretizat in standardul UML (Unified Modeling Language). UML a rezultat prin integrarea a trei din cele mai cunoscute metode orientate-obiect: OOD (Object Oriented Design) propusa de Booch, OMT (Object Modelling Technique) propusa de Rambaugh si OOSE (Object-Oriented Software Engineering) propusa de Jacobson. In 1996, OMG - Object Management Group si-a manifestat interesul pentru rezultatele muncii celor trei autori, in vederea adoptarii UML ca standard in modelarea orientata obiect. In urma colaborarii si cu alti specialisti din domeniu, UML a fost adoptat ca standard OMG in septembrie 1997, fiind astfel utilizat de majoritatea producatorilor de instrumente de dezvoltare a sistemelor informatice si specialisti in domeniu. OMG si-a asumat responsabilitatea dezvoltarii ulterioare a standardului UML.

Programarea vizuala

Complexitatea mediilor de dezvoltare a aplicatiilor si bariera artificiala ce se interpune intre programator si aplicatii sunt doar doua impedimente pe care le elimina programarea vizuala. In plus, usurinta de invatare si exploatare a limbajelor constituie un argument hotarator in favoarea programarii vizuale. Obiectivul declarat al acesteia este ca programarea sa devina mai usoara pentru programatori si mai accesibila nespecialistilor, indiferent de destinatia limbajului: proiectarea rapida a aplicatiilor, prototipizare, simulari etc. In oricare domeniu, limbajele vizuale trebuie sa permita utilizatorului sa se concentreze asupra problemei ce o are de rezolvat si mai putin asupra limbajului de programare propriu-zis

Notatiile vizuale au fost utilizate, practic, de la aparitia programarii, ele devenind treptat tot mai complexe. Programatorii au inteles facilitatiile si puterea pe care le confera notatiile vizuale, mai ales in contextul tehnologiilor tot mai sofisticate.

In mod natural, oamenii se raporteaza la lumea reala in mod grafic, iar imaginile se constituie ca si componenta principala a gandirii creative. In aceste conditii, limbajele de programare textuale s-au dovedit destul de dificil de invatat pentru oameni dealtfel creativi si inteligenti. Prin reducerea sau eliminarea completa a necesitatii de a traduce ideile vizuale in reprezentari textuale, uneori artificiale, devine posibila atenuarea curbei de invatare a unui limbaj de programare.

Programarea vizuala imbraca mai multe forme si acopera o arie larga de aplicatii, de unde si diversitatea opiniilor si a punctelor de vedere. Astfel, unii specialisti considera ca acest concept a aparut odata cu mediile de programare precum Visual Basic sau Visual C++. Pentru altii, Visual Basic este nereprezentativ pentru domeniul vast al tehnologiilor care poarta eticheta vizual. Ei considera ca programare vizuala inseamna Prograph (Pictorius), Visual AppBuilder (Novell) sau Parts (Digitalk).

Nu exista o definitie unanim acceptata pentru programarea vizuala, dar majoritatea specialistilor sunt de acord ca este limbaj de programare vizuala acela care-si realizeaza toate sarcinile de programare intr-o maniera vizuala, fara a face uz de reprezentarea textuala. O definitie frecvent citata considera ca programarea vizuala inseamna utilizarea de expresii vizuale (grafice, icon-uri, desene) in procesul de programare[5]

Mai este intalnit in literatura de specialitate termenul de programare vizuala pura care are in vedere modul de proiectare al unui program, prin operare directa asupra unui set de elemente grafice. Operarea directa se realizeaza prin intermediul unor tehnici de interactiune, iar programul se dezvolta fara a scrie instructiuni sub forma de text.

Pentru Visual Basic si altele asemenea exista notiunea de limbaje de programare transformate vizual, care au implementate anumite tehnici de reprezentare vizuala a informatiilor, ce se suprapun unor limbaje textuale[6]

Un alt concept este cel al mediilor de programare vizuala, definite de unii autori ca si mediile in care sunt implementate limbajele de programare vizuala.

In alte opinii, mediile de programare vizuala (Visual Programming Environment) asigura dezvoltarea rapida a aplicatiilor (RAD - Rapid Application Development). Ele se caracterizeaza printr-un grad ridicat de utilizare a elementelor grafice si sunt utilizate in scopul accelerarii dezvoltarii si distributiei aplicatiilor, motiv pentru care sunt denumite si medii de dezvoltare vizuala a aplicatiilor.

Ar fi poate utila o separare intre aceste doua concepte - limbaje de programare vizuala si medii de programare vizuala. Primul are in vedere limbajele care se sprijina pe tehnicile vizuale pe intreg parcursul procesului de programare: proiectarea, testarea, depanarea si executia se realizeaza in acelasi mediu vizual. Mediul de programare vizuala lucreaza adesea cu reprezentari vizuale suprapuse elementelor textuale. Cele mai des intalnite in practica sunt limbajele de proiectare a interfetelor grafice care, combinate cu elemente textuale sunt utilizate in proiectarea de aplicatii. Caracteristicile programarii vizuale, care se concretizeaza in simplificarea si optimizarea procesului de programare din punct de vedere al timpului necesar construirii aplicatiei au transformat mediul de programare vizuala intr-un mediu RAD.

In categoria mediilor RAD se incadreaza: Visual Basic, Visual FoxPro si Visual C + + (Microsoft), Delphi (Borland), Visual Objects (Computer Associates), PowerObjects (Oracle), Power Builder (Power Software), SQL Windows (Gupta), VisualAge (IBM).

Liderul pietei RAD este Visual Basic, produs de Microsoft. Cei de la Microsoft au observat la timp aparitia unei noi categorii de utilizatori, numita generic power users. Aceasta a derivat din cea a utilizatorilor finali si poate fi numita "utilizatori finali avansati" care, fara a fi profesionisti, au acumulat suficiente cunostinte si isi pot rezolva singuri o buna parte din problemele curente folosind aceste medii de programare.

Intr-un mediu de dezvoltare vizuala se cuprind[7]

mediul de lucru integrat, care asigura dezvoltarea aplicatiei si permite accesul la toate componentele unei aplicatii

instrumente vizuale de descriere a interfetei, folosite pentru a defini form-uri, ferestre de dialog, machete de rapoarte etc. Plasarea controalelor se face prin drag&drop, iar definirea proprietatilor printr-un "inspector de obiecte";

limbajul de programare, care este in continuare necesar, in ciuda tuturor facilitatilor vizuale oferite de aceste medii de lucru. Acesta este mai mult sau mai putin orientat obiect (exemple: diverse variante de Basic, Pascal, limbaje xBase, SmallTalk);

suportul pentru conectarea la diferite surse de date - conectivitatea prin ODBC (Open DataBase Connectivity) este cea mai frecvent intalnita;

componentele vizeaza obtinerea unui spor de productivitate in dezvoltarea aplicatiilor si se refera la doua aspecte: utilizarea de componente prefabricate si reutilizarea codului de la o aplicatie la alta;

suportul pentru activitatile specifice distributiei (compilarea aplicatiei, realizarea discurilor de instalare, a documentatiei etc.).

Figura nr. 2.2 ilustreaza o parte dintr-o aplicatie scrisa in Visual Basic. Se observa ca este vorba despre o fereastra intitulata CALCUL AMORTIZARE, ceea ce indica scopul utilizarii ei. Ea poarta numele de form, termen intalnit la noi si ca formular sau chiar forma.

Form-ul reprezinta zona principala de lucru, o aplicatie constand de regula din mai multe form-uri, legate intre ele in functie de logica ei. Practic, intreaga aplicatie se desfasoara in limitele form-urilor, pe care sunt plasate diverse componente ce au atasate secvente de cod. Asa cum se observa in figura 2.2, astfel de componente sunt: casetele de text (text box), etichete (label), butoane de comanda (command button). Ele sunt denumite generic controale (in engl. controls) si sunt de fapt obiecte, descrise printr-o parte statica (descriptiva) si una dinamica. Numarul lor este extrem de mare, in fiecare mediu de dezvoltare existand posibilitatea de a lucra si cu controale externe (numite third-party components, deoarece pot fi create de alte firme si inglobate in aplicatii). In fine, trebuie precizat aici ca insasi form-ul este tratat ca un obiect, avand toate caracteristicile care sunt descrise in continuare.

Ca si obiect programabil, un control este definit in primul rand printr-un ansamblu de proprietati. O proprietate poate fi definita ca un atribut nominalizat al unui obiect programabil. Proprietatile definesc atat caracteristicile unui obiect (dimensiune, culoare, pozitie pe ecran), cat si modul in care se comporta un obiect (de exemplu, un obiect poate fi la un moment dat, activ sau inactiv, sau poate fi afisat pe form sau ascuns). Orice proprietate a unui obiect are o valoare care se poate modifica la proiectare si/sau executie.

Figura nr. 2.2 Form-ul CALCUL AMORTIZARE, realizat in Visual Basic

Oricat de multe proprietati ar avea, un obiect este complet descris cu ajutorul metodelor, pentru ca acestea indica ce face obiectul. Deci, proprietatile descriu un obiect, in timp ce metodele permit unui obiect sa faca ceva. Proprietatile sunt date, metodele sunt secvente de instructiuni. O metoda reprezinta o procedura asociata sau incorporata, un bloc de cod care poate fi invocat pentru a asocia o anumita actiune unui obiect. In Visual Basic, o metoda nu se poate modifica. Exista totusi o clasa speciala de metode care se pot modifica, numite proceduri eveniment. Procedura eveniment este un subprogram atasat unui obiect care contine raspunsul obiectului la proceducerea unui eveniment. Spre deosebire de metode, care sunt nemodificabile, procedurile eveniment sunt cele care particularizeaza comportamentul unui obiect intr-o aplicatie.

In varianta Visual Basic - ca si a celorlalte medii vizuale de dezvoltare - programul consta dintr-un ansamblu de rutine, cele mai multe avand dimensiuni reduse. Acestea se numesc proceduri eveniment si fiecare trateaza un eveniment individual. O astfel de procedura se executa daca si numai daca se produce evenimentul pentru care ea a fost scrisa. Altfel spus, un program va raspunde unui eveniment care se produce la rulare numai daca a fost scrisa o procedura pentru evenimentul respectiv, altfel acesta va fi ignorat.

Fiecare control plasat pe un form suporta mai multe evenimente. De exemplu, o caseta de text poate raspunde la unul din urmatoarele evenimente: clic, dublu clic, introducerea unui text. Daca pentru evenimentul clic este scrisa o procedura, atunci cand ruleaza aplicatia si se executa clic pe caseta de text (se produce in acest fel evenimentul) - se va lansa automat in executie procedura definita.

Cele prezentate mai sus ne indreptatesc sa consideram mediile de dezvoltare vizuala a aplicatiilor mai mult drept limbaje/medii multiparadigma, ele reunind principii ale:

programarii vizuale (manipularea de reprezentari vizuale);

programarii OO (lucrul cu obiecte, principiile incapsularii si reutilizarii);

programarii dirijate de evenimente;

programarii structurate (utilizarea structurilor de control fundamentale in cadrul procedurilor).

Elaborarea produselor-program

Elaborarea unui produs-program constituie o activitate deosebit de complexa, care  necesita utilizarea unei metodologii clare si unitare. De regula, o asemenea activitate se desfasoara in echipe de lucru complexe in care sunt inclusi analisti, specialisti ai domeniului pentru care se dezvolta produsul-program, programatori, specialisti in testarea si implementarea produselor-program, utilizatori etc.

Literatura de specialitate pune in discutie o multitudine de probleme legate de metodologia elaborarii produselor-program si subliniaza in mod deosebit necesitatea existentei unei metodologii unitare. Totusi, putem afirma ca in forma sa finala orice produs-program poate fi privit ca un sistem cu functii si componente proprii, cu intrari, iesiri, prelucrari specifice si bucla de autoreglare si cu un scop bine stabilit.

Modele de elaborare a produselor-program

Din punct de vedere practic, elaborarea unui produs-program presupune parcurgerea unui anumit numar de activitati specifice obtinerii acestuia. Exista un numar insemnat de modele pentru elaborarea unui produs-program, dintre care cele mai importante sunt: modelul in cascada, modelul in V, modelul spirala, modelul liniar, modelul incremental, modelul RAD.

. Modelul in cascada

Dintre toate modelele enumerate mai sus, modelul in cascada este cel mai des utilizat in practica.  Activitatile avute in vedere la elaborarea produselor-program in cazul modelului in cascada (vezi si figura 2.3) sunt:

definirea problemei;

analiza;

proiectarea;

dezvoltarea;

testarea;

implementarea;

intretinerea.

Fig. nr. 2.3. Modelul in cascada de elaborare a unui produs-program

Acest model a fost dezvoltat de catre Royce in 1970 si este cel mai familiar programatorilor. Asa dupa cum se observa in figura precedenta, caracteristica fiecarei etape consta in a se finaliza cu o verificare si o validare in scopul eliminarii eventualelor anomalii  care ar putea sa apara in cadrul fiecareia. Daca se constata eventuale anomalii, atunci se va reveni la etapa precedenta pana cand acestea vor fi eliminate. In acest fel se realizeaza o minimizare a costului pentru produsul-program dezvoltat. In acelasi timp, trecerea de la o faza la alta, in sus si in jos, ofera modelului un caracter iterativ si incremental.

Modelul in V

Modelul in V poate fi considerat ca un caz particular al modelului in cascada prin faptul ca activitatile necesare elaborarii produsului-program sunt reprezentate grafic sub forma lui "V". Esenta modelului consta in aceea ca separa primele etape ale procesului de dezvoltare in sub-activitati ce au legatura cu constructia sistemului. Aceasta organizare sub forma literei "V" este data de faptul ca se pune in relatie directa de dependenta primele etape cu cele aflate in partea de jos din modelul in cascada.

In acest model se delimiteaza urmatoarele activitati[8] [GRAM2000,55]:

1.     analiza cerintelor si studiul de fezabilitate;

2.     specificarea globala;

3.     proiectarea de ansamblu;

4.     proiectarea de detaliu;

5.     programarea;

6.     testarea unitara;

7.     integrarea si testul de integrare;

8.     testul de acceptare;

9.     implementarea si testul sistem.

Constatam ca din lista de mai sus activitatile 1-5 influenteaza in mod permanent o activitate din 6-9, ceea ce permite o mai buna organizare a etapelor finale.

Dezavantajul acestui model consta in ca nu pune in evidenta posibilitatea reluarii unei activitati deja parcurse, ceea ce poate sa conduca la depistarea unor anomalii functionale ale produsului-program in faza de implementare. Acest lucru va duce la reluarea intregului proces de elaborare a produsului program cu costuri corespunzatoare si pierderi de timp.

Modelul in spirala

Modelul in spirala a fost propus in 1988 de catre B. W. Boehm si este cel mai cunoscut model evolutiv. El are la baza doua premise[9]:

natura iterativa a dezvoltarii si nevoia de planificare si evaluare a riscurilor fiecarei iteratii;

realizarea validarii cat mai devreme posibil si de cat mai multe ori, prin construirea prototipurilor.

Obiectivul principal urmarit prin modelul spirala este gestiunea atenta a riscurilor prin combinarea modelului cascada cu prototipizarea. Se construieste mai intai o prima versiune a sistemului, sub forma unui prototip, in care nu este definit intregul sistem ci sunt luate in considerare doar caracteristicile sale principale. Dupa transpunerea prototipului in aplicatie, aceasta este evaluata de catre beneficiari, iar in functie de rezultatul evaluarii se pot defini si implementa noi caracteristici ale sistemului, construindu-se un nou prototip ce va fi supus evaluarii. Acest proces se reia de mai multe ori, urmatoarele prototipuri fiind versiuni din ce in ce mai complete ale sistemului propus. Modelul cascada se va regasi in cadrul fiecarei iteratii.

Modelul spirala este descompus in mai multe activitati-cadru - maxim 6, cum sunt prezentate in continuare:

comunicarea cu beneficiarul (stabilirea si mentinerea contactului dintre beneficiar si proiectant);

planificarea (definirea resurselor, a termenelor limita de realizare);

analiza riscului (riscuri tehnice si de organizare);

proiectarea (definirea uneia sau mai multor reprezentari ale aplicatiei);

construirea si lansarea;

evaluarea beneficiarului (feed-back din partea beneficiarului asupra schimbarilor din noua versiune instalata).

Cea mai cunoscuta varianta a modelului este cea bazata pe 4 elemente majore, ca in figura 2.4.

Printre avantajele modelului spirala se pot enumera:

diminuarea riscurilor la nivel de prototip, prin angajarea treptata in proiect a echipei de dezvoltare si a beneficiarilor;

valorificarea experientei anterioare in planificarea activitatilor pentru prototipul urmator;

evaluarea riscurilor asociate proiectului in mai multe momente;

simplificarea operatiunilor de evaluare a ceea ce este necesar in etapa (prototipul) urmatoare, inclusiv prin prisma costurilor.

Fig. nr. 2.4 Ilustrarea modelului in spirala

Aplicarea cu succes a modelului spirala este conditionata de profesionalismul echipei de dezvoltare si flexibilitatea in actiune, inclusiv in alocarea de fonduri, dar si in definirea activitatilor de intreprins.

Modelul RAD

Dezvoltarea aplicatiilor trebuie sa raspunda, ca orice domeniu de activitate, principiului productivitatii si eficientei economice. Detaliind, putem identifica mai multe aspecte ce trebuie avute in vedere in dezvoltarea unei aplicatii[10]

productivitatea resurselor;

calitatea produsului;

timpul de realizare;

simplificarea intretinerii;

satisfactia utilizatorului.

Modelul RAD isi propune sa porneasca de la sursa, adica de la nevoile utilizatorilor. Utilizatorul se gaseste in centrul atentiei, fiind clientul sistemului ce se realizeaza.

RAD reprezinta un arhetip revolutionar de succes in software-ul anilor '90, caracterizat pe scurt prin "mai repede, mai bine, mai ieftin", ceea ce este posibil de realizat printr-o abordare foarte riguroasa, bazata pe echipe mici de specialisti bine pregatiti, pe utilizarea prototipurilor si impunerea unor limite rigide de timp in planificarea activitatilor.

RAD se bazeaza pe modelul spirala, ceea ce permite dezvoltarea incrementala si repetitiva. Desi nu reiese din figura 2.5, trebuie precizata influenta metodelor orientate-obiect, ce asigura o eficienta sporita pentru RAD, prin utilizarea de componente pre-fabricate. De asemenea, RAD apeleaza la generarea automata a codurilor prin sisteme CAPS (Computer-Aided Prototyping System), care inlocuiesc scrierea manuala, mai inceata a codului si minimizeaza erorile. In fine, RAD inseamna flexibilitate, prin faptul ca permite utilizatorilor sa foloseasca propriile limbaje de interogare sau generatoare de rapoarte. Dupa definirea de catre J. Martin a filosofiei RAD[11] a urmat un val de propuneri de modele de dezvoltare a aplicatiilor de tip RAD.

Figura nr. 2.5 Fazele unui ciclu de dezvoltare RAD

RAD se individualizeaza prin urmatoarele caracteristici:

utilizarea de echipe mixte, formate in medie din 6 persoane, incluzandu-i pe utilizatorii finali, manageri si pe dezvoltatorii sistemului (aceasta denumire face referire la specialistul "multilateral", ce are atat cunostinte specifice analizei de sistem, cat si de proiectare si programare). Trebuie precizat ca experienta anterioara este deosebit de importanta, iar succesul proiectului este asigurat prin implicarea activa a utilizatorilor, ca si prin comunicarea si colaborarea permanenta intre membrii echipei;

utilizarea de instrumente specializate (4GL) care asigura:

dezvoltarea "vizuala",

crearea de prototipuri,

planificarea si gestiunea timpului,

colaborarea si lucrul in echipa,

folosirea componentelor re-utilizabile si a componentelor API,

controlul versiunilor;

renuntarea la caracteristici sau componente secundare (in special cu rol de imbunatatire a interfetei sau a dialogului cu utilizatorul) pentru a asigura incadrarea in termenele stabilite. De regula, intregul proces de dezvoltare are o durata maxima de 6 luni;

prototipizarea iterativa, evolutiva.

Etapele unui ciclu de dezvoltare RAD pot fi prezentate si in succesiunea: analiza, proiectare, realizare si integrare, testare si implementare, dar intr-un mod diferit fata de modelul clasic. Pentru ilustrare ne vom opri asupra ciclului de dezvoltare James Martin, cel mai reprezentativ dintre ciclurile de dezvoltare RAD. Exista in acest ciclu 4 faze: (1) identificarea si planificarea cerintelor, (2) proiectare, (3) construire, (4) finalizare (vezi figura nr. 2.4).

Planificarea cerintelor are ca obiectiv determinarea functiunilor sistemului. Utilizatorul trebuie sa aiba un rol activ in aceasta faza. Faza se desfasoara in asa-numitele ateliere de lucru (workshop), de tip Joint Requirements Planning. Activitatile desfasurate pot fi grupate in: evidentierea problemelor, identificarea si precizarea cerintelor, planificarea sarcinilor.

Proiectarea realizeaza modelarea sistemului prin prototipuri si alte instrumente de modelare. Activitatea se desfasoara in ateliere de lucru de tip Joint Application Design. Dupa stabilirea modelului de lucru se intocmeste rapid prototipul. Fiecare prototip va fi testat si validat in atelierele de lucru.

Construirea sistemului este apanajul specialistilor informaticieni, care transpun modelele fazei anterioare in programe. Utilizatorii testeaza componentele si le valideaza sau solicita, daca e necesar, ameliorarea acestora. Faza se incheie prin integrarea componentelor in sistemul final. Asa cum reiese si din figura 2.4, aceasta faza si precedenta se constituie intr-un ciclu iterativ, pana la obtinerea rezultatului dorit (Iterate Until Done). Pe parcursul acestui ciclu  prototipurile definite si revizuite pot evolua in prototipuri operationale.

Finalizarea se refera la punerea in exploatare a sistemului. Aceasta faza continua testarile asupra produsului final, impune schimbari organizationale, formeaza si instruieste utilizatorii finali.

In sinteza, modelul RAD se bazeaza pe urmatoarele solutii[12]

Includerea utilizatorilor in echipa de realizare a aplicatiei si implicarea activa a acestora. S-a pornit de la faptul ca utilizatorii sunt sursa cerintelor informationale, ca si beneficiari directi ai aplicatiei, deci opinia lor este determinanta pentru succesul aplicatiei. Implicarea directa si continua a utilizatorilor in procesul de dezvoltare este esentiala pentru succesul RAD. Ea prezinta importanta in detectarea din timp a eventualelor erori, stiind ca daca defectul este descoperit mai repede, costul remedierii va fi mai scazut. Costul corectarii erorilor creste odata cu trecerea dintr-o etapa a ciclului de viata in alta.

Gestiunea optima a timpului. Se fixeaza intervale scurte de timp pentru realizarea componentelor. Un proiect de dimensiuni mari va fi descompus in subproiecte cu posibilitati de realizare in paralel. Pentru a asigura respectarea termenelor, se vor realiza mai intai versiuni care vor cuprinde doar functionalitatile de baza. In final, se vor integra si functionalitatile complementare.

Dezvoltarea incrementala, numita si ciclu de elaborare in spirala. Este un factor ce contribuie la sporirea vitezei de realizare a aplicatiilor. In loc sa se lanseze direct produsul final, aplicatia va apare in versiuni succesive. Se realizeaza prototipuri ale aplicatiei prin parcurgerea a 3 etape: determinarea cerintelor informationale, transpunerea lor sub forma de aplicatie, testarea acesteia de catre utilizatori. Utilizarea prototipurilor permite ca utilizatorii sa observe si sa corecteze sistemul.

Reutilizarea. O aplicatie nu mai este vazuta ca un ansamblu de programe executabile impreuna cu un ansamblu de date, care comunica prin intermediul unor interfete. Aplicatia reprezinta un ansamblu de servicii/componente care raspund unor obiective sau cerinte.

Utilizarea de instrumente CASE pentru generarea rapida si fara erori a programelor.