estudo de aplicabilidade do padrão mvc fernando & leonardo

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

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, _____/ _____ / _____

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.

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.

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.

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.

Divide as dificuldades que tenhas de examinar em tantas partes quantas for possível, para uma melhor solução.

René Descartes

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.

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.

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

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

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

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

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.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

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


3 ESTUDO DE CASO ........................................................................................... 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


4 IMPLEMENTAÇÃO DO ESTUDO DE CASO .............................................. 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

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


CONCLUSÃO ..................................................................................................................... 96

REFERÊNCIAS ................................................................................................................. 98

GLOSSÁRIO ..................................................................................................................... 102

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.

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

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.

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

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.

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.

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;

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.

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.

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

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

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.

25

2 MVC (MODEL-VIEW -CONTROLLER)


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.

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

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.

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:

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.

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.

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.

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.

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)

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.

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).

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).

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.

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

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:

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;

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.

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.

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.

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/co re" prefix="f" %> 3 - <%@ taglib uri="http://java.sun.com/jsf/ht ml" prefix="h" %> 4 - <f:view> 5 - <head> 6 - <title>A Simple JavaServer Faces Appli cation</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="l ogin"/> 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

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) { nam e = newValue; } 7 - 8 - public String getPassword() { return passw ord; } 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 Fa ces Config 1.0//EN"

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-c lass> 18 - <managed-bean-scope>session</managed-bean-sc ope> 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" p refix="h" %> 4 - 5 - <f:view> 6 - <head> 7 - <title>A Simple JavaServer Faces Applicat ion</title> 8 - </head> 9 - <body> 10 - <h:form> 11 - <h3> 12 - Welcome to JavaServer Faces, 13 - <h:outputText value="#{user.name}"/>!

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

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

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;

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.

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.

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</t itle></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)

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.

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.

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

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.

57

3 ESTUDO DE CASO


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.

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.

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.

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.

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.

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

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.

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.


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

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.

66

4 IMPLEMENTAÇÃO DO ESTUDO DE CASO


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).

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.

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 prio ridade); .

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 createAtividadeD ao() 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

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)

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:

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;

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 = (HttpServ letRequest)FacesContext.getCurr

entInstance().getExternalContext().getRequest(); 23 - Integer codigo = Integer.parseInt( req uest.getParameter(

"codigoClienteEditar") ); 24 - ClienteDao clienteDao = DaoFactory.cre ateClienteDao(); 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

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).

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).

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.

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="U TF-8"%> 2 - 3 - <%@taglib prefix="c" uri="http://java.sun.com/j sp/jstl/core" %> 4 - <%@taglib prefix="f" uri="http://java.sun.com/j sf/core"%> 5 - <%@taglib prefix="h" uri="http://java.sun.com/j sf/html"%> 6 - <%@taglib prefix="a4j" uri="http://richfaces.or g/a4j"%> 7 - <%@taglib prefix="rich" uri="http://richfaces.o rg/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="c liente"/> 17 - <rich:inplaceSelect id="cliente" value="#{relatoBean.relato.codCli}" required="true" requiredMessage="Este camp o é obrigatório" openOnEdit="true" editEvent="onclick" defaultLabel="Selecione um cliente"

78

styleClass="inplaceSelect" viewHoverClass="viewHoverI nplaceSelect" viewClass="viewInplaceSele ct" changedClass="inplaceSelec t" 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" require dMessage="Este compo é

obrigatório" id="descricao" value="#{relatoBean.r elato.descricao}"/> 24 - <h:message errorClass="erroValidacao " for="descricao"/> 25 - 26 - <h:outputLabel value="Data/Hora" for ="dataHora"/> 27 - <rich:calendar value="#{relatoBean.r elato.dataHora}" id="dataHora"

datePattern="dd/MM/yyyy HH:mm"></rich:cal endar> 28 - <h:message errorClass="erroValidacao " for="dataHora"/>

.

.

. 29 - <h:commandButton styleClass="botaoFor m" 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.

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.

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

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.

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.

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/c rm/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.Acti onEvent evt) { 3 - ProximoHandler(evt); 4 - } 5 - }); 6 - 7 - private void btnProximoHandler(java.awt.event.Actio nEvent evt) {

84

8 - if ( getIndexUsuario() < getListaUsuarios().si ze() - 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.

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.

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.

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

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(n ame = "razaoSocial") 18 - String razaoSocial) { 19 - String retorno = ""; 20 - ClienteDao clienteDao = DaoFactory.cre ateClienteDao(); 21 - List<Cliente> cliente = new ArrayList< Cliente>() ; 22 - cliente = clienteDao.listarClientesRaz aoSocial(razaoSocial); 23 - for(int i=0; i<cliente.size();i++) 24 - { 25 - ClienteEndereco[] clienteEndereco = cliente.get(i).getEnderecos(); 26 - ClienteEmail[] clienteEmail = clie nte.get(i).getEmails(); 27 - retorno += "---------------------- ----------------------------\n" + 29 - " Nome: "+cliente.get(i).ge tRazaoSocial()+"\n" + 30 - " Endereço: "+clienteEndereco[ 0].getEndereco()+"\n" + 31 - " Email: " + clienteEmail[0].g etEmail()+"\n" + 32 - "----------------------------- -----------------------\n"; 33 - 34 - } 35 - 36 - return retorno; 37 - } 38 - 39 - }

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:

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:

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 raza oSocial) 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

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.

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.

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.

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.


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.

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

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.

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/CocoaDesignPatterns/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.

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.

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.

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.

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.

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.

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.

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.

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.

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.