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

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.

Transcript

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