Cap. 10. Proiectarea si dezvoltarea de aplicatii orientate obiect
Dezvoltarea de sisteme orientate obiect pare a fi, la prima vedere,
mai complicata si de durata mai mare decat dezvoltarea aplicatiilor traditionale.
In realitate, durata si costurile dezvoltarii de aplicatii orientate obiect sunt
mult mai mici.
Etapa fundamentala in cadrul acestui proces o constituie cea de
proiectare a sistemului, chiar daca este evident ca structura interna a acestuia
este irelevanta pentru utilizatori. S-a constatat de asemenea ca succesul
aplicatiilor orientate obiect depinde in principal de doi factori:
1. Existenta unei viziuni arhitecturale coerente si bine
definite
Arhitectura unui sistem orientat pe obiecte cuprinde atat structura claselor
si interactiunea dintre obiecte, cat si impartirea aplicatiei in module si
nivele de abstractizare. Cateva conditii in vederea realizarii unei arhitecturi
corecte:
- nivele de abstractizare bine definite
- clase avand interfete bine definite, a caror modificare provoaca
schimbari minime asupra celorlalte clase
- modificarea modului de implementare a unei clase nu are repercursiuni
asupra interfetei sau implementarii celorlalte clase
- arhitectura sistemului este simpla, realizata prin abstractii si
mecanisme obisnuite
2. Urmarea unui ciclu de dezvoltare atat iterativ cat si
incremental bine administrat
Exista in principal doua tipuri de cicluri de dezvoltare:
- ciclu de dezvoltare nedefinit. In acest caz, este imposibil de stiut
viteza dezvoltarii sistemului, momentul la care va fi finalizat, calitatea
sistemului ramanand permanent sub semnul intrebarii. Este posibila ca o parte
din eforturile depuse sa fie ineficiente, asadar costurile dezvoltarii sa fie
foarte mari.
- reguli clare care stabilesc fiecare aspect al ciclului. In acest de-al
doilea caz, este impiedicata creativitatea si experimentul, care ar putea
produce o aplicatie avand calitate sporita. Cerintele utilizatorilor ajung cu
dificultate la nivelul programatorilor ce realizeaza aplicatia, ingreunand
procesul de dezvoltare si marindu-i costurile.
In realitate, nu vom intalni nicaieri vreunul dintre aceste cazuri
distinct. In cadrul dezvoltarii de sisteme software, aceste doua tipuri de
cicluri de dezvoltare se intrepatrund, inclinand mai mult sau mai putin spre
una dintre extreme, functie de deciziile luate de conducatorii acestor proiecte.
S-a tras in multe locuri concluzia ca un ciclu de dezvoltare ideal este atat
de tip iterativ cat si de tip incremental.
Ce inseamna ca un ciclu este iterativ? Un proces iterativ presupune
inbunatatirea succesiva a arhitecturii orientata pe obiecte, utilizand
experienta si rezultatele obtinute in fiecare etapa sau versiune in etapa
urmatoare de analiza si dezvoltare. Ce reprezinta un ciclu incremental?
In cadrul unui proces incremental, fiecare trecere printr-un astfel de ciclu de
analiza/dezvoltare conduce la inbunatatirea deciziilor, rezultand astfel in
final o solutie care intruneste adevaratele cerinte ale utilizatorilor, si are
o arhitectura clara, este eficienta si usor de intretinut.
De obicei, sistemele comerciale sunt realizate urmand un ciclu mai clar
definit, deoarece sunt realizate in cadrul unor companii cu numar mare de
programatori si trebuie executate intr-un interval predefinit de timp. Spre
deosebire de acestea, sistemele open source (realizate in lumea
free
software) sunt construite dupa un ciclu mai vag definit, dar care de cele
mai multe ori conduce la sisteme mai extensibile, mai flexibile, si de calitate
superioara celor comerciale.
Sintetizat, etapele dezvoltarii unui sistem orientat pe obiecte sunt:
- I. Analiza
1. Identificarea obiectelor din cadrul sistemului;
2. Identificarea actiunilor efectuate de fiecare obiect;
3. Identificare interactiunilor dintre aceste obiecte (mesajele prin
care comunica obiectele).
- II. Abstractizarea
1. Stabilirea claselor ale caror instantiere sunt aceste obiecte;
2. Elaborarea ierarhiei de clase.
- III. Implementarea
1. Impartirea pe module (clase) a ierarhiei de clase;
2. Elaborarea claselor de baza (fundamentale);
3. Elaborarea celorlalte clase din ierarhie (in aceasta etapa se
determina si disfunctiile in proiectare/implementare a claselor de baza si este
posibila revenirea la pct. 2).
4. Asamblarea intr-un tot unitar a modulelor (claselor)
- IV. Testarea (se realizeaza si pe parcursul etapelor III: 2-4)
- V. Scrierea de documentatie (eventual in timpul etapelor III si
eventual IV).
Perioada de viata a unui sistem nu se rezuma insa la proiectarea si
dezvoltarea sa; ea continua cu lansarea de noi versiuni, corectarea erorilor
ce nu au fost detectate in cadrul etapei de testare, adaptarea sa functie de
cerintele utilizatorilor, etc.
In cadrul etapei de proiectare a sistemului orientat pe obiecte, nu
trebuie sa uitam ca un sistem complex bine construit este alcatuit din mai
multe componente simple (atomice) care interactioneaza intre ele. Sistemele
monolitice au costurile de proiectare, implementare si mai ales de intretinere
mult mai mari decat sistemele modulare. Programarea orientata pe obiecte ofera
toate avantajele in vederea crearii de sisteme modulare.
In ceea ce priveste ierarhiile de clase, exista doua categorii: in prima,
toate sau aproape toate clasele sunt derivate dintr-o clasa de baza, radacina;
intr-a doua, pot exista mai multe ierarhii de clase distincte. Avantajul de a
avea o singura clasa de baza este acela ca se poate evita cu usurinta mostenirea
multipla; dezavantajul este ca de multe ori in cadrul procesului de implementare
a claselor derivate poate aparea necesitatea modificarii clasei de baza.
In cadrul etapei de implementare a aplicatiei, este important sa se
stabileasca o conventie unitara privind stilul de programare utilizat. De cele
mai multe ori nu are importanta stilul adoptat, insa un stil unitar poate
usura foarte mult interconectarea dintre modulele componente si micsora
costurile de intretinere a sistemului. In continuare voi face cateva sugestii:
Indentarea
- dimensiunea tabularii sa fie de 2-4 caractere
Acoladele
-acoladele corespunzatoare sa fie aliniate vertical
-pe liniile continand o acolada sa nu apara si cod
Liniile lungi
-dimensiunea unei linii de cod sa fie mai mica decat latimea
ecranului
-daca o linie este impartita pe mai multe randuri, cel de-al doilea
rand cat si urmatoarele sa fie indentate
Codul sursa
-sa nu existe spatii inainte si dupa operatorii unari
-sa existe spatiu inainte si dupa operatorii binari
-sa existe un spatiu dupa virgule si punct si virgula, dar nu inainte
-sa nu existe spatii inainte si dupa paranteze
-sa existe spatiu inainte si dupa cuvintele cheie
-sa fie utilizate linii libere pentru a separa diverse module de cod
sursa si a mari lizibilitatea programului
Comentariile
-textul unui comentariu sa fie separat de "//" cu un spatiu
-pe cat posibil, sa fie utilizate comentariile stil C++, "//", in loc
de cele in stil C, "/* */"
-sa fie la obiect si de nivel cat mai inalt
-sa indice operatia realizata de catre functie, efectele secundare,
tipul parametrilor, valorile pe care le poate returna
Denumirile identificatorilor
-denumirile sa fie cat mai descriptive posibil
-sa fie evitate abrevierile criptice
-sa nu fie utilizata notatia "ungureasca" (care prevede includerea
tipului unei variabile in denumirea sa)
Drepturile de acces la membri
-sa se declare mai intai membrii public, apoi cei protected,
iar apoi cei private
-datele membre sa apara dupa declararea metodelor
-prima metoda declarata sa fie constructorul, apoi destructorul
Definirea claselor
-ordinea definirii metodelor sa fie aceeasi cu a declararii acestora
Un ultim sfat: nu este de ajuns sa cititi cursuri, carti sau cod sursa!
Cea mai buna metoda pentru a invata un limbaj de programare este de a scrie
efectiv cod.
Realizat de Dragos Acostachioaie, ©1998-99
http://www.biosfarm.ro/~dragos