Padrões-05 - Padrões Arquiteturais - MVC
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

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

on

  • 3,478 views

Padrões Arquiteturais. Sistemas Interativos. MVC.

Padrões Arquiteturais. Sistemas Interativos. MVC.

Statistics

Views

Total Views
3,478
Views on SlideShare
3,469
Embed Views
9

Actions

Likes
0
Downloads
138
Comments
0

1 Embed 9

http://www.slideshare.net 9

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Padrões-05 - Padrões Arquiteturais - MVC Presentation Transcript

  • 1. Padrões Arquiteturais Sistemas Interativos: MVC
  • 2. 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. 2 Livro Texto: Pattern Oriented Software Eduardo N. F. Zagari Architecture - Buschmann
  • 3. 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 3 Livro Texto: Pattern Oriented Software Eduardo N. F. Zagari Architecture - Buschmann
  • 4. Exemplo 4 Livro Texto: Pattern Oriented Software Eduardo N. F. Zagari Architecture - Buschmann
  • 5. Contexto •  Aplicações interativas com uma interface homem-computador flexível 5 Livro Texto: Pattern Oriented Software Eduardo N. F. Zagari Architecture - Buschmann
  • 6. 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 6 Livro Texto: Pattern Oriented Software Eduardo N. F. Zagari Architecture - Buschmann
  • 7. 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 7 Livro Texto: Pattern Oriented Software Eduardo N. F. Zagari Architecture - Buschmann
  • 8. 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 8 Livro Texto: Pattern Oriented Software Eduardo N. F. Zagari Architecture - Buschmann
  • 9. 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 9 Livro Texto: Pattern Oriented Software Eduardo N. F. Zagari Architecture - Buschmann
  • 10. 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) 10 Livro Texto: Pattern Oriented Software Eduardo N. F. Zagari Architecture - Buschmann
  • 11. 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) 11 Livro Texto: Pattern Oriented Software Eduardo N. F. Zagari Architecture - Buschmann
  • 12. Estrutura 12 Livro Texto: Pattern Oriented Software Eduardo N. F. Zagari Architecture - Buschmann
  • 13. Dinâmica – Cenário 1 Entrada do usuário  trigger MPM * 13 Livro Texto: Pattern Oriented Software Eduardo N. F. Zagari Architecture - Buschmann
  • 14. Cenário 2 – Inicialização da tríade MVC 14 Livro Texto: Pattern Oriented Software Eduardo N. F. Zagari Architecture - Buschmann
  • 15. Implementação 1.  Separar a interface Homem-Máquina do núcleo funcional class Model{ / / factory functions for view access to data List<long> votes; Iterator<long> makevoteIterator( ) { List<String> parties; return Iterator<long> (votes); public : } Model(List<String> partyNames); Iterator<String> makePartyIterator( ) { // access interface for modification by controller return Iterator<String>(parties); void clearVotes(); // set voting } values to 0 void changeVote(String // ... to be continued party, long vote); } 15 Livro Texto: Pattern Oriented Software Eduardo N. F. Zagari Architecture - Buschmann
  • 16. 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 16 Livro Texto: Pattern Oriented Software Eduardo N. F. Zagari Architecture - Buschmann
  • 17. 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; }; 17 Livro Texto: Pattern Oriented Software Eduardo N. F. Zagari Architecture - Buschmann
  • 18. 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() 18 Livro Texto: Pattern Oriented Software Eduardo N. F. Zagari Architecture - Buschmann
  • 19. 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 ; } 19 Livro Texto: Pattern Oriented Software Eduardo N. F. Zagari Architecture - Buschmann
  • 20. 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( ) ; }; 20 Livro Texto: Pattern Oriented Software Eduardo N. F. Zagari Architecture - Buschmann
  • 21. 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) ;... } 21 Livro Texto: Pattern Oriented Software Eduardo N. F. Zagari Architecture - Buschmann
  • 22. Implementação 4.  Projete e implemente os Controllers 22 Livro Texto: Pattern Oriented Software Eduardo N. F. Zagari Architecture - Buschmann
  • 23. 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 23 Livro Texto: Pattern Oriented Software Eduardo N. F. Zagari Architecture - Buschmann
  • 24. Implementação 24 Livro Texto: Pattern Oriented Software Eduardo N. F. Zagari Architecture - Buschmann
  • 25. Implementação 6.  Implementar o set-up do MVC 25 Livro Texto: Pattern Oriented Software Eduardo N. F. Zagari Architecture - Buschmann
  • 26. 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 26 Livro Texto: Pattern Oriented Software Eduardo N. F. Zagari Architecture - Buschmann
  • 27. Variante •  Document-View – Relaxamento da separação entre View e Controller – Ex.: X-Windows System 27 Livro Texto: Pattern Oriented Software Eduardo N. F. Zagari Architecture - Buschmann
  • 28. Benefícios •  Múltiplos Views do mesmo Model •  Views sincronizados •  Views e Controllers plugáveis •  “Permutabilidade” do “look-and-feel” 28 Livro Texto: Pattern Oriented Software Eduardo N. F. Zagari Architecture - Buschmann
  • 29. 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 29 Livro Texto: Pattern Oriented Software Eduardo N. F. Zagari Architecture - Buschmann