Dezvoltarea rapidă a aplicatiilor

Instrumentele de dezvoltare rapidă a aplicatiilor reprezintă solutia propusă de industria de software pentru iesirea dintr-o criză, provocată de cresterea exponentială a complexitătii aplicatiilor moderne.

În ultima vreme este imposibil să deschizi o revistă de tehnologia informatiei fără să te lovesti de sintagma RAD. La modul minimal, înseamnă Rapid Application Development. La modul ideal, e un soi de "Sesam, deschide-te!" al proiectării software. Poate că peste cîtiva ani termenul va fi uitat, sau va fi compromis prin abuz. Acum însă, nu putem să-l ignorăm.

Înainte de orice trebuie să remarcăm o confuzie primară: în general se vorbeste despre RAD ca despre niste instrumente software de dezvoltare. Denumirea însă pare mai degrabă să se refere la o tehnologie sau, mai precis, la o metodologie aplicabilă în procesul de dezvoltare a aplicatiilor. Evident, aplicarea ei se bazează pe instrumente software specifice, pe care le vom numi "instrumente RAD" (RAD Tools) si la care ne vom referi în mod preponderent în continuare.

Nevoia de RAD

Ca orice activitate productivă si aducătoare de profit, productia de software a fost în permanentă preocupată de problema productivitătii. Cu toate acestea, termenul RAD a apărut abia în ultimii ani, ceea ce ne sugerează ideea că anumite schimbări recente de context au condus la nevoia de RAD. La modul cel mai general, putem enumera cîteva mutatii importante în informatica ultimului deceniu. În primul rînd, democratizarea informaticii prin răspîndirea extrem de rapidă a calculatoarelor personale. În al doilea rînd, nasterea unei veritabile industrii de software, cu cifre de afaceri ametitoare. În al treilea rînd, comunicatiile.

Coborînd în sfera tehnologiei, aceste mutatii se traduc în generalizarea interfetelor utilizator grafice, în impunerea arhitecturilor Client/Server, în orientarea tot mai pronuntată spre sisteme deschise si conectivitate la toate nivelele. Proiectantii de aplicatii software s-au văzut astfel pusi în fata unor cerinte cu totul noi, care i-au prins în mare parte descoperiti. Pur si simplu, profesiunea lor s-a schimbat peste noapte.

Dezvoltarea de aplicatii care să utilizeze o interfată utilizator grafică (GUI) este radical diferită de dezvoltarea "traditională". Nimic nu mai e la fel. Controlul fluxului de executiei este cedat utilizatorului, iar aplicatia, pînă acum monolitică si atotstăpînitoare, se sparge în cioburi care trebuie să-si păstreze o relativă independentă, pentru că ar putea fi apelate în orice moment.

Mai mult chiar. Arhitectura Client/Server rupe total serviciile de procesare cele mai importante de serviciile de prezentare si interfată cu utilizatorul, distribuindu-le pe masini diferite, de regulă functionînd pe platforme hard/soft eterogene. Aceasta afectează pînă si designul fundamental al aplicatiei.

Aceste schimbări de viziune au condus la cresterea explozivă a complexitătii aplicatiilor si primul lucru care a fost clar a fost inadecvarea vechilor unelte si metode la noile cerinte. Asadar, adio Cobol, adio top-down...

Proaspăt născuta industrie de software a sărit de îndată în ajutorul năpăstuitilor proiectanti de aplicatii. Dar, după ani si ani de Read, Write si Perform, contactul cu object-oriented, event-driven, middleware s.a.m.d. a fost un soc. Un soc cultural.

Chiar dacă costurile implicate de o reprofilare a proiectantilor (timp si bani) nu ar fi fost prohibitive, lucrurile tot nu s-ar fi rezolvat. Pentru proiectantii de aplicatii economice (cei la care ne referim cu precădere) a pierde 70-80% din timpul de proiectare pritocind interfete simpatice era inacceptabil.

Solutia: amortizarea socului cultural prin instrumente de proiectare developers friendly si cresterea productivitătii prin posibilitatea utilizării unor componente prefabricate si a reutilizării unor componente proprii.

Fundamentele

Instrumentele RAD nu sînt o descoperire de ultimă oră, ci mai degrabă o solutie de iesire din criză, avînd la bază cîteva idei ceva mai vechi.

Una ar fi limbajele specializate pe domeniu, în special baze de date, cunoscute sub denumirea de 4GL - limbaje de generatia a patra. Denumirea lor vrea să evidentieze nivelul lor mai înalt (deci mai îndepărtat de masină si sistem de operare) decît al limbajelor de uz general cum ar fi C, Cobol, Pascal, etc (3GL). Aceste limbaje permit proiectantului să se concentreze asupra problemei specifice aplicatiei, scutindu-l în mare măsură de chestiunile de "bucătărie" internă, rezolvate automat (mai grosier, dar mai repede).

O altă idee de la care s-a pornit a fost cea a instrumentelor CASE (Computer Aided Software Engineering). Mai precis, a două categorii mai speciale a acestora: pe de-o parte instrumente CASE care, pornind de la specificatii precise dar exprimate într-un mod mai natural, generează cod într-un limbaj de programare si, pe de altă parte, instrumente CASE specializate pe realizarea de aplicatii prototip.

Mai trebuia ceva, iar acest ceva a iesit din pălăria Microsoft-ului sub numele de Visual Basic. Cei de la Microsoft au observat la timp nasterea unei categorii noi de utilizatori, denumită generic power users. E vorba despre acei utilizatori finali care, fără a fi profesionisti în informatică, din pasiune sau nevoie au acumulat suficiente cunostinte pentru a-si putea rezolva singuri o bună parte din problemele curente. Vechiul BASIC, considerat de programatori infantil si simplist, a fost reconditionat si transpus într-o haină nouă, vizuală. Fiind acum nu doar usor de învătat ci si usor de folosit într-un mediu grafic, Visual Basic-ul s-a impus, aducînd după el un val de "limbaje vizuale" si, desigur, un sac de bani în visteria Microsoft-ului.

Anatomia unui instrument RAD

Putem acum să schităm în linii mari structura unui instrument RAD tipic, evidentiind si variatiile considerate uzuale.

IDE (Integrated Development Environment). În primul rînd e nevoie de un mediu de lucru integrat, care să permită dezvoltarea aplicatiei de la început si pînă la sfîrsit si care să permită accesul la toate componentele aplicatiei. Unele produse din această gamă (de exemplu CA-Visual Objects) dispun de un repository, care tine în mod automat evidenta tuturor componentelor aplicatiei. Unele dispun de suport pentru dezvoltarea în echipă, permitînd controlul accesului la componente si controlul versiunilor (pentru această sarcină este adesea integrat programul PVCS al firmei Intersolv).

Instrumentele vizuale de descriere a interfetei sînt întotdeauna prezente. Cu ajutorul lor se pot desena ferestre de dialog, forme de intrare, machete de rapoarte. Plasarea controalelor se face de cele mai multe ori prin drag&drop, iar definirea atributelor (culoare, etichetă, evenimente, sursa de date, etc) este de regulă posibilă printr-un "inspector de obiecte" (regăsit în mai toate produsele sub diverse nume). Modelul impus de Visual Basic este urmat de majoritatea produselor.

Unele produse merg mai departe pe calea vizualului, permitînd descrierea de aceasi manieră a structurilor de date si a relatiilor între acestea. Mai mult, există produse (Novell Visual AppBuilder, IBM VisualAge) care permit chiar descrierea vizuală a fluxul de prelucrare.

Limbajul. Oricît de departe ar merge însă facilitătile vizuale oferite, ele nu elimină nevoia folosirii unui limbaj de programare (AppBuilder este o notabilă exceptie). Aici optiunile producătorilor sînt foarte diverse. Unii mizează pe accesibilitate, utilizînd fie variatiuni de Basic (Sybase PowerBuilder, Oracle PowerObjects) fie variatiuni de Xbase (CA Visual Objects, MS Visual FoxPro). Altii utilizează versiuni de limbaje mai puternice (Pascal în Delphi, C++ în Enterprise Developer, SmallTalk în VisualAge) sau limbaje 4GL proprii (SQLWindows).

De regulă toate aceste limbaje sînt mai mult sau mai putin orientate-obiect. Unele permit tipizarea strictă a variabilelor (Pascal-ul din Delphi, Clipper-ul din Visual Objects) si dispun de compilator adevărat, altele sînt mai libertine dar admit doar o pseudo-compilare, codul obtinut (p-code) fiind apoi interpretat. În fine, o a treia optiune o reprezintă generarea de cod într-un limbaj 3GL (de obicei C), care urmează apoi a fi compilat

Mai trebuie notat că multe instrumente RAD permit conectarea unor module scrise în limbaje traditionale.

Conectivitate. Suportul pentru conectarea la surse diverse de date este extrem de important pentru instrumentele RAD. Vremurile cînd un mediu de dezvoltare era dedicat doar anumitor surse de date au apus, astfel că acum pînă si instrumentele RAD produse de liderii sistemelor de baze de date (Sybase, Gupta, Oracle) oferă conectivitate către principalele back-end-uri, chiar rivale pe piată. În plus, suportul pentru conectivitatea prin ODBC (Open Database Connctivity) este general, în cazul produselor Windows. Standardul rival de conectivitate, IDAPI, este încă mai putin răspîndit (Borland Delphi).

Pentru a permite proiectantilor să dezvolte si mai ales să testeze aplicatiile client/server în mod off-line, multe dintre produse livrează si o versiune locală a unui server de baze de date: Watcom SQL pentru PowerBuilder si CA-Visual Objects, XDB pentru Enterprise Developer, InterBase pentru Delphi, Gupta SQLBase pentru SQLWindows, etc.

Componente. În fine, unul dintre obiectivele oricărui instrument RAD este să aducă un spor semnificativ de productivitate în dezvoltarea aplicatiilor. În această privintă se detasează două abordări: utilizarea de componente prefabricate si reutilizarea codului (si chiar a design-ului) de la o aplicatie la alta.

În prima abordare, modelul este dat de controalele VBX (Visual Basic custom controls) si de mai noile OCX-uri (OLE custom controls). Produse în general de terti producători, acestea oferă functionalităti diverse (de pildă admistrarea proiectelor de dezvoltare software, calcul tabelar, etc) ce pot fi înglobate în aplicatiile proprii. Bogătia ofertei de astfel de componente si preturile foarte atractive au determinat pe unii producători de instrumente RAD să ofere suport pentru utilizarea acestora în propriile produse (Delphi, PowerBuilder).

A doua abordare este legată în mod direct de tehnologia Object-Oriented si oferă explicatia utilizării preponderente a unor limbaje orientate pe obiecte. Desigur, există posibilitatea de a crea biblioteci de rutine obisnuite, dar gradul lor de generalitate este în mod inerent redus, ceea ce împiedică reutilizarea efectivă a codului. Solutia cea mai elegantă si cea mai productivă o constituie realizarea unei biblioteci de clase, care să poată fi preluate într-o nouă aplicatie si, dacă este cazul, specializate prin mecanismul de mostenire pentru specificul noii aplicatii. Avantajul major îl constituie faptul că cea mai mare parte a codului (uneori integral) este refolosit si, foarte important, acest cod este deja testat. Majoritatea instrumentelor RAD dispun de mecanisme specializate în această privintă (editoare de clase, browser-e) si de extensii corespunzătoare de limbaj pentru a controla elemente cum ar fi mostenirea (chiar multiplă în cazul lui SQLWindows), evenimente, mesaje, metode, protectia si vizibilitatea, etc.

Există si o cale de mijloc: distribuirea de clase predefinite, care pot fi folosite ca atare sau pot fi specializate prin mostenite. Un exemplu în acest sens îl reprezintă QuickObjects din SQLWindows. Există si solutii extreme, în care întreaga aplicatie se construieste doar din elemente prefabricate (AppBuilder).

Distributia. Odată dezvoltată o aplicatie, ea trebuie distribuită clientului sau clientilor. Aceasta implică în general compilarea modulelor componente si, eventual, realizarea unui set de dischete de instalare. Unele produse RAD controlează automat actualitatea modulelor componente (de exemplu Visual Objects), recompilînd selectiv elementele aplicatiei care au fost actualizate. De asemenea, există de regulă posibilitatea de a crea automat dischetele de instalare, incluzînd codul (interpretabil sau direct executabil), modul run-time (dacă e cazul), bibliotecile DLL, documentatia, etc.

Remarcabilă este si posibilitatea multor produse RAD de a genera, în locul aplicatiei, o bibliotecă de rutine (de regulă DLL - Dynamic Link Library) sau de clase.

Controverse

Desigur, prezentarea de mai sus nu este exhaustivă, intentia fiind doar de a surprinde "portretul robot" al unui instrument RAD. Deja se poate observa însă diversitatea optiunilor producătorilor de astfel de instrumente. Directia în care aceste produse vor evolua va depinde de mai multi factori.

Unul dintre acesti factori va fi cu sigurantă produsul care se va impune cel mai repede si mai stabil pe piată. Valul RAD abia a început, dar se consideră că actualmente liderii sînt Visual Basic si PowerBuilder. Astfel ajungem deja la problemele controversate ale domeniului.

Cui se adresează de fapt instrumentele RAD? Utilizatorilor avansati (power users) sau proiectantilor profesionisti? Microsoft, prin Visual Basic (dar si prin Access si noul VisualFoxPro) mizează pe prima categorie si face uz de toată forta sa comercială în această directie. PowerBuilder se adresează în schimb profesionistilor (ca si SQLWindows si Enterprise Developer). Ideal ar fi ca si unii si altii să aibă acces la aceste instrumente, dar simplitatea necesară primei categorii aduce inevitabil limitări care îndepărtează profesionistii. În schimb forta instrumentelor destinate profesionistilor implică o complexitate inaccesibilă utilizatorilor finali, chiar avansati.

O altă chestiune controversată este relatia între RAD si metodologia proiectării aplicatiilor. Este interesant de remarcat că majoritatea instrumentelor RAD fortează oarecum proiectantul să înceapă dezvoltarea cu interfata, ceea ce contravine total metodologiei traditionale. Explicatia constă în faptul că o aplicatie event-driven nu este structurată ierarhic, nu dispune de o "coloană vertebrală". Dimpotrivă, prelucrările se leagă în mod preponderent de elemente vizuale de interfată (dialoguri, forme, controale, etc). Pe de altă parte, o nouă metodologie s-a născut (de fapt ea este cea care se cheamă RAD), sprijinind această orientare si asigurînd ea însăsi un spor de sigurantă si productivitate. Pe de o parte aplicatia poate fi dezvoltată concomitent pe două planuri, cel vizibil si cel invizibil, care pot fi in final asamblate. Pe de altă parte, interfata utilizator, dublată de o functionalitate minimală (de regulă implicit oferită de instrumentele RAD), poate juca rolul de prototip, obtinînd astfel un valoros feed-back din partea utilizatorilor finali. Cu atît mai valoros cu cît poate fi obtinut în primele etape ale proiectării, avantaj pe care orice proiectant cu experientă îl întelege (vezi "Traditional vs. RAD").

O mentiune în acest sens pentru Symantec Enterprise Developer, care permite ambele variante de rezvoltare. Si tot legat de Enterprise Developer, ar fi de mentionat problema limitelor instrumentelor RAD. Că orice astfel de instrument trebuie să permită finalizarea în detaliu a unei aplicatii este clar. Dar unde încep sarcinile destinate instrumentelor RAD? Enterprise Developer merge pînă în primele faze ale analizei, ba chiar oferă facilităti de reverse engeneering pe aplicatii existente ce trebuie refăcute. Majoritatea celorlalte produse se concentrează asupra dezvoltării de aplicatii front-end, lăsînd de exemplu partea de proiectarea a structurilor de date pe seama unor instrumente CASE specializate.

O altă problemă controversată este cea a relatiei între programarea vizuală si cea traditională. Majoritatea programatorilor de simt frustrati dacă nu au acces la codul complet al aplicatiei, iar multe dintre mediile de dezvoltare la care ne referim nu oferă un corespondent la nivel de cod al elementelor dezvoltate vizual. O altă nemultumire a programatorilor se referă la absenta unei viziuni globale asupra aplicatiei în ansamblul ei. Aceste probleme tin probabil si de adaptarea la noile unelte, dar ele determină în mare măsură acceptanta unui astfel de produs. Remarcabilă este solutia aleasă de Gupta în SQLWindows. Corespondenta între vizual si cod este biunivocă, astfel încît în orice moment programatorul poate să aleagă între utilizarea unui instrument vizual sau să scrie cod. Editorul de cod, numit Outliner, oferă si mult dorita viziune de ansamblu, oferind totodată proiectantului sansa de a accede la fiecare linie de cod.

Schimbarea paradigmă

Pentru proiectantii de aplicatii, vremea schimbărilor a venit. Acestia trebuie să facă fată nu doar unei schimbări de instrumente, ci în primul rînd unei schimbări de paradigmă, ce implică modul de a gîndi o aplicatie, modul de a o construi, de a o testa si de a o implementa. Pentru cei inadaptabili, viitorul este sumbru.

Pentru utilizatorii avansati vin iarăsi vremuri noi. Aplicatiile pe care le vor utiliza vor fi mai prietenoase si mai apropiate de dorintele lor. Utilizatorii avansati vor avea sansa să se implice mai mult în proiectarea aplicatiilor, instrumentele de dezvoltare fiindu-le tot mai accesibile.

Cu toate că reclama comercială a instrumentelor RAD sugerează ideea programării fără programatori, nevoia de programatori profesionisti nu va scădea. Ba chiar dimpotrivă. În primul rînd, prea putine sînt aplicatiile reale, serioase, care să poată fi duse la bun sfîrsit de amatori, fie ei si power users. În al doilea rînd, avîntul comercial al instrumentelor RAD va face să se dezvolte o piată importantă pentru componente software.

Care va fi ritmul de evolutie a instrumentelor de dezvoltare de aplicati ("rapide" sau nu) este greu de apreciat. Directia însă pare să se întrevadă dacă vom mai introduce în ecuatie ceilalti doi termeni în vogă în domeniul aplicatiilor software: ComponentWare si Document-Oriented.

Vom trăi si vom vedea.


(C) Copyright Computer Press Agora