Modele Arhitecturale Folosite In Dezvoltarea Aplicatiilor Software

CUPRINS

Introducere

Introducere [Iorga Florin]

Arhitectura Client/Server [Crai Adina]

Generalitati

Structura

Componente

2. Modelul Model-View-Controller(MVC) [Iorga Florin]

2.1 Generalitati

2.2 Structura

2.3 Componente

2.4 Functionare

3. Modelul Model-View-Presenter [Crai Adina]

4. Modelul MVP Taligent [Crai Adina]

4.1 Generalitati

4.2 Structura

4.3 Componente

4.4 Functionarea

5. Modelul Supervising Controller [Crai Adina]

5.1 Generalitati

5.2 Structura

5.3 Componente

5.4 Functionare

6. Modelul Passive View [Crai Adina]

6.1 Generalitati

6.2 Structura

6.3 Componente

6.4 Functionare

7. Modelul Presentation-Abstraction-Control(PAC) [Iorga Florin]

7.1 Generalitati

7.2 Structura

7.3 Componente

7.4 Functionarea

7.5 Modele derivate din PAC

8. Bibliografie

Introducere

1.1. Introducere

Pattern-urile MVC, MVP si PAC au aparut din necesitatea dezvoltarii de aplicatii interactive si au la baza separarea si alocarea sarcinilor in cadrul diferitelor componente ale arhitecturilor lor. Desi sunt similare, fiecare dintre aceste modele difera putin in motivatiile si aplicabilitatea lor la diverse obiective de design.

In discutarea modelelor de arhitectura in general , este util sa intelegem ca modelele din aceasta clasa sunt adesea motivate de considerente de proiectare care s-au format in contextul mediilor de dezvoltare specifice. De exemplu, modelul Model-View -Controller a avut ca motivatie divizarea intre input-ul si output-ul aplicatiei (care a dus la conceptul componentei Controller). Mediile de dezvoltare de astazi au parcurs au evoluat suficient de mult pentru a nu mai face necesara separarea input si output la nivelul aplicatiei. In astfel de medii , o aplicatie bazata pe modelul Model-View -Controller poate duce la o abordare care adera la intentia initiala a acestuia, dar nu respecta forma sa originala , sau adera la forma sa originala , fara urmări intentia initiala. Formalizarea unui Controller pentru a pentru interceptarea input-ului utilizatorului nu mai este necesara, deoarece majoritatea platformelor ofera deja aceasta functionalitate.

1.2 Arhitectura Client/Server

1.2.1 Generalitati

Modelul client-server a fost elaborat in anii ‘70 de catre cercetatorii de la Xerox si Xerox PARC in cadrul dezvoltarii unui limbaj de programare numit Decode-Encode Language(DEL). Scopul limbajului era sa accepte comenzi de la un computer(client), sa le codifice si sa le trimita sub forma de pachete prin intermediul unei retele. La capatul celalat al retelei se afla un alt computer(Server) ce avea ca rol sa decodifice pachetele si sa returneze date formatate computerului de la care a primit cererea, pentru a fi prezentate utilizatorului. Dezvoltarea DEL a inceput in anul 1969, an ce coincide cu implementarea in cadrul Departamentului de Aparare al Statelor Unite al ARPANET-ului(predecesorul internetului).

1.2.2 Structura

Fig.1 Model conceptual al unei arhitecturi Client-Server

(referinta bibliografie[10])

1.2.3 Componente

Aceasta arhitectura imparte elementele componente in doua categorii: Client si Server.

Rolul unui computer Client este de a asigura interfata cu utilizatorul si o parte din procesarea necesara aplicatiei.

Rolul unui computer Server este de a asigura o capacitate mare de stocare si de a se ocupa de partea de procesare mai intensiva a aplicatiei.

Functionare

Computerul Client trimite o cerere(request) catre computerul Server, acesta la randul lui o decodifica si returneaza datele solicitate, in formatul in care a fost programat sa le prelucreze. Pentru a putea comunica, atat Client-ul cat si Server-ul trebuie sa foloseasca un limbaj comun si sa urmeze acelasi set de reguli. Atat limbajul cat si regulile sunt definite in cadrul protocolului de comunicare. Toate protocoalele clinet-server opereaza in cadrul nivelului OSI 7: Aplicatie.

Modelul Model-View-Controller

2.1 Generalitati

Modelul MVC a fost conceput original in 1978-79 de catre Trygve Reenskaug si a avut ca si scop principal oferirea unei interfete in care utilizatorii sa manipuleze multiple View-uri cu date ca si cand ar lucra cu entitati din lumea reala. Numele initial al modelului era Thing-Model-View-Editor, dar a fost schimbat ulterior in Model-View-Controller. O versiune modificata a modelului lui Reenskaug a fost ulterior implementata in bibliotecile de clase din cadrul Xerox PARC Smalltalk-80.

2.2 Structura

Model View Controller(MVC) reprezinta un model arhitectural utilizat in Inginerie Software ce separa partea de stocare a datelor de interfata cu utilizatorul. Se disting astfel trei componente:

Model: are rolul de a manipula operatiile logice si de utilizare de informatie

View: interactioneaza cu utilizatorul evidentiindu-i informatia

Controller: controleaza accesul la aplicatie

Fig. 2 Schema conceptuala a modelului( liniile punctate arata legaturile indirecte)

(referinta bibliografie [9] )

2.3 Componente

Controller-ul , asa cum se observa in Fig2, este elementul de legatura dintre View si Model. El este responsabil pentru prelucrarea input-ului utilizatorului, deseori facand modificari in model. Rolul controller-ului este de a asigura flow-ul aplicatiei, de a prelucra datele primate si de a asigura datele necesare catre View-ul corespunzator.

View-ul constituie ceea ce va fi vizibil utilizatorului din cadrul intregii aplicatii. Acesta componenta a triunghiului MVC este responsabila pentru asigurarea interfetei pentru utilizator (UI), prin transformarea datelor din Model intr-un format pentru a fi prezentate utilizatorului.

Model-ul se refera la datele si logica de functionare(bussiness logic) ale aplicatiei. Cel mai des este reprezentat de un Domain Model, in cadrul caruia obiectele sunt folosite pentru a modela entitati din lumea reala si sunt procesate prin reprezentarea proprietatilor si comportamentului acestora.

2.4 Functionarea

Principiul de functionare al unei aplicatii lucrand dupa modelul MVC:

User-ul interactioneaza cu interfata

Controller-ul primeste requestul si il converteste intr-o actiune pe care view-ul o poate intelege

Reimprospatarea campului de adresa

View-ul afiseaza noua adresa

Interfata asteapta noi actiuni din partea utilizatorului

In cadrul modelului MVC, in spatele oricarui obiect ce va fi manipulat de catre utilizator exista triunghiul MVC.

Modelul reprezinta starea, structura si comportamentul datei care este vizualizata si manipulata de catre utilizator. Asa cum se observa in figura 2, Model-ul nu contine nici o legatura directa cu Controller-ul si cu View-ul si poate fi modificat de catre acestea. Cand este necesar, Model-ul foloseste Observer Pattern pentru a anunta faptul ca datele din cadrul sau au fost modificate.

View-ul si Controller-ul lucreaza impreuna pentru a oferi utilizatorului posibilitatea de a vizualiza si de a interactiona cu Model-ul. Un View este asociat unui singur Controller, iar unui singur Controller ii este asociat un singur View. Intre aceste doua componente exista o legatura directa cu Model-ul.

Ca si o generalizare, rolul unui View este de a se ocupa in principal de output, iar al unui Controller de input si impreuna sa interactioneze cu Model-ul. Ambele pot accesa si modifica datele din cadrul Model-ului in functie de situatie.

Cand un utilizator interactioneaza cu aplicatia, Controller-ul intercepteaza input-ul sau raspunde in conformitate. Rezultatul poate consta in interactiuni cu Model-ul sau in modificari vizuale ale View-ului.

Modelul Model-View-Presenter

Modelul Model-View-Presenter este o variatie a modelului Model-View-Controller, ce in mod similar aloca sarcinile (de exeplu input-ul utilizatorului, output-ul, prezentarea, etc.) componentelor specializate din cadrul arhitecturii aplicatiei.

Deoarece exista mai multe modele care desi sunt acceptate sub numele de MVP, au diferente semnificative, vom prezenta unul dintre cele mai cunoscute modele ce se considera a fi MVP.

Modelul MVP Taligent

4.1 Generalitati

Modelul MVP are la baza modelul de programare Talingent, care la randul sau a fost influentat de modelul MVC implementat in Smalltalk-80. Acest model a fost prima data descris de catre Mike Potel in 1996, angajat in aceea perioada la Taligent Inc.

Compania Taligent a fost inceputa de Apple Computer impreuna cu IBM, la care s-a adaugat mai tarziu Hewlett Packard, iar apoi a fost detinuta in totalitate de catre IMB spre sfarsitul anului 1995. Majoritatea elementelor modelului MVP original au inceput sa ia forma la Apple, sub conducerea lui Larry Tesler, fost angajat la Xerox Parc si contribuitor la dezvoltarea Smalltalk.

Desi principalele elemente alre modelului erau folosite in cadrul Talingent, abia dupa achizitionarea companiei de catre IBM, numele de Model-View-Presenter a fost sugerat de catre Mike Potel, pentru a descrie arhitectura folosita in cadrul Taligent.

4.2 Structura

Spre deosebire de modelul MVC, modelul MVP a renuntat la folosirea Controller-ului ca element central ce comunica direct atat cu View-ul cat si cu Model-ul, in locul acestuia fiind folosite mai multe “blocuri functionale”.

Fig. 3 (referinta bibliografie [8])

4.3 Componente

Model-ul se refera la datele si logica de functionare(bussiness logic) ale aplicatiei.

Blocul Selections are rolul de a specifica ce portiune de date din cadrul Model-ului vor fi folosite. Ca si exemplu pot fi considerate selectiile care definesc randuri, coloane sau elemente individuale ce indeplinesc un anumit criteriu.

Commands este constituit din componentele ce definesc operatiile care pot fi efectuate asupra datelor, de exemplu operatii de stergere, salvare, modificare, etc.

View-ul este reprezentarea visuala a Model-ului si contine diferitele elemente de interfata folosite in cadrul aplicatiei.

Interactors reprezinta componentele care adreseaza modul in care interactiunile utilizatorului sunt mapate pe operatii efectuate asupra Model-ului, cum ar fi de exemplu input-urile de la tastatura, selectia unei optiuni dintr-un meniu, etc.

Elementul central il constituie Presenter-ul. Acesta este responsabil pentru a coordona interactiile dintre celelalte blocuri din cadrul aplicatiei. Printre atributiile lui se numara crearea celorlate blocuri conform necesitatilor si de a directiona fluxul de lucru in cadrul aplicatiei.

4.4 Functionarea

Principalele diferente de functionare dintre modelele TaligentMVP si MVC sunt localizate in cadrul Presenters si Interactors.

Presenter-ul este componenta care supervizeaza un subsitem particular din cadrul unei aplicatii. Este responsabil de mentinerea cicluilui de viata si a relatiilor dintre Views, Interactors, Commands, Selection si Model. Responsabilitatea interceptarii evenimentelor generate de utilizator revine in totalitate componentei Interactors si din aceasta cauza, de exemplu, nu este necesar un Presenter pentru fiecare widget din cadrul unui View, spre deosebire de modelul MVC din cadrul Smalltalk-80, unde un Controller era necesar. In general este suficient un singur Presenter pentru un singur View.

Componenta Interactors este analogul Controller-ului din modelul MVC implementat in Smalltalk-80, in sensul ca ea raspunde evenimentelor generate de utilizator si apeleaza componentele Commands si Selections necesare.

In anul 2006, Martin Fowler a propus divizarea modelului Model-View-Presenter in doua componente numite Supervising Controller si Passive View. Aceasta distinctie a fost justificata pe baza responsabilitatilor pe care pe care componenta Presenter/Controller o are in stratul de prezentare.

Modelul Supervising Controller

5.1 Generalitati

Modelul Supervizing Controller separa preocuparile prezentarii si logicii de prezentare in componentele specializate View si Controller, in care View-ul este responsabil de logica simpla de prezentare, iar Controller-ul de logica de prezentare complexa si de a raspude la imput-ul utilizatorului.

5.2 Strucura

Fig. 4 (referinta bibliografie [8])

5.3 Componente

View-ul este componenta vizuala folosita in aplicatie, de exemplu widget-uri

Controller-ul este componenta ce proceseaza evenimentele generate de utilizatori si logica de prezentare complexa din aplicatie.

5.4 Functionare

In cadrul modelului Supervising Controller, pentru logica de prezentare simpla, View-ul foloseste tehnici de “data binding” si modelul Observer Pattern pentru a se actualiza singur cand apar modificari in aplicatie. Logica de prezentare complexa este procesata de catre Controller/Presenter.

Modelul Passive View

6.1 Generalitati

Modelul Passive View separa preocuparile legate de prezentare si logica de prezentare in componentele specializate View si Controller, unde Controller-ul este responsabil de logica de prezentare si de a raspunde evenimentelor generate de utilizator.

6.2 Structura

Fig. 5 (referinta bibliografie [8])

6.3 Componente

View-ul este componenta vizuala folosita in aplicatie, de exemplu widget-uri

Controller-ul este componenta ce proceseaza evenimentele generate de utilizatori si logica de prezentare din aplicatie.

6.4 Functionare

In cadrul modelului Passive View, View-ul depinde in totalitate de Controller pentru a se actualiza conform modificarilor din aplicatie si pentru logica de prezentare.

Controller-ul din acest model este mult mai apropiat de Controller-ul din MVC din perspectiva atributiilor sale si a modului in care interactioneaza cu celelalte componente.

Modelul Presentation-Abstraction-Control

7.1 Generalitati

Modelul Presentation-Abstraction-Control, este in esenta o arhitectura ce separa diferitele sarcini in cadrul unei ierarhii de componente ce colaboreaza una cu cealata, fiecare fiind constituita din 3 subcomponente: Presentation, Abstraction si Control. Modelul PAC cauta sa descompuna aplicatia intr-o ierarhie de abstractizari si sa obtina un framework consistent pentru construirea interfetelor cu utilizatorul la orice nivel de abstractizare in cadrul aplicatiei.

Modelul PAC a fost conceput de Joëlle Coutaz in 1987. Scopul acestui model a fost sa asigure un model pentru dezvoltarea de aplicatii interactive si sa acopere golul dintre modelele teoretice de interactiune om-computer si probleme practice in construirea interfetelor cu utilizatorii. Coutaz sustine ca modelul PAC are la baza modelul cognitiv al gandirii umane, in sensul ca mintea noastra nu percepe lumea in diferite straturi, ci ca o panza de ideei abstracte interconectate.

7.2 Structura

Modelul PAC este conceput ca o ierarhie, in care elementele colaboreaza intre ele, si sunt descrise de 3 componente: Abstraction, Control si Presentation.

Fig. 6 (referinta bibliografie [4])

7.3 Componente

Presentation este reprezentarea vizuala a unei abstractizari particulare din cadrul aplicatiei. Rolul acestei componente este de a defini cum va interactiona utilizatorul cu sistemul.

Abstraction reprezinta logica de functionare a domeniului din cadrul aplicatiei.

Control este componenta ce asigura consistenta dintre abstractiile din sistem si prezentarea lor catre utilizator, precum si comunicarea cu celelate componente Control din cadrul sistemului.

7.4 Functionarea

Conceptual, modelul Presentation-Abstraction-Control abordeaza organizarea unei aplicatii sub forma unei ierarhii de subsiteme spre deosebire de celelalte modele prezentate, ce realizau acest lucru prin separarea in mai multe straturi. Fiecare sistem din cadrul aplicatiei poate depinde de mai multe subsisteme sau de nici unul pentru a isi indeplinii functia. Prin organizarea ierarhica in subsiteme, ce sunt compuse din aceleasi componente PAC, intrgul sistem mentine acealasi model arhitectural.

Desi interactiunea dintre utilizator si aplicatia se realizeaza prin intermediul Presentation, interactiunea in cadrul elementelor modelului PAC se realizeaza exclusiv prin intermediul elementului Control. Acesta este responsabil de asigurarea legaturii dintre Presentation si Abstraction, de updatarea View-ului, accesarea Abstraction si interactiunea cu componentele asociate din ierarhie. Intre Presentation si Abstraction nu exista legatura directa in cadrul unui obiect PAC.

7.5 Modele derivate din PAC

Intre anii 1989-1995, Comisia Comunitatilor Europene a finantat doua proiecte de cercetare in domeniu interfelor om-computer, sub numele de Amodeus si Amodeus-2. Termenul de “Amodeus” este un acronim pentru “Assimilating Models of Designers, Users and Systems”. In cadrul Amodeus-2, un cercetator numit Laurance Nigay, sub supervizarea lui Joëlle Coutaz, a creat modelul PAC-Amodeus. Acest model imbina beneficiile unei abordari stratificate cu organizarea ierarhica introdusa de PAC.

Un alt model arhitectural este Hierarchical-Model-View-Controller(HMVC). Desi nu este derivat direct din PAC, este adesa asociat cu acest model datorita similaritatilor dintre ele. Modelul HMVC a fost prezentat prima data in anul 2000 si presupune organizarea ierarhica a triunghiurilor MVC. Desi aceasta organizare este similara cu PAC, componentele Model si View isi pastreaza aceleasi roluri si relatii intre ele ca si in MVC.

Bibliografie

http://stst.elia.pub.ro/

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

http://en.wikipedia.org/wiki/Presentation%E2%80%93abstraction%E2%80%93control

http://www.martinfowler.com/eaaDev/SupervisingPresenter.html

http://www.wildcrest.com/Potel/Portfolio/mvp.pdf

Professional ASP.NET MVC4- Jon Galloway, Phil Haack, Brad Wilson, K. Scott Allen

http://www.slideshare.net/omniapro/mvc-seminar-presantation

http://ro.wikipedia.org/wiki/Model-view-controller

http://en.wikipedia.org/wiki/Client%E2%80%93server_model#Client_and_server_roles