Entendendo a Tríade Model-View-Controller (MVC) Utilizando Padrões de Projeto de Software Orientado a Objetos

Anhanguera Educacional Ltda.

Correspondência/ContatoAlameda Maria Tereza, 4266Valinhos, SP - CEP [email protected]

CoordenaçãoInstituto de Pesquisas Aplicadas e Desenvolvimento Educacional - IPADE

Publicação: 13 de setembro de 2012

Trabalho realizado com o incentivo e fomento da Anhanguera Educacional

ANHANGUERA EDUCACIONAL

RESUMO

A proposta para este projeto de pesquisa é apresentar o modelo de desenvolvimento de software orientado a objetos denominado MVC (Model-View-Controller) como um padrão de projeto composto, utilizando os designs patterns Observer, Composite e Strategy. A utilização do modelo de desenvolvimento MVC no desenvolvimento de softwares, têm-se apresentado com uma ferramenta interessante quando se pensa em produtividade e padronização de metodologias aplicadas na elaboração de projetos de diversos portes. Seu objetivo é definir as responsabilidades de seus participantes e demostrar como ocorrem suas relações. Para o desenvolvimento, será realizado um levantamento bibliográfico, agregando as principais ideias apresentadas em livros e artigos publicados ao longo do tempo, resultando na melhor compreensão de sua arquitetura e definição das vantagens e desvantagens de sua aplicação. Este trabalho demonstrará as características desta metodologia primeiramente através de um estudo das componentes que formam o MVC e apresentará uma simulação da utilização e criação de um projeto utilizando esta metodologia através de uma linguagem de programação orientada a objetos.

Palavras-Chave – MVC; Padrões de Projeto; Engenharia de software; Análise de Sistemas; Programação.

1

ANUÁRIO DA PRODUÇÃO DE INICIAÇÃO CIENTÍFICA DISCENTE

Vol. 0, N. 0, Ano 2013

ENTENDENDO A TRÍADE MODEL-VIEW-CONTROLLER (MVC) UTILIZANDO PADRÕES DE PROJETO DE SOFTWARE ORIENTADO A OBJETOS

2 (não alterar)

1. INTRODUÇÃO

O paradigma MVC foi desenvolvido para construir interfaces gráficas em

Smalltalk por Trygve Reenskaug enquanto trabalhava na Xerox PARC.

Utilizado em diversas plataformas de desenvolvimento, este padrão de

desenvolvimento contribuiu para a criação de sistemas pioneiros que

marcaram historia como o Apple Lisa e Macintosh, além de contribuir para a

na evolução dos serviços baseadas na internet como o Twitter.

O MVC consiste em dividir o código do software em segmentos

funcionais para tornar a aplicação pronta para atender a mudanças de forma

rápida, realização de testes unitários e ampliações sem afetar o código já

pronto, mantendo o limite entre três camadas, o Modelo, a Visualização e o

Controlador.

Utilizando os padrões de projeto de software orientado a objetos,

podemos definir o MVC como um padrão composto, pois utiliza

simultaneamente os padrões Observer, Composite e Strategy, que estão

catalogados no livro “Design Patterns: Elements of Reusable Object-Oriented

Software”, escrito por Erich Gamma, Richard Helm, Ralph Johnson e John

Vlissides, a chamada “gangue os quatro”.

Este artigo está organizado em seções. A primeira seção é essa

introdução, a seção 2 apresenta os objetivos da pesquisa. A metodologia

utilizada na realização da pesquisa é apresentada na seção 3. As informações

relacionadas ao desenvolvimento da pesquisa como a revisão de literatura, o

problema abordado, a solução proposta e implementada são mostradas na

seção 4. A forma de abordar os experimentos, os resultados e as discussões

são descritos na seção 5. Por fim, as considerações finais estão são

apresentadas na seção 6.

2. OBJETIVO

Tendo em vista importância do MVC na engenharia de software e a dificuldade

de muitos programadores de compreender seu funcionamento ao se utilizar

uma abordagem superficial, este artigo tem como objetivo apresentá-lo como

um padrão de projeto de software orientado a objeto composto, agrupando os

padrões Observer, Composite e Strategy para a estruturação de suas

camadas, criando uma visão mais detalhada de cada participante e dos

relacionamentos do modelo.

Anuário da Produção de Iniciação Científica Discente • p. 1-10 (não alterar)

(não alterar) 3

3. METODOLOGIA

Para o desenvolvimento do trabalho proposto, a metodologia consiste em uma

pesquisa do tipo exploratória, realizando um levantamento bibliográfico por

meio de livros e artigos de autores famosos no meio do desenvolvimento de

software, como Eric Gamma, Trygve Reenskaug, Eric Freeman e Harvey M.

Deitel. A pesquisa também se baseia na interpretação das idéias propostas

por estes pesquisadores, a fim de agrupá-las para resolução do mesmo

problema.

4. DESENVOLVIMENTO

O modelo MVC é constituído por três tipos de objetos, o modelo (Model) é a

razão da existência do aplicativo, armazenando toda lógica de negócios e

dados do sistema, a visão (View) é a representação do modelo gerando a

saída gráfica de forma adequada ao usuário, e o controlador (Controller), que

faz a mediação entre as camadas, interpretando a entrada de dados e

gerenciando o modelo e a visão.

Figura 1 – Diagrama do MVC

1.1. Padrões de Projeto

Também denominado Design Pattern, segundo Gamma (1995) “um padrão de

projeto de software nomeia, abstrai e identifica os aspectos-chave de uma

estrutura de projeto comum para torná-lo útil para a criação de um projeto

orientado a objetos reutilizável. O padrão de projeto identifica as classes e

instancias participantes, seus papeis, colaborações e as distribuição de

responsabilidades”.

Padrões são catalogados descrevendo:

(não alterar) Anuário da Produção de Iniciação Científica Discente • p. 1-10

4 (não alterar)

• Um nome como forma de referencia, descrevendo uma solução para

algum problema somente com algumas palavras;

• A explicação do problema, descrevendo o contexto em que o padrão

deve ser aplicado;

• Uma solução, demonstrando os componentes que formam sua

estrutura, seus relacionamentos e a divisão de responsabilidade;

• As consequências da aplicação do padrão, demonstrando suas

vantagens e desvantagens.

Padrões podem ser classificados em categorias, conforme usas

características. A classificação mais usada é dividi-los entre os que

determinam a forma como os objetos são criados (Padrões de criação), os que

definem as associações entre classes e objetos (Padrões estruturais), e os de

descrevem a divisão de responsabilidades (Padrões comportamentais).

1.2. Modelo e Observer

Os objetos modelos contem os dados e a lógica do aplicativo, como por

exemplo, as notas e o calculo da media de um aluno, métodos CRUD para

registros de um banco de dados, ou a lógica para executar um arquivo MP3.

Fornece uma interface para manipular e recuperar seu estado, estando

levemente ligado à visualização e o controlador.

Mesmo com a fraca acoplagem, o modelo deve notificar todos os

objetos que dependem de seu estado quando algum dado é alterado, sendo

por alguma modificação interna ou ação do usuário. É nesse contesto que o

padrão Observer é aplicado.

O Observer define uma dependência um-para-muitos entre objetos de

forma que, quando ocorre alguma alteração, todos os interessados são

notificados e atualizados automaticamente.

Figura 2 – Padrão de Projeto Observer


(não alterar) 5

Os objetos modelos, que são os únicos que podem acompanhar todas as

mudanças em seus atributos, se assemelham aos objetos observáveis

(Subject), mantendo um elo de comunicação de leve acoplamento criado pelo

método register, que tem como parâmetro os dependentes do estado do

modelo, os observadores, podendo ser visões e/ou controladores, bastando

implementar a interface correta (Observer). Para cada alteração, o método

notifyObservers chama o método update de cada observador, que deve obter

os dados de interesse através de uma referencia a interface do modelo e

utilizá-los da melhor maneira.

1.3. Visão e Composite

O padrão Composite compõe uma estrutura em arvore contendo tanto objetos

individuais como compostos de forma a criar uma hierarquia parte-todo,

permitindo o tratamento uniforme por parte do cliente para ambos os tipos de

objetos.

Os participantes do Composite são:

• Component: define uma interface comum para acessar e

gerenciar os integrantes da coleção e define um comportamento padrão a

todas as classes.

• Leaf: representa e definem o comportamento dos objetos

primitivos da composição, os que não têm filhos, também denominados

objetos-folha.

• Composite: representa e define o comportamento dos objetos

que armazenam os componentes filhos, são os nós que tem filhos.

• Client: manipulam objetos da composição utilizando a interface

Componente.


6 (não alterar)

Figura 3 – Padrão de Projeto Composite

É importante observar que a Folha herda os métodos acrescentar, remover e

recuperarFilho, o que não faz muito sentido, podendo ser criado uma exceção

ou um valor de retorno nulo para este caso.

Visões utilizam o Composite para a criação de interfaces gráficas para

o usuário, utilizando componentes, como painéis, quadros, caixa de textos,

rótulos, botões, entre outros, formando varias partes alinhadas, mas ao ser

exibida é interpretada como um todo. Ao ordenar que um componente

contêiner, por exemplo, um painel, seja exibido, ele cuidará da exibição dos

objetos de menor hierarquia, como os botões e caixa de textos.

1.4. Controlador e Strategy

A relação entre a visualização e o controlador utiliza o padrão Strategy, que

consiste em definir uma família de algoritmos e encapsulá-los, permitindo

assim que o algoritmo varie sem interferir na implementação dos clientes.

Este padrão é baseado em importantes princípios de POO, como

encapsular o que varia, dar preferência a composição invés da herança e a

programação para interfaces e não para implementações.


(não alterar) 7

Figura 4 – Padrão de Projeto Strategy

A visualização é o cliente do padrão Strategy, sendo responsável

apenas pela apresentação dos dados, delegando a responsabilidade de

interpretar as ações do usuário para o modelo a uma estratégia, o

controlador. Com esta estrutura, modelo e visão ficam desconectados, sendo

o controlador o intermédio entre as duas camadas. Também é possível

modificar o comportamento da visualização sem modificar seu código,

somente trocando a estratégia por outra da mesma família.

1.5. Aplicação

Para demonstrar a aplicação do MVC, foi desenvolvido um software em Java

que pode ser obtido pelo seguinte endereço <http://goo.gl/9jsMtv>. O

software consiste em um simples cadastro de contatos, para não fugir o

escopo deste artigo.

A aplicação utiliza a classe POJO Contato para representar os contatos

cadastrados no sistema.

Os modelos são definidos pela interface Model, onde são definidos os

métodos CRUD para gerenciar contatos. O modelos são:

• MemoryModel: Acesso a dados na memoria principal;

• FileModel: Acesso a dados em arquivo serializavel;

• MySqlModel: Acesso a dados em banco de dados MySQL.

Para demostrar o fraco acoplamento dos Modelos, o software permite

a troca do modelo utilizado em tempo de execução.


8 (não alterar)

Os modelos implementam um novo padrão de projeto, o Singleton.

Este padrão define que só uma instancia da classe correspondente exista na

aplicação.

São utilizadas três visões, CadastroForm para o cadastro e atualização

de contatos, ListForm e TextForm para a listagem de contatos, seguindo o

padrão observer para a atualização das mesmas.

Controladores são definidos pela interface Controller, definindo as

estratégias utilizadas pelas visões. Os controladores concretos são:

• SimpleController: Controlador simples com as estratégias

implementadas;

• ThreadController: Controlador com as mesmas funções de

SimpleController, com o adicional de utilizar múltiplas threads.

A escolha do controlador é definida ao iniciar a aplicação, sendo a sua criação

implementada pelo padrão de projeto Factory Method, onde é definido uma

interface para a instanciação do objeto, sendo as subclasses da fabrica que

definem qual objeto vai ser criado.

1.6. Android

O Android é a plataforma de softwares para dispositivos móveis desenvolvido

pela Google e pelo Open Handset Allicance (OHA). Baseada em Linux, oferece

um ambiente de desenvolvimento completo e inovador.

Ao criar projetos para Android, a lógica da aplicação pode ser

encapsulada em classe escritas utilizando a linguagem de programação Java,

aproveitando grande parte de seus recursos, se assemelhando ao

desenvolvimento de aplicativos desktop.

Arquivos no formato XML localizados no diretório layout do projeto são

utilizados para definirem a interface gráfica. Os componentes gráficos e

gerenciadores de layout são definidos por tags como, por exemplo,

<TextView>, <EditText> e <LinearLayout>. Cada tag corresponde a uma

subclasse de android.view.View. Há também a possibilidade de utilizar a API

Java para a criação das GUIs.


(não alterar) 9

Classes herdadas de android.app.Activity atuam como controladores da

aplicação, pois estas representam e gerenciam as telas da aplicação e

respondem aos eventos gerados pela interação do usuário.

1.7. Web

Com o aumento da complexidade das aplicações WEB, o MVC foi adaptado

para atuar no modelo browser/servidor, sendo umas das implementações mais

comum denominada Modelo 2. Utilizando tecnologias JSP, Servlets e

Enterprise JavaBeans(EJB) pertencentes a plataforma Java EE, tem como

objetivo a separação das camadas igualmente ao MVC convencional.

O Servlet atua como o controlador, recebendo a entradas de dados do

usuário através do envio de formulários HTTP e as interpretando a um EJB, que

atua como o modelo. Uma nova pagina JSP é devolvida ao browser, que pode

utilizar o JavaBean para a recuperação dos dados, formando a nova visão.

Embora não evidente, os padrões continuam a compor o padrão, mas

de forma adaptada. A visão, agora utilizando HTML para a criação de um

composto de componentes gráficos alinhados, deixou de ser um observador

clássico, não se registrando ao modelo, recebendo notificações de forma

indireta, através do controlador, que continua sendo uma estratégia, mas

utilizando os métodos HTTP GET e POST para obter a ação e dados os

enviados pelo do usuário.

Para apoiar a aplicação do MVC e outros padrões no desenvolvimento

de sistemas baseados em internet, foram criados os frameworks de aplicações

Web (do inglês web application frameworks ou WAP).

Segundo Schmidt et al. (2004) um framework é

“...um conjunto integrado de artefatos de software (como classes, objetos e componentes) que colaboram para fornecer uma arquitetura reusável para uma família de aplicações relacionadas” (Schmidt, 2004).

Java Serves Faces (JSP), Spring MVC e Apache Struts são exemplos de

WAPs baseados em Java EE. Outros exemplos para outras plataformas são o

ASP.NET MVC utilizado no .Net, Zend Framework implementado em PHP e o

Ruby on Rail’s.


10 (não alterar)

Para evitar código duplicado e facilitar a manutenção, geralmente

estes frameworks adicionam a sua estrutura um novo padrão de projeto não

GoF denominado Front Controller, assim todas as requisições do usuário são

recebidas por um único componente, centralizando processos que devem ser

realizados por toda as requisições.

5. RESULTADOS

Com base no levantamento bibliográfico realizado, foi possível observar como

os padrões de projeto Strategy, Observer e Composite trabalham de forma

conjunta para a criação do MVC.

Foi observada a possibilidade de se criar inúmeras visões para o

mesmo modelo sem alterá-lo, e ter a certeza que todos serão atualização

quando ocorrer alguma mudança, além de modificar como ela responde as

ações do usuário sem reescrevê-la, apenas criando um novo controlador.

Outra vantagem importante obtida é a portabilidade dos modelos,

podendo ser usados em outros sistemas, como aplicações Desktop, WEB ou

Mobile, não sendo necessário “reinventar a roda” a cada projeto, pois a

solução já existe, podendo ser reaproveitada. Modelos podem ser alterados

em tempo de execução, como por exemplo, uma aplicação que acessa um

banco de dados localmente pode mudar seu comportamento, passando a

trabalhar em rede, sem impacto ao restante do programa.

Uma desvantagem observada é o aumento da complexidade

desnecessária em pequenas aplicações, sendo recomendada a aplicação do

MVC apenas em sistemas de médio ou grande porte.

Por fim, foi constatado que o MVC pode usar outros padrões de projeto

para sua expansão, como o Factory Method para a criação de objetos, Adapter

para adaptar visões a controladores ou modelos, ou o Decorator para o

acréscimo de funções.

6. CONSIDERAÇÕES FINAIS

Com o estudo realizado, foi constatada a aplicabilidade dos padrões de projeto

de software orientado a objetos de forma conjunta para obter reusabilidade,

escalabilidade e atender a complexidade exigida das aplicações atuais. O MVC

é um desses casos, que em seu principio utiliza três desses padrões, mas


(não alterar) 11

sendo possível a utilização de outros para usa ampliação, dependendo os

estudos e habilidades do programador que o utilizar.

REFERÊNCIAS

BURBECK, Steve; Applications Programming in Smalltalk-80(TM): How to use Model-View-Controller (MVC); Disponível em: <http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html> . Acesso em: 06/01/2013.

DEITEL, Dr. Harvey M.; DEITEL, Paul J.; SANTRY, Sean E.. Advanced Java 2 Platform How to Program. New Jersey: Prentice Hall, 2001. 1496 p. (How to Program).

DEITEL, Harvey M.; DEITEL, Paul J.. Java - como programar. 6. ed. São Paulo: Pearse Education, 2005.

FREEMAN, Eric; FREEMAN, Elisabeth. Use a cabeça! padrões de projeto: Design Patterns. 2. ed. São Paulo: Alta Books, 2007.

GAMMA, Eric. et al. Padrões de projeto - soluções reutilizaveis de software orientado a objetos autor: gamma, erich. São Paulo: Bookman, 2000.

LECHETA, Ricardo R.. Google Android: Aprenda a criar aplicações para dispositivos móveis com o Android SDK. 3 ed. São Paulo: Novatec, 2013.

SIERRA, Kath; BASHAM, Brian. Use a cabeça! servlet e jsp. São Paulo: Alta Books, 2008.

SOMMERVILLE, Ian. Engenharia de Software. 9 ed. São Paulo: Person Hallm 2011.
