Desenvolvimento de Sistema Web utilizando arquitetura em Três Camadas e Applets Kanji Hara Neto 1, Lucas G Nadalete 1, Fabio A. Gennari 1, 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 funcionalidades 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 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 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 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 camadas 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 pa ra aplicações WEB Lógica de Apresentação para dispositivo móvel Lógica de Acesso a Dados ao Firebird 1.5 Lógica de Acesso a Dados ao PostgreSQL Banco de Dados Firebird 1.5 Banco de Dados 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. Lógica de Apresentação JavaScript Applet Html JSP Css 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 desenvolver 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 ordenando 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.