1. O documento descreve o modelo MVC (Model-View-Controller) como um padrão de projeto composto que utiliza os padrões Observer, Composite e Strategy. 2. O objetivo é definir as responsabilidades dos participantes do MVC e demonstrar como ocorrem suas relações. 3. Será realizado um estudo das componentes do MVC e uma simulação de um projeto utilizando esta metodologia através de uma linguagem orientada a objetos.

1. Anhanguera Educacional Ltda.
Correspondência/Contato
Alameda Maria Tereza, 4266
Valinhos, SP - CEP 13278-181
rc.ipade@aesapar.com
Coordenação
Instituto 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. 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)

3. (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. 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
Anuário da Produção de Iniciação Científica Discente • p. 1-10 (não alterar)

5. (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.
(não alterar) Anuário da Produção de Iniciação Científica Discente • p. 1-10

6. 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.
Anuário da Produção de Iniciação Científica Discente • p. 1-10 (não alterar)

7. (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.
(não alterar) Anuário da Produção de Iniciação Científica Discente • p. 1-10

8. 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.
Anuário da Produção de Iniciação Científica Discente • p. 1-10 (não alterar)

9. (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.
(não alterar) Anuário da Produção de Iniciação Científica Discente • p. 1-10

10. 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
Anuário da Produção de Iniciação Científica Discente • p. 1-10 (não alterar)

11. (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.
(não alterar) Anuário da Produção de Iniciação Científica Discente • p. 1-10