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