Sabloane de Proiectare Ui Pentru Aplicatii Web

Sabloane de Proiectare UI pentru Aplicatii Web

Cuprins

1. Introducere

2. Sabloane orientate obiect

2.1 Tipuri de sabloane orientate obiect

3. Clasificarea sabloanelor orientate obiect

(Badea Alexandru-Victor)

4. Rolul sabloanelor de proiectare in rezolvarea problemelor de proiectare

4.1 Identificarea obiectelor adecvate

4.2 Determinarea granularitatii obiectelor

4.3 Specificarea interfetelor obiectelor

4.4 Specificarea implementarii obiectelor

4.4.1 Mostenirea claselor si mostenirea interfetelor

4.4.2 Programarea prin interfete si nu prin

(Istrate Alexandru)

4.5 Mecanisme ale reutilizarii

4.6 Structuri stabilite la compilare si structuri create la executie

4.7 Proiectare pentru Schimbare

4.8 Cadre de lucru (Frameworks)

4.9 Selectarea sablonului de proiectare

4.10 Utilizarea sablonului de proiectare

(Scrieciu Marius – Valentin)

5 Sabloane de proiectare folosind MVC

5.1 MVC Model 1 versus Model 2

6. Sabloane de proiectare – XML

6.1 Fisiere Xml

6.2 Sabloane de proiectare a fisierelor XML

(Chirica Teodor)

7. Bibliografie

Capitolul 1

Introducere

Cu trecerea timului , si o data cu marirea capacitatii de calcul a calculatoarelor moderne, s-a trecut de la sisteme primitive unde calculatoarele aveau functii fixe programate permanent in sistem sau foarte greu reprogramabile la calcula la sisteme ce permit rularea simultana a unei multitudini extraordinare de solutii software ce pot coexista impartind resurse in mod armonios in sistemul de calcul. Aceasta evolutie a venit desigur si cu o modificare substantiala a modului de programare a acestor masini . S-a trecut in mod succesiv de la programarea prin setarea fizica a starilor bitilor individuali in mod mecanic , la programare in cod masina , programare secventiala culminand prin programaea obiect orientata implementata in mod paralel. Datorita complexiattii crescande a stiintei programarii si datorita experientelor trecute s-a ajuns , pentru atingerea anumitor rezultate in ceea ce priveste prelucrarea datelor , la niste forme de cod ce pot oferi performante ridicate in cele mai comune situatii. Acest lucru a dus prin apstractizarea acestor elemente la creerea saboanelor de proiectare.

Reiese astfel ca sabloanele de proiectare reprezinta secvente abstractizate de cod ce ofera solutii generale la anumite probleme de programare bazandu-se pe experientele trecute in ceea ce prieste obtinerea solutiei dorite.

Lucrarea de fata are o structura formata din 3 teme principale – o viziune de ansamblu asupra sabloanelor , o prezentare mai amanuntita a sabloanelor mcv si xml , si un exemplu practic de sablon.

Prima parte compusa din capitolele 2,3 si 4 contine detalii istorice (capitol 1) pentru observarea evolutiei sabloanelor in programare , a istoriei acestora si a rolului lor (capitolul 2) precum si o clasificare a sabloanelor moderne de proiectare dupa diferite criteruu (creational , structural , comportamental , etc.) Aceasta parte este continuata cu o privire mai amanuntita asupra rezolvarii problemelor de proiectare utilizand sabloane. Rezolvarea folosind aceste unelte de proiectare permit gasirea rapida a solutiilor in ceea ce priveste gasirea elementelor adecvate pentru o problema , gestionarea granularitatii obiectelor la nivel program , specificarea de interfete si de implementari ale obiectelor. De asemenea aici mai sunt mentionate si situatiile ce necesita reproiectarea sabloanelor in cursul utilizarii acestuia.

Cea de-adoua parte a lucrarii face referire la doua paradigme moderne de programare ce pot fi concretizate in sabloane foarte evoluate , anume sabloanele xml si sabloane specifice MVC. Sabloanele MCV prezinta un interes specific datorita faltului ca reprezinta o metoda relativ moderna de a lega interfata utilizatorului de sistemul de prelucrare a datelor si de modelul de date. Aceste trei elemente sunt mentinute separate pentru o mai buna crestere si mai o usoara mentenanta a codului dar in acelasi timp sunt definite standarde stricte de comunicare intre acestea ce usureaza foarte mult sarcina programatorului.

Capitolul 2

Sabloane orientate obiect

O data cu cresterea in complexitate si volum a programelor actuale , aparuta datorita maririi puterii de procesare , principala metoda de programare a devenit programarea orientata pe obiecte. Proiectarea de software sub aceasta paradigna presupune identificarea elementelor ce pot deveni obiecte independente , abstractizarea acestor elemente pastrand intre ele interfete ce permit o buna interfunctionare , toate acestea in timp ce se fac eforturi pentru a avea o granularitate a obiectelor potrivita mentinerii universalitatii si independentei obiectelor. Rezultatul trebuie sa fie un set de obiecte cu caracteristici indeajuns de universale pentru a permite refolosirea, dar in acelasi timp focusate pe o rezolvare eficienta a problemei si indeajuns de adaptabile pentru a permite adaugarea de noi modificari sau obiecte in cazul schimbarii problemei ce trebuie rezolvate in vreun aspect.

O data obtinute obiecte ce indeplinesc toate aceste caracteristici se pot folosi ca sabloane pentru rezolvarea de alte probleme in viitor. Sabloanele astfel rezultate pot usura proiectarea unor noi solutii fiind un punct de plecare ce garanteaza functionarea eficienta si gata optimizata.

Din aceste cerinte rezulta ca un sablon de proiectare reprezinta formalizarea unei solutii de succes intr-o metoda ce permite refolosirea ei. Ideea de sablon a fost introdusa de Christopher Alexander si a fost aplicata printre altele si programarii. Este important de mentionat ca un sablon de proiectare nu reprezinta o solutie in sine ci reprezinta descrierea unei solutii optime. De asemenea un sablon nu este un algoritm , sabloanele tratand probleme de arhitectura nu de calcul.

Ca orice unealta de proiectare sabloanele prezinta atat avantaje cat si dezavantaje , aceste apot fi sumarizate astfel:

Avantaje:

-Solutiile prezentate asigura o buna functionare

-Solutiile sunt deseori optimizate

-Solutiile cel mai des se bazeaza pe experienta cumulata a multi programatori si ating multe probleme ce pot sa apara in timp

Dezavantaje:

-folosirea unui sablon ce se dovedeste inadecvat poate fi dificil de modificat in timp

-unele sabloane extrem de flexibile pot adauga prea multa complexitate in solutie

Din aceasta lista reiese ca o folosire atenta a sablaonelor poate produce o crestere semnificativa a vitezei de proiectare a unei solutii , cu toate acestea trebute intotdeauna avut grija sa nu se adauge complexitate excesiva datorita folosirii unei solutii extrem de complexe intr-un cadru in care un este necesar. In cazul programarii obiect orientate inseamna ca solutie aleasa nu are in vedere granularitatea relativ mare prezenta in restul programului.

Clasificarea

Datorita posibilitatii de a rezolva o multitudine de solutii cu ajutorul sabloanelor , acestea pot fi clasificare in functie de tipul problemei astfel:

-Sabloane fundamentale

-Sabloane creationale (se utilizeaza la creerea obiectelor)

-Sabloane comportamentale (trateaza intercomunicarea intre obiecte si structura elementelo si rezurselor comune intre acestea)

-Sabloane structurale ( se ocupa de relatiile intre entitati , mosteniri , etc)

-Sabloane de concurenta

In functie de dorinta programatorului aceste sabloanele acopera un domenuil mare din spectrul activitatilor realizate de catre programator , se pot folosi sabloane in aproape toate etapele dezvoltarii solutiei.

In cazul cadrelor de lucru moderne exista sabloane care vin chiar cu mediul de dezvoltare. De la aceste macrostructuri ce permit definirea scheletului si a structurilor primare a unui program pana la sabloane cu o desfasurare mica cu rolul rezolvarii unor probleme punctuale sabloanele moderne prezinta intercompatibilitate. Acest lucru este asigurat de catre folosirea a unor elemente de interfata comune pentru sabloanele care au acelasi rol in solutie. Acest aspect este cel mai bine accentuat in cazul bibliotecilor de clase. Aceste structuri pot fi importate si interschimbate fara a necesita macar recompilarea codului solutiei.

Productivitatea in dezvoltarea de software a crescut in ultimele trei decade. Totusi, exista diferente intre ceea ce se cere in industria software-ului si ceea ce se produce. Una din cele mai importante abordari (poate cea mai importanta), care are ca rezultat cresterea productivitatii si calitatii software-ului, este reutilizarea. O data cu introducerea tehnologiei orientate obiect, au fost introduse o serie de aspecte care favorizeaza reutilizarea[1]:

• Orientarea pe problema. Modelele orientate obiect sunt descrise in termenii domeniului problemei. Drumul de la analiza la implementare (scrierea codului) faciliteaza comunicarea intre dezvoltator si utilizator, contribuind astfel la furnizarea unui produs software mai bun.

• Elasticitate la evolutie. Procesele intr-un domeniu al unei aplicatii se schimba mai des decat entitatile din domeniul respectiv. Astfel, un model care este structurat in jurul entitatilor dintr-un domeniu este mai stabil la schimbari.

• Analiza domeniului. Este natural ca analiza orientata obiect sa cuprinda si analiza domeniului (nu numai analiza unei singure aplicatii). Analiza domeniului poate fi vazuta ca o analiza mai larga si extensiva care incearca sa cuprinda cerintele intregului domeniu al problemei (inclusiv cerinte viitoare).

Cand se introduce reutilizarea software-ului intr-o organizatie, aceasta implica schimbarea ciclului de viata al software-ului in :

• Dezvoltarea pentru reutilizare, si

• Dezvoltare folosind reutilizarea.

In cazul dezvoltarii pentru reutilizare accentul se pune pe dezvoltarea de componente care sa fie refolosite in ciclul dezvoltarii folosind reutilizarea. In al doilea caz, componentele sunt cautate, regasite si refolosite (daca sunt potrivite) in procesul de dezvoltare.

In tehnologia orientata obiect exista o mare varietate de componente reutilizabile, mergand de la obiecte si clase, pana la sabloane de proiectare si framework-uri orientate obiect.

Notiunea de sablon (pattern) a fost introdusa de Christopher Alexander, un arhitect care a dezvoltat idea unui limbaj de sabloane care sa permita oamenilor sa-si proiecteze propriile locuinte. Idea a fost adoptata de dezvoltatorii de software care au adaptat-o domeniului lor de activitate. Idea principala este dezvoltarea de sabloane care sa reprezinte solutii la probleme de proiectare de mici dimensiuni[4].

Un limbaj de sabloane (pattern language) reprezinta un set de sabloane, fiecare descriind rezolvarea unei probleme particulare. Sabloanele lui Alexander variaza in functie de nivelul de detaliere, ele pornind de la un nivel global; cum poate fi lumea impartita in tari, tarile in regiuni, pana la impartirea pe birouri si plasarea ferestrelor in birouri[1].

In cartea sa, “A pattern Language”, Alexander prezinta 253 de sabloane, fiecare fiind prezentat dupa cum urmeaza:

• Nume – o fraza descriptiva sau un nume. Deseori acesta sugereaza solutia la o problema, mai curand decat problema sau contextul;

• Exemplu – fotografii, diagrame si descrieri care ilustreaza utilizarea sablonului;

• Context – circumstantele in care se poate aplica sablonul. Explica cat de general este sablo-nul;

• Problema – o descriere a constrangerilor;

• Solutia – relatiile si regulile dinamice care descriu cum se foloseste sablonul. Sunt referite variante si sabloane similare. De asemenea sunt referite sabloane la nivele mai inalte si mai scazute de abstractizare.

In plus fata de cele enuntate mai sus, un sablon, pentru a fi util, trebuie sa indeplineasca alte cateva proprietati, cum ar fi incapsulare, generativitate, echilibrare, abstractizare, extensibilitate si compozabilitate. Ideal este ca un sablon sa indeplineasca toate aceste proprietati.

• Incapsulare. O problema / solutie bine definita este incapsulata de sablon. Acesta trebuie sa fie specific si independent. Trebuie sa fie formulat précis pee – o fraza descriptiva sau un nume. Deseori acesta sugereaza solutia la o problema, mai curand decat problema sau contextul;

• Exemplu – fotografii, diagrame si descrieri care ilustreaza utilizarea sablonului;

• Context – circumstantele in care se poate aplica sablonul. Explica cat de general este sablo-nul;

• Problema – o descriere a constrangerilor;

• Solutia – relatiile si regulile dinamice care descriu cum se foloseste sablonul. Sunt referite variante si sabloane similare. De asemenea sunt referite sabloane la nivele mai inalte si mai scazute de abstractizare.

In plus fata de cele enuntate mai sus, un sablon, pentru a fi util, trebuie sa indeplineasca alte cateva proprietati, cum ar fi incapsulare, generativitate, echilibrare, abstractizare, extensibilitate si compozabilitate. Ideal este ca un sablon sa indeplineasca toate aceste proprietati.

• Incapsulare. O problema / solutie bine definita este incapsulata de sablon. Acesta trebuie sa fie specific si independent. Trebuie sa fie formulat précis pentru a fi clar cand poate fi aplicat.

• Generativitate. Fiecare sablon contine o descriere a procesului care explica cum se realizeaza solutia. Sabloanele sunt construite astfel incat sa poata fi utilizat de toti participantii la activitatea de constructie, nu numai de proiectanti.

• Echilibrare. Sablonul are un spatiu al solutiilor cu un invariant care minimizeaza conflictul intre constrangeri si obligatii.

• Abstractizare. Sablonul inglobeaza experienta acumulata intr-o problema.

• Extensibilitate. Semnifica abilitatea extinderii sablonului la un nivel arbitrar de detaliere.

• Compozabilitate. Sabloanele sunt legate unele de altele ierarhic, astfel incat cele avand un grad mai inalt de abstractizare sunt plasate spre varful ierarhiei.

Structura sabloanelor lui Christopher Alexander si proprietatile descrise i-au determinat pe specialistii in software sa creeze sabloane analoge in analiza si proiectarea orientate obiect.

2.1 Tipuri de sabloane orientate obiect

Au fost identificate doua variante principale de sabloane orientate obiect, nongenerative si generative, fiecare dintre ele avand la randul ei un numar de variante.

Sabloane non-generative. Accentul este pus pe solutii. Asa cum in lucrarea lui Christopher Alexander exista sabloane pentru diverse faze arhitecturale, asa exista abloane non-generative pentru diferite faze ale procesului de dezvoltare software analiza si proiectare)[4].

In general sabloanele de analiza, proiectare si implementare sunt nongenerative. abloane de analiza. Scopul unui sablon de analiza orientat obiect este de a urniza metode pentru buna desfasurare a analizei, in general. Ele nu sunt associate nui domeniu particular. Coad defineste un sablon de analiza orientat obiect ca fiind o bstractizare a unui dublet, triplet, sau a unui numar mic de clase care se dovedesc in mod repetat folositoare in dezvoltarea orientata obiect . Formalismul folosit de Coad, pentru descrierea sabloanelor de analiza orientate obiect, este relativ simplu si este descris in tabelul de mai jos.

Sabloane arhitecturale. Reprezinta un element important in structurarea aplicatiilor. Ele determina structura de baza a unei aplicatii si pot fi vazute ca un templete pentru arhitecturile software concrete .

Sabloane de proiectare. Reprezinta sabloanele cele mai cunoscute si fara indoiala cele mai utilizate. Ele au fost introduse de E. Gamma, motiv pentru care mai poarta denumirea de sabloane Gamma.

Conform definitiei date de E. Gamma, un sablon de proiectare este o structura pentru captarea si exprimarea experientei in proiectare. Ele identifica, numesc si abstractizeaza teme comune in proiectarea orientata obiect. Informatia este protejata prin capturarea intentiei din spatele proiectului. Sunt identificate clasele, instantele, rolurile lor, colaborarile si distributia responsabilitatilor.

Un sablon de proiectare nu este o aplicatie completa sau un subsistem. Este un set de clase si instante care colaboreaza pentru a rezolva un anumit tip de probleme si nu sunt descrise in nici un tip de limbaj de programare. Acest fapt le face reutilizabile, intrucat pot fi aplicate ori de cate ori apare problema respectiva .

Un sablon de proiectare consta din trei parti majore :

• o descriere abstracta a colaborarii claselor sau obiectelor si a structurii sale;

• utilizarea in proiectarea sistemelor;

• consecintele aplicarii sablonului;

Formalismul utilizat de E. Gamma este inspirat de cel folosit de C. Alexander in domeniul arhitecturii. Tabelul descrie acest formalism[1].

Sabloanele lui E. Gamma au urmatoarele proprietati :

• capteaza si descriu experienta acumulata.

• o descriere a cum sa se realizeze un principiu functional sau structural. Descrierea include diferitele parti ale sablonului, colaborarile si responsabilitatile lor.

• o tehnica de abordare a complexitatii software-ului.

• un vocabular comun pentru proiectanti, care faciliteaza comunicarea, documentarea si explorarea alternativelor de proiectare.

• independenta fata de aplicatie.

• un element reutilizabil in dezvoltarea software-ului.

• trateaza atat aspecte functionale cat si non-functionale.

Sabloane de implementare. Sabloanele prezentate mai sus sunt independente de limbajele de programare. Sabloanele de implementare depind de un limbaj, ele definesc constructii specifice unui limbaj. Acestea, desi ar putea fi utilizate pentru orice tip de limbaj, sunt definite pentru limbajele orientate obiect. Aceasta se datoreaza, fara indoiala, faptului ca celelalte sabloane orientate obiect sunt utilizate pentru dezvoltari orientate obiect. In principal, sabloane de implementare pot fi gasite in C++, Smaltalk si Java.

Programatorii care utilizeaza sabloane de implementare, evita sa faca unele greseli si, astfel, diminueaza timpul de dezvoltare. Daca intr-un grup de programatori toata lumea utilizeaza aceeasi tehnica pentru a face o anumita operatie, atunci intelegerea codului va fi mult mai usoara pentru ceilalti progra-matori. Astfel, maniera de programare va fi identica pentru toata echipa, iar intelegerea programului va fi simplificata.

Sabloane generative. Descriu cum se ajunge la o anumita solutie (in loc sa descrie o solutie la o problema, asa cum fac sabloanele non-generative). Acestea exista pentru diferite faze si situatii, in dezvoltarea unui program. Exista sabloane generative de proiectare, de documentare si de mentenanta [1].

Structura unui set de sabloane generative implica un graf non-ciclic, unde fiecare sablon generativ reprezinta un varf. Daca graful este realizat cu grija, acesta ar putea forma un limbaj de sabloane (pattern language) [1].

Un sablon generativ de proiectare descrie cum se ajunge de la o decizie de proiectare la o solutie in forma unui sablon de proiectare orientat obiect. El este strans legat de un sablon de proiectare orientat obiect si poate fi privit ca o extensie a sectiunii Intentie a acestuia din urma. Formatul este urmatorul :

• preconditii – ce cerinte si sabloane generative de proiectare trebuie satisfacute inainte de al aplica;

• problema – caror probleme de proiectare se adreseaza;

• constrangeri – constrangerile ce trebuiesc respectate;

• solutia – o descriere a solutiei.

Sabloanele de documentare a unei aplicatii orientate obiect /cadru de lucru (framework) pot fi folosite pentru a invata si intelege un framework.

Sabloanele pentru mentenanta pun accentul pe tehnici de restructurare a programelor orientate obiect.

Limbajele de sabloane (pattern languages) reprezinta o colectie structurata de sabloane generative, care pot fi utilizate pentru a transforma cerintele si constrangerile intr-o arhitectura.

Capitolul 3

Clasificarea sabloanelor orientate obiect

Clasificarea bazata pe erorile de reutilizare . Cea mai simpla schema de clasificare foloseste drept principiu, diferitele tipuri de erori de reutilizare pe care un sablon le rezolva. Intrucat folosirea sabloanele de proiectare are ca scop cresterea gradului de reutilizare, este important ca dezvolta-torii programelor sa cunoasca ce tipuri de erori de reutilizare rezolva acestea. O eroare de reutilizare apare atunci cand o clasa nu este reutilizabila fara a implica un efort major sau modificari. Dezvoltatorii experimentati, care au incercat in repetate randuri sa reutilizeze clase de-a lungul timpului, au invatat din experienta ce tipuri de erori de reutilizare pot sa apara. Au fost identificate urmatoarele tipuri de erori[4]:

• Dependenta de o clasa particulara de implementare atunci cand se creeaza un obiect.

• Dependenta de o operatie particulara.

• Dependenta de mediul de operare. Pentru a realiza portabilitatea si aplicabilitatea in diferite medii este importanta pentru a proiecta independent de mediul software sau hardware.

• Dependenta de o reprezentare specifica sau implementare. Pentru clienti trebuie sa fie transparenta reprezentarea, stocarea, sau implementarea unui obiect.

• Dependenta de un algoritm particular. Algoritmii pot fi optimizati, extinsi sau inlocuiti in timp. Algoritmii pentru care exista probabilitatea modificarii in timp, trebuie izolati.

• Dependenta de un client particular si de relatiile intre obiecte. Trebuie evitate clasele care sunt strans cuplate.

• Dependenta de subclasare ca mecanism de extensie. Dezavantajul este ca detaliile interne ale superclasei devin vizibile, ceea ce implica un accord pentru o implementare particulara. Relatiile de mostenire intr-o biblioteca de clase nu pot fi schimbate.

Clasificare Gamma. Clasificarea propusa de E. Gamma, clasifica sabloanele in concordanta cu doua dimensiuni: jurisdictie si caracterizare. Jurisdictia este domeniul in care se aplica sabloanele. Se disting clase, obiecte si jurisdictie compusa.

Caracterizarea poate fi creationala, structurala si comportamentala. Sabloanele creationale privesc crearea de obiecte, sabloanele structurale descriu compozitia claselor sau obiectelor, iar sabloanele comportamentale caracterizeaza modalitatea in care clasele sau obiectele interactioneaza.

Jurisdictia claselor se ocupa cu relatiile intre clase si subclasele lor. Jurisdictia obiectelor priveste relatiile intre obiecte egale spre deosebire de jurisdictia compusa se refera la structuri recursive de obiecte[3].

Tabelul 5.3. prezinta clasificarea Gamma a sabloanelor.

O noua abordare de a organiza sabloanele de proiectare este modul in care ele refera alte sabloane.Figura 3.1 evidentiaza aceste relatii in mod grafic[3].

Figura 3.1 Relatii intre sabloane de proiectare

Clasificarea Buschmann . O clasificare a sabloanelor de proiectare orientate obiect mai potrivita pentru proiectanti, este cea realizata de F. Buschmann. El afirma ca toate sabloanele, impreuna, formeaza un sistem de blocuri constructive care poate fi folosit pentru constructia unei arhitecturi software. Pentru a fi util dezvoltatorilor, sistemul de blocuri constructive, trebuie sa indeplineasca anumite conditii si cerinte[4]:

• O clasificare a sabloanelor pentru a usura selectia unui anumit sablon, care sa fie util pentru o situatie data.

• Toate sabloanele trebuie sa fie descrise intr-un mod uniform. Descrierea trebuie sa acopere aspecte privind caracterizarea, descrierea detaliata, implementarea, selectia si compararea cu alte sabloane.

• Compozitia sabloanelor – care sabloane pot fi combinate. Astfel se pot oferi solutii pentru combinatii reutilizabile.

• Descrierea evolutiei sistemului.

Schema de clasificare Buschmann cuprinde trei principii: granularitate, functionalitate si principii structurale. Clasificarea in functie de granularitate este necesara intrucat dezvoltarea unui program software presupunea acoperirea mai multor nivele de abstractizare, de la structuri de baza la implementari concrete. Nivelele de granularitate sunt[4]:

• Cadre de lucru arhitecturale

• Sabloane de proiectare

• Sabloane de implementare (idioms)

Fiecare arhitectura software este construita pe baza unui principiu de structurare. Aceste principii sunt descrise de framework-urile arhitecturale.

Selectia unui framework arhitectural pentru sistemul ce urmeaza sa fie construit este o decizie fundamentala. Acesta determina structura de baza a aplicatie si poate fi vazut ca un template pentru arhitectura concreta.

Unitatile software arhitecturale mici, din care este compusa o arhitectura software, sunt descrise cu ajutorul sabloanelor de proiectare. Sabloanele de proiectare pot fi compuse in, noi, sabloane de proiectare compuse.

La nivelul cel mai fin de granularitate, sabloanele de implementare, trateaza realizarea si implementarea unei anumite decizii de proiectare. Ele descriu cum trebuie implementata o anumita componenta, (parte din) functionalitatile ei, sau relatiile cu alte componente intr-un proiect dat.

Clasificarea in functie de functionalitati captureaza un anumit tip de functionalitati pentru sabloanele de proiectare. Acestea pot fi impartite in urmatoarele patru subcategorii:

• Crearea de obiecte. Creare de structuri de obiecte agregate sau recursive.

• Comunicatia intre obiecte. Cum colaboreaza un set de obiecte.

• Accesul la obiecte. Accesarea serviciilor si starilor unui obiect, fara a viola incapsularea.

•Organizarea calculelor proceselor complexe. Specifica cum trebuie distribuite responsabilitatile intre obiectele care coopereaza pentru a rezolva o problema complexa.

A treia categorie, principiile structurale, este folosita de sabloane pentru a realiza functionalitatile lor. Principiile structurale sunt:

• Abstractizarea. Un sablon furnizeaza o vedere abstracta sau generalizata asupra unei entitati sau proces particular si deseori complex, in cadrul unui program software.

• Incapsularea. Un sablon incapsuleaza detaliile unui obiect, componente sau serviciu, pentru a elimina dependentele de clientii ei sau pentru a proteja anumite detalii.

• Separarea sarcinilor. Un sablon factorizeaza anumite responsabilitati in obiecte separate sau componente pentru a rezolva o anumita problema sau pentru a furniza un serviciu.

• Cuplarea si coeziunea. Un sablon elimina sau relaxeaza relatiile structuralesau de comunicatie obiecte, altfel strans legate unele de altele.

In urma aplicarii acestor trei dimensiuni rezulta schema de clasificare prezentata in tabelul de mai jos.

Clasificarea Zimmer . Un alt mod de clasificare al sabloanelor de proiectare a fost prezentat de Zimmer. Acesta a investigat setul de sabloane Gamma si relatiile dintre ele. A observat o tema majora, prezenta in unele dintre sabloanele lui E. Gamma si a creat un nou sablon de proiectare, Objectifier. Acesta este o generalizare a sabloanelor care organizeaza diferite tipuri de comportament. Sabloanele legate (generalizate) de Objectifier sunt prezentate in tabelul de mai jos[4].

Constructia sablonului Ojectifier si relatiile intre sabloanele Gamma (incluzand si Objectifier) formeaza o baza ce permite clasificarea sabloanelor pe trei nivele semantice:

• sabloane de proiectare de baza;

• sabloane pentru anumite probleme;

• sabloane de proiectare specifice aplicatiilor dintr-un anumit domeniu.

Sabloanele de proiectare de baza cuprind acele sabloane care sunt folosite de proiectanti la celelalte doua nivele. Ele sunt destinate unor probleme ce apar frecvent in procesul de proiectare al software-ului. Sabloanele nivelului intermediar sunt folosite la nivelul specific aplicatiilor sau de alte sabloane de pe acelasi nivel. Se adreseaza urmatoarelor tipuri de probleme: crearea de obiecte, traversarea de obiecte, organizarea unei operatii etc[4].

Pe ultimul nivel, sabloanele specifice domeniului aplicatiei, sunt cele mai specializate. Setul de sabloane Gamma include un singur astfel de sablon, si anume Interpreter.

Pentru selectia sabloanelor orientate obiect au fost identificate mai multe metode, in functie de clasificarea folosita. Acestea vor fi prezentate pe scurt in continuare.

Selectia bazata pe clasificarea erorilor de reutilizare . Se incearca sa se raspunda la urmatoarea intrebare : ce noi tipuri de cerinte sau schimbari va trebui sa suporte proiectul in viitor ? Intrucat sabloanele de proiectare permit ca anumite aspecte ale structurii unui sistem sa fie variate independent, ele pot fi mapate pe un set de erori de reutilizare, asa cum este prezentat in tabelul de mai jos.

Selectia bazata pe clasificarea Buschmann . Daca sabloanele sunt clasificate conform schemei Buschmann, atunci urmatorii pasi sunt potriviti cand se selecteaza un sablon:

• Ce granularitate trebuie sa aiba sablonul ?

• se selecteaza functionalitatea dorita.

• Care sunt principiile dupa care se structureaza proiectul ?

Clasificarea Gamma, in sabloane structurale, creationale si comportamentale, este prea larga. Uneori insa ea poate fi utila in combinatie cu alte sisteme de clasificare, cum ar fi clasificarea Zimmer.

Selectia bazata pe clasificarea in functie de erorile de reutilizare necesita ca dezvoltatorul sa cunoasca foarte bine sabloanele clasificate. Aceasta poate fi destul de dificil de realizat, atunci cand numarul sabloanelor este mare.

Clasificarea realizata de Buschmann pare sa fie cea mai potrivita, intrucat este cea mai detaliata, iar procesul de selectie reduce semnificativ setul de sabloane care poate fi potrivit intr-o situatie data[4].

Capitolul 4

Rolul sabloanelor de proiectare in rezolvarea problemelor de proiectare

Sabloanele sunt unelte puternice ce permit rezolvarea unei multitudini de probleme intalnite de proiectantii d esolutii siftware. Cateva dintre aceste situatii sunt tratate in subcapitolele ce urmeaza :

4.1 Gasirea obiectelor adecvate

Programarea orientata pe obiecte impacheteaza elementele codului in functie de cerinte legate de problema in obiecte generice ale caror caracteristici sunt editate de-a lungul programului. Aceste obeicte pot fi structuri ce definesc variabile i problema sau chiar elemente intregi de cod ce rezolva o solutie. In cazul al doile obiectele sunt proiectate s acomunice prin mesaje bine definite ce determina executii de protocoale si subprograme care prelucreaza obiectul de tip variabila ca un intreg: acesta poate primi modificari asupra parametrilor dar are toate proprietatile sale sub o singura structura indivizabila de catre elemente externe [5]

Desigur aceasta abordare ridica niste probleme distincte , anume acelea de a determina granularitatea , dependintele si gradul d eincapsulare a obiectului , lucruri care la randul lor determina trasaturi precum gradul de reutilizare si flexibilitatea obiectelor atata in postura de variabile ale problemei cat si elemente de cod cu scopul de a rezolva anumite probleme bine definite. Exista muliple abordari pentru a obtine un bun echilibru intre complicarea inutila a codului si obtinerea unor obiecte robuste si adaptabile situatiei. Un proiectant bun va porni de la cerinta incercandaplicarea unor notiuni cat mai intuitive legate de lumea fizica inconjuratoare obtinand niste obiecte inuitive si usor de reutilizat . Cu toate acestea datorita naturii complexe a lumii inconjuratoare pentru a modela intr-un mod relativ eficient aceste interactiuni se are automat in vedere un grad de abstractizare pentru a nu complica inutil obiectul generat. Aceste abstractizari sunt puncte cheie ce pot defini gradul d eflexibilitate a obiectului ducand deseori la obiecte extrem de adaptabile ce pot deveni unelte extrem d eutile cand sunt folosite d eun programator bun [5].

in acest context un sablon poate ajuta la economisirea unor eforturi monumentale . Este usor de observat usurinta de crestere exponentiala a gradului d ecomplexitate a folutiei la o crestere liniara a cerintei probemei. Astfel o data obtinut un obiect care indeplineste intr-un mod satisfacator cerintele problemei si reuseste sa fie usor reutilizabil fara o complicare extrema a codului poate fi documenta obtinand un sablon ce detaliaza toate elementele necesare obtinerii unui rezultat la fel d ebun in iteratii vitoare a procesului de proiectare intrebuintand un efort mult scazut din partea unui programator.

4.2 Determinarea granularitatii obiectelor

O data definita o problema indeajuns de complexa se pune porblema determinarii gradului ideal de granularitate a obiectelor folosite. Echilibrul ce trebuie obtinut in acest scenariu este intre un grad mare d egranularitate ce permite definirea de trasaturi sub forma de subobiecte la nivele extrem de detaliate si complexitatea ce provine din acea complexitate ce poate utiliza resurse d ecalcul in mod ne eficient si poate duce la o complicare extrema a solutiei in general.

Utilitatea saloanelor in acest caz este evidenta , existand sabloane care detaliaza exact gradul de granularitate dorit precum si metode eficiente de a menaja un numar rdicat de obiecte precum si comunicarea ubtre aceste obiecte (sablon de tip flyweight). Exista de asemenea si sabloane ce detaliaza "spargerea" obiectelor in multimi d eobiecte cu o granularitate mai mare precum si procesul invers , toate operatiuni necesare la nivel d eproiectare pentru a obtine o sitautie cat mai apropiata de ideal.

4.3 Specificarea interfetelor obiectelor

Interfetele reprezinta unica metoda de a realiza intercomunicare intre obiecte. Prin interfete se permite modificarea tuturor parametrilor ce se doresc variabili a unui obiect fara a se realiza mentiuni privind procesele ce au los in interiorul procedurii. din aceste motive nici o alta caracteristica a unui obiect nu este mai importanta. Avand un set bine definit d einterfete s epermite creerea de bucati intregi d ecod ce pot fi interschimbate pentru a experimenta cu alte obiecte si alte caracteristici (polimorfism) . Atata timp cant interfetele sunt bine definite restul programului nu va percepe nici o diferenta in cea ce priveste apelarea si obtinerea comportamentului dorit de la un obiect. Aceasta actiune de a obtine un set de rezultate sau modificari de l un obiect se numeste cerere. Aceste cereri trebuie sa respecte acelasi set strict de reguli care dicteaza interactiunea intre obiecte pentru a obtine o functionare armonioasa si modulara de la programul proiectat.

Se observa din cele descrise mai sus cum polimorfismul este cu usurinta una dintre cele ami importante trasaturi ale proiectaii orientate pe obiecte , sabloane speciale existand care sa defineasca in mod formal pentru programator un set de interactiuni in functie de situatie astfel incat sa se mentina acest polimorfism . Aceste sabloane specifica trasaturile cererilor , a obiectelor returnate , regulile d einteractiune , dar lasa la altitudinea programatorului orice detaliu legata de implementarea interna specifica obiectelorin sine , in acest mod mentinandu-se un polimorfism perfect intre elemente

4.4 Specificarea implementarii obiectelor

La bazele paradigmei proframarii orientate pe obiecte se afla clasele . Acestea sunt prototipuri ce definesc elementele interne ale unui obiet ( variabile etc.) cu rolul express de a fi instantiate la executare pentru a crea obiecte. La aceasta instantiere sunt alocate zonele d ememorie necesare elementelor definite in clasa. Pentru creerea unor serii d eelemente cu caracteristici asemanatoare este posibila mostenirea claselor lucru care da nastere la obiecte al caror diverse subseturi de caracteristici sunt identice cu cele definite de catre clasa mostenita.

Un tip special d eclasa ce merita mentiune este slasa abstracta cu scopul de a defini interfete comune pentru toate subclasele acesteia lasand sarcina de definire a operatiilor in mod total sau partial subclaselor acesteia. Aceste subclase pot redefini sau detalia caracteristicile deja stabilite in clasa parinte permitand astfel prelucrarea cererilor la nivel de subclasa.

Un alt tip special de clasa mai rar folosita este clasa mixin ce ofera elemente optionale pentru alte clase , aceasta nu poate fi instantiata dar poate fi mostenita augmentand functionalitatile clasei care face mostenirea.

4.4.1 Mostenirea claselor si mostenirea interfetelor

Este important sa intelegem diferenta intre clasa unui obiect si tipul obiectului.
Clasa defineste starea interna a obiectului si implementarea operatiilor lui. Tipul obiectului se refera doar la interfata obiectului – setul cererilor la care obiectul poate raspunde. Un obiect poate avea mai multe tipuri, iar obiecte de clase diferite pot avea acelasi tip[1].

Desigur ca intre clasa si tip exista o stransa legatura: prin faptul ca o clasa defineste operatiile pe care un obiect le poate executa, automat ea defineste si tipul obiectului. Cand spunem ca un obiect este instanta a unei clase, aceasta inseamna ca obiectul poseda interfata definita de clasa respectiva.

Un limbaj ca C++ foloseste clasele pentru a specifica tipul obiectului si implementarea.

Este de asemenea important sa intelegem diferenta dintre mostenirea de clasa si mostenirea de interfata (subtipizare)[5]. Mostenirea de clasa presupune ca implementarea unui obiect este definita in termenii implementarii altui obiect. Cu alte cuvinte, ea reprezinta un mecanism de reutilizare (partajare) a reprezentarii si a codului. Mostenirea de interfata (subtyping) este un mecanism prin care un obiect poate fi utilizat in locul altuia.

Este destul de usor de confundat aceste concepte intre ele deoarece majoritatea limbajelor de programare OO nu le disting in mod explicit. De exemplu in C++ mostenire inseamna atat mostenire de clasa, cat si de interfata. O diferentiere intre cele doua s-ar putea face astfel:

mostenirea de interfata poate fi redata ca o derivare publica a unei clase abstracte (o clasa care contine functii-membru pur virtuale);

mostenirea de clasa poate fi modelata prin derivarea privata a unei clase.

Multe dintre sabloanele de proiectare se bazeaza pe aceasta distinctie. De exemplu obiectele dintr-un Lant de succesori trebuie sa aiba un tip comun, fara insa a avea si implementarea comuna. In cadrul sablonului Compozit, Component defineste o interfata comuna, in timp ce Composite defineste o implementare comuna. Sabloanele Comanda, Observator, Stare si Strategie sunt adesea implementate cu ajutorul claselor abstracte.
 

4.4.2 Programarea prin interfete si nu prin implementari

Mostenirea de clasa este in esenta un mecanism care permite:

extinderea functionalitatii unei aplicatii prin reutilizarea functionalitatii din clasele parinte;

definirea rapida a unui nou fel de obiect,in termenii unuia deja existent;

obtinenerea unor noi implementari aproape fara efort,prin preluarea unei mari parti din ceea ce avem nevoie de la clase existente;

Reutilizarea implementarii reprezinta doar o fateta a conceptului de mostenire. Posibilitatea de a defini familii de obiecte cu interfete identice (de obicei prin mostenirea de la o clasa abstracta) este un alt aspect important, deoarece polimorfismul depinde de el[1].

Clasele derivate dintr-o clasa abstracta vor partaja interfata acelei clase. Subclasele vor adauga sau vor redefini operatii, dar nu vor ascunde operatii ale clasei parinte. In felul acesta toate subclasele vor putea raspunde la cererile corespunzatoare interfetei clasei abstracte parinte.

Exista doua avantaje ale manipularii obiectelor prin intermediul interfetelor definite in clasele abstracte:[1]

clientii nu trebuie sa stie tipurile particulare ale obiectelor utilizate, atata timp cat obiectele respective sunt compatibile cu interfata pe care clientii o asteapta;

clientii nu trebuie sa stie care sunt clasele care implementeaza obiectele respective, stiu doar despre clasele abstracte care definesc interfata.

Toate acestea reduc substantial dependentele dintre subsisteme, permitand formularea urmatorului principiu al proiectarii OO:
 

Nu declara variabile ca fiind instante ale unor clase concrete, mai degraba angajeaza-te sa folosesti o interfata definita printr-o clasa abstracta. Cand este necesara instantierea unor clase concrete, se recomanda aplicarea sabloanelor creationale (Abstract Factory, Builder, Factory Method, Prototype, Singleton) care permit abstractizarea procesului de creare a obiectelor. In felul acesta se realizeaza o asociere a unei interfete cu implementarile ei transparent la momentul instantierii.

4.5 Mecanisme ale reutilizarii

Problema este cum obtinem un software flexibil si reutilizabil folosind concepte ca obiect, clasa, interfata, mostenire. Sabloanele constituie un raspuns.

Mostenirea si compunerea obiectelor

Cele mai cunoscute tehnici de reutilizare a functionalitatii in cadrul sistemelor OO sunt mostenirea de clasa si asamblarea sau compunerea obiectelor (object composition)[1].

Mostenirea de clasa este cunoscuta si sub numele de reutilizare tip cutie alba (white-box reuse) deoarece in majoritatea cazurilor o parte din starea interna a claselor parinte este vizibila in subclase.

Asamblarea obiectelor reprezinta o tehnica de obtinere a unei functionalitati noi prin asamblarea sau compunerea unor obiecte avand interfete bine definite. Tehnica este cunoscuta sub numele de reutilizare tip cutie neagra (black-box reuse) deoarece obiectele care se asambleaza nu isi cunosc unul altuia starea interna, ele apar unul fata de altul ca niste cutii negre.

Ambele tehnici au avantaje si dezavantaje. Mostenirea de clasa se caracterizeaza prin urmatoarele (avantaje)[1]:

este definita static la compilare si poate fi specificata direct, fiind suportata explicit de limbajele de programare;

permite modifcarea usoara a implementarii operatiilor reutilizate,si anume intr-o subclasa ce redefineste o parte din operatiile clasei parinte pot fi afectate si operatii mostenite daca acestea apeleaza operatii redefinite.

Dezavantaje:

implementarea mostenita de la clasele parinte nu poate fi modificata in momentul executiei;

cel mai adesea clasele parinte definesc cel putin partial reprezentarea fizica a subclaselor lor, deci subclasele au acces la detalii ale implementarii superclaselor. De aceea se mai spune ca mostenirea de clasa incalca principiile incapsularii;

modificarile aduse implementarii unei superclase vor forta subclasele sa se modifice si ele. Dependentele de implementare pot cauza probleme atunci cand se incearca reutilizarea subclaselor: daca anumite aspecte ale implementarii mostenite nu corespund necesitatilor aplicatiei clasa parinte trebuie rescrisa sau inlocuita. Aceasta dependenta limiteaza flexibilitatea si, in ultima instanta reutilizarea. O solutie in acest caz ar fi aplicarea mostenirii de la clase abstracte, deoarece ele includ implementare in mica masura.

Compunerea obiectelor se caracterizeaza prin[1]:

se defineste in mod dinamic, la executie, prin faptul ca anumite obiecte primesc referinte ale altor obiecte;

necesita ca obiectele sa-si respecte unul altuia interfata, ceea ce presupune ca interfetele sa fie proiectate astfel incat sa nu impiedice utilizarea unui obiect in combinatie cu mai multe tipuri de obiecte. Deoarece obiectele sunt accesate doar prin intermediul interfetelor nu este incalcat principiul incapsularii. In decursul executiei orice obiect poate fi inlocuit cu altul, atata timp cat obiectele respective au acelasi tip. In plus, datorita faptului ca si implementarea unui obiect este scrisa tot in termenii interfetelor altor obiecte, dependentele de implementare vor fi substantial reduse;

prin compunerea obiectelor se obtine urmatorul efect asupra unui proiect: clasele sunt incapsulate si focalizate asupra cate unui singur obiectiv, ceea ce face ca ele, ca si ierarhiile lor, sa aiba dimensiuni mici si sa fie mai usor de gestionat. Un proiect bazat pe compunerea obiectelor se caracterizeaza printr-un numar mai mare de obiecte si un numar mai mic de clase, iar comportarea sistemului va depinde de relatiile dintre obiecte, in loc sa fie definita intr-o clasa.

Toate aceste aspecte conduc spre formularea celui de-al doilea principiu al proiectarii OO:
 

In mod ideal nu ar trebui create noi componente pentru a realiza reutilizarea. Pentru obtinerea functionalitatii dorite trebuie doar asamblate componentele prin intermediul compozitiei obiectelor existente. In practica insa aceasta nu se poate realiza in totalitate deoarece setul de componente disponibile nu este niciodata destul de bogat. Reutilizarea prin mostenire este mai usor de folosit pentru a face componente noi in comparatie cu compunerea componentelor deja existente. De aceea mostenirea si compunerea obiectelor sunt folosite impreuna.

Experienta arata ca adesea proiectantii folosesc mostenirea in mod abuziv. De aceea se recomanda studiul si aplicarea sabloanelor de proiectare, acestea bazandu-se foarte mult pe compunerea obiectelor.

Delegarea

Reprezinta o cale de aplicare a principiului compunerii obiectelor. Intr-o relatie de delegare doua obiecte sunt implicate in rezolvarea unei cereri, si anume: obiectul care recepteaza mesajul – delegatorul – deleaga executia operatiei corespunzatoare unui alt obiect – delegat. Acest lucru este oarecum similar cu situatia in care subclasele paseaza sarcina executiei unor operatii claselor parinte (este vorba despre operatiile mostenite si neredefinite). Dar, in timp ce clasa parinte a unei subclase ramane aceeasi pe toata durata executiei, in cazul delegarii obiectele delegat pot fi schimbate, cu conditia sa aiba aceeasi interfata[1].

Delegarea este considerata ca un sablon de proiectare fundamental, pe ea bazandu-se foarte multe din celelalte sabloane (de exemplu State, Visitor, Strategy, Mediator, Chain of Responsibility, Bridge).

Principalul avantaj al delegarii este ca face posibil foarte usor sa se compuna comportari in timpul executiei, inclusiv sa se schimbe dinamic aceasta compunere.

Dezavantajul, pe care il au si alte tehnici ce fac software-ul flexibil, este ca software-ul dinamic, parametrizat, este mai greu de inteles decat software-ul static. In plus exista si penalitati in timpul executiei.

Mostenirea si tipurile parametrizate

Tipurile parametrizate reprezinta o alta tehnica de reutilizare a functionalitatii care nu este strict legata de modelul orientat pe obiecte. Ele permit definirea de catre utilizatori a unui tip nou fara a specifica tipurile pe care acesta le foloseste. Aceste tipuri se vor furniza ca si parametrii unde se foloseste acest tip parametrizat. De exemplu un tip Lista poate fi parametrizat prin tipul elementelor continute. Acesta poate fi intreg, sir de caractere, etc.

Printre limbajele care suporta aceasta tehnica se numara Ada, Eiffel (prin tipurile generice) si C++ (prin template-uri).

Tipurile parametrizate ne ofera a treia cale pentru a compune comportarea in sistemele OO. Exista diferente importante intre aceste trei tehnici[1]:

compunerea obiectelor permite modificarea in timpul executiei a comportamentului, dar presupune indirectare si, ca urmare, poate fi mai putin eficienta;

mostenirea ofera posibilitatea de a utiliza implementari deja existente ale unor operatii, dar si de a redefini in subclase operatiile respective;

tipurile parametrizate permit modificarea tipurilor pe care o clasa le utilizeaza, dar, la fel ca si mostenirea, sunt precizate la compilare si nu mai pot fi modificate la executie.

4.6 Structuri stabilite la compilare si structuri create la executie

Structura unui program OO aflat in executie aminteste foarte putin cu structura codului. Acesta din urma este inghetat in momentul compilarii si consta dintr-un ansamblu de clase aflate in relatii fixe de mostenire. Structura la executie consta dintr-o retea de obiecte aflate in continua schimbare si comunicare. De fapt cele doua tipuri de structuri sunt aproape independente intre ele.

Exemplificam pe deosebirea dintre relatiile de agregare si asociere (sau cunoastere – acquaintance)[2] si cum se manifesta acestea in timpul compilarii si executiei. Agregarea presupune ca un anumit obiect poseda sau este responsabil fata de un alt obiect. In general spunem despre un obiect ca are sau este parte dintr-un alt obiect. Agregarea implica faptul ca un obiect agregat si proprietarul lui au durata de viata comuna.

Asocierea, numita si relatie de utilizare (de tip "using")[2], presupune ca un obiect pur si simplu stie de existenta altui obiect. Cele doua obiecte asociate pot cere operatii unul altuia dar nu sunt responsabili unul fata de altul. Asocierea este o relatie mai slaba decat agregarea si sugereaza o cuplare mai slaba intre obiecte.

Cele doua tipuri de relatii pot fi usor confundate din cauza ca pot fi implementate in mod asemanator. In C++ agregarea se poate implementa prin definirea de membrii variabila ce sunt instante adevarate dar este mai folosita practica sa o definim prin pointeri sau referinte la instante. Asocierea este implementata si ea prin pointeri si referinte.

De fapt agregarea si asocierea sunt determinate mai mult de intentia proiectantului decat de mecanismele din limbaj. Distinctia intre ele este dificil de observat in codul sursa. Agregarile apar in nu-mar mai mic, dar au un caracter mai stabil in timp. Asocierile se fac si se refac mai frecvent, uneori stabi-lindu-se doar pe durata unei operatii. Asocierile au un caracter mai dinamic, ceea ce le face greu de depis-tat in codul sursa[3].

Multe dintre sabloanele de proiectare, mai ales cele care au domeniul de aplicare la nivel de obiect, capteaza distinctia dintre structurile stabilite la compilare si cele de la executie, in sensul ca un specialist care cunoaste sabloanele de proiectare poate detecta mai usor in codul sursa structurile ce se vor crea la executie.

4.7Proiectare pentru Schimbare

Cheia pentru maximizarea reutilizarii (refolosirii) consta in anticiparea noilor cerinte si modificari la cerintele existente, si in proiectarea sistemelor., pentru ca acestea sa evolueze in mod corespunzator[3].

Pentru a proiecta un sistem astafel incat sa-si pastreze robustetea , trebuie luat in conside-rare modul in care sistem are nevoie de schimbari de-a lungul „vietii” sale.O proiectare care nu tine cont de schimbari risca reproiectari mari in viitor.Acele schimbari pot produce/provoca redefinire , reimple-mentare de clase, modificari ale clientului si retestari.

Sabloanele de proiectare ne ajuta sa evitam aceste lucruri prin asigurarea ca un sistem se poate modifica in multe moduri.Fiecare sablon de proiectare permite unor aspecte ale structurii sistemului o oarecare independenta fata de alte aspecte , in acest fel realizand un sistem mult mai robust , mai deschis la un tip particular de schimbari.

Aici sunt cateva cause comune ale reproiectarii , impreuna cu sabloanele de proiectare care li se adreseaza[3]:

Crearea unui obiect prin specificarea unei clase in mod explicit. Specificand numele unei clase atunci cand creezi un obiect te obliga la o implementare particulara in loc de o interfata particulara. Acest angajament poate produce complicatii in viitor. Pentru a evita acest lucru , se recomanda crearea indirecta de obiecte.

Sabloane de Proiectare : Atelier Abstract, Metoda Atelier, Prototip.

Dependenta de anumite operatii. Atunci cand se specifica o anumita operatie , acest lucru implica la un singur mod de a satisface o cerere. Pentru evitarea cererilor greu de implementat, se poate usura prin schimbarea modului in care cererea este satisfacuta atat la compilare cat si la executie.

Sabloane de Proiectare :Lant de succesori,Comanda

Dependenta de sistemul de operare. Operatiile externe ale interfetelor sistemului si aplicatiile de programare a interfetelor sunt diferite de la sistem de operare la altul.Soft ce depinde de o platforma particulara va fi greu de folosit pe alta platforma.In consecinta este important ca sistemul sa fie proiectat la limitele de dependenta cu platforma.

Sabloane de Proiectare:Atelier Abstract,Punte

Dependenta de algoritimi.Algoritmii sunt in cele mai multe cazuri extinsi,optimizati,inlocuiti si reutilizati de-alungul implementarii.Un obiect care depinde de un algoritm va trebui sa se schimbe atunci cand algoritmul de schimba.In consecinta algoritmii care sunt predispusi la schimbari trebuie izolati.

Sabloane de Proiectare:Constructor,Iterator,Strategie,Metoda Atelier, Vizitator

4.8 Cadre de lucru (Frameworks)

Un cadru de lucru orientat obiect poate fi descris ca fiind un set de clase care colaboreaza pentru realizarea unui anumit comportament si care constituie un punct de plecare in realizarea aplicatiilor dintr-un anumit domeniu. Obiectivele unui cadru de lucru sunt:

inmagazinarea cunostintelor referitoare la un anumit domeniu, cunostinte dobandite in cadrul unei organizatii producatoare de software;

reducerea efortului de dezvoltare al unei noi aplicatii; prin realizarea unui cadru de lucru se creeaza un punct de plecare pentru toate aplicatiile dezvoltate pentru domeniul respectiv;

Cadrele de lucru orientate obiect sunt caracterizate de mai multe dimensiuni, dintre care cele mai importante sunt [4]:

Domeniul cadrului de lucru. In functie de aceasta dimensiune cadrele de lucru se impart in:

cadre de lucru pentru aplicatii – nu sunt specifice unui anumit domeniu (pot fi folosite in orice aplicatie); astfel de cadre sunt cele ce permit construirea interfetelor grafice;

cadre de lucru pentru un domeniu – sunt specifice unui anumit domeniu, ele putand fi folosite pentru orice aplicatie dezvoltata pentru domeniul respectiv;

cadre de lucru pentru suport – ofera suport la un nivel scazut, cum ar fi drivere sau acces la fisiere.

Structura cadrelor de lucru. Se refera la structura interna a cadrelor de lucru. Structura interna este legata de conceptul de arhitectura software.Principiul care sta la baza structurii interne a unui cadru de lucru este denumit de Buschmann „cadru de lucru arhitectural” [4].

Felul in care sunt utilizate. Exista doua modalitati de utilizare a cadrelor de lucru orientate obiect:

Modul condus prin arhitectura – sunt derivate de noi clase din clasele ce compun cadrul de lucru;

Modul condus prin date – sunt instantiate si combinate clasele existente.

Avantajele utilizarii cadrelor de lucru sunt urmatoarele:

reducere a codului ce trebuie scris pentru aplicatia dezvoltata;

crestere a calitatii: se utilizeaza cod a carei corectitudine a fost probata in proiecte anterioare;

un cadru de lucru ofera, de asemenea, posibilitatea reutilizarii modelului de proiectare;

imbunatatirea mentenantei: cand este corectata o eroare in cadrul de lucru, acea eroare este corectata si in aplicatiile derivate din cadrul de lucru respectiv.

Dintre dezavantajele potentiale ale cadrelor de lucru orientate obiect se pot mentiona:

dezvoltarea unui cadru de lucru bun este dificila, fiind necesara o experienta bogata in dezvoltarea de aplicatii pentru domeniul considerat;

in unele cazuri documentatia cadrului de lucru este deficitara, fapt ce face cadrul respectiv dificil de utilizat;

pe masura ce cadrul de lucru evolueaza, prin adaugarea de noi functionalitati, este dificil de mentinut compatibilitatea cu versiunile anterioare (trebuie sa evolueze si aplicatiile care se bazeaza pe cadrul de lucru respectiv);

generalitatea si flexibilitatea cadrului de lucru pot actiona impotriva eficientei utilizarii lui.

In ciuda acestor dezavantaje utilizarea cadrelor de lucru este importanta, in special in cazul aplicatiilor orientate obiect de mari dimensiuni.

Dezvoltarea cadrelor de lucru orientate obiect.

Dezvoltarea cadrelor de lucru presupune studierea atenta a domeniului pentru care acestea sunt dezvoltate in scopul identificarii aspectelor comune aplicatiilor specifice domeniului studiat. Astfel, dezvoltarea unui cadru de lucru presupune [4]:

• Analizarea domeniului problemei;

• Identificarea abstractizarilor primare;

• Proiectarea modalitatii de interactiune a clientilor cu cadrul de lucru;

• Implementarea, testarea si rafinarea cadrului de lucru.

Analiza domeniului. Analiza unui domeniu, in vederea identificarii si dezvoltarii unui cadru de lucru pentru domeniul respectiv, presupune analiza unor aplicatii deja existente. Acest lucru este, in general, posibil numai daca organizatia are deja dezvoltate o serie de aplicatii pentru domeniul considerat. Cadrele de lucru trebuie gandite ca abstractizari ale solutiilor posibile. Pentru a identifica necesitatea dezvoltarii unor cadre de lucru, trebuie gandit in termenii familiilor de aplicatii [4]:

Trebuie cautate solutiile software folosite in mod repetat in zone importante ale domeniului analizat.

Trebuie identificat ce anume au in comun solutiile si ce anume este particular fiecarui program. Aspectele comune devin baza cadrelor de lucru ce urmeaza a fi dezvoltate.

Identificarea abstractizarilor primare. Procesul presupune identificarea acelor abstractizari pe care expertii in domeniul analizat le folosesc pentru a descrie problemele. Urmatorul pas il constituie stabilirea logicii pentru construirea unei solutii valide folosind abstractizarile identificate.

Modalitatea cea mai usoara de identificare a abstractizariilor primare o constituie abordarea de tip „bottom-up”: se porneste cu examinarea solutiilor existente. Se identifica structurile de date si algoritmii si se organizeaza abstractizarile.

In dezvoltarea cadrelor de lucru un rol important il au sabloanele de proiectare orientate obiect. Ele identifica si abstractizeaza teme comune in proiectarea orientata obiect. Ele constituie elemente ce inmagazineaza experienta dobandita in dezvoltari anterioare si actioneaza ca blocuri constructive de la care se poate porni constructia unor sisteme complexe.

Proiectarea modalitatii de interactiune a clientilor cu cadrul de lucru.

In proiectarea cadrelor de lucru un aspect important il reprezinta modalitatea in care utilizatorii cadrului vor interactiona cu acesta. Se are in vedere reducerea, cat de mult posibil, a cantitatii de cod pe care dezvoltatorul este nevoit sa o scrie.

Urmatoarele actiuni au ca rezultat o reducere a codului ce trebuie dezvoltat:

furnizarea de implementari ce pot fi utilizate direct;

minimizarea numarului de clase ce trebuie derivate;

minimizarea numarului de functii membru ce trebuie suprascrise.

Proiectarea unui cadru de lucru presupunea realizarea unui echilibru intre urmatoarele doua aspecte:

Realizarea unui cadru de lucru flexibil, general, din care sa poata fi derivate alte cadre de lucru specializate pe anumite subdomenii ale domeniului considerat. Dezavantajul acestora este o intelegere mai dificila si o cantitate mai mare de cod ce trebuie dezvoltat.

Minimizarea cantitatii de cod (si o utilizare mai usoara), dar care duce la o specializare a cadrului de lucru (se pierde din flexibilitate).

Implementarea, testarea si rafinarea cadrului de lucru.

Construirea unui cadru de lucru reprezinta un proces iterativ. Dezvoltarea unui cadru de lucru porneste de la un proiect initial, care, in urma consultarii cu expertii in domeniu, este rafinat in continuu: se reanalizeaza domeniul si se modifica proiectul pe baza rezultatelor testarii, a feedback-ului clientului si a experientei dezvoltatoprului.

Pe masura ce cadrul de lucru se maturizeaza, dezvoltatorii vor adauga noi functionalitati si vor identifica oportunitati pentru dezvoltarea de noi cadre de lucru. Acestea pot fi in intregime noi, sau pot reprezenta un subset particular al domeniului problemei.

4.9 Cum selectezi un sablon de proiectare

Cu mai mult de 20 de sabloane de proiectare din catalog , poate fi greu sa alegi unul care se adreseaza unui anumit tip de proiectare , in special daca catalogul este nou si nefamiliar.Aici sunt cateva aspecte ale cautarii unui sablon de proiectare apropiat de problema intampinata[3]:

Gandeste modul in care sabloanele de proiectare rezolva problemele de proiectare.Sabloanele de proiectare te pot ajuta sa gasesti obiectele apropiate , determinarea granularitatii , specificarea interfetelor si multe alte moduri in care sabloanele de proiectare rezolva problemele de proiectare.

Cauta printre sectiunile de intentie alte sabloanelor.Cautand printre intentiile sabloanelor se poate afla unul care este mai aproape de problema avuta.

Studiaza modul in care sabloanele interactioneaza.Cauta relatiile la nivel grafic intre sabloane , acest lucru te poate directiona catre un sablon sau grup de sabloane.

Studiaza scopul sabloanelor.

Examineaza cauza reproiectarii.

Hotaraste ce trebuie sa fie variabil in proiectarea ta.

4.10 Cum folosesti un sablon de proiectare

Odata ce sablonul de proiectare a fost ales , cum se foloseste? Aici sunt cativa pasi cum sa aplici un sablon de proiectare efectiv [3]:

Citeste sablonul din nou pentru o vizualizare mai amanuntita.Atentie sporita la Aplicabilitatea si Consecintele sectiunilor pentru asigurarea faptului ca sablonul este cel ales bine conform problemei.

Studiaza Structura,Participantii si sectiunile de Colaborare.Fi sigur ca ai inteles clasele si obiectele din sablon si modul in care acestea relationeaza intre ele.

Cauta un exemplu de cod al sablonului.Acest lucru te va ajuta la implementarea sablonului.

Alege nume reprezentative pentru petru aplicatiile sablonului in conformitate cu contextul aplicatiei.

Defineste clasele.Defineste-le interfetele , stabileste relatiile de mostenire si instantele variabilelor care reprezinta referinte de obiecte.Cauta clasele existente in aplicatie care vor fi afectate de catre sablon si modifica-le corespunzator.

Defineste nume specifice ale operatiilor .

Implementeaza operatii care sa reflecte responsablitatea si colaborarea in sablonul de proiectare.

Capitolul 5

Sabloane de proiectare folosind MVC

Model-View-Controller (MVC) este un design pattern care leaga eficient interfata cu utilizatorul de modelul de date in programarea orientata pe obiecte. Acesta arhitectura este larg utilizata in programarea in limbajele Java, C++ sau Smalltalk, permitand reutilizarea codului sursa si reducand astfel durata de dezvoltare a aplicatiilor cu interfete utilizator. Arhitectura model-view-controller se constituie din trei componente principale.

Relatiile dintre Model, Interfata si Control (liniile continue sugereaza o asociere directa pe cand cele punctate o asociere indirecta).

Paradigma MVC ofera o modalitate de a “sparge” aplicatia sau macar o parte a interfetei aplicatiei in 3 parti : modelul, view’ul si controller’ul .

Modelul reprezinta informatia (datele) aplicatiei si regulile de business ce guverneaza accesul la date sau modificarea acestora. Modelul nu stie nimic despre GUI, despre modalitatea in care vor fi afisate datele sau actiunile folosite de GUI pentru a manipula datele.

Viewul corespunde elementelor legate de interfata cu userul . Foloseste metode de query asupra modelului pentru a obtine informatie necesara interfetei . Specifica in ce mod trebuie reprezentata data . Este de responsabilitatea acestui nivel sa mentina consistenta in cazul unei schimbari in model .

Controllerul are grija de comunicarea dintre model si actiunile intreprinse de user . Controllerul traduce interactiunile cu viewul in actiuni ce vor fi intreprinse de model . Intr-un client GUI stand-alone interactiunile pot fi clickuri pe butoane sau selectari pe meniuri in timp ce intr-o aplicatie Web ele apar sub forma de requesturi HTTP de GET si POST . Actiunile executate de model includ procese de business sau schimbarea starii modelului . In functie de interactiunile userului si actiunile declansate in model, controllerul alege un view .

Avantaje

Multiple viewuri cu acelasi model: Separarea modelului de view permite folosirea multipla de viewuri pastrand acelasi model .

Suport pentru tipuri noi de client: Pentru a integra un nou tip de client nu trebuie decat sa dezvolti un nou view si un controller pentru el pe care apoi sa le legi de modelul existent.

Claritatea designului: Usurinta in a controla comportamentul modelului.

Reutilizarea codului: Arhitectura optimizeaza reutilizarea codului.

Modularitate eficienta : Modularitatea designului permite schimbarea oricarei componente in orice moment dupa dorinta userului si programatorului – chiar si modelul . Schimbarile asupra unui aspect al programului nu influenteaza alte aspecte eliminand astfel multe situatii neplacute la debug. Totodata dezvoltarea componentelor pot progresa in paralel o data ce interfata dintre componente a fost definita

Usurinta in versionare: Controlerele si viewurile pot creste in paralel cu modelul ; versiunile mai vechi de viewuri si controllere pot fi inca folosite cat timp este mentinuta o interfata comuna[8].

Dezavantaje

Instabilitatea viewului : Separarea viewului de model permite un model mai robust insa codul de interfata sufera schimbari frecvente si chiar dramatice .

Greu de deployat

Clase Controller mari : Pe o aplicatie mare, cu multe screenuri, controllerul ajunge sa fie foarte mare si greu de intretinut . O solutie ar fi o ierarhie de controllere insa ramane o problema[8].

5.1 MVC Model 1 versus Model 2

Arhitectura MVC s-a dezvoltat in urma nevoilor practicii in doua modele usor diferite, cunoscute sub numele de Modelul 1 si Modelul 2.

Model1 MVC

Model2 MVC

Modelul 1 poate fi utilizat cu succes la dezvoltarea de site-uri simple, avantajul sau fiind viteza de dezvoltare a paginilor JSP. Dezavantajele modelului 1 constau in amestecul de componente logice si limbaje la nivelul paginilor JSP, ceea ce face intretinerea lor mai dificila si conduce la imposibilitatea reutilizarii lor pentru alte aplicatii.

Modelul 2 reprezinta o structura bazata pe arhitectura model-view-controller (MVC) 2. Fluxul aplicatiei este mediat de un Controller central (un servlet sau o colectie de servleturi), care are rolul de a delega cererile HTTP catre clasa Java care sa le gestioneze.

Componenta Model este constituita dintr-un ansamblu de clase Java care inmagazineaza logica aplicatiei si starea sistemului. Dupa ce logica necesara este executata la nivelul componentelor Model, controlul este transferat inapoi la Controller care il transmite catre paginile JSP care joaca rol de componenta View. Alegerea uneia dintre paginile View care sa preia controlul este determinata la nivelul unui fisier de mapari (de regula un fisier de configurare XML)[8].

In acest fel modelul MVC realizeaza separarea in componente distincte a logicii aplicatiei de procesarea la nivel de server si de logica de afisare a rezultatelor. Aceasta separare permite fiecarei componente sa poata fi reutilizata si asigura o intretinere mai usoara a intregii aplicatii.

Capitolul 6

Sabloane de proiectare – Xml

6.1 Fisiere Xml

XML – (eXtensible Markup Language) este un limbaj de adnotare/structurare a datelor. Istoria aparitiei sale porneste de la SGML (Standard Generalized Markup Language) aparut in anii 80. Acest limbaj isi propunea la aparitie sa creeze documente ce pot fi analizate de catre masini prin introducerea de marcaje (sau taguri). SGML nu a fost un succes deoarece era foarte complex si astfel crearea de programe care sa-l analizeze[6].

In anii 90 la CERN a aparut HTML-ul (HyperText Markup Language). La baza acestui limbaj a fost SGML-ul si scopul sau a fost marcarea documentelor astfel incat sa poata fi transmise prin retea. Si astfel s-a dezvoltat HTML-ul.

Succesul avut de Web a cauzat o dezvoltare rapida a browserelor care analizau marcajele HTML. Astfel au aparut o gama larga de marcaje si atribute care puteau fi scrise fara prea multe constrangeri. Browserele au trebuit sa tina cont de aceste constrangeri si au devenit foarte complexe. Pe de alta parte s-a sesizat utilizarea HTML-ului pentru adnotarea documentelor si o slabiciune de-a sa – faptul ca nu se pot adauga marcaje noi[6].

XML sta la baza multor tehnologii si limbaje noi. Astfel pentru prezentare de continut pe web exista XHTML si WML (pentru dispozitive mobile), pentru descrierea unor fisiere XML exista XSchema, pentru transformarea fisierelor XML pentru a fi reprezentate exista XSL, pentru realizarea unor prezentari exista SMIL, pentru descrierea obiectelor grafice exista SVG, pentru reprezentarea semanticii unor domenii exista RDF si/sau OWL, pentru schimb de informatii intre aplicatii exista SOAP si asa mai departe, lista aceasta fiind departe de a cuprinde toate tehnologiile/limbajele existente bazate pe XML. De ce au aparut atatea limbaje bazate pe XML? Pentru ca are o structura simpla si totusi stricta, pentru ca este foarte usor de analizat si foarte usor de definit si dezvoltat.

6.2 Sabloane de proiectare a fisierelor XML

Sabloane pentru folosirea Metadatelor (date despre date)

Cand exista metadate intr-un document pot fi folosite mai multe solutii pentru integrarea lor:

Head+Body – varianta folosita si in HTML – datele despre date se pun intr-o sectiune speciala a documentului numita head si datele efective se vor plasa in sectiunea body.

Metadatele se pun inaintea datelor in document. Motivul este destul de simplu si anume in conditiile in care procesarea XML-ului se face secvential s-ar putea ca un proces, dupa ce interpreteaza meta-datele sa nu mai doreasca sa prelucreze si restul documentului si implicit sa nu-l mai incarce sau parseze

In cazul in care exista un mare numar de metadate, poate fi util ca acestea sa fie plasate intr-un fisier separat. Acest lucru este recomandabil mai ales in cazul in care este vorba de metadate comune mai multor fisiere (vezi ontologii si RDF)[6].

Abstractizare

Cum se pot alege si respectiv grupa elementele astfel incat structura XML-ului format sa fie cat mai inteligibila.

Containere – in containere se pot pune mai multe elemente diferite dar care caracterizeaza un „parinte” comun dintr-un anumit punct de vedere. De exemplu pentru un om putem pune intr-un container „date de identificare” elementele „nume”, „prenume”, „CNP”

Colectii – cand in cadrul unui element pot aparea ca si copii mai multe elemente de acelasi tip acestea este recomandabil sa se grupeze ca si copii al unui element separat. Exemplu un om are mai multi copii ceea ce putem exprima in mai multe feluri:

<om>

<date_identificare>…</date_identificare>

<copil></copil>

<copil></copil>…

..

</om>

Sau

<om>

<date_identificare>…</date_identificare>

<copii>

<copil></copil>

<copil></copil>…

</copii>

..

</om>

A doua varianta presupune adaugarea elementului „copii” care reprezinta o colectie de elemente de tip „copil”

Elementele este bine sa aiba o corespondenta in cadrul domeniului descris (v. Descrierea claselor si a proprietatilor la programarea orientata obiect)

Organizarea datelor

Declararea elementelor inainte de a fi referite. Cu ajutorul atributelor de tip IDREF elemente pot fi referite in cadrul altor elemente. Este recomandabil ca intai sa apara in document elementul si apoi referinta (tot pentru usurinta procesarii)

Referirea datelor si nu repetarea lor. Datele pot fi declarate folosind declaratii de tip Entity sau pot fi identificate in mod unic folosind atribute de tip ID si referite prin atribute de tip IDREF

Clasificare folosind atribute – cand pot clasifica anumite elemente in mai multe feluri se pot introduce atribute pentru a nu complica ierarhia. In exemplul de mai sus elementului copil i se poate introduce atributul „sex” care practic introduce o clasificare suplimentara fara a adauga elemente suplimentare[6].

Altele

Reutilizare atribute – daca mai multe elemente au aceleasi atribute nu trebuie definite atributele de mai multe ori

Nume scurte dar inteligibile – „loc_de_munca” este preferat elementului “serv”.

Proiectarea structurii unui document Xml

Lungimea documentului

Usurinta folosirii marcajelor (ease of authoring)

Usurinta procesarii (ease of processing)

Usurinta validarii

Flexibilitatea

Consistenta

Gradul de abstractizare

Xml Design Pattern – scurta clasificare [6]:

Oportunitatea folosirii XML-ului : Folosirea XML

Reutilizarea tipurilor de documente existente: Reutilizarea Documentului Tip;

Alegerea documentului/elementelor radacina: tipuri Multiple de Documente, Multiple Tipuri de Documente Radacina.

Stabilirea gradului de abstractizare: Dezvoltare,Nume Intelese Usor, Elemente de Domeniu , Elemente Container , Elemente Colectie …

Asocierea de metadate: Separarea Metadatei si a Datei , Metadata in Documente Separate .

Organizarea documentului : Referentierea unor constructii (Declara Inainte de prima utilizare), Aceeasi informatie referentiata in locuri multiple (Obiect Partajat) , Arbore (ierarhie) versus graf ;

Extinderea ulterioara : Catch – All Element , Rolul Atributului , Model cu continut extensibil

Asigurarea consistentei: Atribute Comune, Mutimea Elementelor Consistente.

Utilizare XML

determina situatia in care XML e solutia viabila de reprezentare a informatiei (semi) structurate

existenta unor reprezentari multiple: binar,CSV,HTML,baze de date relationale, obiecte serializate, XML

XML poate fi o solutie adecvata cand:

Continutul (datele) trebuie separate de formatare

Datele trebuie partajate intre aplicatii , organizatii …

Reprezentarea sa poata fi usor procesata de calculator , independent de platforma si de limbaj.

factori care trebuie considerati : simplitatea,extensibilitatea,interoperabilitatea,existenta instrumentelor de procesare ,transformarea facila in alte reprezentari,usurinta validarii,existenta standar-dizarii

XML ca limbaj pentru reprezentarea atat a datelor,cat si a metadatelor.

Denumiri scurte si usor de inteles

Numele elementelor & stributelor trebuie sa fie scurte si usor de inteles atat de autori, cat si de dezvoltatorii soft-ului de procesat documentul

Pattern-ul poate fi utilizat pentru orice tip de document

Numele prea scurte sunt dificil de inteles,dar reduc lungimea documentelor

Conventii de numire : <nume_tag>,<NumeTag>[6].

Elementul Container

Un container grupeaza elemente (copil) inrudite

Problema: numeroase elemente care apar pe acelasi nivel in document si care pot fi divizate in grupuri distincte

Pattern-ul ajuta la structurarea documentului,dar e foarte general (pot exista pattern-uri mai specializate,derivate din acesta)

Pattern-ul adauga un nivel de abstractizare,gruparea elementelor oferind informatii semantice suplimentare (ex: asocierea de metadate unui grup de elemente)

Pattern-uri inrudite : Head-Body , Collection Element

Elementul Colectie

Creeaza un element al carui model de continut permite doar instante de singur tip

Problema: exista un element care trebuie repetat la acelasi nivel al documentului

Context : gruparea pe categorii a elementelor, existenta multor „frati” (siblings), asocierea de metadate etc.

Solutie: crearea unui element continand mai multe elemente de acelasi tip

Structura rezultata e mult mai usor de procesat

Daca columul de metadate este mare, se va putea utiliza pattern-ul Head-Body

Exemple: XHTML,RDF,DocBook,…[6].

Envelope

Ofera un tip de document care va desemna un „plic” in care se vor putea stoca date XML arbitrare

Problema: diferite seturi de date trebuie livrate unui sistem, intr-o maniera consistenta

Context: structura datelor din „plic” poate varia si nu e cunoscuta la momentul creearii sistemului

Pattern-ul permite separarea diferitelor tipuri de continuturi, oferind un mecanism de livrare a datelor XML;plicul nu interfereaza cu continutul propriu-zis al mesajului transmis

Exemplu: SOAP (Simple Object Access Protocol)[6].

Obiect Partajat

Cand acceasi informatie este inclusa in diferite locuri in document, atunci ea poate fi plasata o singura data si referita in locuri multiple

Problema: plasarea repetata a acelorasi date in locuri diferite poate cauza erori si dificultati in mentananta documentului;creste nejustificat lungimea documentului;

Solutie:utilizarea entitatilor XML (externe),folosirea datelor „embed” via Xlink, utilizarea atributelor ID si IDREF etc.

Pattern-ul mareste fradul de mentenanta si modularizare, dar poate afecta abilitatea de intelegere a documentului.

<?xml version=”1.0”?>

<!DOCTYPE Titlu [

<!ENTITY titlu ”Sietul WebGroup”>

]>

<html>

<head>

<title>&titlu:</title>

<meta name=”description” content=”&titlu;”/>

</head>

<body>

<h1> &titlu; :: Salut! </h1>

</body>

Exemple de pattern-uri de proiectare:

XML Intrare Iesire – rezolva problema obtinerii, procesarii si returnarii datelor XML,procesele interne de prelucrare fiind ascunse

Asistare Externa – procesul de generare a formatului de prezentare plecand de la XML este realizat de o aplicatie externa

Gruparea Informatiilor – solutioneaza problema gruparii si prezentarii datelor XML,indiferent de aplicatia care genereaza aceste date

Mediatorul XML– rezova problema inter-operabilitatii dintre aplicatii care utilizeaza documente XML cu structuri eterogene.

XML Intrare Iesire

Organizeaza activitatea componentelor implicate in procesele de colectare si de vizualizare a datelor

Scop: dezvoltarea de conexiuni intre componente traversate de date XML pastrand o cuplare slaba si o coeziune ridicata (similar cu pattern-ul Proxy)

Existenta unui ”lipici” intre componente => independenta de limbaj/platforma

Gruparea Informatiilor

Date la intrare documente XML, pattern-ul ofera o modalitate de a formata datele XML, grupate pe diverse criterii (asemanator lui group by din SQL)

Asigura separarea intre formatul de reprezentare si cel de stocare a datelor, putand organiza informatiile intr-un mod diferit de cel al stocarii[6].

Bibliografie

Dorin Mancu , Sabloane de proiectare (Design Patterns) http://web.info.uvt.ro/~dmancu/oop/oop-l3.doc

Freeman, Eric; Elisabeth Freeman, Kathy Sierra, and Bert Bates (2004). Head First Design.

Gamma Erich, R Helm, R Johnson, J Vlissides , Design Patterns: Elements of Reusable Object-Oriented Software 9780201633610 (0201633612), 1995

Dan Laurentiu Jisa,Analiza si proiectarea orientate obiect in realizarea aplicatiilor economice (2000)

http://c2.com/cgi/wiki?DesignPatterns

Spencer, P., Professional XML Design and Implementation, Wrox, 1999 [3] C# 3.0 Design Patterns O'Reilly, 2008

Wikipedia http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

Wikipedia http://en.wikipedia.org/wiki/Model-view-controller

Bibliografie

Dorin Mancu , Sabloane de proiectare (Design Patterns) http://web.info.uvt.ro/~dmancu/oop/oop-l3.doc

Freeman, Eric; Elisabeth Freeman, Kathy Sierra, and Bert Bates (2004). Head First Design.

Gamma Erich, R Helm, R Johnson, J Vlissides , Design Patterns: Elements of Reusable Object-Oriented Software 9780201633610 (0201633612), 1995

Dan Laurentiu Jisa,Analiza si proiectarea orientate obiect in realizarea aplicatiilor economice (2000)

http://c2.com/cgi/wiki?DesignPatterns

Spencer, P., Professional XML Design and Implementation, Wrox, 1999 [3] C# 3.0 Design Patterns O'Reilly, 2008

Wikipedia http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

Wikipedia http://en.wikipedia.org/wiki/Model-view-controller