Desenvolvimento de Sistema Web utilizando arquitetura em

Três Camadas e Applets

Kanji Hara Neto 1 , Lucas G Nadalete 1 , Fabio A. Gennari1 , Antonio A. Carneiro de
Freitas 2
1
Coordenação de Informática – Centro Federal de Educação Tecnológica do Paraná
(CEFET-PR)
Caixa Postal 86.300-000 – Cornélio Procópio – PR – Brazil
1
Coordenação de Eletrotécnica – Centro Federal de Educação Tecnológica do Paraná
(CEFET-PR)
Caixa Postal 86.300-000 – Cornélio Procópio – PR – Brazil
kanji@cp.cefetpr.br,lookyller2002@yahoo.com.br, fabiogennari@bol.com.br,
carneirofreitas@brturbo.com.br
Abstract. This article presents a practical application of a developed system using
architecture in three layers and using a Web navigational mechanism through
Applet.
Resumo. Este artigo apresenta uma aplicação prática de um sistema
desenvolvido utilizando arquitetura em três camadas e utilizando um mecanismo
navegacional através de Applets.

1. INTRODUÇÃO
O desenvolvimento de aplicações para web obrigou os desenvolvedores a utilizar uma nova
arquitetura de sistemas, abandonando a arquitetura monolítica para se empregar uma
arquitetura em camadas.
O Objetivo deste artigo é apresentar uma aplicação prática de sistemas
desenvolvidos utilizando arquitetura em camadas , com a utilização de applets pa ra gerar e
manipular mapas.

2. CAMADAS
Nos primórdios da computação, quando um aplicativo era executado em uma única
máquina, era comum encontrar sistemas monolíticos contendo todas as funcionalidade s do
aplicativo em uma única grande camada como demonstra a Figura 1, onde sua manutenção
e atualização eram extremamente penosas e complexas.
 Lógica de Apresentação

Código Lógica de Negocio

Monolítico

Lógica de Acesso a Dados

Banco
de Dados

Figura 1 – Código monolítico.

Com o objetivo de se manter diversos aplicativos e uma única base de dados, a

arquitetura monolítica evoluiu para uma arquitetura em duas camadas onde a lógica de
acesso aos dados estava separada do restante da aplicação, permitindo assim vários
programas acessarem a mesma base de dados. Apesar desta evolução na arquitetura os
sistemas ainda eram potencialmente monolíticos, pois a lógica de apresentação (a interface
homem máquina) e a lógica de negócio (algoritmos do sistema), estavam reunidas em uma
única camada [Bond M.,Haywood D. 2003], como representa a Figura 2.

Lógica de Apresentação

Lógica de Negocio

2 Camadas
Físicas
Lógica de Acesso a Dados

Banco
de Dados

Figura 2 - Código em 2 camadas.

Com o advento da Internet, esta arquitetura teve que ser alterada , pois o tempo
necessário para carregar todos os componentes da regra de negócio no cliente em um
aplicativo Web é extremamente elevado, tornando assim o sistema inviável.
Devido a esses problemas a arquitetura em duas camadas foi substituída por uma
arquitetura em três camadas, como está representado na Figura 3.
 Lógica de Apresentação

3 Camadas Lógica de Negocio

Físicas

Lógica de Acesso a Dados

Banco
de Dados

Figura 3 - Código em 3 camadas

A arquitetura em 3 camadas, envolve a separação das funcionalidades usando

camadas, com o objetivo de separar a lógica de apresentação, a lógica de negocio e a
conexão com o banco de dados (lógica de acesso a dados).
A separação em três camada s torna o sistema mais flexível, de modo que partes
podem ser alteradas independentemente. Com o emprego de arquitetura em três, qualquer
alteração em uma determinada camada não influi nas demais, desde que o mecanismo de
comunicação entre elas permanece inalterado.
Isto permite substituir uma camada inteira por outra, independente de que camada seja,
como mostra a Figura 4, ou que um projeto desenvolvido para web, possa abranger também
dispositivos móveis ou standalone, a partir da inclusão de uma nova camada de
apresentação.

Lógica de Apresentação para Lógica de Apresentação para

aplicações WEB dispositivo móvel

Lógica de Negocio Lógica de Negocio

Lógica de Acesso a Dados ao Lógica de Acesso a Dados ao

Firebird 1.5 PostgreSQL

Banco de Dados Banco de Dados

Firebird 1.5 Pos tgreSQL

Figura 4 – Substituição de camadas do Sistema

3. Zoneamento Agroclimatico da Cultura da Soja
A imprevisibilidade das variações climáticas confere à ocorrência de adversidades
climáticas o principal fator de risco e de insucesso na exploração da cultura da soja.
Segundo o relatório sobre seguridade agrícola elaborado pelo Ministério do Planejamento,
consta a ocorrência de secas como principal evento sinistrante (71% dos casos), seguida por
chuva excessiva (22% dos casos), granizo e geada. Além desses, são mencionadas ainda
perdas devido à tromba d'água, vento frio, vento forte, variação excessiva de temperatura e
enchente. Não considerando os eventos exclusivamente climáticos, são relatadas ainda as
perdas por ocorrência de pragas e de doenças (responsáveis por 0,20% nas safras de verão e
por 0,05% nas de inverno).
Neste sentido, o Zoneamento Agroclimático da Cultura da Soja tem por objetivo
delimitar as áreas com menores riscos de insucesso devido à probabilidade de ocorrência de
déficits hídricos durante as fases mais críticas da cultura da soja, fornecendo informações
que subsidiem a definição de políticas agrícolas e a tomada de decisões pelo setor
produtivo, para a obtenção de maiores rendimentos com menores riscos.
A realização deste trabalho envolveu a participação de várias instituições (MAPA,
EMBRAPA, ANEEL, INMET, IAPAR), cobrindo os estados do PR, de GO, do TO, do
MS, do MT, de MG, do MA e da BA. A primeira etapa do trabalho consistiu na obtenção
do banco de dados necessário . As séries pluviométricas foram obtidas junto à ANEEL e
analisadas pela Embrapa Cerrados, compreendendo os valores diários de precipitação,
observados num período mínimo de 15 anos, abrangendo várias estações (de 45 a 331
estações por estado), localizadas nos diferentes Estados. Para efeito da simulação, as
classes de solos foram agrupadas, segundo sua capacidade de armazenamento de água, em
três tipos: alta, média e baixa retenção de água. Para representar a maioria das cultivares de
soja recomendadas para as diferentes regiões, foram eleitas duas cultivares hipotéticas,
consideradas perfeitamente adaptadas às condições termofotoperiódicas dos diferentes
locais, com ciclos diferentes, as quais foram denominadas de PRECOCE e TARDIA .
De posse dos dados necessários, foram estimados os índices de satisfação das
necessidades de água (ISNA), definidos como a relação existente entre evapotranspiração
real (ETr) e a evapotranspiração máxima da cultura (ETm), utilizando-se um modelo de
simulação do balanço hídrico da cultura (Bipzon). Para definição dos níveis de risco
agroclimático, foram estabelecidas três classes, de acordo com a relação ETr/ETm obtida:
favorável (ETr/ETm >= 0,65); intermediária (0,65 > ETr/ETm > 0,55) e desfavorável
(ETr/ETm <= 0,55). Foram feitas simulações para nove ou doze períodos de semeadura.
Para a espacialização dos resultados, foram empregados os ISNA estimados para o período
fenológico compreendido entre a floração e o enchimento de grãos (período mais crítico ao
déficit hídrico), com freqüência mínima de 80% nos anos utilizados em cada estação
pluviométrica. Cada valor de ISNA observado durante esta fase, foi associado a localização
geográfica da respectiva estação para posterior espacialização dos mesmos, utilizando-se
sistemas de informações geográficas. Foram confeccionados os mapas para cada Estado,
definindo-se as áreas de maior ou menor risco de ocorrência de déficit hídrico durante a
fase mais crítica da cultura, caracterizadas como favoráveis, intermediárias e desfavoráveis,
em função das diferentes épocas de semeadura.
4. Sistema Zoagro
Com base nas informações adquiridas no Zoneamento Agroclimatico da Soja, foi iniciado o
desenvolvimento do Sistema Zoagro, um trabalho da Empresa Brasileira de Pesquisa
Agropecuária (Embrapa) em parceria com o Centro Federal de Educação Tecnológica do
Paraná (CEFET-PR) unidade Cornélio Procópio , que visa disponibilizar aos produtores
informações sobre o plantio indicado para cada município, as estatísticas de produções e de
rendimento dos respectivos, bem como as cultivares indicadas para cada Estado.
O plantio indicado do Sistema Zoagro difere do Zoneamento Agroclimatico, por
trabalhar apenas com duas classes ao invés das três definidas no estudo. Esta eliminação foi
devido à imparcialidade que a classe intermediaria poderia causar ao produtor.
O Zoagro é um sistema que inicialmente foi desenvolvido em Delphi com o banco
de dados Paradox, mas com o intuito de se atingir um maior numero de produtores, o
Zoagro foi migrado para Web e seu banco de dados substituído pelo Firebird 1.5.

5. Arquitetura do Sistema Zoagro

O desenvolvimento foi baseado na arquitetura em três camadas, onde os arquivos Html
(Hypertext Markup Language) , JavaScript, CSS (Cascading Style Sheets), JSP (Java Server
Pages) e Applets se encontram na camada de apresentação, os componentes JavaBeans e as
Servlets na camada de regra de negócio e as classes responsáveis pela comunicação com o
Banco de Dados na camada de acesso a dados, como representa a Figura 5. O servidor
utilizado na aplicação é o Apache Tomcat 4.1.27, e o sistema gerenciador de banco de
dados utilizado é o FireBird 1.5.

JavaScript Html
Lógica
de Css
Apresentação
Applet JSP

Lógica do Negócio Servlets JavaBeans

Lógica de Acesso a Dados ConexaoBD

FireBird 1.5

Figura 5 Arquitetura do Zoagro - Web

Os arquivos Html são definidos simplesmente como uma aplicação especifica do
SGML (Standard Generalized Markup) , ajustada para apresentação de documentos textos[
Conallen J., 2003] , que juntamente com o CSS foi utilizado para projetar a interface
gráfica do Zoagro.
 Os arquivos JavaScripts são pequenos programas que tem a finalidade de transferir
parte do processamento para os clientes [ Albuquerque F. 2001]. No sistema , JavaScript foi
empregado para realizar solicitaç ões a um JSP a partir de uma Applet. Sua utilização
tornou-se necessária devido as restrições do método Java showDocument( ), que restringe o
carregamento do navegador sem às toolbars. Devido a esta restrição optou-se por utilizar o
método open( ) do JavaScript, como representa o código abaixo.

Código Applet
import netscape.javascript.JSObject;
public class JApplet extends javax.swing.JApplet {
private JSObject window;

public void chamarJavaScript( ){

window = JSObject.getWindow(this);
String param [] = new String[2];
param[0]= “String”
param[1]= “String”
window.call("func_java_script", param);
}
}

Código Html

<HTML>
<HEAD>
<TITLE>Applet HTML Page</TITLE>
</HEAD>
<SCRIPT language= "JavaScript" >
function func_java_script(){
open("http://200.17.97.120:8080/zoagro/jsp/resultpalntioindicado
.jsp?nomecidade="+txt2+"&cod="+txt1,"DisplayWindow","toolbar=no,
width=530,directories=no,menubar=no,scrollbars=yes");
}
</SCRIPT>
<BODY>
<H3><HR WIDTH="100%">Applet HTML Page<HR WIDTH="100%"></H3>
<P>
<APPLET code="JApplet.class" width=350 height=200>
<PARAM name="scriptable" value="true">
</APPLET>
</P>
<HR WIDTH="100%"><FONT SIZE=-1><I>Generated by NetBeans IDE</I></FONT>
</BODY>
</HTML>

O código acima demonstra como é feita a chamada a uma função JavaScript de

uma Applet.
As Applets são pequenos programas Java armazenados normalmente em um
computador remoto no qual usuário se conecta a partir do Navegador Web. As Applets
são carregadas e executadas no Navegador e descartadas quando se completa a execução [
Deitel H. M, Deitel P. J. 2001]. A aplicação de Applets no Sistema Zoagro será descrita no
tópico a seguir, devido a sua importância no sistema.
 JSP é uma tecnologia baseada em Java que simplifica o processo de
desenvolvimento de sites da web. Com o uso de JSP, os designers da web e programadores
podem rapidamente incorporar elementos dinâmicos em páginas da web utilizando Java e
algumas tags de marcação simples. Estas tags fornecem ao designer de HTML um meio de
acessar dados e lógica de negócios armazenados em objetos Java sem ter que dominar as
complexidades do desenvolvimento de aplicações [ Fields D. K. , Kolb M. A. 2000 ].
JSP foi empregado em todas as páginas do sistema Zoagro que necessitavam de
informações armazenadas no Banco de Dados. Seu funcionamento no sistema ocorre da
seguinte forma : O usuário seleciona em uma cidade através da Applet , que realiza uma
chamada a uma pagina JSP, a partir de um JavaScript.
A comunicação da JSP não ocorre diretamente com o Banco de Dados. A
solicitação e a transmissão de informações com o Banco de Dados é intermediada pelos
componentes JavaBeans e pela classe de Comunicação com o Banco de Dados. Isso ocorre
pelo fato do Zoagro ter sido projetado sobre a arquitetura em três camadas.
Apesar de aparentemente estas camadas intermediárias tornarem o sistema mais
complexo, o mesmo acaba se tornando, mais flexível com um acoplamento mínimo entre as
camadas do sistema, onde partes do mesmo podem ser alteradas independentemente.
Os JavaBeans são componentes de softwares escritos em Java, que tem a finalidade
de serem reutilizáveis e independentes [Bomfim J. F. T. 2002]. Eles se encontram na
camada de lógica de negócio e foram empregados no sistema com o intuito de separar a
lógica de programação da interface com o usuário.
As Servlets são componentes do lado do servidor que são empregada para escrever
aplicativos Web em um servidor. Com freqüência Servlets é empregada para a geração de
paginas dinâmicas [Bond M.,Haywood D. 2003], mas no sistema Zoagro ela foi empregada
para realizar a comunicação da Applet de Cultivares com a base de dados, através do
servidor.
A última camada do sistema é a camada de lógica de acesso a dados, onde a sua
funcionalidade única e exclusiva é a comunicação com o banco de dados. Ela possui dois
métodos além do construtor os métodos alterarBD e consultarBD , que são chamados
através dos componentes JavaBeans.
A existência desta classe é justificada por uma restrição do desenvolvimento do
projeto Zoagro de : “Não ser dependente de banco de dados”; isto significa que se o banco
utilizado não atender mais as necessidades do Zoagro, ou por alguma razão tiver que ser
alterado, isto possa ser feito substituindo exclusivamente esta camada, sem influenciar o
restante do sistema.
O funcionamento desta classe é bem simples, o método construtor fica responsável
por toda parte de conexão com o banco de dados, o método alterarBD tem a finalidade de
alterar o banco de dados, recebendo o SQL da alteração como parâmetro e retornando um
inteiro como resposta. Já o método consultarBD tem a finalidade de realizar as consultas do
sistema aonde ele recebe a consulta SQL como parâmetro e retorna um ResultSet.
6. Desenvolvendo um mecanismo navegacional através de Applets
Um dos grandes problemas na implementação do sistema Zoagro, foi desenvolver o
mecanismo em que o usuário pudesse selecionar os Estados e municípios utilizando
somente mapas.
A razão de se de senvolver tal mecanismo é devido os usuários em potencial do
Zoagro (os produtores de Soja ),não possuem, na sua grande maioria, um conhecimento
básico necessário de informática . O desenvolvimento de um mecanismo navegacional
através de mapas foi a melhor solução de navegação encontrada para este nível de usuários,
uma vez que mapas fazem parte de suas concepç ões cognitivas.
Os mapas foram implementados com a utilização de vetores de polígonos, onde
cada polígono representava uma cidade ou Estado, formando assim, o mapa do Brasil e dos
seus respectivos Estados, como mostra a Figura 6.

Figura 6 – Mapa do Sistema Zoagro

As cidades só puderam ser identificadas devido à ordem de criação dos polígonos,

que obedecem à ordem alfabética das cidades , isto significa que o polígono zero representa
a primeira cidade na ordem alfabética do respectivo Estado, como no caso do Paraná é
Abatiá.
A ordenação na criação dos polígonos foi necessária devido à inexistência de um
método que representasse diretamente o polígono selecionado, o único método do objeto
polígono, que possibilitou a identificação, foi o método inside(x,y), que verifica se o
polígono possui ou não determinada coordenada x,y. Assim ordena ndo os polígonos e
realizando uma rotina de verificação, foi possível identificar em que cidade o mouse esta
posicionado.
Apesar de não ser a maneira mais elegante de se solucionar o problema, a utilização
de polígonos foi à única encontrada. Tendo em vista que o mesmo mecanismo
navegacional é facilmente implementado em Visual Basic, utilizando API do Windows.
7. Discussões e Conclusão
O desenvolvimento utilizando arquitetura em três camadas não é complexo e pode muito
bem ser aplicado em sistemas pequenos. Sua utilização proporciona muitas vantagens,
sendo a principal delas a separação entre interface e regra de negócio.
Já a utilização de Applet deixou uma enorme dúvida: A aplicação utilizando Java
foi a melhor solução possível, tendo em vista que existem outras tecnologias para
solucionar o mesmo problema, como por exemplo Flash?
Não há duvida em relação à capacidade das Applets, e sim quanto a sua viabilidade
em relação aos mecanismos de comunicação existentes.

8. Apoio
Centro Federal de Educação Tecnológica do Paraná unidade de Cornélio Procópio
(CEFET-PR) e Empresa Brasileira de Pesquisa Agropecuária (Embrapa).

9. Agradecimentos
A todos que colaboraram direta ou indiretamente com este projeto, em especial, à
coordenação do Curso de Tecnologia em Informática da Unidade de Cornélio Procópio do
CEFET-PR, e à Embrapa Londrina-PR.

10. Referências

Bond M.,Haywood D., Law D., Longshaw A. And Roxburgh P., (2003) “Aprenda J2EE
com EJB, JSP, Servlets, JNDI, JDBC e XML” editora Makron Books, São Paulo.
Conallen J., (2003) “Desenvolvendo Aplicações Web com UML”, editora Campus, São
Paulo, p.15.
Albuquerque F., (2001) “TCP/IP Internet – Programação de Sistemas Distribuídos Html,
JavaScript e Java”, editora Axcel Books, Rio de Janeiro, p.91-109.
Deitel H. M., Deitel P. J., (2001) “Java Como Programar 3ed” , editora Bookman, Porto
Alegre, p.56-82.
Fields D. K., Kolb M. A., (2000) “Desenvolvendo na Web com Java Server Pages”, editora
Ciência Moderna, Rio de Janeiro, p. 2-20.
Bomfim J. F. T., (2002) “JSP A Tecnologia Java na Internet”, editora Érica, São Paulo, p.
229 – 263.