Estudo De Aplicabilidade Do PadrãO Mvc Fernando & Leonardo

  • 8,191 views
Uploaded 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 …

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.

More in: Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
8,191
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
488
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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. 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. 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. 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. 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. 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. Divide as dificuldades que tenhas de examinar em tantas partes quantas for possível, para uma melhor solução. René Descartes
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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;
  • 54. 50 • Apache Tomcat: Servidor de aplicativos simples e altamente utilizado, ele possui apenas o contêiner web, que limita-o na não utilização de EJBs; • GlassFish: Projeto desenvolvido pela própria Sun Microsystems desde 2005, o GlassFish é um software livre que, por ser desenvolvido pela própria responsável pelo JavaEE, se enquadra perfeitamente ao desenvolvimento de aplicações comerciais com uso dessa tecnologia. O GlassFish ainda, segundo a própria Sun, é o mais rápido servidor de aplicativos. Apresentadas estas simples características, é definido que o GlassFish será utilizado como servidor de aplicativos para o estudo de caso deste projeto. Além da simples apresentação feita, tal servidor demonstra progressivo crescimento, principalmente por seu baixo consumo de recursos do servidor, rápida inicialização, entre outros. 2.6.2 Componentes Segundo Bond et al. (2003), existem dois tipos de componentes distribuídos que são executados em um servidor JavaEE, são eles: • Componentes Web: situados em um servidor web, esses componentes interagem com um cliente (normalmente utilizando um navegador) com base na web, dentre esses componentes há as JSP (Java Server Pages) usadas para montar páginas HTML dinâmicas para serem enviadas como resposta aos usuários e servlets que tratam das requisições e respostas HTTP. • Componentes de negócio (EJB): Divididos em Enterprise JavaBean e web services que implementam a lógica de negócios da aplicação. Estes interagem com os componentes web recebendo chamadas e devolvendo resultados, mas também interagem com uma outra camada chamada de EIS(Enterprise Information System), que consistem em sistemas de bancos de dados e aplicações legadas.
  • 55. 51 Apesar da definição de Bond et al. (2003), a Sun Microsystems (2009) trata também da existência de componentes que são os clientes EE. Estes são onde ocorrem as interações do usuário com a aplicação JEE, através de páginas HTML, com applets, ou de aplicações desktop construídas na plataforma JSE. As interações serão tratadas pelos componentes web e componentes de negócios da aplicação JEE. Ao desenvolver aplicações no modelo MVC para web, com a plataforma JEE, os principais componentes que compõem a aplicação web são os servlets, EJB e JSP, opcionalmente a tecnologia/framework JSF. Neste caso os servlets são adotados para a implementação dos controladores da aplicação no modelo MVC. Eles são responsáveis por receber as requisições, tratá-las, invocando os componentes do modelo quando necessário, e encaminhar a resposta para a view adequada. Geralmente faz-se o uso do padrão Front-Controller para centralizar todas as requisições em um único servlet. Os EJB, componentes de negócio, implementam a camada model do MVC. Geralmente são classes Java comuns (POJOs) que definem as regras de negócio da aplicação. A camada View do MVC, na plataforma JEE, é construída através de JSPs, que geram páginas HTML dinâmicas para serem enviadas como resposta às requisições. A tecnologia JSF surgiu como uma rica e eficiente solução para aplicações web MVC baseadas na plataforma JEE, com diversos componentes para a fácil construção de views e um Front-Controller já implementado. 2.6.2.1 Implementação de Componentes Web A seguir, uma breve explicação sobre a implementação de componentes web. Servlets Servlets são classes em Java que, desenvolvidas com uma estrutura bem definida, tratam requisições do cliente. Ao receber esta requisição, as servlets tratarão o processamento de forma inerente aos parâmetros capturados da mesma.
  • 56. 52 As servlets são tão portáveis como qualquer programa escrito em Java e ainda são orientado a objetos, sendo assim, cada servlet é um objeto em Java que recebe as requisições (request) e dão uma resposta (response) que será uma página em HTML ou uma imagem, por exemplo. A seguir, apenas um exemplo simples sobre o uso de um servlet: 1 - import javax.servlet.*; 2 - import javax.servlet.http.*; 3 - import java.io.*; 4 - 5 - public class Pessoa extends HttpServlet { 6 - public void doGet(HttpServletRequest request, HttpServletResponse response) 7 - throws ServletException, IOException { 8 - 9 - PrintWriter out = response.getWriter(); 10 - out.println("<html><head><title>Ola Mundo</title></head><body>"); 11 - out.println("Exemplo Hello World"); 12 - out.println("</body></html>"); 13 - } 14 - } Este exemplo é muito simples e implementa apenas um método de um servlet, abstraindo algumas informações. Nas linhas de número 1 a 3, há as importações de pacotes de classes para a utilização dos servlets. Na linha 5, a declaração da classe que deve, obrigatoriamente, estender a classe HttpServlet. O método doGet(), na linha 6 recebe como parâmetros as requisições e respostas, de forma que o mesmo possa “conversar” com o navegador cliente. Em sua continuação, existe um throws, que indica que as exceções que podem ocorrer são conhecidas, porém, não serão tratadas neste momento. Cria-se um objeto da classe PrintWriter na linha 9, que será o responsável pela saída que será apresentada no navegador. Nas linhas seguintes esse objeto chamará o método println e passará parâmetros para que a saída seja configurada. As servlets residem na memória do servidor após serem instanciadas, apenas um objeto é criado e as páginas suportam acesso de múltiplos usuários. A partir disto, obtem- se os múltiplos fluxos de execução (multithreading) que ajudam na eficiência e escalabilidade, desde que haja sincronização no acesso a recursos compartilhados. JSP (Java Server Pages)
  • 57. 53 As servlets, apresentadas anteriormente, são capazes de gerar dinamicamente o conteúdo de uma página web. Todavia, o desenvolvedor precisa gerar uma grande quantidade de código HTML emaranhado com as classes. Acrescentado a isso, as servlets deixam a camada de apresentação e a camada de negócios bastante próximas, tornando difícil uma real separação dessas camadas. Com JSP (Java Server Pages) a simplicidade na codificação é atingida e é possível definir que as JSP’s são servlets escritas em HTML, com código em Java simples misturado. Isso torna o código JSP legível até para pessoas que não tem ampla experiência em Java. Cabe, neste momento, salientar que as servlets geram código HTML a partir do código em Java e as JSP’s adicionam código Java no próprio HTML. Abaixo um exemplo de uma página codificada em JSP: 1 - <HTML> 2 - <HEAD><TITLE>Olá Mundo!</TITLE></HEAD> 3 - <BODY> 4 - <% String name = request.getParameter(“name”); %> 5 - <H1> Hello, <%=name%> </H1> 6 - </BODY> 7 – </HTML> Das linhas 1 a 3 há somente o código HTML em si, posteriormente, nas linhas 4 e 5, existe um processamento que faz menção a um parâmetro previamente recebido (de um formulário em outra página, por exemplo). Todos os elementos do JSP são, assim como HTML, colocados entre sinais de maior e menor (< >), porém, ao contrário da linguagem de marcação o JSP é sensível ao contexto, ou seja, diferencia maiúsculas de minúsculas. Os elementos JSP ainda possuem uma diferença do HTML pelo fato de os mesmos serem iniciados com <% ou <jsp:. Apesar de o exemplo ser bastante curto, ele demonstra bem a disposição do código JSP perante o código HTML e como os mesmos podem ser trabalhados juntos de forma eficaz para a aplicação. Dentro do código de JSP existem 3 elementos de scripts que são responsáveis por: criar e acessar objetos; definir métodos e variáveis; gerenciar o controle do fluxo da aplicação, entre outros. Esses elementos, por sua vez, separam-se em: • Declarações: Introduz a declaração de um método ou variável.
  • 58. 54 <%! String nome = “Jhon Teddy”; int idade = 32; %> • Expressões: São instruções avaliadas cujo resultado é convertido em uma String para apresentação na página HTML. <%= nome %> • Scriptlets: Trechos de código processados quando uma requisição é recebida pela página do JSP. Pode, assim como as declarações, ser utilizado para criar variáveis, desde que as mesmas tenham escopo de cada requisição. <% String grade = request.getParameter(“nota”); %> 2.6.2.2 Implementação de Componentes de Negócio Finalizando os conceitos de componentes, a implementação dos componentes de negócio demonstra os Enterprise JavaBeans. EJB (Enterprise JavaBeans) A lógica do negócio de uma aplicação pode perfeitamente ser implementada em objetos Java simples, contudo, segundo Bond et. al (2003), utilizando os Enterprise JavaBeans é possível implementar toda essa lógica do negócio e contar com a resolução de muitos problemas que serão encontrados usando objetos Java simples, como é o caso da escalabilidade, gerenciamento de estados, ciclo de vida, entre outros. O contêiner EJB é responsável por gerir o número de EJBs que estão sendo utilizados e quais recursos (hardware e software) estes estão usando. Há, ainda conforme Bond et. al (2003), algumas recomendações para o uso do EJB e eles devem destinar-se a: aplicações web que exijam alto nível de escalabilidade e sejam manuteníveis; softwares de duas camadas, com aplicativos Swing, que precisam compartilhar lógica de negócio entre os clientes; construção de soluções para B2B (Business- to-business) e comércio eletrônico; integração de diferentes aplicativos corporativos.
  • 59. 55 Existem três tipos de EJB diferentes, convenientes para cada finalidade, são eles: • EJB de sessão: usado com finalidade de mapear o fluxo do processo de negócios, podem ser sem estados ou com estados e representam a funcionalidade simples da aplicação; • EJB de entidade: são criados com base em repositório de dados existentes. • EJB dirigido por mensagem: similar ao primeiro tipo, todavia, seu acionamento depende da recepção de uma mensagem assíncrona. 2.6.3 Comparativo com outras tecnologias É importante salientar que há várias tecnologias que podem ser aderidas para aplicações web e o JavaEE não é uma unanimidade absoluta. Há principais concorrentes, como a Microsoft© que tem o produto .NET cuja amplitude da utilização é bastante similar ao JEE. Além dela há uma combinação conhecida por LAMP. Existem no mercado outras plataformas de desenvolvimento e execução de aplicações distribuídas. É valido observar as características de cada uma delas ao escolher qual plataforma adotar para o desenvolvimento de aplicações. Dentre as plataformas disponíveis no mercado, que fazem concorrência à JEE, destacam-se a .Net (dot Net) da Microsoft Corporation® e a denominada plataforma LAMP, acrônimo para Linux, Apache, Mysql e PHP, ou outras linguagens iniciadas com a letra P (Perl, Python). A plataforma LAMP é muito popular entre os desenvolvedores de aplicações web. Seu sucesso deve-se em grande parte ao uso de recursos gratuitos e de bom desempenho. Porém, questões sobre segurança e falta de padrões de desenvolvimento são fatores que fazem com que a plataforma não seja fortemente utilizada em aplicações empresariais de grande porte. Também tem se empregado o termo LADP, substituindo o ‘M’ do MySQL por ‘D’ de Database, onde outro SGBD mais adequado a cada aplicação pode ser adotado. Entre as plataformas JEE e .NET é observada maior semelhança. Segundo Macoratti(2004), ambas possuem o foco no mercado de aplicações corporativas e Web
  • 60. 56 Services. A JEE é baseada na linguagem JAVA e é multiplataforma; enquanto .NET é baseada na plataforma Windows, porém podendo suportar diversas linguagens. Na JEE fica- se restrito a linguagem JAVA, na .NET fica-se restrito a plataforma Windows. JEE consiste em um conjunto de padrões permitindo que diversas empresas forneçam soluções para a plataforma, como servidores de aplicação, IDEs (Integreted Development Environment), frameworks. .NET é um produto proprietário da Microsoft® que conta com um esforço isolado da mesma para o desenvolvimento de soluções para a plataforma. Ainda de acordo com Macoratti(2004), ambas possuem boa integração com sistemas legados, ferramentas de desenvolvimento rápido, suporte a Web Services. Porém a plataforma JEE ganha em portabilidade pela independência de plataforma, o que é um ponto forte ao se tratar de web e de sistemas distribuídos de uma forma geral. 2.6.4 CONSIDERAÇÕES FINAIS Com o estudo fica demonstrado a estrutura do padrão MVC e como ela contribui na construção de soluções de qualidade. Além disso, foram apresentados os principais frameworks Java que podem ser aplicados na implementação do padrão com ênfase para o framework JSF (Java Server Faces) que é a ferramenta de apoio para desenvolvimento do estudo de caso do projeto. A especificação JavaEE recebeu uma definição objetiva, visando à estrutura e os principais componentes que serão utilizados também no estudo de caso.
  • 61. 57 3 ESTUDO DE CASO 3.1 CONSIDERAÇÕES INICIAIS Com intuito de uma demonstração prática a respeito da pesquisa realizada sobre o padrão MVC, o estudo de caso definido é uma aplicação baseada em um CRM (Customer Relationship Management). Os sistemas do tipo CRM visam atender, reconhecer e cuidar das necessidades dos clientes perante a empresa, de forma que seja possível traçar um perfil, criando um relacionamento único entre ambos. Conforme Goes Filho (2009), os CRM’s tem uma tipologia bem definida que difere qual vertente o mesmo procura atender: • CRM Operacional: Criação de canais de relacionamento com o cliente; • CRM Analítico: Visão consistente do cliente, obtendo dados a partir de um CRM Operacional, para obter conhecimento, otimizar e gerar novos negócios; • CRM Colaborativo: Obtenção de valor do cliente, através de colaboração inteligente, baseada em conhecimento. Considerando os tipos de aplicação de cada uma das tipologias, o nível de conhecimento e a dependência de informações que os sistemas exigem, é definido que a essência de um CRM operacional é melhor aplicada para o estudo de caso. Justificando ainda que o CRM em si seja um sistema muito amplo e como o foco é uma demonstração da aplicação de padrões, o projeto desenvolvido aborda uma parte deste gênero de software. 3.2 MODELAGEM DO PROJETO Seguindo as especificações da UML (Linguagem de Modelagem Unificada), a seguir serão apresentados os modelos para o projeto.
  • 62. 58 3.2.1 Descrição narrativa do sistema Deverá ser construído um sistema que atenda às seguintes áreas de uma organização: • Comercial; • Relacionamento com clientes; • Cobranças; • Mala direta. O sistema visa criar e gerenciar um registro de todas as relações da empresa com cada um de seus clientes, gerenciando funcionalidades triviais em cada uma das áreas citadas. Comercial O sistema deverá criar um registro de acompanhamento de todas as atividades que ocorrerem durante qualquer relacionamento com o cliente, registrando dados como: descrição, observações, datas e horários, responsáveis, prioridade e o que mais for pertinente. Marcar visitas que forem realizadas entre ambas as partes, armazenando dados como: contato, horário, local, motivo, resultados e demais informações cabíveis. Relacionamento com clientes Registrar relatos de todas as opiniões do cliente (positivas ou negativas), sugestões, reclamações e elogios. Fornecer um dispositivo para pesquisar a satisfação dos clientes como trabalhos realizados e resultados obtidos. Cobranças Registrar eventos relacionados às movimentações financeiras de cada cliente com a empresa, armazenando dados de ligações (data, motivo, quem atendeu, quem ligou), visitas e eventos, ou seja, tudo que ocorrer no processo de pagamentos e recebimentos junto aos clientes. Mala Direta (Newsletter) Dispositivo de envio de mensagens eletrônicas para os clientes. Fornece uma segmentação simples através de filtros.
  • 63. 59 3.2.2 Especificação dos requisitos do sistema O sistema deve ser capaz de criar contas de usuários para seus utilizadores, estes estarão divididos em três diferentes tipos de usuários, administrador, intermediário e auxiliar. Cada um terá as devidas restrições para o uso das funcionalidades do sistema. Somente o usuário com o nível de administrador, poderá criar novas contas de usuários. Deve haver um cadastro para novos clientes no sistema. Para que seja possível o registro de atividades, relatos por parte do mesmo, pesquisas de satisfação e todas as demais funcionalidades relativas aos clientes, o mesmo precisa ser previamente cadastrado. Neste cadastro deverá constar todas as informações necessárias para total identificação e contato com o cliente. Esta será umas das funcionalidades mais triviais do sistema e estará aberta para que qualquer nível de usuário possa fazê-lo. Para todo cliente cadastrado, existirá um registro de todas as atividades que ocorrerem por parte da empresa junto ao mesmo. Essas atividades consistem em qualquer interação que ocorra entre a empresa e o cliente. Haverá também um registro de todas as visitas que forem efetuadas entre ambas as partes, cliente e empresa. E também um registro de todos os relatos feitos pelo cliente sobre qualquer assunto que seja. Existirá uma funcionalidade que possibilitará que usuários de nível a partir do intermediário possam enviar aos clientes cadastrados pesquisas de satisfação com os serviços e relação com a empresa. Para controle financeiro, haverá também um registro de todas as interações que ocorrerem com finalidade de pagamentos e recebimentos do cliente para a empresa. Estas interações podem ser: ligações, visitas, correspondências, etc. Esta funcionalidade será acessível apenas para usuários do tipo administrador. Haverá ainda um dispositivo para o envio de mensagens eletrônicas para os clientes. Esta funcionalidade estará disponível para usuários do tipo intermediário e administrador. Para o envio destas mensagens deve ser possível que o usuário selecione um ou mais clientes específicos, através de filtros que permitam segmentar os clientes. Para maior eficiência e confiabilidade do sistema, o mesmo deve possuir dispositivos de segurança para impedir que usuários não autorizados acessem o sistema ou que determinados usuários acessem recursos não permitidos. Deve também relatar quando houver falhas no envio das mensagens eletrônicas para determinado cliente, afim de que possa ser realizado um re-envio da mensagem.
  • 64. 60 O sistema deverá possuir uma interface com o usuário criada sobre a plataforma da web, para que seja acessível, por todos os níveis de usuário com todas as funcionalidades citadas, através de um navegador em qualquer dispositivo com acesso a Internet. Deverá também possuir uma interface para celular que possuirá apenas as funcionalidades de cadastrar um novo cliente e consultar informações sobre o mesmo. Possuirá também uma interface criada para máquinas desktop que conterá apenas a funcionalidade criar conta de usuário. 3.2.3 Diagrama de casos de uso do sistema O software sugerido possui alguns casos de uso separados de acordo com os níveis de usuários. Conforme citado anteriormente, há três níveis diferentes, sendo que o nível hierarquicamente mais alto (administrador) pode executar, além de suas tarefas específicas, todas as tarefas dos níveis abaixo do seu (intermediário e auxiliar). Logo, o nível de acesso intermediário também tem permissão maior que auxiliar. Portanto, além das tarefas a si designadas, consegue acesso às tarefas do outro usuário em questão. Completando, o cliente também interage com o sistema, respondendo o questionário enviado por usuários de nível intermediário ou administradores. Seguindo essa linha dos níveis de usuário, cabe definir alguns papéis que cada um deles executa perante o sistema e explanar mais esses termos para uma boa compreensão geral do domínio do sistema. Na representação gráfica por meio dos diagramas de casos de uso da UML, onde são demonstrados os atores e os papéis de cada um, o ator denominado auxiliar tem para si algumas atividades especificas como é o caso de cadastrar novos clientes no sistema, a partir de informações coletadas junto a esses clientes e ainda efetuar o registro de todas as atividades que ocorram junto a um cliente, como o caso de visitas, telefonemas, dentre outras. O ator auxiliar ainda conta com as tarefas de consultar informações dos clientes para estabelecer contatos com os mesmos e, por último, o auxiliar pode cadastrar relatos do cliente. Relatos estes que são independentes da pesquisa de satisfação que é respondida pelo cliente em si.
  • 65. 61 Atores com a denominação de auxiliar podem ser associados a pessoas envolvidas com tarefas rotineiras da organização, como é o caso de secretárias. Prosseguindo com os níveis de usuário, aqueles com o nível intermediário que podem ser ilustrados organizacionalmente como vendedores, entre outros, tem as tarefas de criar pesquisas de satisfação e enviar mensagens eletrônicas de acordo com a seleção dos clientes certos para envio das mesmas. Por exemplo, baseado em uma transação ou serviço com clientes da cidade qualquer, esse ator intermediário filtrará esses clientes e enviará mensagens de cunho comercial (marketing) para estes clientes. Além disso, os usuários intermediários têm a tarefa de registrar visitas realizadas as empresas dos clientes e/ou as visitas dos clientes na sede da sua organização. Os clientes interagem com o sistema respondendo as questões criadas pelo usuário intermediário. O ator administrador tem as tarefas de tratar os eventos financeiros de cada cliente, registrando as ligações de cobrança, as visitas com esta finalidade, entre outros. Finalizando, o administrador é responsável pela criação das novas contas de usuário e pela definição do nível de acesso destas contas. Figura 10 – Diagrama de casos de uso.
  • 66. 62 3.2.4 Diagrama de classes Conforme toda a análise de domínio da solução há a representação da estrutura e das relações entre as classes do projeto, sendo estas uma abstração de possíveis objetos detectados para o sistema. É importante salientar, neste momento, que por traçar um estudo de padrões de projeto, este é somente um diagrama de classes de domínio, sendo que no decorrer da pesquisa, há demonstrações de diagramas de componentes, bem como o detalhamento de cada um desses componentes de acordo com a solução que o mesmo implementar. Figura 11 – Diagrama de classes. Demonstrado anteriormente, por se tratar de um CRM, a classe de cliente é o ponto central do sistema, associando-se assim, a maior parte das classes. Os conjuntos de multiplicidades destacam a participação das classes nestas associações. 3.2.5 Diagrama de componentes
  • 67. 63 Um diagrama de componentes é a representação de um módulo físico do código, ou seja, muitas vezes está vinculado a um pacote, ou mesmo a projetos que se inter- relacionam. Assim sendo, a seguir (figura 12) fica demonstrada uma visão geral sobre o diagrama de componentes do projeto CRM, sendo que no decorrer do capítulo de implementação, haverá descrições detalhistas sobre cada componente e quais pacotes compõem o mesmo. Figura 12 – Diagrama de componentes. São representados na imagem: • CRM_Library que trata-se da camada de modelo do MVC, onde há a lógica de negócios, regras de acesso a dados, entre outros. Todos os demais projetos utilizam o mesmo como modelo; • CRM_web e CRM_desktop implementam, dentro de sua estrutura interna, a visão e o controlador. E fazem uso do CRM_Library. • O componente que possui uma leve diferenciação dos demais é o CRM_mobile, que exige a existência de um web service (representado pelo componente CRM_mobileWS) atuando como controlador, para que o mesmo estabeleça a conexão com o modelo que executa o acesso a dados em um SGBD (Sistema Gerenciador de Banco de Dados). A view do CRM_mobile, é a única implementação interna deste componente.
  • 68. 64 3.2.6 Diagrama de entidade-relacionamento Para melhor ilustrar a solução, foi criado o diagrama de entidade- relacionamento, onde cada elemento do mundo real é observado como uma entidade e são definidos os relacionamentos entre essas entidades. A partir deste diagrama é feito o mapeamento para o modelo relacional que findará na construção do projeto físico da base de dados, ou seja, findará na criação das tabelas (relações). Figura 13 – Diagrama de entidade-relacionamento. 3.3 CONSIDERAÇÕES FINAIS A modelagem de sistemas é uma etapa fundamental que permite descobrir os principais elementos que devem ser tratados durante a implementação. Com uma modelagem concisa é possível prevenir a incidência de grande porcentagem dos erros possíveis em um
  • 69. 65 projeto e, ainda, desenvolver a partir de um modelo é muito mais simples do que com mera experiência sobre um problema. Este capítulo apresentou o estudo de caso sobre a simulação de um CRM operacional que permite demonstrar todo o uso do padrão de projeto estudado, bem como fornecerá requisitos para aprimoramento efetivo em soluções de software visando atingir maior qualidade durante o desenvolvimento. O capítulo que sucede traz apresentada a implementação do software e os principais resultados obtidos.
  • 70. 66 4 IMPLEMENTAÇÃO DO ESTUDO DE CASO 4.1 CONSIDERAÇÕES INICIAIS O software desempenha seu papel principal baseado na web, porém conta com suas vertentes para executar em dispositivos móveis e desktop, desde o início, boas regras de programação tiveram de ser tratadas para evitar o acarretamento de problemas futuros. Logo, durante o desenvolvimento houve separações de packages (pacotes) e também de projetos em si. Para demonstração total desta estrutura, como também foi definido nos diagramas de componentes apresentados no capítulo anterior, a seqüência da pesquisa demonstra a implementação do estudo de caso e seus projetos específicos. 4.2 DESENVOLVIMENTO DA CAMADA MODELO CRM LIBRARY No padrão de projeto MVC estudado durante a pesquisa, fica explicito que o modelo é uma camada extremamente importante para aplicação, sendo que este é responsável por conter a lógica de negócios, além de tratar diretamente o acesso a dados em uma base de dados privativa. Cabe salientar que é possível haver a combinação de mais de um padrão de projeto, como ocorreu na implementação do CRM Library. Essa combinação se deu ao fato da utilização dos patterns DAO (Data Access Object) e Factory. O DAO, que visa abstrair a origem e modo de obtenção/gravação dos dados em uma base. Este pattern deve funcionar como um tradutor entre os conjuntos de relações e chaves de um banco de dados e os objetos de uma linguagem de programação. Portanto, o DAO efetivamente utilizado na solução do CRM Library, permite que seja unificado o acesso a dados da aplicação, evitando que o código acesse os dados em diferentes locais (o que tornaria este código fortemente acoplado e pouco manutenível).
  • 71. 67 O pattern citado (Factory), que também teve uma simples utilização do projeto, trabalha como uma ‘fábrica de objetos’, onde ao invés de instanciar cada objeto com new e o construtor de sua classe, ele simplesmente isola o modo de criação de objetos. Assim sendo, o CRM Library trabalhará como o modelo de todas as outras aplicações desenvolvidas. Neste modelo, há a divisão de três pacotes específicos (br.crm.model.dao, br.crm.model.dao.implementation e br.crm.model.entities) que são representados na figura a seguir e estão detalhados nos subitens da continuação do capítulo. Figura 14 – Representação do CRM_Library (camada modelo). Com essas considerações, no estudo de caso em questão, foi determinado o uso do SGBD (Sistema Gerenciador de Banco de Dados) MySQL, que é de ampla utilização em servidores web por ser extremamente simples e de fácil utilização.
  • 72. 68 4.2.1 Pacote br.crm.model.entities Este é o pacote mais simples da implementação do projeto Library. É constituído unicamente das classes do sistema que, por sua vez, contêm seus atributos e métodos. Apesar de sua simplicidade, este pacote é de ampla importância para aplicação como um todo. Pode-se fazer uma analogia entre estas classes e as entidades do diagrama de Entidades-Relacionamentos do banco de dados e as classes que aqui foram definidas, serão utilizadas no projeto completo por toda a parte. Cabe comentar que na imagem anterior foram omitidas algumas informações de associações entre as classes, tornando os pacotes mais visíveis. 4.2.2 Pacote br.crm.model.dao No pacote br.crm.model.dao é onde estão aplicados os padrões DAO e Factory, que estão combinados com o MVC do estudo em questão. Neste pacote, serão implementadas todas as interfaces que somente definem as assinaturas de seus métodos sem implementá-los. Posteriormente, no pacote definido no próximo item, veremos a implementação destes métodos definidos nas interfaces tratadas aqui. Abaixo, selecionou-se um trecho do código-fonte da interface AtividadeDao que traz somente as assinaturas de métodos e após ela, da classe DaoFactory que funcionará como a fábrica de objetos citada anteriormente: 1 - package br.crm.model.dao; 2 - 3 - import br.crm.model.entities.Atividade; 4 - import java.util.Date; 5 - import java.util.List; 6 - 7 - public interface AtividadeDao { 8 - 9 - public Atividade inserir(Atividade atividade); 10 - public Atividade salvar(Atividade atividade); 11 - public Atividade apagar(Atividade atividade); 12 - public Atividade buscar(Integer codigo); 13 - public List listarPorPrioridade(Integer prioridade); .
  • 73. 69 . . } 1 - package br.crm.model.dao; 2 - 3 - import br.crm.model.dao.implementation.*; 4 - import br.crm.model.dao.*; 5 - public class DaoFactory 6 - { 7 - 8 - public static AtividadeDao createAtividadeDao() 9 - { 10- return new JdbcAtividadeDao(); 11 - } . . . } Demonstrados esses códigos da interface AtividadeDao e da classe DaoFactory, é importante comentar que na linha 8 do segundo trecho de código, onde existe um método de classe (estático) que permite a criação dos objetos sem haver a instanciação com new e de acordo com o tipo de objetos necessitado (neste caso, criou-se objetos do tipo JdbcAtividadeDao que estão presentes no pacote br.crm.model.dao.implementation). 4.2.3 Pacote br.crm.model.dao.implementation Para não embaralhar o código de acesso a dados com o restante do código da aplicação existe esse pacote que é a unificação do acesso a dados em somente um local. Neste pacote, todas as operações conhecidas como CRUD (Create, Retrieve, Update and Delete) serão efetuadas. Especificamente na implementação do CRM Library foi definida a utilização da API nativa do Java, a JDBC (Java Data Base Connectivity), contudo, com o código unificado desta forma, este pacote de implementações de JDBC poderia ser facilmente substituído por outros métodos de armazenamento de dados, como a utilização do framework Hibernate ou até a utilização de arquivos texto. Durante a criação do banco de dados foi utilizado somente o padrão SQL puro, evitando o uso de triggers e procedures, desta forma, é notável a possibilidade de migração de
  • 74. 70 base de dados. Por exemplo, atualmente a aplicação encontra-se em uma base gerenciada pelo SGBD MySQL, caso futuramente necessite ser feita uma migração para um SGBD mais robusto como Oracle, basta mudar um arquivo no pacote br.crm.model.dao.implementation (JdbcConexao) e o resultado será obtido desde que o banco seja migrado com sucesso. 4.2.4 Conceitos da utilização do modelo na aplicação Em todo o restante do projeto utilizou-se o CRM Library como camada de modelo da aplicação. Na figura que segue, uma demonstração retirada da IDE (Integrated Development Environment) Netbeans durante o desenvolvimento do projeto CRM_desktop que demonstra o uso do projeto Library importado como uma biblioteca. Figura 15 – Utilização do modelo nos outros projetos. 4.3 DESENVOLVIMENTO DO APLICATIVO CRM WEB O foco principal do desenvolvimento foi a demonstração da aplicabilidade do MVC em projetos web. Logo, todas as funcionalidades definidas foram implementadas neste projeto. Aqui é onde podem ser observados os três níveis de usuários (administrador, intermediário e auxiliar)
  • 75. 71 No desenvolvimento do aplicativo web, foi necessário implementar as camadas de view e controller, sendo que a camada de modelo utilizada foi a CRM Library demonstrada anteriormente. A implementação da view baseou-se na utilização do framework JSF (Java Server Faces) que está presente na especificação do JEE. Agregado ao framework foi utilizada a biblioteca richfaces que permite melhor tratamento visual de componentes de interação com usuário, além de fornecer atrelado a si o tratamento de eventos em Ajax. O resultado obtido foram as páginas JSP que o usuário interagirá. Para desenvolver o controller foram utilizados Beans que serão responsáveis por captar os eventos dos usuários na view e, atualizar ou chamar o modelo, receber a notificação de resposta e devolver para a view os resultados obtidos. Além desses componentes há o phaselistener que é da especificação do JSF e sua função é interceptar as fases do ciclo de vida de requisições do usuário. A seguir (figura 16), para melhor ilustração, o projeto web e seus pacotes:
  • 76. 72 Figura 16 – Representação do CRM_Web (camadas de controle e visão). 4.3.1 Pacote br.crm.web.controller O pacote br.crm.web.controller, conforme citado, implementa os Beans que aguardam os eventos do usuário na view e, a partir disso, executa a interação com o model. Para demonstrar, um trecho do código da classe ClienteBean a partir da chamada do método editar, em um formulário de edição de clientes na view. 1 - package br.crm.web.controller; 2 - 3 - import br.crm.model.dao.ClienteDao; 4 - import br.crm.model.dao.DaoFactory; 5 - import br.crm.model.entities.Cliente; 6 - import java.util.ArrayList;
  • 77. 73 7 - import java.util.List; 8 - import javax.faces.application.FacesMessage; 9 - import javax.faces.context.FacesContext; 10 - import javax.faces.model.SelectItem; 11 - import javax.servlet.http.HttpServletRequest; 12 - 13 - public class ClienteBean 14 - { 15 - . . . 16 - public ClienteBean() { 17 - this.cliente = new Cliente(); 18 - } . . . 19 - public String editar() 20 - { 21 - 22 - HttpServletRequest request = (HttpServletRequest)FacesContext.getCurr entInstance().getExternalContext().getRequest(); 23 - Integer codigo = Integer.parseInt( request.getParameter( "codigoClienteEditar") ); 24 - ClienteDao clienteDao = DaoFactory.createClienteDao(); 25 - setCliente( clienteDao.buscarPorCodigo(codigo) ); 26 - 27 - if ( getCliente() != null ) 28 - return "editarCliente"; 29 - else 30 - return "erro"; . . . 31 - } Na linha 22 há a obtenção de uma requisição do usuário na qual existe o parâmetro de um cliente que será editado, posteriormente esta requisição obtida é atribuída em uma variável denominada código (linha 23) e com esta informação é feita a criação de um objeto do modelo, (clienteDao, linha 24) e é chamado um método buscarPorCodigo( código) deste objeto. Com isso fica demonstrada a interação do controller com a view e diretamente com o model. 4.3.2 Pacote br.crm.web.phaselistener Como ele intercepta as fases do ciclo de vida das requisições, o phaselistener deste projeto implementa o controle de acessos do sistema, ou seja, antes que uma página
  • 78. 74 possa ser acessada por um usuário é verificado se o perfil do mesmo tem autorização para chegar até a página requisitada. 4.3.3 Implementação da visão do sistema A camada de visão é essencial ao sistema, pois é onde o usuário interage e recebe informações do sistema. Esta camada deve ser agradável, de fácil utilização e bastante intuitiva. Pensando nesses requisitos foram definidas todas as páginas, conforme citado na introdução sobre o projeto do CRM Web, utilizando o framework JSF que conta com uma boa definição para criação de interfaces de usuário. 4.4 EXECUÇÃO DO APLICATIVO CRM WEB Inicialmente, foi definido que há três tipos de usuário, cada qual com suas permissões dentro do sistema. Para efetuar esta diferenciação e para agregar um nível de segurança no projeto, logo na execução da aplicação, o usuário é direcionado para a tela de login, conforme demonstrado na figura 17 a seguir, onde fará sua identificação perante o sistema. Figura 17 – Aplicativo em execução (tela de login).
  • 79. 75 A partir do momento em que o login é realizado, há um filtro de páginas que o usuário pode ou não acessar, sendo assim, a seguir existem três páginas iniciais nas figuras 18, 19 e 20, uma para cada tipo de usuário. Figura 18 – Tela inicial (usuário de perfil auxiliar). Figura 19 – Tela inicial (usuário de perfil intermediário).
  • 80. 76 Figura 20 – Tela inicial (usuário de perfil administrador). A diferença entre os perfis anteriormente apresentados é a mesma definida nos diagramas de casos de uso, onde nos perfis mais restritos, o menu principal não apresenta os links para as telas de cobrança, além disso, um usuário de perfil auxiliar não pode enviar mensagens para os clientes, dentre outros. A partir da tela inicial, serão apresentadas algumas das funcionalidades destinadas a cada usuário, lembrando que a criação de novos usuários está somente restrita para administradores e que esta função só foi implementada no CRM Desktop, dando um nível ainda mais elevado na questão da segurança. 4.4.1 Funcionalidades disponíveis para o perfil Auxiliar Pelas definições feitas na especificação do software, o cliente pode fazer um relato da empresa perante um serviço executado, uma situação vivida ou quaisquer atividades. Assim sendo, a seguir são apresentadas uma tela de cadastro de relatos (figura 21), seguida da exibição dos relatos cadastrados (figura 22). Lembrando que esta função está no nível mais baixo de permissão, podendo ser acessível por qualquer usuário.
  • 81. 77 Figura 21 – Tela de cadastro de relatos (acessível por qualquer perfil). Visando um melhor entendimento e didática da solução, segue trechos do código da página cadastrar_relato.jsp, com sua explicação para demonstrar a eficácia do uso do JSF. 1 - <%@page contentType="text/html" pageEncoding="UTF-8"%> 2 - 3 - <%@taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> 4 - <%@taglib prefix="f" uri="http://java.sun.com/jsf/core"%> 5 - <%@taglib prefix="h" uri="http://java.sun.com/jsf/html"%> 6 - <%@taglib prefix="a4j" uri="http://richfaces.org/a4j"%> 7 - <%@taglib prefix="rich" uri="http://richfaces.org/rich"%> 8 - . . . 9 - 10 - <rich:messages globalOnly="true" styleClass="mensagens" /> 11 - 12 - <rich:panel header="Cadastrar Relato" style="margin:0 auto" id="cadastrarRelatoBox"> 13 - 14 - <h:form> 15 - <h:panelGrid columns="3"> 16 - <h:outputLabel value="Cliente" for="cliente"/> 17 - <rich:inplaceSelect id="cliente" value="#{relatoBean.relato.codCli}" required="true" requiredMessage="Este campo é obrigatório" openOnEdit="true" editEvent="onclick" defaultLabel="Selecione um cliente"
  • 82. 78 styleClass="inplaceSelect" viewHoverClass="viewHoverInplaceSelect" viewClass="viewInplaceSelect" changedClass="inplaceSelect" editClass="inplaceSelect"> 18 - <f:selectItems value="#{clienteBean.selectClientes}" /> 19 - </rich:inplaceSelect> 20 - <h:message errorClass="erroValidacao" for="cliente"/> 21 - 22 - <h:outputLabel value="Descrição" for="descricao"/> 23 - <h:inputText required="true" requiredMessage="Este compo é obrigatório" id="descricao" value="#{relatoBean.relato.descricao}"/> 24 - <h:message errorClass="erroValidacao" for="descricao"/> 25 - 26 - <h:outputLabel value="Data/Hora" for="dataHora"/> 27 - <rich:calendar value="#{relatoBean.relato.dataHora}" id="dataHora" datePattern="dd/MM/yyyy HH:mm"></rich:calendar> 28 - <h:message errorClass="erroValidacao" for="dataHora"/> . . . 29 - <h:commandButton styleClass="botaoForm" value="Cadastrar" action="#{relatoBean.inserir}"/> 30 - </h:form> 31 - </rich:panel> . . . Neste trecho de código, as linhas de 3 a 7 tratam-se das referências as bibliotecas utilizadas, como é o caso do richfaces e da a4j (Ajax for Java). Na linha 12 o elemento <rich:panel> traz um agradável painel que não necessita de muitas configurações para ficar visivelmente bonito ao usuário, além disso, dentro do richfaces, há componentes como o <rich:inplaceSelect> e o <rich:calendar> (linhas 17 e 27, respectivamente) que tornam a aplicação mais amigável e de fácil aprendizado. Nos atributos values da maior parte dos componentes, nota-se que há uma chamada para os Beans, neste caso relatoBean. Fica demonstrado, portanto, a efetivação do conceito de view e controller conversando entre si, ou seja, quando o cliente preenche uma informação e promove a ação sobre o botão cadastrar, este chamará o método inserir de relatoBean, que por sua vez será responsável pelas notificações com a camada de modelo da aplicação.
  • 83. 79 Figura 22 – Visualização de relatos (acessível por qualquer perfil). Nas telas de exibição, tanto dos relatos como a da maior parte das funcionalidades do sistema, as informações são apresentadas em componentes <rich:dataTable> cujo resultado é demonstrado na parte inferior da figura 22. Esse componente tem uma característica interessante que é a ordenação, onde por cada coluna desta tabela (como é o caso dos relatos onde há colunas de Cliente, Data/Hora, Relator, Descrição, Mídia e Status) é possível ordenar de forma crescente e decrescente. Além desta característica, acima do componente citado anteriormente há variados filtros que podem ser aplicados visando buscar um relato especificamente. Os relatos podem ser filtrados por Cliente, Data/Hora, Status e Mídia. Acrescido ainda da possibilidade de fazer um filtro composto, como por exemplo, cliente X, com status positivo e cuja mídia do relato é o email. 4.4.2 Funcionalidades disponíveis para o perfil Intermediário O usuário de perfil definido como intermediário tem acesso total as funcionalidades do perfil abaixo ao seu (auxiliar) e conta com algumas tarefas específicas, assim sendo, a seguir (figura 23 e 24) uma tela de envio de mensagens aos clientes e a visualização destas mensagens. Ressaltando ainda que o envio das mesmas é feito através do e-mail cadastrado para os clientes que forem selecionados como destinatários.
  • 84. 80 Figura 23 – Tela de envio de mensagens (acessível por perfil intermediário ou superior). Figura 24 – Visualização de mensagens (acessível por perfil intermediário ou superior). 4.4.3 Funcionalidades disponíveis para o perfil Administrador
  • 85. 81 Finalmente, para os usuários com permissão irrestrita dentro do sistema (administradores), cabe também como funções especificas a visualização e inserção das cobranças junto ao cliente (figura 25 e 26). Figura 25 – Tela de cadastro de cobranças (acessível por perfil administrador). Figura 26 – Visualização de cadastro de cobranças (acessível por perfil administrador). Assim, ficam demonstrados os resultados da implementação do projeto mais completo do estudo de caso. Há algumas outras funções que aparecem nos menus, contudo, para demonstrar o estudo e a eficiência dos padrões de projeto, não se faz necessário a presença de todas as telas.
  • 86. 82 4.5 DESENVOLVIMENTO DO APLICATIVO CRM DESKTOP Para atender à especificação do projeto e com o objetivo de demonstrar como o padrão MVC possibilitou um forte desacoplamento entre as responsabilidades de cada parte do código, desenvolveu-se uma aplicação para rodar localmente como um aplicativo desktop. Assim como nos demais aplicativos, aqui coube apenas implementar as camadas de visão e controle, sendo que para a camada do modelo fez-se uso da biblioteca CRM_Library, já explicada anteriormente. Para a implementação das janelas e seus componentes, utilizou-se o pacote swing da API Java, auxiliado pelas funcionalidades da IDE NetBeans para a criação dos mesmos. Basicamente cada classe, demonstradas no diagrama a seguir (figura 27), consiste em uma janela do aplicativo desktop. Figura 27 – Classes do projeto CRM_Desktop. Este pacote já possui uma construção baseada no padrão MVC, uma vez que aplica o conceito de listeners para realizar o tratamento de eventos. Desta forma, os componentes visuais da API atuam como parte da view e os listeners que respondem aos eventos sobre os mesmos, atuam como controllers. Devido a esta arquitetura do swing, não se observa neste aplicativo a separação física de pacotes entre os códigos que implementam a visão e o controle.
  • 87. 83 Figura 28 – Desenvolvimento de janela com o NetBeans. Este aplicativo implementa somente a funcionalidade de cadastro de novos usuários e somente usuários de nível Administrador tem acesso à mesma. A seguir, partes do código retirado da classe Usuarios.java que implementa a janela e os controles para inserção, edição, alteração e navegação entre os usuários. 1 - private javax.swing.JButton btnProximo; 2 - btnProximo = new javax.swing.JButton(); 3 - 4 - btnProximo.setIcon(new javax.swing.ImageIcon(getClass().getResource("/br/crm/desktop/view/icons/up.png"))) ; 5 - btnProximo.setToolTipText("Próximo"); O trecho acima demonstra a declaração de um componente JButton do pacote swing e a configuração de alguns de seus atributos para definir a forma como ele deve aparecer na camada de visão. 1 - btnProximo.addActionListener(new java.awt.event.ActionListener() { 2 - public void actionPerformed(java.awt.event.ActionEvent evt) { 3 - ProximoHandler(evt); 4 - } 5 - }); 6 - 7 - private void btnProximoHandler(java.awt.event.ActionEvent evt) {
  • 88. 84 8 - if ( getIndexUsuario() < getListaUsuarios().size() - 1 ) 9 - { 10 - setIndexUsuario( getIndexUsuario() + 1 ); 11 - Usuario user = getListaUsuarios().get( getIndexUsuario() ); 12 - mostrarUsuario( user ); 13 - } 14 - } Neste outro trecho retirado da mesma classe, nas linhas de 1 a 5, um exemplo de como é atribuído um listener que faz o papel do controller tratando os eventos que ocorrerem sobre este botão. Nas linhas de 7 a 14 o método que é chamado pelo listener para efetuar alguma ação, neste caso, visualizar os dados do próximo usuário. 4.6 EXECUÇÃO DO APLICATIVO CRM DESKTOP Ao executar a aplicação, é exibida uma tela (figura 29) requerendo um nome de usuário e senha para acessar a aplicação. Conforme explicado anteriormente, somente usuários com perfil de Administrador conseguem fazer login neste aplicativo. Figura 29 – Tela de login do aplicativo desktop. Efetuando login corretamente, o usuário é direcionado para a tela principal da aplicação (figura 30), que exibe uma barra de menus com as opções possíveis para o usuário.
  • 89. 85 Figura 30 – Tela principal aplicativo desktop. Conforme explicado, este aplicativo implementa somente a funcionalidade para a manipulação de usuários. A seguir a tela onde é possível realizar todas as ações disponíveis com os registros de usuários. Na figura 31, estão destacados os botões que permitem a navegação entre os registros para a visualização dos dados de cada usuário.
  • 90. 86 Figura 31 – Botões de navegação entre os registros. Observa-se que os botões “Salvar” e “Cancelar” ficam desabilitados, assim como os campos de entrada de texto onde os dados são exibidos; estes ficam disponíveis somente quando se está fazendo uma operação de inserção ou edição de um usuário. Figura 32 – Edição de registro de usuário.
  • 91. 87 Ao realizar a operação de edição ou inserção, somente os botões “Salvar” e “Cancelar” ficam disponíveis, como demonstrado na figura 32. Ao salvar, um alerta é exibido informando sobre o sucesso na realização da operação. Cancelar a operação desfaz qualquer mudança não gravando os dados no banco de dados. Como ultima possibilidade de operação nesta janela, há o botão excluir que apaga o registro de um usuário do sistema. Figura 33 – Exclusão de registro de usuário. Antes de efetivar a exclusão do registro, uma mensagem é exibida para confirmando se o registro dever realmente ser excluído, a fim de evitar a perda de dados por falha ao operar o aplicativo. 4.7 DESENVOLVIMENTO DO WEB SERVICE CRM MOBILE WS A plataforma JME (Java Micro Edition) utilizada para implementar a solução para dispositivos móveis, não possui nativamente uma API para disponibilizar acesso a dados. Com isso, houve uma limitação durante o desenvolvimento da solução em que fez-se
  • 92. 88 necessário criar um web service com finalidade de obter a conexão com o banco a partir das classes do CRM_Library que o implementam. Figura 34 – Classe web service. Como a principal funcionalidade dos web services é fornecer comunicação para aplicações heterogêneas, esses serviços web trabalham com XML (Extesible Markup Language) e para se comunicar com o mesmo é necessário a implementação do SOAP (Simple Object Access Protocol). O serviço web implementado contém apenas a funcionalidade de buscar os clientes a partir de uma razão social fornecida, a seguir o código de implementação. 1 - package br.crm.mobile.webservice; 2 - 3 - import br.crm.model.dao.ClienteDao; 4 - import br.crm.model.dao.DaoFactory; 5 - import br.crm.model.entities.Cliente; 6 - import br.crm.model.entities.ClienteEmail; 7 - import br.crm.model.entities.ClienteEndereco; 8 - import java.util.ArrayList; 9 - import java.util.List; 10 - import javax.jws.WebMethod; 11 - import javax.jws.WebParam; 12 - import javax.jws.WebService; 13 - 14 - @WebService() 15 - public class ClienteService { 16 - @WebMethod(operationName = "selecionaClientes") 17 - public String selecionaClientes(@WebParam(name = "razaoSocial") 18 - String razaoSocial) { 19 - String retorno = ""; 20 - ClienteDao clienteDao = DaoFactory.createClienteDao(); 21 - List<Cliente> cliente = new ArrayList<Cliente>() ; 22 - cliente = clienteDao.listarClientesRazaoSocial(razaoSocial); 23 - for(int i=0; i<cliente.size();i++) 24 - { 25 - ClienteEndereco[] clienteEndereco = cliente.get(i).getEnderecos(); 26 - ClienteEmail[] clienteEmail = cliente.get(i).getEmails(); 27 - retorno += "--------------------------------------------------n" + 29 - " Nome: "+cliente.get(i).getRazaoSocial()+"n" + 30 - " Endereço: "+clienteEndereco[0].getEndereco()+"n" + 31 - " Email: " + clienteEmail[0].getEmail()+"n" + 32 - "----------------------------------------------------n"; 33 - 34 - } 35 - 36 - return retorno; 37 - } 38 - 39 - }
  • 93. 89 Na linha 17 existe a chamada para o método seleciona clientes, este mesmo método define um objeto clienteDao na linha 20 e um ArrayList do tipo Clientes na linha 21. Fornecidos estes objetos há a chamada do método listarClientesRazaoSocial(razaoSocial) que retornará o ArrayList que será utilizado como retorno. Para esta aplicação, o retorno é somente um tipo String por atender as necessidades da aplicação, contudo, como trabalha com uma linguagem baseada em XML (usualmente WSDL – Web Service Description Language) é possível receber retornos de tipos complexos, que implicariam na criação de parsers para obter valores efetivos. 4.8 EXECUÇÃO DE TESTES DO WEB SERVICE Após ser implantado o serviço, há a execução de testes do mesmo antes de efetuar o consumo do serviço por parte de uma aplicação. Figura 35 – Teste de um serviço web. 4.9 DESENVOLVIMENTO DO APLICATIVO CRM MOBILE Partindo inicialmente da situação que devemos criar uma aplicação para dispositivos móveis que consuma, ou seja, que utilize o web service desenvolvido, a estrutura do projeto por inteiro ficará como define o diagrama de componente detalhado a seguir:
  • 94. 90 Figura 36 – Representação do CRM_Mobile. A plataforma de criação do aplicativo para dispositivos móveis é a JME (Java Micro Edition) e a utilização da IDE NetBeans facilitou bastante na implementação do software. 4.9.1 Pacote br.crm.mobile.controller.ws Conforme citado anteriormente, utilizou-se a IDE NetBeans para criação do aplicativo móvel. Nesta ferramenta há a opção de criar um cliente JME para serviços web, conforme demonstrado na figura 37 a seguir:
  • 95. 91 Figura 37 – Criação de um cliente de serviços web em Java ME. Nota-se nesta janela de criação do cliente para serviços que deve ser passado como parâmetro a URL (Universal Resource Location) do WSDL que faz menção ao web service desenvolvido no projeto CRM_MobileWS (demonstrado no subitem anterior). Preenchida essa URL, é recuperado o WSDL do serviço e finalizando a construção é possível observar que a IDE gera automaticamente um código bastante valioso para aplicação. Trata-se de uma interface, que no projeto foi chamada de ClienteServiceService.java e uma classe de implementação desta interface que é a ClienteServiceService_Stub.java. 1 - package br.crm.mobile.controller.ws; 2 - import javax.xml.namespace.QName; 3 - 4 - public interface ClienteServiceService extends java.rmi.Remote { 5 - 6 - public String selecionaClientes(String razaoSocial) throws java.rmi.RemoteException; 7 - 8 – } A interface, demonstrada no código acima, somente contém a assinatura do método selecionaClientes(String razaoSocial). Contudo, a classe ClienteServiceService_Stub provê a estrutura necessária para a comunicação de rede, implementação de envio e
  • 96. 92 recebimento de mensagens SOAP, e tradução dos resultados para a classe Java correta, no caso, String, visto que o serviço retorna um string XML com os dados dos clientes cujo atributo razaoSocial era similar ao pesquisado. 4.9.2 Pacote br.crm.mobile.view Como a ferramenta de desenvolvimento executou toda a parte mais árdua que era a comunicação e empacotamento das mensagens transmitidas, cabe desenvolver somente as midlets que serviram de interface para o cliente, este pacote. Há duas classes neste pacote, sendo que a classe ClienteListarMidlet é responsável pela instância do web service, bem como a chamada de método para selecionar clientes, que há implementado no web service em questão. A partir da chamada de método, esta midlet verifica se o retorno é válido e repassa a informação para o usuário do aplicativo. A classe ClienteMidlet é responsável somente por carregar as informações na tela do usuário e gerenciar o que deve ser feito quando um usuário efetuar uma operação disponível. Contudo, esta classe é fundamental e é ela que é executada e carregada durante o projeto. 4.10 EXECUÇÃO DO APLICATIVO CRM MOBILE Aqui, para executar o aplicativo foi utilizado o próprio simulador da IDE disponível no NetBeans devido ao JME Wireless Toolkit. Este simulador facilita demasiadamente o trabalho do programador, pois sem sua presença, todas as alterações e testes teriam de ser enviados a um dispositivo móvel compatível, para posterior adequação caso fosse notado alguma discordância.
  • 97. 93 Figura 38 – Execução do CRM_Mobile. A imagem anterior (figura 38) apresenta um menu simples, com apenas uma funcionalidade que foi definida para demonstração do dispositivo móvel. A seguir (figura 39) a tela de busca por razão social.
  • 98. 94 Figura 39 – Tela de busca. Digitadas as informações da pesquisa e confirmado no botão buscar, é necessário confirmar uma autorização de conexão do dispositivo móvel com o web service responsável pelo papel de controlador do sistema, ou seja, responsável por intermediar as ações na view com as solicitações e notificações do model. Figura 40 – Confirmar conexão com web service.
  • 99. 95 Permitida esta conexão, são processadas as informações e quando o controller devolver o resultado para a view, os resultados são demonstrados, conforme figura a seguir. Figura 41 – Busca efetuada com sucesso. 4.11 CONSIDERAÇÕES FINAIS Este capítulo demonstrou como foi feita uma aplicação prática de todo o estudo realizado sobre padrões, na construção do estudo de caso descrito e modelado no capítulo 3. Durante a implementação observou-se a necessidade e a possibilidade de aplicação de outros padrões de projeto, em acréscimo ao MVC, como foram citados o DAO e o Factory. Também fez-se necessário o desenvolvimento de um web service para atender aos requisitos especificados, uma vez que o dispositivo de armazenamento escolhido foi banco de dados e não era possível realizar acesso direto à mesma na versão mobile do aplicativo em questão. O aplicativo, enfim, funcionou de forma correta perante os testes executados, atendendo de forma satisfatória. O próximo capítulo trará a conclusão geral do trabalho.
  • 100. 96 CONCLUSÃO Estudados durante as pesquisa e demonstrados na implementação, padrões de projetos não são soluções únicas que precisam atuar isoladas dentro de um sistema. Uma vasta combinação dos mesmos pode ser utilizada na facilitação da resolução de diversos problemas e necessidades. Eles não são uma solução específica para um problema específico, mas sim uma concentração de esforços e experiências sobre um determinado domínio de problema, abstraindo assim, as idéias de como solucionar tais situações. Tratando-se especificamente do padrão MVC, ficou comprovada sua eficiência na construção de sistemas complexos, compostos de diversas funcionalidades e requisitos de implantação. Ainda, sendo o MVC um padrão arquitetônico (categoria de padrões com o propósito de unir partes de um sistema) a possibilidade de combinações de outros padrões para resolver problemas específicos, foi marcante. No que diz respeito à qualidade, é inegável que o uso de padrões, sobretudo o MVC, promove grande melhoria em todos os processos que compõem todo o ciclo de vida de um software (concepção, análise, implementação, desenvolvimento, manutenção). O resultado de melhores processos são produtos melhores sob todos os pontos de vista, do usuário, do analista e do desenvolvedor. Ficou concluído que o desenvolvimento de softwares fazendo uso de padrões acarreta inicialmente maior complexidade na formação de uma estrutura, entretanto, no desfecho do desenvolvimento e posteriores manutenções, o trabalho fica simplificado. Outro ponto importante a salientar, foi de que ao realizar o desenvolvimento seguindo padrões, faz-se um uso efetivo e aprofundado de muitos conceitos da Orientação a Objetos que podem passar despercebidos por programadores menos experientes. Durante toda a pesquisa, buscou-se conhecer de forma aprofundada o que são, para que servem e por que utilizar padrões de projeto. Também, através da implementação de um estudo de caso, buscou-se conhecer quais as condições práticas ao fazer uso de padrões de projeto. Todas estas questões foram respondidas e os resultados obtidos foram satisfatórios. Novos trabalhos podem ser realizados seguindo a vertente da pesquisa aqui desenvolvida, entre eles, estudos sobre a utilização de frameworks variados, como é o caso do
  • 101. 97 Spring que é bastante grande e atende a uma ampla gama de situações, ou Struts e até mesmo o VRaptor. Entretanto, a elevação no nível de qualidade em todos os processos resultante de um desenvolvimento baseado em padrões foi um ponto marcante durante a pesquisa. Um espaço que fica para maiores pesquisas e trabalhos futuros, é a busca por mais recursos e conceitos que gerem um produto com alto grau de qualidade. Questões como melhores formas de gerenciamentos de recursos de hardware, otimização de algoritmos, segurança ou ainda as métricas para avaliação de sistemas de software são um espaço amplo para futuros trabalhos e pesquisas.
  • 102. 98 REFERÊNCIAS APACHE SOFTWARE FOUNDATION. Struts. 2009. Disponível em: <http://struts.apache. org/>. Acesso em: 8 abr. 2009. APPLE DEVELOPER CONNECTION. Cocoa Design Patterns. 2008. Disponível em: <http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDe signPatterns/CocoaDesignPatterns.html> Acesso em: 20 mar. 2009. AUGUSTO, L. D. C. Spring Framework. 2006. Disponível em: <http://www.ime.usp.br/~re verbel/SMA-06/Slides/seminarios/spring.pdf>. Acesso em: 3 abr. 2009. BASHAM, B.; SIERRA, K.; BATES, B. Use a Cabeça! Servlets & JSP. Tradução de Marcelo Soares e Weuler Gonçalves. Rio de Janeiro: Alta Books, 2005. Título do original: Head First Servlets & JSP. BOND, M.; HAYWOOD, D.; LAW, D.; LONGSHAW, A.; ROXBURGH, P. Aprenda J2EE em 21 Dias. Tradução de João Eduardo Nóbrega Totello. São Paulo: Pearson Education, 2003. Título do original: Design Patterns: Elements of Reusable Object-Oriented. BROWN, K. Enterprise Java: Programming with IBM Websphere. Boston, Addison- Wesley, 2003. DALMOLIN, L. C. Reutilização de Software no Paradigma da Orientação a Objetos, Universidade da Região da Campanha, Bagé, v. 1, n. 1, p. 14-17, 1997. Disponível em: <http://attila.urcamp.tche.br/site/ccei/revista/numero1.pdf#page=14>. Acesso em: 31 mar. 2009. DEITEL, H. M.; DEITEL, P. J. Java como programar. 6. ed. Tradução de Edson Furmankiewicz. São Paulo: Pearson Education, 2005. Título do original: Java how to program, 6th. DEVELOPERSBOOK. Spring Framework Tutorials. 2008. Disponível em: <http://www.developersbook.com/spring/spring-tutorials/spring-tutorials.php> Acesso em: 7 abr. 2009.
  • 103. 99 DONALD, K. Spring Web Flow 2 Released: Introduces New Faces and JavaScript Modules. 2008. Disponível em: <http://www.springsource.org/webflow> Acesso em: 8 abr. 2009. ECKSTEIN, R. Java SE Application Design With MVC. 2007. Disponível em: <http://java. sun.com/developer/technicalArticles/javase/mvc>. Acesso em: 18 mar. 2008. FIORINI, S. T. Arquitetura para reutilização de processos de software. 2001. Tese (Doutorado em Informática) – Pontifica Universidade Católica do Rio de Janeiro, Rio de Janeiro. FOWLER, M. Inversion of Control. Disponível em: <http://martinfowler.com/bliki/Inversio nOfControl.html>. Acesso em: 1 abr. 2009. GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Padrões de Projeto: Soluções Reutilizáveis de Software Orientado a Objetos. Tradução de Luiz A. Meirelles Salgado. Porto Alegre: Bookman, 2000. Título do original: Design Patterns: Elements of Reusable Object-Oriented. GOES FILHO, J. R. CRM. 2009. Disponível em: <http://www.futureware.com.br/business/in dex.php/por/Solucoes/FW-Corporate/CRM> Acesso em: 15 mai. 2009. GOVONI, R. Design an MVC framework using annotations. 2005. Disponível em: <http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html> Acesso em: 8 abr. 2009. HORSTMANN, C. Big Java. Porto Alegre: Bookman, 2002.cap. 25 p. 948-1002. HORSTMANN, C.; GEARY, D. M. Core Java Server Faces. 1. ed. Alta Books, 2005. JARDIM, R. U. F. Spring MVC Framework. 2004. Disponível em: <http://blog.urubatan.c om.br/uploads/justjava2004.pdf>. Acesso em: 27 mar. 2009. MACORATTI. J. C. Plataforma .NET x Plataforma Java. 2004. Disponível em <http://imasters.uol.com.br/artigo/2592/java/j2ee_x_net/>. Acesso em: 3 mai 2009. NASCIMENTO, G. S. Framework MVC: Apache Struts ou JavaServer Faces. 2005. Disponível em: <http://www.plugmasters.com.br/sys/materias/213/1/Framework-MVC%3A- Apache-Struts-ou-JavaServer-Faces%3F-parte-3> Acesso em: 1 abr. 2004.
  • 104. 100 PITANGA T. JavaServer Faces: A mais nova tecnologia Java para desenvolvimento WEB. GUJ - Grupo de Usuários Java, 2004. Disponível em: <http://www.guj.com.br/content/articles/jsf/jsf.pdf >. Acesso em: 8 abr. 2009. RAIBLE, M. Comparing Web Frameworks - Struts, Spring MVC, WebWork, Tapestry & JSF. 2006 Disponível em :<https://equinox.dev.java.net/frameworkcomparison/WebFrame works.pdf>. Acesso em: 24 mar. 2009. ______. The Spring Framework - Simplifying J2EE. 2006. Disponível em: <https://equino x.dev.java.net/SpringFramework.pdf>. Acesso em: 27 mar. 2009. RAIBLE, M.; PORTER, M. Spring MVC vs. WebWork – Smackdown. 2006 Disponível em: <https://equinox.dev.java.net/framework-comparison/SpringVsWebWork.pdf>. Acesso em: 27 mar. 2009. REENSKAUG, T. M. H. MVC – Xerox Parc 1978-79. 1979. Disponível em: <http://heim.ifi .uio.no/~trygver/themes/mvc/mvc-index.html>. Acesso em: 24 mar. 2009. SAMPAIO JÚNIOR, A. B. C. Arquitetura JEE. Disponível em: <http://www.unama.br/abc/ cursosProfissionalizantes/java/downloads/modulo4/Unidade2.pdf>. Acesso em: 28 abr 2009. SAUVÉ, J. P. Projeto de Software Orientado a Objeto – Programa. 2006. Disponível em: <http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/map2.htm>. Acesso em: 28 fev. 2009. ______. Java Server Faces (JSF). 2006. Disponível em: <http://www.dsc.ufcg.edu.br/~jacqu es/cursos/daca/html/jsf/jsf.htm>. Acesso em: 2 abr. 2009. SHALLOWAY, A. e TROTT, J. Explicando padrões de projeto: uma nova perspectiva em projeto orientado a objeto. Tradução de Ana M. de Alencar Price. Porto Alegre: Bookman, 2004. Título do original: Design Patterns Explained: A New Perspective on Object-Oriented Design. SILVA, R. P.; PRICE, R. T. O uso de técnicas de modelagem no projeto de frameworks orientados a objetos. In: Proceedings of 26th International Conference of the Argentine Computer Science and Operational Research Society (26th JAIIO) / First Argentine Symposium on Object Orientation (ASOO'97). Buenos Aires, Argentine: aug. 1997. p. 87-94.
  • 105. 101 SOUZA, M. V. B. Estudo Comparativo entre Frameworks Java para Construção de Aplicações Web. 2004. 67 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) - Universidade Federal de Santa Maria, Santa Maria. SUN MICROSYSTEMS. Model-View-Controller. 2002. Disponível em: <http://java.sun.co m/blueprints/patterns/MVC.html>. Acesso em: 2 set. 2008. ______. Java 2 Platform, Enterprise Edition (J2EE) Overview. 2009. Disponível em: <http://java.sun.com/j2ee/appmodel.html>. Acesso em: 24 abr 2009. ______. Java EE Technologies at a Glance. 2009. Disponível em: <http://java.sun.com/java ee/technologies/>. Acesso em: 24 abr 2009. ______. Why Move to Java EE? 2009. Disponível em: <http://java.sun.com/javaee/whymov e.jsp>. Acesso em 24 abr 2009. ______. JavaServer Faces Technology. 2006. Disponível em: <http://java.sun.com/javaee/ja vaserverfaces/index.jsp> Acesso em: 10 abr. 2009. UNIVERSIDADE DE FRANCA. Manual. Normas para elaboração e apresentação de trabalhos acadêmicos. 10.ed. Editora Unifran, 2008.
  • 106. 102 GLOSSÁRIO .NET: Plataforma de desenvolvimento de software desenvolvida pela Microsoft. ActionForms: JavaBeans que interagem com os formulários no framework Strtus. Ajax4jsf: Biblioteca que adiciona capacidades AJAX ao framework JSF. Akelos: Framework PHP para implementação seguindo o padrão MVC. Algoritmos: Seqüências finitas e não ambígua de passos para a realização de uma tarefa. Aplicativo: Programas de computador com finalidade de execução de tarefas práticas. Applet: Pequeno programa desenvolvido na linguagem Java que podem ser incorporados em páginas HTML. BackingBeans: Classes que fazem parte da especificação do framework JSF e atuam no papel de controllers do modelo MVC. Banco de dados: Conjunto de dados relacionados. Biblioteca: Conjunto de classes e scripts pré-definidos que auxiliam no desenvolvimento de aplicativos. CakePHP: Framework PHP para implementação seguindo o padrão MVC. Casos de uso: Funcionalidade que um sistema possui ou deve possuir para atender as necessidades dos usuários. Classe: Estrutura do paradigma da orientação a objetos que representam abstrações de entidades do mundo real. Código monolítico: Código que agrupa em um único bloco de programação todas funcionalidades de uma aplicação. Componentes: Parte física de um sistema. Composite: Padrão de projeto que consiste de um composto de objetos aninhados trabalhando de forma coordenada hierarquicamente. Computação ubíqua: Computação em qualquer lugar. Onipresença da informática.
  • 107. 103 Conectores: APIs para esconder complexidade, promover a portabilidade e facilitar a interação entre sistemas. Contêiner: Ambiente virtual em um servidor JEE que fornece recursos e serviços para a execução do código criado. Controller (Controle): Uma das camadas do padrão MVC. Responsável pelo tratamento das interações do usuário provocando alterações no modelo. Desktop: Computador de mesa. PC (computador pessoal). Área de trabalho. Dependency Injection (Injeção de Dependências): Padrão de desenvolvimento de software que permite manter um baixo nível de acoplamento entre as partes do sistema. Design patterns (Padrões de projeto): Soluções, idéias abstratas para a solução de problemas sob um determinado domínio. Dispatching: realizar o encaminhamento de uma solicitação. Dispositivo: equipamento ou aparelho com alguma finalidade. Django: Framework escrito em Python para desenvolvimento rápido que implementa o padrão MVC. Domínio: Ambiente ou situação com pontos em comum. Exceções: Situações em que o programa sai de seu ciclo normal de execução. Factory: Padrão de projeto criacional que visa gerenciar a instanciação de objetos. Framework: Conjunto de classes relacionadas que formam uma estrutura que consistem em uma solução abstrata de um problema. Front-controller: Padrão de projeto utilizado para centralizar o tratamento de requisições. Muito comum em aplicações web. Gang of Four (Gangue dos Quatro): Grupo formado por Eric Gamma, Richard Helm, Ralph Johnson e John Vlissides, precursores na abordagem sobre padrões de projeto na informática. GET: Método do protocolo HTTP para realizar a solicitação de algum recurso. GlassFish: Servidor de aplicativo JEE desenvolvido pela Sun Microsystems. Herança: Conceito da orientação a objetos que cria uma relação do tipo “pai e filho” entre classes, onde a classe pai transmite para a outra todos seus atributos e métodos. Hibernate: Framework para realizar o mapeamento objeto-relacional em sistemas escritos na linguagem Java.
  • 108. 104 Input: Entrada por meio da qual o usuário realiza a inserção de dados e parâmetros em uma aplicação. Internacionalização: Recurso para facilitar a tradução de sites ou aplicações para diversos idiomas. Interface: Fronteira comum entre dois lados distintos. Interfaces gráficas: Interface que conta com recursos visuais onde o usuário pode interagir de forma mais agradável e intuitiva. Inversão de Controle: Padrão onde a estrutura de um sistema é que fica responsável pelo gerenciamento dos códigos, e não o programador diretamente. iPlanet: Servidor de aplicativo para a plataforma JEE e outros serviços como utilização de XML, CORBA, entre outros. Java: Plataforma para desenvolvimento de softwares multiplataforma desenvolvida e mantida pela Sun Microsystems. Linguagem de programação orientada a objetos para programação na plataforma Java. JavaBean: componentes reutilizáveis de software escritos na linguagem Java. JBoss: Contêiner EJB gratuito. Listener: Classes ou objetos responsáveis por tratar eventos ocorridos sobre outros objetos. Lógica de negócio: Toda a lógica, ou regras, que definem como deve ser o comportamento e como devem ser tratados os dados em um sistema. Login: Processo pelo qual um usuário se identifica dentro de um sistema. Mensagem assíncrona: mensagem fora do ciclo normal de execução. Mensagens: chamadas de métodos por parte de um objeto para outros. Merb: Framework para a linguagem Ruby que implementa o padrão MVC. Midlets: Aplicativos Java para a plataforma JME (dispositivos móveis). Mobile: Móvel. Versão de aplicativos para dispositivos móveis. Model (Modelo): Uma das camadas do padrão MVC. Responsável pela lógica de negócios de um sistema. Multiplataforma: Algo que funcione em qualquer ambiente, independente do sistema operacional ou mesmo do dispositivo em que esteja rodando. Multiplicidades: Definições, ou limitações numéricas no relacionamento entre classes de um sistema.
  • 109. 105 Multithreading: Recurso que possibilita a existência de diversos fluxos de execução paralelos. MySQL: SGDB mantido pela Sun Microsystems, muito comum em sistemas web. Navegador: Aplicativo utilizado para acessar, navegar, na internet. NetBeans: IDE gratuito que auxilia no desenvolvimento de sistemas, sobretudo em Java. Objeto: Ocorrência, ou instância de uma classe. Objetos remotos: Objetos que fazem parte de uma aplicação, mas que não estão localizados no computador local onde esta aplicação está rodando. Observer: Padrão de projeto que permite que objetos recebam notificações de outros. Opensource: Código aberto. Softwares que possuem seu código disponível para visualização e alterações. Orientação a objetos: Paradigma de programação que tenta mapear entidades do mundo real em componentes de software. Overhead: Sobrecarga em uma transmissão ou execução. Packages (Pacotes): Grupos físicos de classes dentro de um projeto de software baseado na programação orientada a objetos. Parsers: Programas ou scripts para realizar a tradução e análise de uma entrada em uma saída esperada. Phaselistener: Componente da especificação do JSF que permite interceptar as fases do ciclo de execução de uma requisição. Plug-ins: Recursos ou dispositivos que podem ser adicionados a uma entidade maior a fim de dar-lhes mais funcionalidades. Polimorfismo: Conceito da orientação a objetos que possibilita o tratamento de objetos de diferentes tipos de forma igual como se todos fossem de apenas um tipo. POST: Método do protocolo HTTP para realizar o envio de dados ao servidor durante uma requisição. PrintWriter: Classe Java que possibilita o tratamento da saída que deve ser devolvida pelo servidor ao usuário em resposta a uma requisição. Python: Linguagem de programação orientada a objetos. Rails: Framework, escrito na linguagem Ruby, que implementa o padrão MVC.
  • 110. 106 Recompilado: Compilado novamente para geração de um novo programa executável. Renderizar: Tornar algo visível. Requisitos: Necessidades do usuário que devem ser atendidas no desenvolvimento de um software. Richfaces: Biblioteca que acrescenta recursos e componentes visuais ao framework JSF. Ruby: Linguagem de programação orientada a objetos. Servidor: Máquina ou sistema que disponibiliza serviços e recursos. Servlet: Classes escritas em Java que rodam no servidor JEE tratando das requisições feitas pelos usuários. Smalltalk: Linguagem de programação orientada a objetos. Softwares: Programas, dados, arquivos. Todas as unidades lógicas que funcionam dentro de um computador. Spring: Framework escrito em Java baseado nos conceitos de inversão de controle e injeção de dependência. Stand-alone: Computador dedicado, isolado. Strategy: Padrão de projeto comportamental que atua na camada do Controller no padrão MVC. String: Tipo de dado para manipulação de dados textuais. Struts: Framework MVC escrito em Java mantido pela Apache Sofware Fundation. Subrotina: Trecho de código com propósito específico. Sun Microsystems: Empresa de norte-americana que mantém a plataforma Java, SGDB MySQL, entre outros produtos. Swing: Pacote de classes da API do Java para criação de interfaces gráficas. Tag library (Biblioteca de Tags): Bibliotecas que podem ser incorporadas a páginas JSP para a extensão de suas funcionalidades e recursos. Tags: Marcações dentro de documentos através do uso de linguagens de marcação, como HTML, XML, entre outras. Thick: Termo para denominar o chamado cliente gordo. Máquina que possui todo o código da aplicação que está rodando na mesma.
  • 111. 107 Thin: Oposto ao Thick. Máquina que possui em si apenas o aplicativo necessário para acessar uma aplicação disponível em um servidor. Tomcat: Servidor de aplicativos JEE que possui apenas um contêiner web. Usuário: Pessoa, ou mesmo programa, que faz uso de outro programa. View (Visão): Uma das camadas do padrão MVC. Responsável por receber as interações do usuário e exibir os dados do modelo. VRaptor: Framework para desenvolvimento rápido baseado no padrão MVC. Web: Serviço disponível pela internet para a disponibilização de documentos de hipertexto. Websphere: Servidor de aplicativo fornecido pela IBM. Web services: Serviços disponíveis pela web. Web Work: Framework escrito em Java para desenvolvimento de aplicações web. XML: Linguagem de marcação muito utilizada na troca de informações entre aplicações heterogêneas e também em arquivos de configuração. XWork: Framework base do WebWork. Zend Framework: Framework PHP que implementa o padrão MVC.