FERNANDO ANTONIO BARBEIRO CAMPOS
     LEONARDO BALDUINO SANTUCI




ESTUDO DE APLICABILIDADE DO PADRÃO MVC




           ...
FERNANDO ANTONIO BARBEIRO CAMPOS
                         LEONARDO BALDUINO SANTUCI




                   ESTUDO DE APLIC...
DEDICO este trabalho aos meus pais, Maria Aparecida e Reinaldo,
pela educação, afeto, ensinamentos e por acreditarem
incon...
DEDICO este estudo aos meus pais, Benvindo e Celma, pelo amor
sem medida, pela educação e ensinamentos que muito me auxili...
AGRADEÇO primeiramente a Deus, por ter proporcionado saúde,
paz e sabedoria;
ao nosso orientador e amigo Daniel Facciolo P...
AGRADEÇO à Deus pela possibilidade de estar realizando mais esta
etapa em minha vida;
à todo o corpo docente da Universida...
Divide as dificuldades que tenhas de examinar em tantas partes
quantas for possível, para uma melhor solução.
            ...
RESUMO



CAMPOS, Fernando Antonio Barbeiro; SANTUCI, Leonardo Balduino. Estudo de
aplicabilidade do padrão MVC. 2009. 111...
ABSTRACT



CAMPOS, Fernando Antonio Barbeiro; SANTUCI, Leonardo Balduino. Estudo de
aplicabilidade do padrão MVC. 2009. 1...
LISTA DE ABREVIATURAS



MVC      Model-View-Controller

JEE      Java Enterprise Edition

CRM      Customer Relationship ...
XML     Linguagem de Marcação Extensível

API     Interface de Programação de Aplicativos

AOP     Programação Orientada a...
LISTA DE FIGURAS



Figura 1 –    Padrão MVC aplicado para GUI e tecnologias
              Servlet/JSP.                   ...
Figura 20 –   Tela inicial (usuário de perfil administrador).     76

Figura 21 –   Tela de cadastro de relatos (acessível...
SUMÁRIO



INTRODUÇÃO .......................................................................................................
2.6.2     Componentes .......................................................................................................
4.9           DESENVOLVIMENTO DO APLICATIVO CRM MOBILE ............................ 89
4.9.1         Pacote br.crm.mobile....
13




                                     INTRODUÇÃO



                O uso de softwares para atender as mais variadas...
14



              Nesse cenário, o padrão MVC tornou-se amplamente adotado para divisão de
sistemas em diversos componen...
15



(JSE, JME e JEE), fazendo-se necessário o uso de frameworks e pacotes, como JSF (Java
Server Faces) e Swing.
       ...
16




1 PADRÕES DE PROJETO




1.1 CONSIDERAÇÕES INICIAIS




               Este capítulo demonstra os padrões de projet...
17



                      permite que as pessoas envolvidas no desenvolvimento tenham
                      facilidade e...
18



               Entende-se que, ao adotar um padrão para a resolução de um determinado
problema, está se utilizando u...
19




1.4.1   Arquitetura de camadas



              Segundo Bond et al. (2003) o processo evolutivo das aplicações pass...
20



                     •   Podem ocorrer situações onde o fornecedor, apesar de possuir um
                         có...
21



1.4.2   Programação Orientada a Objetos




               O paradigma da orientação a objetos tenta modelar os elem...
22



               A adoção de padrões não se dá somente na implementação. De acordo com os
pensamentos de Shalloway e T...
23



vezes um trecho é fortemente acoplado em outro dependendo de heranças e outras estruturas
da programação.
          ...
24



Decorator que podem ser usados em casos onde, por exemplo, um objeto deve mascarar outro
objeto ou um subsistema; cr...
25




2   MVC (MODEL-VIEW-CONTROLLER)



2.1 CONSIDERAÇÕES INICIAIS



               O MVC (Model-View-Controller) é um ...
26



               Após longas conversas, principalmente com Adele Goldberg, o termo Model-
View-Controller foi aderido ...
27



tendências atuais fazem o padrão ser normalmente empregado em projetos baseados na web,
onde a solução é dividida da...
28



              Há projetos que são extremamente modestos e que, muitas vezes, resumem-se
em poucos formulários que se...
29




       Figura 2 – Exemplo de um modelo representado por diferentes views (visões).
       Fonte: GAMMA et al, 2000,...
30



              Este esquema ilustra uma aplicação onde o modelo é acessado utilizando
diversas visões que podem ser i...
31



              Como a separação de componentes é a característica fundamental do padrão,
cabe explicar que essa divis...
32



Contudo, como se exige um alto grau de reusabilidade destes componentes, adotou-se a
utilização do controlador para ...
33



                De acordo com Reenskaug (1979), definindo o que é o model, ele representa
conhecimento, e pode ser u...
34




               A visão é o componente da arquitetura MVC que é responsável pela
apresentação, é a interface de repr...
35



                Pode ser considerado como a fronteira entre os outros dois componentes do
MVC e sua finalidade é con...
36



              Assim, frameworks são conjuntos de classes que fornecem recursos e a
estrutura necessária para a resol...
37



                 A imagem demonstra bastante a idealização do que se trata um framework,
como pode ser observado, el...
38



               O Struts atua como um Front-Controller, padrão onde, para Basham, Sierra e
Bates (2005), “todas as so...
39



de computação no instituto de matemática e estatística da própria universidade. Com o tempo,
pessoas de todo o mundo...
40




Figura 7 – Visão geral do framework Spring.
Fonte: Developersbook, 2008.


              Como cada quadro represent...
41



   •    Módulo de contexto do Spring: trata-se de um arquivo de configuração que inclui
        serviços como JNDI (...
42



               Indo além nesta abstração, as ações que o programador define não ficam
dependentes do ambiente web; d...
43



              Embora seja focado na construção de componentes para interface, o JSF
implementa o padrão MVC como um ...
44




               Quando uma requisição é feita, o FacesServlet, que deve ser configurado no
arquivo web.xml da aplica...
45



JSF devem estar contidas dentro da tag <f:view> que se inicia na linha 4 e termina na linha
30. Na linha 9 é iniciad...
46


   4 -         "http://java.sun.com/dtd/web-facesconfig_1_0.dtd">
   5 -
   6 -            <!--configuração das regra...
47


14   -          </h3>
15   -       </h:form>
16   -   </body>
17   -   </f:view>
18   -   </html>
                   ...
48



particular pode selecionar qual a solução se aplicará melhor dentro das suas necessidades do
domínio.
              ...
49



portabilidade. Facilitam a interação da plataforma JEE com outros sistemas, como base de
dados e sistemas legados.

...
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Estudo De Aplicabilidade Do PadrãO Mvc   Fernando & Leonardo
Upcoming SlideShare
Loading in...5
×

Estudo De Aplicabilidade Do PadrãO Mvc Fernando & Leonardo

8,649

Published on

Estudo de aplicabilidade do padrão MVC que demonstra sua eficiência e um caso de uso com sua aplicação. No caso de uso é definido que o sistema deve ser acessível por dispositivos móveis, desktop e pela web.

Published in: Technology, Education
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
8,649
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
497
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Transcript of "Estudo De Aplicabilidade Do PadrãO Mvc Fernando & Leonardo"

  1. 1. FERNANDO ANTONIO BARBEIRO CAMPOS LEONARDO BALDUINO SANTUCI ESTUDO DE APLICABILIDADE DO PADRÃO MVC Trabalho de Conclusão de Curso apresentado como exigência parcial, para a obtenção do grau no curso de Ciência da Computação, da Universidade de Franca. Orientador: Prof. Dr. Daniel Facciolo Pires FRANCA 2009
  2. 2. FERNANDO ANTONIO BARBEIRO CAMPOS LEONARDO BALDUINO SANTUCI ESTUDO DE APLICABILIDADE DO PADRÃO MVC Orientador: Nome: Prof. Dr. Daniel Facciolo Pires Instituição: Universidade de Franca. Examinador(a): Nome: Instituição: Examinador(a): Nome: Instituição: Franca, _____/ _____ / _____
  3. 3. DEDICO este trabalho aos meus pais, Maria Aparecida e Reinaldo, pela educação, afeto, ensinamentos e por acreditarem incondicionalmente em meus sonhos; à minha tia Marinda e minha avó Palmira por terem sempre me acolhido como filho; à minha namorada Lidiane, pelo amor, atenção e compreensão em todos os momentos.
  4. 4. DEDICO este estudo aos meus pais, Benvindo e Celma, pelo amor sem medida, pela educação e ensinamentos que muito me auxiliaram dando-me base necessária para vencer esta e todas as etapas que estão por vir; às minhas irmãs, Érica e Lívia, pela amizade e apoio; à minha namorada Bruna, pelo amor e companheirismo.
  5. 5. AGRADEÇO primeiramente a Deus, por ter proporcionado saúde, paz e sabedoria; ao nosso orientador e amigo Daniel Facciolo Pires pela dedicação, paciência e, sobretudo, por ter nos amparado com seu profundo conhecimento durante todo o estudo; A Universidade de Franca, englobando todo corpo docente do curso de Ciência da Computação, todas as pessoas do Centro Discente de Informática e todos os colaboradores em geral; aos meus amigos e colegas pelos excelentes e indispensáveis momentos de descontração e apoio; a todos que contribuíram de forma direta ou indireta para a realização deste trabalho.
  6. 6. AGRADEÇO à Deus pela possibilidade de estar realizando mais esta etapa em minha vida; à todo o corpo docente da Universidade de Franca, por todo o conhecimento compartilhado, em especial ao nosso orientador Daniel Facciolo Pires pelo total apoio, não apenas neste trabalho, mas em todos os passos que nos trouxeram até aqui; à toda minha família, em especial à minha mãe pelo amor e suporte que possibilitou e motivou a superação de mais esta etapa; à minha namorada pelo amor, companheirismo e compreensão.
  7. 7. Divide as dificuldades que tenhas de examinar em tantas partes quantas for possível, para uma melhor solução. René Descartes
  8. 8. RESUMO CAMPOS, Fernando Antonio Barbeiro; SANTUCI, Leonardo Balduino. Estudo de aplicabilidade do padrão MVC. 2009. 111 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) – Universidade de Franca, Franca. Este trabalho propõe uma pesquisa sobre padrões de projeto, com ênfase no padrão MVC. Inicialmente, foi realizado um levantamento bibliográfico para a obtenção de conhecimento sobre todos os aspectos que envolvem os conceitos e utilização de padrões de projeto, a partir disto, são estudados frameworks e a plataforma JEE. Em busca de soluções para as necessidades dos clientes de software (ressaltando disponibilidade e os requisitos altamente mutáveis) e como prova de conceito da pesquisa, é definido como estudo de caso um sistema baseado nos requisitos de um CRM (Customer Relationship Management) operacional que deve possuir suas funcionalidades disponíveis através de diferentes dispositivos: web, desktop e mobile. Em seguida, o software foi implementado em Java (JSE, JME e JEE) a partir do ambiente de desenvolvimento Netbeans 6.5.1, seguindo a modelagem de dados definida pela UML e fazendo uso do SGBD MySQL como dispositivo de armazenamento de dados. O resultado foi uma aplicação melhor construída e comprovadamente mais fácil de manter e expandir, que demonstra de forma eficaz o uso do padrão MVC. A partir de uma mesma camada de modelo, foram desenvolvidos os três diferentes aplicativos definidos, onde o aplicativo voltado para web é o que contém a maior parte das funcionalidades. O produto obtido apresentou melhor qualidade, sendo que esta característica esteve envolvida em todas as etapas de desenvolvimento. Palavras-chave: Model-View-Controller, Padrões de Projeto, JAVA EE.
  9. 9. ABSTRACT CAMPOS, Fernando Antonio Barbeiro; SANTUCI, Leonardo Balduino. Estudo de aplicabilidade do padrão MVC. 2009. 111 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) – Universidade de Franca, Franca. This paper proposes a research about design patterns, with emphasis on the MVC pattern. Initially, had been performed a literature review to obtain knowledge of all aspects that involves the concepts and use of the design patterns, then frameworks and JEE platform were studied. In searching for solutions to the needs of software customers (emphasizing availability and highly changeable conditions) and as proof of concept research, a case of study about a system was defined based on the requirements of a CRM (Customer Relationship Management) operational that must have available functionalities through different devices: web, desktop and mobile. Then, the software was implemented in Java (JSE, JEE, and JME) from the development environment Netbeans 6.5.1, following the modeling data defined by UML and using the MySQL DBMS as a storage device data. The result was a better built application, easier to maintain and expand that effectively demonstrates the use of the MVC pattern. From a single layer model, had been developed the three different defined applications, where the web application-oriented contains the most features. The product showed better quality, and this characteristic had been involved in all stages of the development. Key words: Model-View-Controller, Design Patterns, JAVA EE.
  10. 10. LISTA DE ABREVIATURAS MVC Model-View-Controller JEE Java Enterprise Edition CRM Customer Relationship Management JSE Java Standard Edition JME Java Micro Edition UML Linguagem de Modelagem Unificada JSF Java Server Faces GUI Interface Gráfica dos Usuários JSP Java Server Pages IDE Integrated Development Environment SGBD Sistema Gerenciador de Base de Dados JDK Java Development Kit OOPSLA Object-Oriented Programming, Systems, Languages, and Applications GoF Gang of Four ORM Mapeamento Objeto-Relacional DAO Objeto de Acesso a Dados HTML Linguagem de Marcação de Hipertexto ASP Active Server Pages PHP Personal Home Page HTTP Protocolo de Transferência de Hipertexto ASF Apache Software Foundation
  11. 11. XML Linguagem de Marcação Extensível API Interface de Programação de Aplicativos AOP Programação Orientada a Aspectos EJB Enterprise JavaBeans JDO Java Data Objects JDBC Java DataBase Connectivity JNDI Java Naming and Directory Information AJAX Asynchronous JavaScript and XHTML PDF Portable Document Format XSTL Extensible Stylesheet Language Transformation UI Interface do Usuário POJO Plain Old Java Object JCP Java Community Process CORBA Common Object Request Broker Architecture EIS Enterprise Information System B2B Business-to-Business LAMP Linux, Apache, Mysql e PHP LADP Linux, Apache, Database e PHP CRUD Create, Retrieve, Update and Delete SQL Structured Query Language SOAP Simple Object Access Protocol WSDL Web Service Description Language URL Universal Resource Location
  12. 12. LISTA DE FIGURAS Figura 1 – Padrão MVC aplicado para GUI e tecnologias Servlet/JSP. 27 Figura 2 – Exemplo de um modelo representado por diferentes views (visões). 29 Figura 3 – Esquema de uma aplicação que deve suportar diversos tipos de usuários e interfaces. 29 Figura 4 – Versão tradicional do MVC. 31 Figura 5 – Versão do MVC web (MVC Model2). 32 Figura 6 – Aplicação desenvolvida com uso de um framework. 36 Figura 7 – Visão geral do framework Spring. 40 Figura 8 – Arquitetura JSF baseada no modelo MVC. 43 Figura 9 – Contêiner JEE. 49 Figura 10 – Diagrama de casos de uso. 61 Figura 11 – Diagrama de classes. 62 Figura 12 – Diagrama de componentes. 63 Figura 13 – Diagrama de entidade-relacionamento. 64 Figura 14 – Representação do CRM_Library (camada modelo). 67 Figura 15 – Utilização do modelo nos outros projetos. 70 Figura 16 – Representação do CRM_Web (camadas de controle e visão). 72 Figura 17 – Aplicativo em execução (tela de login). 74 Figura 18 – Tela inicial (usuário de perfil auxiliar). 75 Figura 19 – Tela inicial (usuário de perfil intermediário). 75
  13. 13. Figura 20 – Tela inicial (usuário de perfil administrador). 76 Figura 21 – Tela de cadastro de relatos (acessível por qualquer perfil). 77 Figura 22 – Visualização de relatos (acessível por qualquer perfil). 79 Figura 23 – Tela de envio de mensagens (acessível por perfil intermediário ou superior). 80 Figura 24 – Visualização de mensagens (acessível por perfil intermediário ou superior). 80 Figura 25 – Tela de cadastro de cobranças (acessível por perfil administrador). 81 Figura 26 – Visualização de cadastro de cobranças (acessível por perfil administrador). 81 Figura 27 – Classes do projeto CRM_Desktop. 82 Figura 28 – Desenvolvimento de janela com o NetBeans. 83 Figura 29 – Tela de login do aplicativo desktop. 84 Figura 30 – Tela principal aplicativo desktop. 85 Figura 31 – Botões de navegação entre os registros. 86 Figura 32 – Edição de registro de usuário. 86 Figura 33 – Exclusão de registro de usuário. 87 Figura 34 – Classe web service. 88 Figura 35 – Teste de um serviço web. 89 Figura 36 – Representação do CRM_Mobile. 90 Figura 37 – Criação de um cliente de serviços web em Java ME. 91 Figura 38 – Execução do CRM_Mobile. 93 Figura 39 – Tela de busca. 94 Figura 40 – Confirmar conexão com web service. 94 Figura 41 – Busca efetuada com sucesso. 95
  14. 14. SUMÁRIO INTRODUÇÃO .................................................................................................................. 13 1 PADRÕES DE PROJETO ................................................................................ 16 1.1 CONSIDERAÇÕES INICIAIS ............................................................................ 16 1.2 DEFINIÇÃO ........................................................................................................ 16 1.3 ORIGEM .............................................................................................................. 17 1.4 EVOLUÇÃO ........................................................................................................ 18 1.4.1 Arquitetura de Camadas ....................................................................................... 19 1.4.2 Programação Orientada a Objetos ........................................................................ 21 1.5 REUTILIZAÇÃO ................................................................................................ 22 1.6 CLASSIFICAÇÃO .............................................................................................. 23 1.7 CONSIDERAÇÕES FINAIS ............................................................................... 24 2 MVC (MODEL-VIEW-CONTROLLER) ....................................................... 25 2.1 CONSIDERAÇÕES INICIAIS ............................................................................ 25 2.2 SURGIMENTO ................................................................................................... 25 2.3 APLICAÇÃO ....................................................................................................... 26 2.3.1 Vantagens e Desvantagens ................................................................................... 27 2.4 COMPONENTES DO PADRÃO MVC .............................................................. 30 2.4.1 Modelo (Model) ................................................................................................... 32 2.4.2 Visão (View) ........................................................................................................ 33 2.4.3 Controlador (Controller) ...................................................................................... 34 2.5 FRAMEWORKS ................................................................................................. 35 2.5.1 Struts .................................................................................................................... 37 2.5.2 VRaptor ................................................................................................................ 38 2.5.3 Spring ................................................................................................................... 39 2.5.4 WebWork ............................................................................................................. 41 2.5.5 JSF (Java Server Faces) ....................................................................................... 42 2.6 JEE (JAVA ENTERPRISE EDITION) ............................................................... 47 2.6.1 Arquitetura ........................................................................................................... 48
  15. 15. 2.6.2 Componentes ........................................................................................................ 50 2.6.2.1 Implementação de Componentes Web ................................................................. 51 2.6.2.2 Implementação de Componentes de Negócio ...................................................... 54 2.6.3 Comparativo com outras tecnologias ................................................................... 53 2.7 CONSIDERAÇÕES FINAIS ............................................................................... 56 3 ESTUDO DE CASO ........................................................................................... 57 3.1 CONSIDERAÇÕES INICIAIS ............................................................................ 57 3.2 MODELAGEM DO PROJETO ........................................................................... 57 3.2.1 Descrição narrativa do sistema ............................................................................ 58 3.2.2 Especificação dos requisitos do sistema .............................................................. 59 3.2.3 Diagrama de casos de uso do sistema .................................................................. 60 3.2.4 Diagrama de classes ............................................................................................. 62 3.2.5 Diagrama de componentes ................................................................................... 62 3.2.6 Diagrama de entidade-relacionamento ................................................................. 64 3.3 CONSIDERAÇÕES FINAIS ............................................................................... 64 4 IMPLEMENTAÇÃO DO ESTUDO DE CASO .............................................. 66 4.1 CONSIDERAÇÕES INICIAIS ............................................................................ 66 4.2 DESENVOLVIMENTO DA CAMADA MODELO CRM LIBRARY .............. 66 4.2.1 Pacote br.crm.model.entities ................................................................................ 68 4.2.2 Pacote br.crm.model.dao ...................................................................................... 68 4.2.3 Pacote br.crm.model.dao.implementation ............................................................ 69 4.2.4 Conceitos da utilização do modelo na aplicação ................................................. 70 4.3 DESENVOLVIMENTO DO APLICATIVO CRM WEB.................................... 70 4.3.1 Pacote br.crm.web.controller ............................................................................... 72 4.3.2 Pacote br.crm.web.phaselistener .......................................................................... 73 4.3.3 Implementação da visão do sistema ..................................................................... 74 4.4 EXECUÇÃO DO APLICATIVO CRM WEB .................................................... 74 4.4.1 Funcionalidades disponíveis para o perfil Auxiliar ............................................. 76 4.4.2 Funcionalidades disponíveis para o perfil Intermediário ..................................... 79 4.4.3 Funcionalidades disponíveis para o perfil Administrador ................................... 80 4.5 DESENVOLVIMENTO DO APLICATIVO CRM DESKTOP ......................... 82 4.6 EXECUÇÃO DO APLICATIVO CRM DESKTOP ........................................... 84 4.7 DESENVOLVIMENTO DO WEB SERVICE MOBILE WS ............................ 87 4.8 EXECUÇÃO DE TESTES DO WEB SERVICE ................................................ 89
  16. 16. 4.9 DESENVOLVIMENTO DO APLICATIVO CRM MOBILE ............................ 89 4.9.1 Pacote br.crm.mobile.controller.ws ..................................................................... 90 4.9.2 Pacote br.crm.mobile.view ................................................................................... 92 4.10 EXECUÇÃO DO APLICATIVO CRM MOBILE .............................................. 92 4.11 CONSIDERAÇÕES FINAIS ............................................................................... 95 CONCLUSÃO ..................................................................................................................... 96 REFERÊNCIAS ................................................................................................................. 98 GLOSSÁRIO ..................................................................................................................... 102
  17. 17. 13 INTRODUÇÃO O uso de softwares para atender as mais variadas necessidades cotidianas de pessoas e organizações é algo já consolidado, mas ainda crescente. Com a importância e tendência corrente que os softwares possuem na gestão de informações e auxílio na tomada de decisões estratégicas, estes não poderiam ser produtos construídos sem a adoção de metodologias que garantam um padrão de qualidade e o total atendimento dos requisitos presentes e futuros dos usuários. Além disto, o desejo pela chamada computação ubíqua, que se pode entender por “computação em qualquer lugar”, impulsiona o desenvolvimento de aplicações amigáveis para web, o que acarreta na maior incidência de servidores de aplicativos, provedores de serviços e constante aprimoramento e evolução no que diz respeito a construção de aplicativos em n camadas, Assim, o panorama é que as informações fiquem disponíveis em qualquer computador com acesso a internet, mas a evolução constante e o verdadeiro sentido da computação ubíqua levam as pessoas a pensarem em aplicações que rodem em qualquer dispositivo, seja ele um computador pessoal, notebook ou qualquer dispositivo móvel que uma pessoa possa levar consigo. Acrescenta-se ainda as características de alta mutação no requisitos de usuários, ou seja, por melhor que seja definida a especificação de requisitos, os mesmo mudam constantemente de acordo com necessidades diferenciadas da empresa e dos usuários deste software. Neste contexto, os padrões de projeto são cada vez mais tratados com naturalidade em projetos diversificados. Seguir práticas que deram certo e foram bem- sucedidas, significa não necessitar reinventar soluções para um domínio de problema já observado. Também o conceito de desenvolvimento em camadas citado, resultado de uma evolução histórica no desenvolvimento de softwares, é implementado pelo MVC, que divide os componentes de um sistema em Model (Modelo), View (Visão) e Controller (Controle), deixando-o mais modularizado e fracamente acoplado.
  18. 18. 14 Nesse cenário, o padrão MVC tornou-se amplamente adotado para divisão de sistemas em diversos componentes, tal qual o nome sugere, onde cada componente tem suas funcionalidades específicas. Assim, atinge-se um projeto extremamente manutenível. Acresce-se a possibilidade de trabalhar paralelamente com equipes de desenvolvimento, cada qual criando soluções para uma camada distinta da aplicação. Esse método resulta em um software seguro, flexível, disponível (afinal, foi desenvolvido por especialistas em uma dada categoria do desenvolvimento) de forma muito mais ágil (várias equipes trabalham em um tempo mais reduzido) e que sempre atenda aos requisitos dos usuários. Portanto, trazer ciência e avaliar os padrões de projeto e como eles ajudam a atender as necessidades e desejos citados são extremamente importantes no processo de desenvolvimento de software. Como principal objetivo com este trabalho visa investigar, explorar e levar ao conhecimento os padrões de projeto, em especial o MVC, e como eles podem ser utilizados e combinados para resolver um problema sob um determinado domínio. Mais especificamente, é feito um estudo da aplicabilidade do padrão MVC no desenvolvimento de aplicações web com a plataforma JEE e frameworks que auxiliam nesta construção, por exemplo, Spring, VRaptor, Struts, WebWork e JSF (Java Server Faces) que é o utilizado no estudo de caso. Para demonstrar como é possível construir aplicações robustas, manuteníveis, expansíveis e acessíveis com o padrão MVC, desenvolve-se um estudo de caso baseado nos requisitos de um CRM (Customer Relationship Management) operacional. Neste estudo de caso, mostra-se que a partir de uma mesma camada de modelo de software, podem-se criar aplicativos para diferentes dispositivos, como desktop, web e dispositivos móveis. Inicialmente, toda a pesquisa é baseada em levantamento bibliográfico para obtenção da base de conhecimento necessária para desenvolver todo o conteúdo. Como estudo de caso, é definido um software fundamentado nos requisitos de um CRM (Customer Relationship Management) operacional que, com o auxílio da ferramenta JUDE e embasado na UML (Linguagem de Modelagem Unificada), teve definido sua especificação, análise e documentação do sistema. Completando a gama de ferramentas utilizadas, como dispositivo de armazenamento dos dados da aplicação foi adotado o SGDB (Sistema Gerenciador de Banco de Dados) MySQL e a implementação do software em si, foi apoiada pela ferramenta NetBeans IDE (Integrated Development Environment) em conjunto com o JDK (Java Development Kit). Logo, o projeto foi implementado sobre especificações da linguagem Java
  19. 19. 15 (JSE, JME e JEE), fazendo-se necessário o uso de frameworks e pacotes, como JSF (Java Server Faces) e Swing. Definidas essas características, faz-se necessário delinear a estruturação do trabalho. O mesmo divide-se em quatro capítulos, onde o primeiro abrange toda a parte de padrão de projetos em geral, desde o seu surgimento, até a motivação de seu uso, suas classificações, entre outros. O segundo capítulo trata uma visão minuciosa do padrão MVC em si, que é o foco de estudo da pesquisa. O terceiro capítulo traz consigo a definição do estudo de caso e a modelagem da solução proposta. Por fim, o último capítulo apresenta a implementação e resultados obtidos.
  20. 20. 16 1 PADRÕES DE PROJETO 1.1 CONSIDERAÇÕES INICIAIS Este capítulo demonstra os padrões de projeto, passando por seu contexto histórico e evolutivo de forma a descrever sua classificação, o progresso na construção de software e as melhorias que os padrões podem agregar aos projetos da atualidade. 1.2 DEFINIÇÃO Padrões de projeto no desenvolvimento de software, como citam Gamma et al. (2000), são como um gabarito que podem ser aplicados para diversas soluções, é importante notar que um padrão não é uma mera implementação pronta de um projeto específico orientado a objetos, mas sim uma definição abstrata que indica os métodos que devem ser seguidos alcançando um objetivo. Um erro comum de desenvolvedores sem experiência é tentar traçar um árduo caminho construindo uma aplicação por inteiro. Enquanto que projetistas experientes tomam por base sucessos em aplicações que já estão desenvolvidas para encaixar sua solução no novo domínio que está sendo tratado. Esse é um exemplo da utilização de padrões onde, a partir de uma boa documentação de software e gestão de atividades, os desenvolvedores podem reutilizar suas soluções em uma vasta gama de situações. Gamma et al. (2000) citam também que existem quatro elementos essenciais para definir um padrão de projeto, são eles: • Nome do padrão: O nome deve descrever de forma sucinta os objetivos, problemas em que o padrão se aplica, as soluções e as conseqüências de se aplicar tal padrão, ou seja, o nome deve fornecer uma visão geral do padrão com poucas palavras. O nome é de difícil definição pela importância que ele tem, contudo, definido o nome ele
  21. 21. 17 permite que as pessoas envolvidas no desenvolvimento tenham facilidade em debater as soluções propostas. • Problema: Descreve o contexto onde o padrão pode ser aplicado e pode conter uma pequena lista com condições que devem ser enquadradas para optar ou não pelo uso de tal padrão. • Solução: Algumas pessoas com pouca experiência no tema podem confundir-se com o termo solução. Ela não é uma implementação específica para um domínio em particular, até porque um tipo de solução pode ser aplicado em diferentes âmbitos. Entretanto, uma solução deve fornecer uma visão abstrata de como solucionar o problema e como organizar os elementos para essa resolução. • Conseqüências: Serve para aferir qual o custo-benefício de aplicar-se o padrão, avaliando se sua utilização favoreceu e engrandeceu o projeto, ou então se esta utilização foi onerosa para o mesmo. 1.3 ORIGEM O conceito dos padrões de projeto teve como pioneiro o arquiteto austríaco Christopher Alexander. Ele concebeu a idéia de documentar suas experiências em projetos de arquitetura e urbanismo na forma de padrões. Christopher buscou encontrar quais eram os pontos em comum entre os projetos considerados de alto nível, e documentar estes pontos, para que pudessem ser seguidos em projetos posteriores. Entre as décadas de 60 e 70, ele escreveu livros e artigos em universidades norte-americanas. Na obra “A Pattern Language: Towns, Buildings, Constructions” (ALEXANDER, 1977 apud GAMMA et al., 2000, p. 10), onde cita que: “cada padrão descreve um problema no nosso ambiente e o cerne de sua solução, de tal forma que se possa usar essa solução mais de um milhão de vezes, sem nunca fazê-lo da mesma maneira”. Essa citação, ainda que direcionada à arquitetura, é extremamente adequada aos padrões de projeto no desenvolvimento de software.
  22. 22. 18 Entende-se que, ao adotar um padrão para a resolução de um determinado problema, está se utilizando uma solução que já foi aplicada e possui uma eficiência comprovada. Alguns anos após os estudos do arquiteto, mais precisamente no ano de 1987, em uma conferência sobre programação orientada a objetos, a OOPSLA (Object-Oriented Programming, Systems, Languages, and Applications), os pesquisadores Kent Beck e Ward Cunningham apresentaram um conjunto reduzido de padrões para o desenvolvimento de software na linguagem Smalltalk, focando o uso em projetos com janelas. Posteriormente, na década de 90, Erich Gamma, em sua tese de doutorado, realizou estudos sobre padrões de projetos orientados a objetos visando à utilização de interfaces gráficas. Com isso, Erich aproximou-se a Richard Helm e mais tarde a Ralph Johnson e John Vlissides, formando assim a conhecida “gangue dos quatro” (Gang of Four) que é responsável pelo precursor e um dos principais livros do assunto, o “Design Patterns: Elements of Reusable Object-Oriented Software”, publicado em 1994. Tal livro é um verdadeiro catálogo sobre os padrões da época e traça suas características principais. Visando sanar as dificuldades comuns na criação de softwares orientados a objetos (desenvolver soluções reutilizáveis, de qualidade, de fácil manutenção e expansão), a Gangue dos Quatro escreveu este livro documentando e catalogando as melhores soluções que vinham sendo adotadas nos projetos orientados a objetos, porém, sem registros formais das soluções, o que implicava em uma redescoberta da solução sempre que se deparava com algum problema. Os padrões de projeto vieram para melhorar e aprimorar as vantagens dos projetos orientados a objetos. 1.4 EVOLUÇÃO O desenvolvimento de aplicações passou por grandes mudanças desde o surgimento dos primeiros programas de computador. As mudanças mais notórias fazem menção à troca de paradigmas, onde os algoritmos procedurais perderam espaço perante aos programas de orientação a objeto. Este fato sem dúvida trata-se de uma constante evolução de uma arquitetura em camadas, conforme descrito a seguir.
  23. 23. 19 1.4.1 Arquitetura de camadas Segundo Bond et al. (2003) o processo evolutivo das aplicações passa por modelos de camadas, sejam elas físicas ou lógicas, tendo em mente que camadas físicas tratam componentes e equipamentos diferentes, enquanto que camadas lógicas fazem menção aos programas em si. Ainda nas teorias de Bond et al. (2003), na época dos computadores de grande porte existia uma grande centralização do processamento que acarretava na utilização de programas escritos em um único bloco de código, instalados em uma única máquina. Esse aglomerado de código incluindo todas as funcionalidades é o chamado código monolítico. No código monolítico estavam concentrada a lógica de apresentação, lógica de negócio e lógica de acesso a dados. Com isso, esses programas sofriam graves consequências no que diz respeito à manutenção. Com as necessidades de mudanças, ao incluir funcionalidades ao projeto, o grande código deveria ser recompilado por completo, podendo ocasionar erros não esperados em outras partes (devido ao forte acoplamento) e uma série de outros empecilhos. Além disto, com o decorrer do tempo e da maior disseminação dos computadores pessoais, surgiu a vontade de compartilhar dados entre duas ou mais máquinas. A partir de então introduziu-se outra camada física, deixando a lógica de acesso a dados separada das lógicas de apresentação e do negócio. Com isso, é necessária a existência de um servidor de banco de dados que, teoricamente, pode ser substituído por outro, até com SGBD’s (Sistema Gerenciador de Banco de Dados) diferentes. Apesar da arquitetura implantada com duas camadas apresentar vantagens sobre o código monolítico existem alguns pontos negativos que, de acordo com Bond et al. (2003), devem ser observados, por exemplo: • O cliente fica repleto de código da lógica de negócios e da lógica de apresentação, sendo assim, o cliente torna-se um cliente ‘gordo’ (thick). Isso implica em diversas deficiências, por exemplo, quando é necessária uma atualização;
  24. 24. 20 • Podem ocorrer situações onde o fornecedor, apesar de possuir um código executável que já foi compilado, não se sinta completamente seguro de deixar sua lógica de negócio na máquina cliente; • Como há apenas um único módulo executável, a manutenção é dificultada por uma necessidade de atualização e recompilação de todo o projeto. Com o advento da Internet e o surgimento da web, separar a lógica do negócio da interface de apresentação do usuário tornou-se um desejo por parte dos usuários e também dos desenvolvedores. Os clientes agora seriam apenas navegadores web, ou seja, clientes ‘magros’ (thin) que faz com que os usuários tenham acesso a diferentes aplicações disponíveis em um mesmo software (o navegador). Com isso, acrescentou-se uma nova camada física, separando então a lógica do negócio da lógica de apresentação e da lógica de acesso a dados. O processamento, assim, torna-se tarefa dos servidores web e isso torna extremamente vantajoso em diversos aspectos como manutenção, fraca dependência entre o código (fraco acoplamento), modularidade e escalabilidade. Diante do cenário atual onde as necessidades de uma organização mudam com uma incrível freqüência, esta organização de camadas parece fornecer um bom suporte para as necessidades mutantes das empresas. Além disso, é importante salientar que os aplicativos atuais devem fornecer alta disponibilidade, ou seja, permanecerem disponíveis sempre que solicitados, mesmo que em condições adversas. A escalabilidade é outro ponto favorável e ela implica que deve ser tolerado um aumento no número de computadores que utilizam o programa, sem que o mesmo sofra demasiadamente as conseqüências desta adição. O acréscimo destas máquinas não deve ser muito trabalhoso e como no modelo de três camadas é necessário apenas um navegador para acessar a aplicação, esse é o panorama mais adequado atualmente. O processo de evolução constante exigiu uma maior sofisticação das linguagens de programação e métricas de análise e modelagem de sistemas. Devido a essas necessidades, a orientação a objetos ocupou um grande e importante espaço nos ambientes de desenvolvimento devido aos seus poderosos recursos.
  25. 25. 21 1.4.2 Programação Orientada a Objetos O paradigma da orientação a objetos tenta modelar os elementos em um sistema da mesma forma que são percebidos no mundo real. Desta forma, neste paradigma, os sistemas são compostos por objetos que possuem responsabilidades e funções, e estes, colaboram entre si para a realização de um objetivo comum. Porém, os projetos orientados a objetos tendem a ser mais complexos e difíceis de modelar e implementar. Os processos de modelagem de software tradicionais não preparam o software para futuras modificações, eles descrevem apenas as necessidades presentes no levantamento de requisitos observados no início do projeto. Por isto mudanças futuras tornam-se um grande problema para os desenvolvedores, uma vez que modificações são difíceis de fazer e sempre estão sujeitas a introduzir erros no sistema. As mudanças de requisitos são uma questão inevitável, e por melhor que seja o levantamento de requisitos iniciais, eles nunca atenderão a todas as necessidades do cliente, por deficiência no levantamento de requisitos, ou simplesmente porque as necessidades do cliente mudam. Como citam Shalloway e Trott (2004, p. 34), “em vez de reclamar de requisitos variáveis, devemos mudar o processo de desenvolvimento para que possamos realizar as alterações de modo mais eficaz”. Mesmo com o poder que possui, o simples fato de adotar o paradigma da orientação a objetos não é garantia de um software de qualidade e bem estruturado. Os padrões de projeto descrevem formas eficientes de se construir aplicações baseadas no paradigma da orientação a objetos que possuam uma boa engenharia e que sejam manuteníveis e expansíveis. Sistemas de software que não possuem uma separação bem definida entre as partes, e mesmo entre as diversas responsabilidades de cada uma dessas partes, tornam-se sistemas impossíveis de manter, devido à dificuldade que possuem para receberem mudanças. Os padrões descrevem formas de desacoplar as partes de um sistema e tornar essas partes totalmente independentes umas das outras. Eles abstraem o problema, de forma que se tenha uma visão de alto nível do mesmo, podendo assim fazer uma melhor análise e desenho do projeto. Possibilitam ainda, o estabelecimento de uma terminologia comum, facilitando a comunicação entre aqueles que participam da criação de um software.
  26. 26. 22 A adoção de padrões não se dá somente na implementação. De acordo com os pensamentos de Shalloway e Trott (2004), os padrões podem ser adotados em todos os níveis de um sistema, na análise, no projeto e, é claro, na implementação. 1.5 REUTILIZAÇÃO O processo de construção de software é uma tarefa extremamente complexa. Desenvolver algo a partir do zero é dispendioso e demorado, especialmente se for algo grande. Deve ser feito um planejamento minucioso visando atender da melhor forma as necessidades de um cliente. Para otimizar este processo, o melhor recurso encontrado pelos projetistas e desenvolvedores foi o reuso. Porém o reuso não é algo simples de realizar de forma efetiva e eficiente. Conforme a idéia de Gamma et al. (2000), o reuso é uma das necessidades dos projetistas, aproveitando-se de experiências e projetos bem sucedidos anteriormente, captando funcionalidades dos mesmos para utilizar em um novo domínio. Contudo, essa reutilização é complexa e difícil de lidar, ainda que os projetos anteriores tenham sido desenvolvidos nos melhores moldes da programação orientada a objetos. Antes de se falar em orientação a objetos, as primeiras formas de reuso que foram adotadas, em nível de implementação, foram a utilização de subrotinas e a criação de bibliotecas. Nesse momento já surgia à necessidade de se criar abstrações das idéias. Os trechos de código que eram repetitivos tinham seu objetivo principal abstraído e, se tornavam uma subrotina que realizava sempre a mesma coisa. A mesma subrotina era chamada, porém com parâmetros diferentes, assim ela realizava sempre a mesma função, mas sempre criando resultados diferentes. A orientação a objetos chegou e parecia resolver definitivamente o problema da dificuldade do reuso. Recursos como a herança, o polimorfismo, agregações, composições, possibilidade de ser criar pacotes de classes; de fato possibilitam o reuso, porém, apenas em nível de implementação, e também requer um amplo conhecimento de todos estes conceitos para que seja bem feito. Neste caso, as dificuldades enfrentadas em lidar com o reuso de componentes se dão em função das dependências existentes dentro de um programa completo, onde muitas
  27. 27. 23 vezes um trecho é fortemente acoplado em outro dependendo de heranças e outras estruturas da programação. A idéia central dos padrões é seguir maneiras que levem ao desenvolvimento baseado em abstração de soluções e isso acarreta diretamente em melhores práticas no desenvolvimento, adotando modelos que deram certo. Os padrões de projeto surgiram por meio da documentação formal de soluções que vinham sendo utilizadas, afim de que as soluções não tivessem que ser redescobertas sempre que se deparasse com um mesmo problema. De acordo com Sauvé (2006) não se reutiliza o código, apenas as idéias. Ainda de acordo com Sauvé (2006), os design patterns definem maneiras de separar e isolar características que são comuns das que são distintas entre casos. É essa separação que permite abstrair a idéia central da solução e fazer reuso dela em outro problema sob o mesmo domínio. 1.6 CLASSIFICAÇÃO Padrões ditam as melhores formas de se criar classes e objetos e como melhor relacioná-los. O livro base da ‘Gang of Four’ que é na verdade um dos principais catálogos de padrões de projeto define, inicialmente, 23 padrões distintos para solucionar variados problemas. Esses 23 padrões, contudo, permanecem divididos em três classificações iniciais, são elas: padrões de projeto criacionais, padrões estruturais e padrões comportamentais. Essa classificação nos dá uma abstração ainda maior sobre a solução a ser adotada para um problema particular. Os padrões criacionais descrevem formas de se criar e instanciar objetos, esta categoria agrupa padrões de projeto como o Abstract Factory, Singleton, Double-Checked Loking, Factory Method que podem ser usados em casos onde, por exemplo, apenas um objeto de uma classe pode ser instanciado; não se sabe, em tempo de compilação, qual objeto deverá ser instanciado, entre outras situações. Os padrões estruturais apresentam formas para reunir os objetos existentes no sistema, esta categoria agrupa padrões de projeto como o Facade, Adapter, Bridge e
  28. 28. 24 Decorator que podem ser usados em casos onde, por exemplo, um objeto deve mascarar outro objeto ou um subsistema; criar interfaces para que objetos distintos possam se comunicar. Comportamentais descrevem a maneira como os componentes comunicam-se, além de desvincular objetos no sistema para que este possa ser variável. Um exemplo nesse sentido são os componentes que fornecem comportamento para interação com os usuários do sistema. Alguns padrões que se enquadram como comportamentais são: Observer, Strategy, Memento, State, entre outros. Apesar das três classificações anteriormente citadas, com avanço da tecnologia e surgimento de novas tendências, algumas novidades modificaram um pouco as disposições dos padrões. Segundo Deitel (2005) há uma inclusão de padrões populares como é o caso dos padrões de projeto que tratam a concorrência (multithreading) e ainda os padrões arquitetônicos, como é o caso do MVC (Model-View-Controller). Os padrões de concorrência tratam de casos onde se faz uso de processamento paralelo através do uso de multithreading, descrevendo boas formas de uso para evitar problemas pertinentes a estes tipos de sistemas. Os padrões arquitetônicos descrevem formas de interligar partes de um sistema de uma maneira que estas partes possam colaborar uma com a outra, porém sem que haja dependência entre elas. O padrão MVC é classificado como um padrão arquitetônico. Sendo este o foco principal deste trabalho. 1.7 CONSIDERAÇÕES FINAIS Frequentemente, os padrões são adotados em projetos diversos e há um senso comum de que a utilização dos mesmos implica em maiores benefícios durante o ciclo de vida de uma aplicação. Conhecer e aprofundar as informações a respeito das definições, características e classificações destes padrões pode tornar o profissional diferente dentro do mercado e levá- lo a um alto nível no desenvolvimento de software. Os estudos formaram base de conhecimento sobre padrões de projeto de uma forma geral para que fosse possível um melhor entendimento do padrão MVC especificamente, que é o foco de pesquisa apresentado no próximo item.
  29. 29. 25 2 MVC (MODEL-VIEW-CONTROLLER) 2.1 CONSIDERAÇÕES INICIAIS O MVC (Model-View-Controller) é um padrão de projeto arquitetural baseado em outros padrões como o Observer, Composite e Strategy. O MVC, como o nome sugere, possibilita a separação de um projeto em múltiplas camadas, das quais fazem parte: Modelo (Model), Visão (View) e Controlador (Controller). Este capítulo apresentará um estudo aprofundado das características desse padrão, passando por uma conjuntura histórica e explicando suas aplicações, frameworks, vantagens e desvantagens de sua utilização, entre outros. Além do MVC em si, o capítulo trará algumas considerações a respeito da especificação JEE (Java Enterprise Edition) que é uma das tecnologias que podem ser empregadas na construção de aplicações distribuídas. 2.2 SURGIMENTO O cientista da computação Trygve Mikkjel Heyerdahl Reenskaug foi o responsável pelo Model-View-Editor que foi o primeiro nome dado ao padrão arquitetural de projeto criado em meados da década de 70. O norueguês, que nesta época estava como um cientista visitante na empresa Xerox Parc©, pesquisava junto ao grupo de desenvolvimento do projeto Smalltalk (tal projeto tratava-se de uma das primeiras linguagens puramente orientada a objeto). Transpondo os sistemas que existiam em sua época e focando um estudo nas GUI’s (Graphical User Interface), Reenskaug criou a primeira implementação para o MVC que surgiu como uma forma otimizada de se construir tais interfaces gráficas com o usuário e, segundo o próprio Reenskaug, a concepção do nome foi uma das partes mais duras, pois era extremamente difícil encontrar um bom nome para a diferente arquitetura de componentes que tratara.
  30. 30. 26 Após longas conversas, principalmente com Adele Goldberg, o termo Model- View-Controller foi aderido de vez, deixando a palavra Editor de lado. Antes mesmo de imaginar o MVC, Trygve estudava formas de implementar sua estratégia de que o sistema a ser construído deveria ser decomposto em componentes, de forma que o sistema resultante fosse suficientemente flexível podendo ser facilmente modificado para atender à mudanças. Segundo Gamma et al (2000) o MVC é formado, essencialmente, pela combinação dos padrões de projeto Observer, Composite e Strategy, aproveitando-se dos recursos de cada um para atender a seus propósitos. Conforme citado, o MVC surgiu como uma forma melhorada para construção de interfaces gráficas, mas tomou grande amplitude e passou a ser utilizado, de uma forma geral, na arquitetura de sistemas complexos. Toda a parte histórica, incluindo a documentação da época, permanece disponível na página pessoal de Reenskaug junto a Universidade de Oslo (http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html). Lembrando que o mesmo dedicou-se também a pesquisa voltada a UML (Linguagem de Modelagem Unificada). 2.3 APLICAÇÃO Muitos problemas aparecem quando o código está fortemente acoplado, o acesso a dados, regras do negócio e apresentação estão no mesmo código. Essa ênfase é fortemente tratada pela Sun Microsystems (2002) que salienta também, dentro de suas boas práticas de implementação, a necessidade de aplicações empresariais terem de suportar múltiplos tipos de usuários e diferentes tipos de interface. O MVC que separa a lógica de negócios no model, a apresentação na view e a interação entre eles no controller, também se apresenta como uma boa escolha para a construção de aplicações web interativas. Isto devido ao fato de neste tipo de aplicação haverem grandes quantidades de interações de diversos tipos de usuários e buscas e exibições de dados. Brown (2003), analisando especificamente a linguagem Java, ressalva o conceito onde os componentes da view eram identificados como componentes GUI e os controllers eram componentes que uniam esses elementos. E, ainda na visão de Brown, as
  31. 31. 27 tendências atuais fazem o padrão ser normalmente empregado em projetos baseados na web, onde a solução é dividida da seguinte maneira: JSP ocupam o posto de elementos de visão; Servlets são os controladores e os Java Objects como JavaBeans assumem o papel de modelo. A seguir (figura 1) uma imagem que ilustra essas definições: Figura 1 – Padrão MVC aplicado para GUI e tecnologias Servlet/JSP. Fonte: Brown, 2003, p. 58. O MVC, portanto, demonstram que é um padrão arquitetônico que se adéqua de forma concisa a soluções na web. Isso, graças à separação de camadas conforme a sua funcionalidade. A partir dessa definição e maior aprofundamento, a pesquisa trata do desenvolvimento voltado para as aplicações web já citadas, cabendo lembrar que o desenvolvimento para desktop também aplica de forma correta e eficaz o pattern em questão. 2.3.1 Vantagens e desvantagens O uso deste design pattern, como de outros padrões diversos, exige um empenho inicial no estudo, permitindo definir de forma correta, quando sua utilização apresenta vantagens e quando a mesma pode ser de alguma forma onerosa.
  32. 32. 28 Há projetos que são extremamente modestos e que, muitas vezes, resumem-se em poucos formulários que se comunicam com um banco de dados através de um acesso a dados. Para esses projetos pequenos, onde não é necessária uma lógica de negócio apurada e muito menos a existência de diversas visões para o usuário, a aplicação do padrão pode gerar uma visível desvantagem que é a complexidade desnecessária. Contudo, ainda em casos pequenos deve ser levado em consideração que os requisitos dos clientes são extremamente mutáveis e o sistema que é simples em um dado momento, pode sofrer o acréscimo de várias funcionalidades tornando-se um grande software. Segundo Basham, Sierra e Bates (2005) a aplicação do padrão MVC possibilita o desacoplamento das partes do programa deixando-o modularizado. O sistema é decomposto em componentes com funções específicas e independentes uns dos outros, aumentando assim, a coesão dos mesmos. Todas essas características tornam o projeto mais reutilizável devido ao fraco acoplamento, ou seja, não há interdependências entre componentes e os mesmos podem ser empregados com pequenas adaptações em projetos futuros. Acrescentando ainda que, reutilizando projetos que foram baseados em padrões, é aceitável que foram abordadas as melhores práticas de pessoas experientes que trabalharam soluções neste domínio. No MVC, os componentes se comunicam através da definição de interfaces e troca de mensagens. Desta forma, qualquer um dos componentes pode ser modificado ou substituído sem interferir em nada no funcionamento dos demais, basta que o novo componente siga a implementação das interfaces definidas. Com isso se obtém a desejada flexibilidade que os sistemas atuais exigem. O MVC possibilita que um mesmo dado, representado no modelo, possa ser exibido em diferentes visões da melhor e mais conveniente forma e, sempre que necessário, novas visões podem ser criadas sem interferir em nada no modelo. Um exemplo clássico da relação do model com a view é demonstrado na figura a seguir:
  33. 33. 29 Figura 2 – Exemplo de um modelo representado por diferentes views (visões). Fonte: GAMMA et al, 2000, p. 15. Uma situação comum em que o MVC seria uma boa solução a ser adotada e que está exemplificada pela Sun Microsystems (2002) em Java Blue Prints: Model-View- Controller é a de um sistema que tem que suportar diversos tipos de usuários com diversas interfaces. Segue a ilustração: Figura 3 – Esquema de uma aplicação que deve suportar diversos tipos de usuários e interfaces. Fonte: Sun Microsystems, 2002.
  34. 34. 30 Este esquema ilustra uma aplicação onde o modelo é acessado utilizando diversas visões que podem ser implementadas com diversas tecnologias. Outro exemplo comum poderia ser de uma aplicação Java que possui uma versão para a web, implementada com JEE, uma versão stand-alone implementada com JSE e ainda uma versão mobile implementada com JME. De acordo com as idéias de Basham, Sierra e Bates (2005) o MVC aumenta a complexidade da aplicação pelo fato de, ao aumentar a coesão dos componentes individualmente, muitos novos componentes são necessários na aplicação. Em contrapartida, ele minimiza os impactos das mudanças feitas na aplicação. A divisão em componentes pode aumentar o overhead de comunicação entre os mesmos. Esta é uma pequena dificuldade a ser enfrentada, sendo dissolvida com uma maior atenção na parte de análise do software, garantindo que os processos estejam otimizados e que a modelagem condiz com a realidade necessária para atender a aplicação. Embora ao adotar o MVC o trabalho no desenvolvimento fique maior e mais complexo, o rendimento na produção de software pode aumentar devido à possibilidade de se terem equipes desenvolvendo em paralelo cada parte do sistema e, também, à possibilidade de melhor entendimento entre os membros da equipe, devido ao vocabulário comum que se estabelece quando se adota padrões para o desenvolvimento. O MVC é utilizável em aplicações de grande porte, onde devem ser atendidos os atributos para um bom produto de software. Com isso, o correto é que o MVC, com sua divisão em camadas, torna o projeto extremamente legível, sendo vantajoso para uma aplicação futuramente manutenível. Conforme afirma Govoni (2005) a própria implementação de swing no Java adota este padrão, devido a sua forma de tratar as interações dos usuários com a delegação de tratamentos destas interações. 2.4 COMPONENTES DO PADRÃO MVC A essência do padrão MVC está no relacionamento entre os componentes model, view e controller. Cada um possui uma responsabilidade específica para o funcionamento do sistema, e através das interações que ocorrem entre eles obtém-se o resultado desejado.
  35. 35. 31 Como a separação de componentes é a característica fundamental do padrão, cabe explicar que essa divisão, segundo Eckstein (2007), desacopla o acesso a dados da lógica do negócio e também da maneira na qual a informação é exibida para os clientes finais. Essa separação que torna os sistemas desenvolvidos com este padrão mais flexíveis, manuteníveis e ainda permitindo o reuso dos componentes. Conforme artigo da Developer Connection da Apple (2008), o MVC foi construído a partir dos padrões Composite, Strategy e Observer, seguindo a imagem a seguir: Figura 4 – Versão tradicional do MVC. Fonte: Apple Developer Connection, 2008. Neste modelo tradicional os padrões Composite, Strategy e Observer atuam sobre as camadas as quais estão indicados, ou seja: • Composite: Representam a view e é um composto de objetos aninhados trabalhando de forma coordenada hierarquicamente; • Strategy: Trabalham na camada do controller e seus objetos implementam a estratégia para os views; • Observer: Atuando no componente model, que mantém a lógica do negócio da aplicação, o padrão é utilizado para enviar notificações de alteração de estado para as views. Esses padrões trabalham juntos no MVC tradicional e, como notado na imagem anterior, uma mudança no modelo deve ser notificada por este componente para a visão.
  36. 36. 32 Contudo, como se exige um alto grau de reusabilidade destes componentes, adotou-se a utilização do controlador para ficar responsável por definir transição de mensagens de troca no modelo para a visão, com isso um novo diagrama define melhor o contexto atual do MVC que é voltado para web (também conhecido como MVC Model-2): Figura 5 – Versão do MVC web (MVC Model2). Fonte: Apple Developer Connection, 2008. Desta nova maneira, o controlador ganha a responsabilidade de receber a notificação do modelo e transcrever que deve ser feita uma atualização na visão. Esta alteração torna a view menos acoplada ao model e é satisfatória para o cenário de desenvolvimento de aplicações para web. Para Basham, Sierra e Bates (2005): “a essência do MVC é que você pode separar a lógica de negócio da apresentação, mas ponha algo entre elas para que a lógica de negócio possa agir sozinha como uma classe JAVA reutilizável, sem precisar saber nada sobre a view.” 2.4.1 Modelo (Model) A camada do modelo é designada como o núcleo da aplicação que funciona implementando toda a lógica do negócio e as operações que governam e modificam tais dados (SUN MICROSYSTEMS, 2008). Com isso, o modelo é o software (todas as classes e funcionalidades) em si. O model representa e manipula, seguindo as regras de negócio, os dados do sistema.
  37. 37. 33 De acordo com Reenskaug (1979), definindo o que é o model, ele representa conhecimento, e pode ser um único ou uma estrutura de objetos. O model pode ser considerado a aplicação em si ou, o nível mais baixo da mesma. O modelo encapsula o estado e comportamento da aplicação além de ser o único componente do MVC que faz interface da aplicação frente à fonte de dados, que normalmente é representada pelo banco de dados da aplicação. Um conceito errado e freqüente é que o banco de dados de uma aplicação é o próprio model. Na verdade, o banco de dados constitui a camada de persistência do modelo e os componentes model são os únicos a acessarem e executarem alterações no banco de dados. É valido observar que a persistência também poderia ser implementada pelo uso de outros dispositivos. Conforme Souza (2004), devido aos bancos serem, em sua esmagadora maioria, relacionais, é necessário no modelo existir um mapeamento dos objetos do software orientados a objeto, para as tabelas do banco de dados. Essa técnica é o Mapeamento Objeto- Relacional (ORM – Object Relational Mapping). Além desta técnica, há o padrão DAO (Data Access Object – Objeto de acesso a dados) que permite melhor acesso a dados por parte dos objetos. Salientando a ausência de dependências entre os componentes, segundo Basham, Sierra e Bates (2005), no MVC, a lógica de negócio (o model) não fica apenas separada da apresentação, ela sequer sabe da existência da mesma. O model é a combinação dos dados e dos métodos que os manipulam. Com isso, o reuso provido pelo MVC se dá principalmente neste componente (modelo), sendo este o núcleo funcional do sistema. Antes do MVC voltado para a web o modelo deveria também executar a tarefa de enviar notificações das atualizações em seus dados para que as views tivessem informações consistentes e atualizados com as últimas versões disponíveis e presentes no software. Para promover um desacoplamento, atingindo melhor o objetivo do padrão em si e tornando os componentes mais independentes entre si, no MVC2, o model é notificado através do controller quando alguma view requer a exibição de dados ou provoca a alteração dos mesmos. Em resposta, o model, disponibiliza para a view, através do controller, os dados requisitados ou o seu novo estado após a atualização provocada. 2.4.2 Visão (View)
  38. 38. 34 A visão é o componente da arquitetura MVC que é responsável pela apresentação, é a interface de representação do modelo, ou seja, trata-se da fronteira entre usuário e o sistema em si. A definição de Reenskaug (1979) para a view diz que ela pode, da forma mais conveniente, exibir alguns atributos e ocultar outros, atuando como um filtro para os dados do modelo. É papel do controlador definir a view apropriada para a exibição da resposta obtida pela requisição feita. No modelo tradicional do MVC, décadas após a concepção de Reenskaug, apesar de ainda com os ideais do mesmo, a view é composta por GUI’s (Graphical Users Interface) enquanto que no MVC web a visualização das informações acontece através das páginas HTML (HyperText Markup Language – Linguagem de Marcação de Hipertexto) para informação estática e JSP, ASP, PHP, dentre outras, para informações dinâmicas. Outra diferença entre o MVC original e o web é que as views no original recebiam notificações do model, feitas por sua vez, através da implementação de interfaces que definem objetos observadores e observados. No caso de aplicações web estas notificações são sempre mediadas pelo controlador, principalmente pela necessidade do reuso. Ainda assim, a visão deve ter definido um procedimento de atualização que é ativado por um mecanismo de propagação e troca. Devido à associação direta com os controllers, as views estabelecem com os mesmo um relacionamento ‘um-para-um’. É na visão que ocorrem todas as interações do usuário que serão tratadas pelo controlador para chamar os métodos apropriados no modelo. Este componente pode ser considerado o mais flexível do MVC, podendo ser facilmente alterado ou substituído. Novas visões também podem ser facilmente implementadas, sem afetar em nada a estrutura do sistema. De acordo com Sun Microsystems (2002) no artigo Java BluePrints: Model- View-Controller , a view renderiza o conteúdo do modelo e deve manter uma consistência na sua apresentação quando os dados do modelo mudam. 2.4.3 Controlador (Controller) Este componente controla a comunicação entre o modelo e a visão.
  39. 39. 35 Pode ser considerado como a fronteira entre os outros dois componentes do MVC e sua finalidade é controlar interações que ocorram a partir do usuário (recebe o input) que trabalha sobre elementos na camada de visão e descobre o que essa entrada significará para o modelo. Ou, ainda, do modelo em resposta às ações anteriores. As entradas que esses componentes recebem são, normalmente, eventos de mouse, entradas de teclado, entre outras. Estes eventos por sua vez serão traduzidos em requisições de serviços para outro componente que deverá tratar. Eckstein (2007) define a responsabilidade do controller. The controller translates the user's interactions with the view into actions that the model will perform. In a stand-alone GUI client, user interactions could be button clicks or menu selections, whereas in an enterprise web application, they appear as GET and POST HTTP requests. Depending on the context, a controller may also select a new view -- for example, a web page of results -- to present back to the user. É o controller que define o comportamento da aplicação, mapeando as ações do usuário em atualizações e buscas no modelo, e também selecionando qual a view deve ser enviada como resposta. De acordo com a Sun Microsystems (2002), existe um controlador para cada função da aplicação, mas algumas estratégias podem ser adotadas para que se desenvolva um controle central e se evite código duplicado. Em aplicações web, uma solução comumente adotada para a criação deste controle central é a implementação do padrão Front-Controller. Um objeto é criado e serve como ponto de entrada principal para todas as requisições que vem da view, este objeto mapeia a requisição para o tratador adequado. O Struts é um exemplo de framework que faz o papel de Front-Controller em aplicações Java para web. 2.5 FRAMEWORKS Os frameworks são também conhecidos como arcabouços ou quadro de objetos. Eles são criados para fornecer funcionalidades e um objetivo maior, podendo ser reutilizados em forma de único componente em outra aplicação. Funcionam como a estrutura de um esqueleto que é completada para construção de um programa completo (DALMOLIN, 1997, p. 14).
  40. 40. 36 Assim, frameworks são conjuntos de classes que fornecem recursos e a estrutura necessária para a resolução de problemas sob um mesmo domínio. Eles estão intimamente relacionados a padrões de projeto e pode-se dizer que são uma implementação genérica de uma solução. Para Basham, Sierra e Bates (2005) “O objetivo de um framework é ‘ajudar os programadores no desenvolvimento e na manutenção de aplicações complexas’”. Neste momento, é importante diferenciar uma biblioteca de classes de um framework. Enquanto em uma biblioteca existem diversas classes sem definição das relações entre elas, cabendo ao programador relacionar as classes conforme sua necessidade; em um framework as classes que o compõe já possuem suas relações internas definidas. A construção de um framework se dá em função da generalização de entidades em um projeto de domínio comum. Normalmente essa generalização também pode ser feita devido a uma necessidade particular que certo desenvolvedor observa em uma linguagem ou em uma gama de projeto qualquer. A construção, segundo Fiorini (2001), envolve 3 etapas que são: análise de funcionalidades comuns, definição de pontos flexíveis (hot-spots) e o projeto do framework em si. Silva e Price (1997) comentam que os frameworks também minimizam o esforço no desenvolvimento, por já possuir um conceito implementado. Contudo, a utilização do mesmo pode acarretar na criação desnecessária de alguma classe, pelo desconhecimento completo do arcabouço em questão. Essa é uma situação bastante tangível, afinal, na atualidade, existem distintos frameworks em diferentes linguagens. Logo, conhecer as características de um destes arcabouços em particular, pode ser uma tarefa trabalhosa, mas muito relevante. Figura 6 – Aplicação desenvolvida com uso de um framework. Fonte: Silva e Price (1997, p. 2).
  41. 41. 37 A imagem demonstra bastante a idealização do que se trata um framework, como pode ser observado, ele traz consigo as funcionalidades em comum desenvolvidas e, a partir disto, são tratadas novas características para seu emprego com o domínio específico. Um adendo é que um framework diverge de um padrão de projeto pelo padrão ser tratado como uma idealização de solução para problemas e dificuldades em comum, enquanto que o framework trata-se de uma implementação em si. Fazendo uma listagem minimalista sobre frameworks que seguem o MVC, notamos que o mesmo se aplica em diversas linguagens, por exemplo: • Java: Struts, Spring, JSF, VRaptor; • PHP: Zend Framework, CakePHP, Akelos; • Python: Django; • Ruby: Rails, Merb. Apesar desta diversidade existente, como item de estudo serão abordados os frameworks voltados para tecnologia Java (JEE), por ser uma linguagem amplamente usada no mundo, além de suas vantagens como ampla comunidade de desenvolvimento, padrões abertos, diversos fornecedores de soluções para a tecnologia, multiplataforma e tradição incontestável. Acrescentando que implementar o padrão MVC sem fazer uso de algum framework pode aumentar a dificuldade de desenvolvimento, uma vez que todas as funções de cada componente terão que ser implementadas e planejadas a partir do zero. 2.5.1 Struts Concebido pelo programador Craig R. McClanahan, o framework foi oferecido para a Apache Software Foundation (ASF) durante o ano de 2000 para o projeto Jakarta, assim o Struts tornou-se Jakarta Struts Framework. Sua versão corrente é a 2.1.6, de 12 de janeiro de 2009. Atualmente, ainda é o framework MVC mais utilizado em soluções web MVC, embora se diga que seu uso está em declínio. Conforme definido pela Apache (2009) o Struts é um framework livre e de código aberto para criação de aplicações web com Java. Essas aplicações provêm interação com banco de dados, lógica do negócio e entregam ao usuário final, o resultado de uma resposta dinâmica.
  42. 42. 38 O Struts atua como um Front-Controller, padrão onde, para Basham, Sierra e Bates (2005), “todas as solicitações passam por um só controlador, o qual se encarrega de fazer o dispatching da solicitação para os lugares apropriados”. O Struts é implementado utilizando recursos como xml, servlets e JavaBeans e fornece diversas funcionalidades como: tags customizadas, tratamento global de exceções, extensão via plug-ins, entre outros. O framework provê três componentes chave que são requisições, respostas e tag library (conjunto de bibliotecas que ajuda o desenvolvedor a criar aplicações interativas). Hoje, o projeto conta com ampla colaboração mundial, onde uma comunidade de desenvolvedores contribui com melhorias, correção de erros e acréscimo de funcionalidades sem obter ganhos financeiros pelo auxílio prestado. Isso faz com que uma vantagem deste framework seja a ampla incidência de informações e exemplos para os programadores. Contudo, segundo Raible (2006), o Struts apresenta também algumas desvantagens que podem direcionar o desenvolvedor para outros frameworks, dentre elas: ActionForms são ruins de programar; há rumores de que os projetos do framework estão “mortos” e não é possível executar testes, exceto na integração. Além destas considerações, para Nascimento (2005) “o JSF (Java Server Faces) faz tudo o que o Struts se propõe a fazer e ainda oferece um poderoso modelo de componentes”. Isso significa que, se há outro framework que cumpre com o proposto pelo Struts, acrescentando novas características, o desuso do Struts pode aumentar com o tempo e a tendência é que ele seja substituído em novas aplicações. 2.5.2 VRaptor Segundo a definição em seu site oficial, o VRaptor é um controlador MVC para web focado no desenvolvimento ágil. Por meio da inversão de controle e da injeção de dependência, este framework diminui drasticamente o tempo gasto em ações repetitivas no desenvolvimento, como validações, conversões e direcionamentos. Produzido por alunos brasileiros de Ciência da Computação durante o ano de 2004 na USP (Universidade de São Paulo) o VRaptor foi criado visando produzir uma alternativa um pouco mais simples do que o Struts que era abordado em projetos destes alunos
  43. 43. 39 de computação no instituto de matemática e estatística da própria universidade. Com o tempo, pessoas de todo o mundo ligaram-se ao projeto e ele vem crescendo. Atualmente a versão deste framework é a 2.6, ele é opensource e tende a auxiliar no desenvolvimento ágil. Além disso, para desenvolvedores do Brasil, pode tratar-se de uma boa alternativa, pela maior parte da documentação ser em português. A lógica de negócios é implementada em classes Java simples, sem contato com a API (Application Programming Interface) javax.servlet, o que facilita o reuso. Prioriza convenções ao invés de configurações, dispensando assim, uma grande estrutura de arquivos de configuração. A view não necessita ser obrigatoriamente implementada em JSP, outras tecnologias são suportadas. Para o modelo, possui fácil ligação com o Hibernate para implementação da camada de persistência. Outro atrativo do VRaptor está em sua simples curva de aprendizado. 2.5.3 Spring O Spring foi criado por Rod Johnson e é baseado no conceito de Dependency Injection (Injeção de Dependência) e AOP (Programação Orientada à Aspectos). Antes de explicar o que é o framework Spring em si, cabe apenas contextualizar os conceitos da Inversão de Controle e Injeção de Dependências. Segundo Fowler (2005), a Inversão de controle nada mais é do que a delegação de chamada de métodos da aplicação por um contêiner e não pela estrutura usual de programação. Assim, o framework faz o papel de coordenar o seqüenciamento de atividades da aplicação. Como inversão de controle era um termo muito genérico, houve discussões em que decidiram definir um nome mais apropriado para o padrão de atividades que acontecia. De tal modo ficou definido a injeção de dependências. Este framework utiliza a injeção de dependências para facilitar o fraco acoplamento da aplicação. Sendo assim, programar com o Spring torna-se algo mais prazeroso e independente (JARDIM, 2004). A seguir (figura 7), apresentamos um quadro que dá idéia de quão modular é o Spring e abaixo uma pequena descrição de alguns dos módulos:
  44. 44. 40 Figura 7 – Visão geral do framework Spring. Fonte: Developersbook, 2008. Como cada quadro representado tem sua função específica, conforme apurado por Augusto (2006), segue resumo sucinto de cada módulo que compõe o framework. • Núcleo do Spring: provê as funcionalidades fundamentais do Spring, sendo o principal elemento o BeanFactory; • Spring AOP (Aspects Oriented Program – Programação Orientada a Aspectos): com este módulo é possível incorporar o gerenciamento de transações declarativas em suas aplicações, sem depender dos componentes EJB; • Spring ORM (Object Relational Mapping – Mapeamento Objeto-Relacional): esse módulo provê integração com o mapeamento objeto-relacional incluindo algumas ferramentas como Hibernate, JDO (Java Data Objects), dentre outros. • Spring DAO (Data Access Object – Objeto de Acesso a Dados): fornece uma camada de abstração da JDBC (reduzindo a complexidade de codificar conexões e classes para banco de dados); • Spring web: fornece suporte a integração com o framework Struts e outras utilidades em geral. Segundo definição de Donald (2008) o módulo web fornece os fundamentos para o desenvolvimento de aplicações web com Spring utilizando o comprovado MVC. O Spring Web pode ser usado em conjunto com outros frameworks MVC, quando não se deseja utilizar o nativo Spring MVC;
  45. 45. 41 • Módulo de contexto do Spring: trata-se de um arquivo de configuração que inclui serviços como JNDI (Java Naming and Directory Information), EJB (Enterprise JavaBeans, e-mail, entre outros); • Spring MVC: com esse módulo a aplicação pode ficar totalmente baseada no modelo MVC, com a separação entre model, view e controller. O Spring Web e MVC fornecem recursos ao desenvolvedor como: definição dos controllers da aplicação; mecanismos para validação de formulários em diversos níveis; mapeamento de requisições para os locais apropriados; criação de views em diversos formatos, não apenas com JSPs, tratamento de exceções; envio facilitado de emails; acesso a objetos remotos. Ainda que bastante completo, o Spring demonstra complexidade devido ao grande número de funções de cada módulo e o entendimento geral dos mesmos. Acrescentado a isso, há a necessidade de configuração intensa de arquivos em XML (Linguagem de Marcação Extensível) e requer que seja escrita uma grande quantidade de código JSP. 2.5.4 WebWork O WebWork é um framework Java para desenvolvimento de aplicações web que, em sua versão atual (2.2.6), visa à simplificação de código e provê robustez na reutilização de interfaces com usuário, como formulários, internacionalização (aplicação pode estar em vários idiomas trocando apenas arquivos de configuração), validação do lado do servidor, características como o suporte a Ajax, e inversão de controle com o contêiner Spring, entre outros. Foi construído com o princípio de prover produtividade e códigos simples para o desenvolvimento. O WebWork é similar ao Struts, ele atua como um controlador fazendo redirecionamentos de acordo com cada requisição. Este framework possui uma grande capacidade de abstrair a camada de apresentação, não importando quem irá criar a visão, ele irá entregar os objetos necessários para o renderizador apropriado.
  46. 46. 42 Indo além nesta abstração, as ações que o programador define não ficam dependentes do ambiente web; devido ao fato de o WebWork ser baseado no XWork (que provê um command pattern framework e também um container para inversão de controle). Com isto, diversas tecnologias para a visão podem ser empregadas, como HTML, Swing, PDF, XSTL, entre outras; sem que seja necessária nenhuma mudança no código escrito pelo programador. Algumas vantagens que podem ser citadas sobre o WebWork são arquitetura simples e de fácil extensão e biblioteca de tags fácil de usar e customizar; como desvantagens pode-se destacar sua fraca documentação e comunidade. Porém, como lado negativo deste framework, a documentação ainda encontra-se organizada de forma pobre e a comunicatividade do mesmo é baixa. (RAIBLE, 2006) 2.5.5 JSF (Java Server Faces) O JSF é um framework opensource para desenvolvimento web que foi incorporado à especificação do JEE. Por ser opensource, o JSF é totalmente expansível permitindo que terceiros implementem e distribuam novos componentes para a criação de interfaces de usuário. De acordo com Horstmann e Geary (2005), para quem está familiarizado com o desenvolvimento Java para desktops, o JSF pode ser pensado como um Swing para aplicações que rodam em um servidor, inclusive com o modelo de tratamento de eventos. Para aqueles que têm experiência com JSP, o JSF irá fornecer recursos que os desenvolvedores JSP teriam que construir manualmente. E para aqueles que já conhecem outros frameworks para aplicações web, como o Struts, nota-se que o JSF possui uma arquitetura similar, porém mais flexível e expansível. De acordo com definição da própria Sun Microsystems (2006), o JSF estabelece o padrão no servidor para a construção de interfaces com usuário. Ainda de acordo com a Sun, o JSF é constituído, em parte, por um conjunto de APIs para representar componentes de interface com usuário e gerenciar estes componentes, sua movimentação, eventos, entradas recebidas, fluxo de navegação entre páginas, tudo isto com suporte à internacionalização e acessibilidade. E a outra parte da constituição do JSF consiste de uma biblioteca de tags customizadas, para inserir os componentes em páginas JSP.
  47. 47. 43 Embora seja focado na construção de componentes para interface, o JSF implementa o padrão MVC como um todo, possuindo também um servlet controlador, o FacesServlet, que atua como um Front-Controller, muito similar ao Struts. Para toda requisição, o FacesServlet verifica o arquivo faces-config.xml, que define as regras de navegação, e mapeia a requisição para o recurso necessário. Através do uso dos chamados BackingBeans do JSF, é muito simples transferir dados entre a visão e a camada de plano de fundo da aplicação, o modelo. Toda a lógica de negócio da aplicação, também fica implementada em Java Beans. Os BackingBeans, são classes Java comuns, com os devidos atributos e métodos get e set. Novamente de acordo com Horstmann e Geary (2005), em aplicações JSF, os beans são usados para acessar todos os dados necessários a partir de uma página. Os beans são vias de circulação de dados entre a interface e a lógica da aplicação. Os BackingBeans recuperam e armazenam os estados dos componentes de interface do JSF. Através do uso de outros frameworks como, por exemplo, o Ajax4jsf, é possível acrescentar suporte a AJAX em aplicações JSF, enriquecendo a aplicação. É possível também desenvolver interfaces mais elaboradas através da adoção do RichFaces, uma biblioteca de componentes para aplicações JSF. A seguir, uma figura que ilustra resumidamente, o ciclo de vida de uma requisição no JSF. Figura 8 - Arquitetura JSF baseada no modelo MVC. Fonte: Pitanga, 2004.
  48. 48. 44 Quando uma requisição é feita, o FacesServlet, que deve ser configurado no arquivo web.xml da aplicação no servidor, verifica no arquivo de configuração faces- config.xml para qual recurso deve ser enviada esta requisição e a transfere. É nesta etapa, quando houver transferência de dados, que os dados são validados e tratados de acordo com a lógica de negócios programada para que atuem sobre o modelo. Baseada na árvore de componentes UI do JSF, a view selecionada para exibir o retorno ao usuário, é renderizada e enviada ao cliente. Um exemplo simples do funcionamento do ciclo de requisição do JSF é demonstrado em um pequeno exemplo retirado do livro Core Java Server Faces, onde um o usuário informa seu nome de usuário e senha, e estes dados são recuperados em outra página através dos BackingBeans do JSF. 1 - <html> 2 - <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %> 3 - <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %> 4 - <f:view> 5 - <head> 6 - <title>A Simple JavaServer Faces Application</title> 7 - </head> 8 - <body> 9 - <h:form> 10 - <h3>Please enter your name and password.</h3> 11 - <table> 12 - <tr> 13 - <td>Name:</td> 14 - <td> 15 - <h:inputText value="#{user.name}"/> 16 - </td> 17 - </tr> 18 - <tr> 19 - <td>Password:</td> 20 - <td> 21 - <h:inputSecret value="#{user.password}"/> 22 - </td> 23 - </tr> 24 - </table> 25 - <p> 26 - <h:commandButton value="Login" action="login"/> 27 - </p> 28 - </h:form> 29 - </body> 30 - </f:view> 31 - </html> Nas linhas 2 e 3 são feitas as importações das bibliotecas de tags customizadas do JSF, é através delas que todos os componentes serão inseridos na view. Todas as tags do
  49. 49. 45 JSF devem estar contidas dentro da tag <f:view> que se inicia na linha 4 e termina na linha 30. Na linha 9 é iniciado um elemento <h:form> que quando renderizado, irá gerar um elemento html <form>. Os elementos <h:inputText> e <h:inputSecret>, nas linhas 15 e 21 respectivamente, correspondem a elementos input do html do tipo text e password. Um diferencial do JSF é que estes elementos são automaticamente vinculados a um BackingBean através do delimitador #{...}. Tomando como exemplo a linha 15, este inputText, está vinculado ao atributo name do objeto user. Quando o formulário é submetido, o método setName() do objeto user é chamado, passando como parâmetro, o valor que está inserido no input. Quando o elemento é renderizado, o método getName() é chamado para preencher o campo do formulário com o valor armazenado no atributo do objeto. O elemento <h:commandButton>, na linha 26, é similar a um botão do tipo submit do html, o diferencial é que seu atributo action pode conter tanto uma string simples, que será usada para direcionar a navegação de acordo com o mapeamento feito no arquivo faces-config.xml, ou a chamada para um método em um BackingBean. A implementação de um BackingBean consiste em uma classe Java simples (POJO), com os devidos atributos e métodos get e set, que serão chamados no momento da submissão ou renderização de um form, conforme citado. Segue uma demonstração. 1 - public class UserBean { 2 - 3 - private String name; 3 - private String password; 4 - 5 - public String getName() { return name; } 6 - public void setName(String newValue) { name = newValue; } 7 - 8 - public String getPassword() { return password; } 9 - public void setPassword(String newValue) { password = newValue; } 10 - } Os BackingBeans utilizados na aplicação e o mapeamento de navegação devem ser feitos no arquivo de configuração faces-config.xml. 1 - <?xml version='1.0' encoding='UTF-8'?> 2 - <!DOCTYPE faces-config PUBLIC 3 - "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.0//EN"
  50. 50. 46 4 - "http://java.sun.com/dtd/web-facesconfig_1_0.dtd"> 5 - 6 - <!--configuração das regras de navegação--> 7 - <navigation-rule> 8 - <from-view-id>/index.jsp</from-view-id> 9 - <navigation-case> 10 - <from-outcome>login</from-outcome> 11 - <to-view-id>/welcome.jsp</to-view-id> 12 - </navigation-case> 13 - </navigation-rule> 14 – 15 - <managed-bean> 16 - <managed-bean-name>user</managed-bean-name> 17 - <managed-bean-class>UserBean</managed-bean-class> 18 - <managed-bean-scope>session</managed-bean-scope> 19 - </managed-bean> 20 - </faces-config> Nas linhas de 7 a 13 é criada uma regra de navegação, que define que quando uma solicitação é feita a partir do arquivo chamado index.jsp e a string informada for “login” será feito um redirecionamento para a página welcome.jsp. Esta regra será aplicada, neste exemplo, quando o commandButton na página index.jsp for clicado, uma vez que sua action está definida com a string “login”. Nas linhas de 15 a 19 é feito o mapeamento do BackingBean, utilizado nas páginas index.jsp e welcome.jsp. Deve ser definido um nome para o objeto (linha 16), qual é a classe que gera este objeto (linha 17), e qual é o seu escopo (linha 18), neste caso session, para que ele esteja disponível durante todo o tempo em que o usuário se mantiver com a aplicação aberta. Na página welcome.jsp, apenas é exibido o valor do atributo name do objeto user, que foi definido no envio do formulário em index.jsp. 1 - <html> 2 - <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %> 3 - <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %> 4 - 5 - <f:view> 6 - <head> 7 - <title>A Simple JavaServer Faces Application</title> 8 - </head> 9 - <body> 10 - <h:form> 11 - <h3> 12 - Welcome to JavaServer Faces, 13 - <h:outputText value="#{user.name}"/>!
  51. 51. 47 14 - </h3> 15 - </h:form> 16 - </body> 17 - </f:view> 18 - </html> welcome.jsp Definido este estudo inicial sobre estes frameworks, incluindo uma maior observação sobre o Java Server Faces (onde foi demonstrado um simples exemplo prático de sua aplicação), é definido que o restante do projeto abordará o JSF, pois o mesmo apresenta crescimento acelerado, grande possibilidades de expansões e tende a substituir alguns outros frameworks (como Struts), por ser mais poderoso que os mesmos. 2.6 JEE (JAVA ENTERPRISE EDITION) Em uma definição da própria Sun Microsystems (2009), Java EE é um conjunto de tecnologias coordenadas que reduzem significativamente o custo e a complexidade de desenvolvimento e manutenção de aplicações distribuídas, multicamadas e baseada em componentes. Construída sobre a sólida base do JSE(Java Standard Edition), o JEE adiciona capacidades para prover uma completa, estável, segura e rápida plataforma para aplicações empresariais. Atualmente na versão 1.5, ou simplesmente JEE 5, que de acordo com a Sun Microsystems (2009) está focada em deixar o desenvolvimento mais fácil. Oferecendo recursos como os EJBs, tecnologia JSF e APIs para desenvolvimento de Web Services, a plataforma torna a codificação simples, porém, sem perder nada do poder que já possuía na versão 1.4. O JEE (Java Enterprise Edition), ao contrário de soluções que fazem concorrência ao mesmo, como é o caso da Microsoft© com o .NET, não é um produto e sim uma especificação. Isso significa que a cada versão, seus recursos e funcionalidades são submetidos à JCP (Java Community Process) que, por sua vez, é uma comunidade empenhada em desenvolver a tecnologia e auxiliar com novas idéias, aprovando as versões em questão. A partir da JCP, os fornecedores dos servidores de aplicativos produzem suas ferramentas atendendo uma determinada gama da especificação e cada desenvolvedor em
  52. 52. 48 particular pode selecionar qual a solução se aplicará melhor dentro das suas necessidades do domínio. Conforme Bond et al. (2003), o JEE é um padrão dinâmico que fornece funcionalidades diversas para criação de aplicativos disponíveis, escaláveis e seguros, definindo quais serviços os servidores de aplicativos devem fornecer. Esses servidores, portanto, proverão os contêineres JEE onde os componentes serão executados. 2.6.1 Arquitetura O modelo de aplicações do JEE divide as aplicações em componentes, contêineres e conectores. Os componentes podem ser classificados em: • clientes EE: aplicações Java stand-alone ou clientes web (que são navegadores com páginas HTML (HyperText Markup Language) e applets); • componentes web: como servlets, JSPs (Java Server Pages), JSFs (Java Server Faces); • componentes de negócio: os EJBs (Enterprise JavaBeans). Cada tipo de componente tem seu contêiner específico, sendo assim, existem: contêiner de applet, contêiner web, contêiner EJB, contêiner de cliente de aplicativos. Os contêineres fornecem um ambiente em tempo de execução para que os componentes possam executar suas funções. Cada contêiner disponibiliza de maneira padronizada a JavaSE (Java Standard Edition) e funções particulares como fornecimento de comunicação entre componentes, descoberta de serviços, persistência, concorrência, segurança, distribuição, entre outros. Os contêineres ficam entre os clientes EE e os componentes do servidor de aplicação, fornecendo serviços transparentes para ambos. Estes se dividem em contêineres web, que tratam da execução de JSPs e Servlets, e contêineres EJB, que tratam da execução dos EJBs. Conforme definido pela Sun Microsystem (2009), os conectores definem APIs (Interface de Programação de Aplicativos) que escondem a complexidade e promovem a
  53. 53. 49 portabilidade. Facilitam a interação da plataforma JEE com outros sistemas, como base de dados e sistemas legados. Figura 9 – Contêiner JEE. Fonte: SAMPAIO JÚNIOR, 200-. Para prover um servidor de aplicativos, os fornecedores devem obedecer a uma gama de requisitos da especificação JEE. Com isso, os servidores que passam em todos os testes destes requisitos passam a possuir uma certificação de compatibilidade com a especificação JEE. Há variados fornecedores que disponibilizam servidores de aplicativos, dentre eles: • IBM: Fornece o Websphere que é bastante completo e dá suporte a tecnologias como EJB (Enterprise JavaBeans), JSP (Java Server Pages), XML (Extensible Markup Language), HTTP (HyperText Transfer Protocol), entre outros; • JBoss: Servidor gratuito que fornece apenas um contêiner EJB, não incluindo assim, o contêiner web; • iPlanet: Suporta plataforma JEE e fornece recursos para utilização de XML, protocolos de aplicativos de comunicação móvel, CORBA, entre outros;

×