Padrões-05 - Padrões Arquiteturais - MVC

Padrões Arquiteturais

Sistemas Interativos: MVC

2 Livro Texto: Pattern Oriented Software Architecture - Buschmann

Eduardo N. F. Zagari

Sistemas Interativos

• Sistemas atuais apresentam alto grau de interação do usuário

• Desafio: independência do núcleo funcional (estável) da interface do usuário (adaptáveis) – MVC – PAC: hierarquia de agentes cooperantes.

Cada um deles é responsável por um aspecto da funcionalidade da aplicação.



Model-View-Controller

• Divide uma aplicação interativa em 3 componentes: – Model: contém o cerne da aplicação e os dados – View: mostra a informação para o usuário – Controller: trata a entrada do usuário

• Juntos, Views e Controllers fazem a interface com o usuário

• Deve haver um mecanismo de propagação de mudanças para assegurar a consistência entre a interface e o modelo



Exemplo



Contexto

• Aplicações interativas com uma interface homem-computador flexível



Problema • Sist. interativos são propensos a mundanças

– Dif. usuários colocam diferentes requisitos • Mesma informação pode ter que ser

apresentada de forma diferente em diferentes janelas

• A visualização e o comportamento da aplicação devem refletir imediatamente os dados manipulados

• Mudanças na interface devem ser fáceis e possivelmente em tempo de execução

• Suportar diferentes padrões de aparência não devem afetar o código do núcleo da aplicação



Solução

• MVC divide uma aplicação interativa em 3 áreas: processamento, saída e entrada – Componente MODEL: encapsula os dados do núcleo

da aplicação e sua funcionalidade – Componentes VIEW: mostra as informações para o

usuário. Obtém-nas do MODEL – Cada componente VIEW tem um componente

CONTROLLER associado • Recebem a entrada (usualmente eventos) • Eventos são traduzidos em requisições de serviços que são

enviadas para o MODEL ou para VIEW • O usuário interage com o sistema apenas através dos

CONTROLLERs



Solução

• Esta separação possibilita múltiplas visões do mesmo modelo

• Usuário modifica Model via Controller de um View – Model notifica todos os Views dependentes

destes dados – Views, por sua vez, recuperam dados do

Model e atualizam a informação para usuário



Estrutura

• Model – exporta procedimentos que realizam

processamento específico da aplicação • Controllers chamam estes procedimentos em

nome do usuário – Provê funções para acesso a seus dados

• Usadas pelos Views

– Usa mecanismo de propagação de mudanças • Views e Controllers se registram



Estrutura

• Views – Cada View define um procedimento de

atualização (ativado pelo mecanismo de propagação de mudanças)

– Uma vez notificado, obtém dados atuais e os atualiza na saída

– Cada View cria um Controller adequado (1:1) – Provê funcionalidades de manipulação da

saída ao Controller que não afetam o Model (p.ex., scrolling)



Estrutura

• Controller – Aceita entradas como eventos (depende da

plataforma da interface) – Eventos são traduzidos em requisições ao

Model ou ao correspondente View – Se o comportamento do Controller depende

do estado do Model • Controller se registra no mecanismo de

propagação de mudança e implementa um procedimento de atualização (ex., habilitar ou desabilitar um menu)



Estrutura



Dinâmica – Cenário 1 Entrada do usuário trigger MPM

*



Cenário 2 – Inicialização da tríade MVC



Implementação

class Model{ List<long> votes; List<String> parties; public : Model(List<String> partyNames);

// access interface for modification by controller

void clearVotes(); // set voting values to 0

void changeVote(String party, long vote);

/ / factory functions for view access to data

Iterator<long> makevoteIterator( ) { return Iterator<long> (votes); } Iterator<String> makePartyIterator( ) { return Iterator<String>(parties); }

// ... to be continued }

1. Separar a interface Homem-Máquina do núcleo funcional



Implementação

2. Implementar o mecanismo de propagação de mudança

• Padrão de Projeto Publisher-Subscriber • Estender Model para suportar o registro • Procedimento notificador do Model deve

chamar procedimento de update nos objetos Observer



Implementação class Observer { // common ancestor for view and controller public : virtual void update( ) { } // default is no-op } ;

class Model { // ... continued public : void attach(Observer *s) { registry.add (s) ; } void detach (Observer *s) { registry. remove (s) ; } protected : virtual void notify( ); private : Set<Observer*> registry; } ;



Implementação void Model::notify ( ) { // call update for all observers Iterator<Observer*> iter(registry) ; while (iter.next()) { iter.curr( )->update ( ); } }

- notify() é chamado pelos métodos clearVotes() e changeVote()



Implementação

3. Projetar e Implementar os Views • Especificar os proced. (draw) para mostrar o

componente na tela • Impl. proced. de update (re-draw) • Impl. proced. de inicialização (registro, setup

do Controller) class View : public Observer ( public: View (Model *m) : myModel (m) , mycontroller (0) { myModel ->attach(this) ; } virtual ~View ( ) ( myModel ->detach (this) ; } virtual void update ( ) { this->draw 0 ; }



Implementação // abstract interface to be redefined: virtual void initialize( ) ; // see below virtual void draw ( ) ; // (re-)display view Model *getModel( ) { return myModel; } Controller *getcontroller( ) { return mycontroller; } protected: Model *myModel ; Controller *myController; // set by initialize } ; class Barchartview : public View { public: BarChartView (Model *m) : View(m) { } virtual void draw( ) ; } ;



Implementação void BarChartView::draw ( ) { Iterator<String> ip = myModel->makePartyIterator(); Iterator<long> iv = myModel->makevoteIterator(); List<long> dl; //for scaling values to fill screen long max = 1; // maximum for adjustment

// calculate maximum vote count while (iv.next( )) { if (iv.curr( ) > max ) max = iv.curr( ); } iv.reset ( ) ;

// now calculate screen coordinates for bars while (iv.next( )) { dl.append((MAXBARS1ZE * iv.curr( ))/max); } // reuse iterator object for new collection: iv = dl; // assignment rebinds iterator to new list iv.reset ( ) ; while (ip.next( ) && iv.next( )) { // draw text: cout << ip.curr 0 << " : " ; // draw bar: ... drawbox(BARWIDTH, iv.curr0) ;... }



Implementação

4. Projete e implemente os Controllers



Implementação

5. Projete e implemente o relacionamento View-Controller

– Tipicamente, cada View tem o seu Controller – Para criar uma hierarquia de classes, usa-se

o Padrão Factory. • Define-se um makecontroller() nas classes View,

para que as subclasses View possam redefinir seus Controllers redefinindo o método Factory



Implementação



Implementação

6. Implementar o set-up do MVC



Implementação

7. Criação (gerência) dinâmica de Views 8. Controllers plugáveis

• Diferentes controllers para um View (expert versus iniciante ou diferentes dispositivos de entrada)

9. Infra-estrutura para View e Controllers hierárquicos



Variante

• Document-View – Relaxamento da separação entre View e

Controller – Ex.: X-Windows System



Benefícios

• Múltiplos Views do mesmo Model • Views sincronizados • Views e Controllers plugáveis • “Permutabilidade” do “look-and-feel”



Desvantagens

• Complexidade maior • Potencial para um número excessivo de updates • Conexão íntima entre View e Controller • Acoplamento de View e Controllers ao Model • Ineficiência no acesso de dados no View • Mudança inevitável do View e Controller quando

se porta a aplicação

Technology

Padrões-05 - Padrões Arquiteturais - MVC