Desenvolvimento de Sistema Web utilizando arquitetura em Trs Camadas e Applets

Kanji Hara Neto 1 , Lucas G Nadalete 1 , Fabio A. Gennari1 , Antonio A. Carneiro de Freitas 2
1

Coordenao de Informtica Centro Federal de Educao Tecnolgica do Paran (CEFET-PR) Caixa Postal 86.300-000 Cornlio Procpio PR Brazil

Coordenao de Eletrotcnica Centro Federal de Educao Tecnolgica do Paran (CEFET-PR) Caixa Postal 86.300-000 Cornlio Procpio 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 aplicao prtica de um sistema desenvolvido utilizando arquitetura em trs camadas e utilizando um mecanismo navegacional atravs de Applets.

1. INTRODUO
O desenvolvimento de aplicaes para web obrigou os desenvolvedores a utilizar uma nova arquitetura de sistemas, abandonando a arquitetura monoltica para se empregar uma arquitetura em camadas. O Objetivo deste artigo apresentar uma aplicao prtica de sistemas desenvolvidos utilizando arquitetura em camadas , com a utilizao de applets pa ra gerar e manipular mapas.

2. CAMADAS
Nos primrdios da computao, quando um aplicativo era executado em uma nica mquina, era comum encontrar sistemas monolticos contendo todas as funcionalidade s do aplicativo em uma nica grande camada como demonstra a Figura 1, onde sua manuteno e atualizao eram extremamente penosas e complexas.

Lgica de Apresentao Cdigo Monoltico Lgica de Negocio Lgica de Acesso a Dados

Banco de Dados

Figura 1 Cdigo monoltico.

Com o objetivo de se manter diversos aplicativos e uma nica base de dados, a arquitetura monoltica evoluiu para uma arquitetura em duas camadas onde a lgica de acesso aos dados estava separada do restante da aplicao, permitindo assim vrios programas acessarem a mesma base de dados. Apesar desta evoluo na arquitetura os sistemas ainda eram potencialmente monolticos, pois a lgica de apresentao (a interface homem m quina) e a lgica de negcio (algoritmos do sistema), estavam reunidas em uma nica camada [Bond M.,Haywood D. 2003], como representa a Figura 2.
Lgica de Apresentao Lgica de Negocio 2 Camadas Fsicas Lgica de Acesso a Dados

Banco de Dados

Figura 2 - Cdigo em 2 camadas.

Com o advento da Internet, esta arquitetura teve que ser alterada , pois o tempo necessrio para carregar todos os componentes da regra de negcio no cliente em um aplicativo Web extremamente elevado, tornando assim o sistema invivel. Devido a esses problemas a arquitetura em duas camadas foi substituda por uma arquitetura em trs camadas, como est representado na Figura 3.

Lgica de Apresentao

3 Camadas Fsicas

Lgica de Negocio

Lgica de Acesso a Dados

Banco de Dados

Figura 3 - Cdigo em 3 camadas

A arquitetura em 3 camadas, envolve a separao das funcionalidades usando camadas, com o objetivo de separar a lgica de apresentao, a lgica de negocio e a conexo com o banco de dados (lgica de acesso a dados). A separao em trs camada s torna o sistema mais flexvel, de modo que partes podem ser alteradas independentemente. Com o emprego de arquitetura em trs, qualquer alterao em uma determinada camada n o influi nas demais, desde que o mecanismo de comunicao 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 tambm dispositivos mveis ou standalone, a partir da incluso de uma nova camada de apresentao.
Lgica de Apresentao para aplicaes WEB Lgica de Apresentao para dispositivo mvel

Lgica de Negocio

Lgica de Negocio

Lgica de Acesso a Dados ao Firebird 1.5

Lgica de Acesso a Dados ao PostgreSQL

Banco de Dados Firebird 1.5

Banco de Dados Pos tgreSQL

Figura 4 Substituio de camadas do Sistema

3. Zoneamento Agroclimatico da Cultura da Soja

A imprevisibilidade das variaes climticas confere ocorrncia de adversidades climticas o principal fator de risco e de insucesso na explorao da cultura da soja. Segundo o relatrio sobre seguridade agrcola elaborado pelo Ministrio do Planejamento, consta a ocorrncia de secas como principal evento sinistrante (71% dos casos), seguida por chuva excessiva (22% dos casos), granizo e geada. Alm desses, so mencionadas ainda perdas devido tromba d'gua, vento frio, vento forte, variao excessiva de temperatura e enchente. No considerando os eventos exclusivamente climticos, so relatadas ainda as perdas por ocorrncia de pragas e de doenas (responsveis por 0,20% nas safras de vero e por 0,05% nas de inverno). Neste sentido, o Zoneamento Agroclimtico da Cultura da Soja tem por objetivo delimitar as reas com menores riscos de insucesso devido probabilidade de ocorrncia de dficits hdricos durante as fases mais crticas da cultura da soja, fornecendo informaes que subsidiem a definio de polticas agrcolas e a tomada de decises pelo setor produtivo, para a obteno de maiores rendimentos com menores riscos. A realizao deste trabalho envolveu a participao de vrias instituies (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 obteno do banco de dados necessrio . As sries pluviomtricas foram obtidas junto ANEEL e analisadas pela Embrapa Cerrados, compreendendo os valores dirios de precipitao, observados num perodo mnimo de 15 anos, abrangendo vrias estaes (de 45 a 331 estaes por estado), localizadas nos diferentes Estados. Para efeito da simulao, as classes de solos foram agrupadas, segundo sua capacidade de armazenamento de gua, em trs tipos: alta, mdia e baixa reteno de gua. Para representar a maioria das cultivares de soja recomendadas para as diferentes regies, foram eleitas duas cultivares hipotticas, consideradas perfeitamente adaptadas s condies termofotoperidicas dos diferentes locais, com ciclos diferentes, as quais foram denominadas de PRECOCE e TARDIA . De posse dos dados necessrios, foram estimados os ndices de satisfao das necessidades de gua (ISNA), definidos como a relao existente entre evapotranspirao real (ETr) e a evapotranspirao mxima da cultura (ETm), utilizando-se um modelo de simulao do balano hdrico da cultura (Bipzon). Para definio dos nveis de risco agroclimtico, foram estabelecidas trs classes, de acordo com a relao ETr/ETm obtida: favorvel (ETr/ETm >= 0,65); intermediria (0,65 > ETr/ETm > 0,55) e desfavorvel (ETr/ETm <= 0,55). Foram feitas simulaes para nove ou doze perodos de semeadura. Para a espacializao dos resultados, foram empregados os ISNA estimados para o perodo fenolgico compreendido entre a florao e o enchimento de gros (perodo mais crtico ao dficit hdrico), com freqncia mnima de 80% nos anos utilizados em cada estao pluviomtrica. Cada valor de ISNA observado durante esta fase, foi associado a localizao geogrfica da respectiva estao para posterior espacializao dos mesmos, utilizando-se sistemas de informaes geogrficas. Foram confeccionados os mapas para cada Estado, definindo-se as reas de maior ou menor risco de ocorrncia de dficit hdrico durante a fase mais crtica da cultura, caracterizadas como favorveis, intermedirias e desfavorveis, em funo das diferentes pocas de semeadura.

4. Sistema Zoagro
Com base nas informaes adquiridas no Zoneamento Agroclimatico da Soja, foi iniciado o desenvolvimento do Sistema Zoagro, um trabalho da Empresa Brasileira de Pesquisa Agropecuria (Embrapa) em parceria com o Centro Federal de Educao Tecnolgica do Paran (CEFET-PR) unidade Cornlio Procpio , que visa disponibilizar aos produtores informaes sobre o plantio indicado para cada municpio, as estatsticas de produes 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 invs das trs definidas no estudo. Esta eliminao 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 substitudo pelo Firebird 1.5.

5. Arquitetura do Sistema Zoagro

O desenvolvimento foi baseado na arquitetura em trs camadas, onde os arquivos Html (Hypertext Markup Language) , JavaScript, CSS (Cascading Style Sheets), JSP (Java Server Pages) e Applets se encontram na camada de apresentao, os componentes JavaBeans e as Servlets na camada de regra de negcio e as classes responsveis pela comunicao com o Banco de Dados na camada de acesso a dados, como representa a Figura 5. O servidor utilizado na aplicao o Apache Tomcat 4.1.27, e o sistema gerenciador de banco de dados utilizado o FireBird 1.5.
Lgica de Apresentao
JavaScript

Html Css

Applet

JSP

Lgica do Negcio

Servlets

JavaBeans

Lgica de Acesso a Dados

ConexaoBD

FireBird 1.5

Figura 5 Arquitetura do Zoagro - Web

Os arquivos Html so definidos simplesmente como uma aplicao especifica do SGML (Standard Generalized Markup) , ajustada para apresentao de documentos textos[ Conallen J., 2003] , que juntamente com o CSS foi utilizado para projetar a interface grfica do Zoagro.

Os arquivos JavaScripts so 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 utilizao tornou-se necessria devido as restries do mtodo Java showDocument( ), que restringe o carregamento do navegador sem s toolbars. Devido a esta restrio optou-se por utilizar o mtodo open( ) do JavaScript, como representa o cdigo abaixo.
Cdigo 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); } }

Cdigo 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 cdigo acima demonstra como feita a chamada a uma funo JavaScript de uma Applet. As Applets so pequenos programas Java armazenados normalmente em um computador remoto no qual usurio se conecta a partir do Navegador Web. As Applets so carregadas e executadas no Navegador e descartadas quando se completa a execuo [ Deitel H. M, Deitel P. J. 2001]. A aplicao de Applets no Sistema Zoagro ser descrita no tpico a seguir, devido a sua importncia 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 dinmicos em pginas da web utilizando Java e algumas tags de marcao simples. Estas tags fornecem ao designer de HTML um meio de acessar dados e lgica de negcios armazenados em objetos Java sem ter que dominar as complexidades do desenvolvimento de aplicaes [ Fields D. K. , Kolb M. A. 2000 ]. JSP foi empregado em todas as p ginas do sistema Zoagro que necessitavam de informaes armazenadas no Banco de Dados. Seu funcionamento no sistema ocorre da seguinte forma : O usurio seleciona em uma cidade atravs da Applet , que realiza uma chamada a uma pagina JSP, a partir de um JavaScript. A comunicao da JSP no ocorre diretamente com o Banco de Dados. A solicitao e a transmisso de informaes com o Banco de Dados intermediada pelos componentes JavaBeans e pela classe de Comunicao com o Banco de Dados. Isso ocorre pelo fato do Zoagro ter sido projetado sobre a arquitetura em trs camadas. Apesar de aparentemente estas camadas intermedirias tornarem o sistema mais complexo, o mesmo acaba se tornando, mais flexvel com um acoplamento mnimo entre as camadas do sistema, onde partes do mesmo podem ser alteradas independentemente. Os JavaBeans so componentes de softwares escritos em Java, que tem a finalidade de serem reutilizveis e independentes [Bomfim J. F. T. 2002]. Eles se encontram na camada de lgica de negcio e foram empregados no sistema com o intuito de separar a lgica de programao da interface com o usurio. As Servlets so componentes do lado do servidor que so empregada para escrever aplicativos Web em um servidor. Com freqncia Servlets empregada para a gerao de paginas dinmicas [Bond M.,Haywood D. 2003], mas no sistema Zoagro ela foi empregada para realizar a comunicao da Applet de Cultivares com a base de dados, atravs do servidor. A ltima camada do sistema a camada de lgica d e acesso a dados, onde a sua funcionalidade nica e exclusiva a comunicao com o banco de dados. Ela possui dois mtodos alm do construtor os mtodos alterarBD e consultarBD , que so chamados atravs dos componentes JavaBeans. A existncia desta classe justificada por uma restrio do desenvolvimento do projeto Zoagro de : No ser dependente de banco de dados; isto significa que se o banco utilizado no atender mais as necessidades do Zoagro, ou por alguma razo 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 mtodo construtor fica responsvel por toda parte de conexo com o banco de dados, o mtodo alterarBD tem a finalidade de alterar o banco de dados, recebendo o SQL da alterao como parmetro e retornando um inteiro como resposta. J o mtodo consultarBD tem a finalidade de realizar as consultas do sistema aonde ele recebe a consulta SQL como parmetro e retorna um ResultSet.

6. Desenvolvendo um mecanismo navegacional atravs de Applets

Um dos grandes problemas na implementao do sistema Zoagro, foi desenvolver o mecanismo em que o usurio pudesse selecionar os Estados e municpios utilizando somente mapas. A razo de se de senvolver tal mecanismo devido o s usurios em potencial do Zoagro (os produtores de Soja ),no possuem, na sua grande maioria, um conhecimento bsico necessrio de informtica . O desenvolvimento de um mecanismo navegacional atravs de mapas foi a melhor soluo de navegao encontrada para este nvel de usurios, uma vez que mapas fazem parte de suas concep es cognitivas. Os mapas foram implementados com a utilizao de vetores de polgonos, onde cada polgono 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 criao dos polgonos, que obedecem ordem alfabtica das cidades , isto significa que o polgono zero representa a primeira cidade na ordem alfabtica do respectivo Estado, como no caso do Paran Abati. A ordenao na criao dos polgonos foi necessria devido inexistncia de um mtodo que representasse diretamente o polgono selecionado, o nico mtodo do objeto polgono, que possibilitou a identificao, foi o mtodo inside(x,y) , que verifica se o polgono possui ou no determinada coordenada x,y. Assim ordena ndo os polgonos e realizando uma rotina de verificao, foi possvel identificar em que cidade o mouse esta posicionado. Apesar de no ser a maneira mais elegante de se solucionar o problema, a utilizao de polgonos foi nica encontrada. Tendo em vista que o mesmo mecanismo navegacional facilmente implementado em Visual Basic, utilizando API do Windows.

7. Discusses e Concluso
O desenvolvimento utilizando arquitetura em trs camadas no complexo e pode muito bem ser aplicado em sistemas pequenos. Sua utilizao proporciona muitas vantagens, sendo a principal delas a separao entre interface e regra de negcio. J a utilizao de Applet deixou uma enorme d vida: A aplicao utilizando Java foi a melhor soluo possvel, tendo em vista que existem outras tecnologias para solucionar o mesmo problema, como por exemplo Flash? No h duvida em relao capacidade das Applets, e sim quanto a sua viabilidade em relao aos mecanismos de comunicao existentes.

8. Apoio
Centro Federal de Educao Tecnolgica do Paran unidade de Cornlio Procpio (CEFET-PR) e Empresa Brasileira de Pesquisa Agropecuria (Embrapa).

9. Agradecimentos
A todos que colaboraram direta ou indiretamente com este projeto, em especial, coordenao do Curso de Tecnologia em Informtica da Unidade de Cornlio Procpio do CEFET-PR, e Embrapa Londrina-PR.

10. Referncias
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, So Paulo. Conallen J., (2003) Desenvolvendo Aplicaes Web com UML, editora Campus, So Paulo, p.15. Albuquerque F., (2001) TCP/IP Internet Programao de Sistemas Distribudos 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 Cincia Moderna, Rio de Janeiro, p. 2-20. Bomfim J. F. T., (2002) JSP A Tecnologia Java na Internet, editora rica, So Paulo, p. 229 263.