Вы находитесь на странице: 1из 9

19

Proposta de um Framework para aplicaes web Proposal for a Framework for web applications
Francisco de Oliveira Dantas Filho Hevanderson da Silva 1 Angelo Mrcio de Paula 2 Palavras-chaves: Web Software Padres de Projeto Arquitetura Resumo Aplicaes envolvendo internet so denominadas aplicaes web e requerem requisitos especiais de arquitetura de software para um correto desenvolvimento e funcionamento. Este trabalho tem como proposta apresentar as tcnicas de software livre, formando uma arquitetura para construir aplicaes web que funcionem na internet ou intranet. Todo framework foi desenvolvido na plataforma Java com o uso de Servlet, JSP e JavaBean. Ao final, o processo realizado apresentou alta produtividade, pois retirou do desenvolvedor a responsabilidade de programar o cdigo de comunicao envolvendo o protocolo HTTP e as trocas de mensagens entre as camadas da aplicao. Desta forma, o programador se concentrar em programar somente a regra de negcio do sistema proposto.
1

Artigo Original Original Paper

Abstract Applications involving Internet are called web applications and require specific requirements for software architecture for a correct development and functioning. This work has a proposal present the techniques of free software forming architecture to build web applications operating on the internet or intranet. Finally, the processor conducted showed high productivity, because withdrew from the developer the responsibility to set the code of communication involving the HTTP protocol and the exchange of messages between application tiers. Thus, the developer will focus on programming only the business rule of the proposed system.

Key words: Web Software Design Pattern Architecture

1. Introduo
Aplicaes de software so complexas porque modelam a complexidade do mundo real. Atualmente, aplicaes tpicas so muito grandes e complexas para que um nico indivduo consiga compreend-la. Sobre essas circunstncias, a construo e a manuteno de grandes aplicaes tornam-se um srio problema. A demanda por mais servios, novos produtos, pela melhoria da qualidade e menores preos vm, j h um bom tempo, impulsio-

1 2

Discente do Curso de Sistema de Informao - Centro Universitrio de Volta Redonda - UNIFOA Coordenao de Sistema de Informao e Engenharia Eltrica - Centro Universitrio de Volta Redonda - UNIFOA Volta Redonda-RJ

edio n 11, dezembro/2009

nando o estudo de tcnicas de desenvolvimento de software que possam ser efetivamente utilizadas para a obteno desses objetivos. Alm do aspecto puramente tcnico, encontramos ainda enorme dificuldade em gerenciar o processo de desenvolvimento. Este trabalho rene as tcnicas denominadas Padres de Projetos para construo de aplicaes que usam a internet/intranet como meio de comunicao, formando um framework, que atinja desde o cliente, executando uma pgina no navegador, at o dado,

Cadernos UniFOA

20

sendo gravado no banco de dados, ou seja, uma proposta de uma arquitetura para desenvolvimento web em uma totalidade razovel. Todos os testes foram realizados com produtos open source, destacando-se a linguagem de programao Java atravs das tecnologias Servlet e JSP que so especialidades para desenvolvimento web. Ao final, apresentado um framework com uma arquitetura madura, pronta para ser usada na construo de aplicaes web por qualquer equipe de desenvolvimento, a qual tenha conhecimentos bsicos na linguagem Java.

2. Reviso Bibliogrfica
2.1 Trabalhos Realizados Entre os trabalhos pesquisados no meio acadmico e na comunidade de desenvolvedores de cdigo aberto (open source), destacamse sob o ponto de vista acadmico e contriburam para o desenvolvimento desta pesquisa: Framework Apache Struts, desenvolvido por Struts (2009); Framework JavaServer Faces, desenvolvido por SDN (2009).

MVC. Esse projeto mantido por um grupo voluntariado que colabora entre si desenvolvendo o framework e mantendo-o dentro das caractersticas de cdigo aberto. O framework JavaServer Faces tambm usado para desenvolvimento de aplicaes web dinmicas visando separao das camadas. mantido pelo Java Community Process (JSR-314) e estabelece o padro do lado servidor para a construo de interfaces com o usurio. Com as contribuies do grupo de especialistas, o JSF foi concebido de forma a ser aproveitado por ferramentas as quais iro tornar ainda mais fcil o desenvolvimento de aplicaes web. A Facilidade de uso a principal meta do JSF, pois ele define claramente uma separao entre a aplicao lgica e a camada de apresentao tornando fcil a ligao entre a camada de apresentao e a lgica do negcio. Esse projeto permite, a cada membro da equipe de desenvolvimento, concentrar-se no desenvolvimento da lgica de negcio, ficando a cargo do JSF as complexidades de ligao entre as camadas. Por exemplo, o desenvolvedor no precisa ser especialista em HTML, pois o JSF possui TAGs que encapsulam a regra de apresentao atravs de passagem de parmetros, sem a necessidade de escrever qualquer script (SDN ,2009). 2.2 Reviso Tecnolgica 2.2.1 Java Beans JavaBeans so componentes de software escritos em Java. A API de JavaBeans foi criada pela Sun Microsystem com a cooperao da indstria e determina as regras que o programador de software deve seguir a fim de criar componentes de software reutilizveis e independentes. Assim como muitos outros componentes de software, os Beans encapsulam tanto estado quanto comportamento. Ao usar a coleo de tags relacionadas a Beans de JSP nas suas pginas da web, os programadores de contedo podem alavancar o poder de Java para adcionar elementos dinmicos s suas pginas sem escrever uma nica linha de cdigo Java. Ento, um JavaBean uma classe que segue certo padro de projeto. O padro tem

O Apache Struts um projeto popular desenvolvido por The Apache Software Foundation (STRUTS, 2009). Trata-se de um projeto open source para desenvolvimento de aplicaes web usando a linguagem de programao Java. O Struts empregado onde h necessidade de criao de web sites que possuem respostas dinmicas. Aplicaes web baseadas em JSP (Java Server Pages), ASP (Active Server Pages) e PHP (Hypertext Preprocessor) misturam dados, controle e visualizao em apenas um componente e, na prtica, verifica-se uma dificuldade na manuteno destes sites, principalmente, quando se trata de sistemas de mdio para grande porte. Ento, umas das preocues em uma aplicao ter uma clara separao das camadas, o que alcanado com a utilizao da arquiteura MVC (Model-View-Controller). O Struts foi concebido para ajudar os desenvolvedores criar aplicaes web que utilizam a arquitetura

Cadernos UniFOA

edio n 11, dezembro/2009

uma semntica bem definida para permitir que a estrutura do JavaBean seja descoberta atravs da introspeco de sua classe compilada, usando a API de reflexo Java. Os requisitos fundamentais de um JavaBean so os seguintes: Ser uma classe Java public, possuir um construtor sem nenhum argumento e, normalmente, possuir uma ou mais propriedades (ou atributos) que podem ser manipulados atravs de mtodos pblicos (DEITEL E DEITEL, 2006). 2.2.2 Servlet Um Servlet Java um programa no lado do servidor que ativado pelo servidor web para atender aos pedidos HTTP. Um Servlet executado em uma mquina virtual Java no servidor da web e, normalmente, realiza alguma computao para gerar o contedo da resposta HTTP (DEITEL E DEITEL, 2006). Em comparao a outras tcnicas de programao no lado do servidor, os servlets representam uma alternativa mais madura e confivel. 2.2.3 JSP Devido ao grande sucesso que o ASP (Active Server Page) da Microsoft, a Sun Microsystem decidiu construir uma verso to poderosa quanto ao ASP da Microsoft, o JavaServer Pages (JSP). A tecnologia JSP incorporado ao modelo de Servlet. A ideia bsica das JSP permitir que o cdigo Java seja misturado com modelos HTML e XML estticos. O propsito da lgica Java gerar contedo dinmico na pgina, enquanto a linguagem de marcao manipula a estruturao e a apresentao dos dados. (DEITEL E DEITEL, 2006).

A proposta desta pesquisa apresentar um framework para desenvolvimento web extendido at a camada da regra de negcio e a camada de dados sem ter que apresentar conhecimentos alm do trivial (JSP, Servlet e JavaBean). A arquitetura da aplicao deve ser projetada de modo que determinadas situaes tpicas no se tornem problemas os quais impediro a aplicao de atender aos requisitos do sistema. So consideradas as seguintes situaes como crticas: Sistemas envolvendo interfaces, servidor de aplicao remoto e banco de dados. Aplicaes distribudas. Aplicaes que acessam dados em mais de uma fonte de dados.

21

3.1.1 Sistemas envolvendo interfaces, servidor de aplicao remoto e banco de dados As seguintes situaes esto presentes nesse caso: O sistema tem que aceitar dados do usurio, atualizar o banco de dados e retornar, mais tarde e em outro cenrio, o dado para o usurio. A existncia de vrias formas em que o dado pode ser aceito e apresentado no sistema do usurio. Dados que alimentam um sistema em um formulrio devero ser restaurveis em outro formulrio.

3. Materiais e Mtodos
3.1 Arquitetura Aplicao Os dois frameworks (Struts e JSF) dominam o mercado de desenvolvimento web, porm, eles apenas tratam a camada que faz a interface com os pedidos HTTP. Alm do mais, como eles cobrem praticamente todos os pontos relacionados ao desenvolvimento web, os mesmos se tornam complexos, exigindo um conhecimento extra alm dos JSP, Servlets e JavaBean.

Se o sistema desenvolve um simples componente que interage com o usurio e tambm mantm o banco de dados, ento um requerimento para suportar um novo tipo de apresentao necessitar o reprojeto do componente. No estudo de caso proposto, a clnica fornece a facilidade de acompanhamento dos resultados. Quando o usurio se autenticar no sistema, se ele for o paciente, ele verificar o resultado de um determinado procedimento; se ele for o administrador, verificar a quantidade de procedimentos realizados em um

Cadernos UniFOA

edio n 11, dezembro/2009

22

perodo de tempo; se ele for o fisioterapeuta, dar um parecer no procedimento realizado. Ou seja, a mesma informao pode ser visualizada de vrias formas, de acordo com o perfil do solicitante. Aqui, o mesmo dado que representa o procedimento visto em mltiplas formas, mas controlado por uma nica entidade na aplicao. Assim, trs tarefas ocorrem ao mesmo tempo na aplicao: Gerenciar a interao do usurio com o sistema. Gerenciar o dado atual. Formatar o dado em mltiplas formas.

Dessa forma, um simples componente que faz todas as tarefas pode ser dividido dentro de trs componentes independentes. Todas trs tarefas podem ser tratadas por diferentes componentes. Ento, a soluo segundo Deshmukh e Malavia (2003) separar os dados da apresentao dos dados de manuteno e ter um terceiro componente coordenador. Esses trs componentes so chamados Modelo, Viso e Controlador. Eles formam o bsico do padro MVC. A Figura 1 mostra o relacionamento entre os componentes do modelo MVC.

dor s aes do usurio. Os componentes web JavaServer Page (JSP) e o JSP Standard Tag Library (JSTL) foram aplicados na construo dessa camada. O Controlador gerencia o modelo e a viso. Ele instancia e associa o modelo e a viso. Dependendo do requerimento da aplicao, ele pode instanciar mltiplas vises e pode associ-las com o mesmo modelo. Ele escuta as aes do usurio e manipula o modelo de acordo com a regra de negcio. Um Servlet foi aplicado nessa camada. Desenvolver uma aplicao seguindo o padro model-view-controller permite criar mltiplas vises para um mesmo dado. Mudanas ocorrem nos componentes do modelo ou nos componentes de viso de forma independente. A viso permanece a mesma. Isso aumenta a manutenibilidade e a extensabilidade do sistema. 3.1.2 Em aplicaes distribudas

Os componentes do cliente e os componentes do servidor residem em locais remotos e a comunicao ocorre sobre a rede de comunicao. Sendo assim: O banco de dados fica no lado do servidor O servidor fornece mtodos gets (getImagem( ), por exemplo) para que o mesmo possa cham-lo um por um para reaver os dados. O servidor fornece mtodos sets (setImagem(byte image[ ]), por exemplo, para o cliente, para que o mesmo possa cham-lo um por um para atualizar os dados no banco de dados.

Cadernos UniFOA

Figura 1. Modelo-Viso-Controlador

O modelo responsvel por manter o dado ou o estado da aplicao. Ele tambm gerencia o armazenamento e recuperao do dado armazenado. O componente JavaBean em conjunto com o framework Hibernate que realiza persistncia objeto relacional foi aplicado nessa camada. A viso contm a lgica de apresentao. Ela mostra o dado contido no modelo para o usurio. Ele tambm permite o usurio interagir com o sistema e notificar o controla-

Cada chamada entre o cliente e o servidor uma chamada de mtodos remotos com uma substancial sobrecarga na rede. Se a aplicao cliente chama os mtodos gets e sets para reaver ou atualizar simples valores de atributos, ocorrero muitas chamadas remotas para esse atributo. Essa chamada remota gera muita sobrecarga na rede e, consequentemente, uma diminuio do desempenho do sistema. A camada de negcio acessar o banco de dados diretamente ou via a camada de recursos, e colocar o mecanismo de acesso dentro de um conjunto de entidades e beans

edio n 11, dezembro/2009

controladores. Esses componentes expem o dado via interfaces remotas. As aplicaes desktop`s, os servlets e pginas JSP na camada de apresentao precisam acessar esses dados de negcio, eles fazem isso chamando os mtodos das interfaces remotas implementadas por Javabeans. Para exemplificar, vamos considerar que desejamos incluir dados de uma paciente na base de dados e se trata de uma aplicao distribuda. Os dados so: identificador, nome e imagem (foto), o qual est encapsulado em um Javabean chamado Laudo. O acesso para a informao est encapsulado pela aplicao da camada de negcio com a ajuda de um Javabean controlador chamado LaudoFacade. Esse controlador expe mtodos para o cliente remoto, tais como: getId(), setId(...), getNome(), setNome(...), getImagem(), setImagem(...). Os servlets e pginas JSP ento tm que chamar cada mtodo um por um remotamente no servidor. Conforme a Figura 2.

serializado e transferido pela rede bit a bit. O cliente do outro lado reconstri o objeto localmente com todos os valores intactos. Uma vez que o objeto est local, o cliente consulta todos os atributos sem gerar sobrecarga na rede. Agora, considerando o exemplo anterior, ao invs de fazer mltiplas chamadas remotas no objeto Laudo para reaver todos os atributos para formar um laudo, o cliente chama um simples mtodo getLaudo no LaudoFacade, este vai extrair os dados do objeto Laudo, criar o LaudoVO e retorn-lo pela rede com todos os atributos estruturados em um objeto prprio para trafegar pela rede. Assim, o cliente acessar todas as informaes em uma nica vez localmente. A Figura 3 est ilustrando a soluo.

23

Figura 2 Sobrecarga de chamadas em objetos remotos

A Figura 2 apresenta alguns problemas: Um simples objeto de negcio tem muitos atributos Na maioria das vezes, o cliente requer vrios atributos ao mesmo tempo e quase nunca apenas um atributo. A utilizao dos mtodos gets muito maior que os mtodos sets

Figura 3 Aplicao dos padres Facade e Value Object

Dessa forma, preciso criar um objeto para encapsular todos os atributos que so requeridos pela aplicao cliente. Esse objeto chamado de Value Object. Quando o cliente requer o dado do servidor, o componente do lado do servidor extrai os valores localmente e constri o Value Object. Esse Value Object ento enviado para o cliente por valor e no por referncia, o que significa que esse objeto

O cliente pode ser uma pgina web JSP, um servlet, uma applet Java, um JPanel no formato desktop que faz chamadas remotas para o objeto de negcio na camada de negcio no servidor. O objeto de negcio um componente que cria o Value Objetct. O cliente sempre far chamadas para o objeto de negcios. A interface remota simplificada porque mltiplos mtodos retornando um simples valor so simplificados dentro de um simples mtodo, retornando um grupo de mltiplos valores. A reduo do nmero de chamadas, por meio da rede, melhora o tempo de resposta da

Cadernos UniFOA

edio n 11, dezembro/2009

24

aplicao. Se o cliente deseja atualizar o valor do atributo, ele primeiro atualiza o valor no Value Object local e, ento, o envia para o servidor para que possa ser persistido o novo valor. Tudo isso acontece usando o mecanismo de passagem por valor. O Value Object pode ficar desatualizado, isto , se o cliente adquiriu um Value Object por um longo perodo de tempo, h possibilidade de a informao ter sido atualizada por outro cliente. No caso de Value Object mutvel, requisies de atualizao de dois ou mais clientes podem resultar em conflito de dados. Resumindo, um Value Object um pequeno objeto Java serializado que usado para conduzir grupo de dados sobre a rede de um componente residente em outra camada de uma aplicao multicamadas distribudas. O seu principal propsito reduzir sobrecarga de comunicao, reduzindo o nmero de chamadas remotas entre os componentes distribudos. 3.1.3 Em aplicaes que acessam dados em mais de uma fonte de dados As aplicaes envolvem atualizaes e consultas de fontes de dados diferentes: banco de dados relacionais, sistemas de arquivos, arquivos XML, assim por diante. As seguintes situaes ocorrem: As aplicaes envolvem atualizaes e consultas de fontes de dados iguais, como um banco de dados, mas bancos de dados so fornecidos por diferentes fabricantes, por exemplo, Oracle, SQLServer da Microsoft, DB2 da IBM e outros, onde cada fabricante construiu o seu prprio mecanismo de acesso. Alguns bancos de dados permitem manipulao de dados via store procedure. O processo de chamada da store procedure so dependentes da implementao do sistema do banco de dados.

apenas uma fonte de dados, mas o banco de dados precisa mudar de endereo fsico em algum momento, logo, todos os componentes da camada de negcio que acessam a fonte de dados diretamente sero alterados. Ento, quando temos vrias fontes de dados ou quando a mesma no est corretamente definida, apresentar um grande problema de manuteno e de baixa flexibilidade do sistema.

Figura 4 Negcio acessando base de dados

A Figura 4 mostra a dificuldade que a camada de negcio encontra para acessar dados de diferentes fontes, visto que cada fonte de dados possui o seu prprio mecanismo de acesso. Outro problema que existe tambm quando a camada de negcio precisa acessar

Dessa forma, a lgica de negcio implementada pelos objetos de negcio no deve depender do tipo do armazenador de dados que usado. O algoritmo de negcio deve ser separado do cdigo que acessa o banco de dados. A lgica de negcio implementada pelo objeto de negcio no dever depender da forma em que o dado armazenado acessado. A soluo apresentada na Figura 5 cria um objeto especial que se ocupa em acessar os bancos de dados. O DAO uma classe abstrata ou uma interface que tem mtodos como select(..), upadate(..), delete(...) e insert(..), as classes derivadas devero ento implementar esses mtodos na forma especfica que requerida pelo banco de dados individualmente. Ento os Daos encapsulam a lgica de acesso aos dados, e o objeto de negcio que usa as classes Daos no precisa conhecer sobre algum conjunto de cdigo SQL ou as APIs de baixo nvel fornecidas pelo fabricante do banco de dados. O padro DAO fornece uma camada de abstrao entre as camadas de negcio e a fonte de dados. Objetos da camada de negcio acessam a fonte de dados via Data Access Object. O DAO encapsula os detalhes de persistncia e fornece um conjunto padro de interface para acessar o dado. Esse objeto realiza todas as ope-

Cadernos UniFOA

edio n 11, dezembro/2009

raes relacionadas fonte de dados, tais como, consultas SQL. Isso limita o impacto de mudanas da fonte de dados para apenas as classes que compe o DAO, isso melhora a flexibilidade e manutenibilidade dos objetos de negcio.

Figura 5 Exemplo do padro DAO

O objeto de negcio usa o DAO para alcanar o dado armazenado, o prprio DAO abstrai e encapsula as caractersticas da fonte de dados que a camada de negcio precisa para acessar os dados. Dessa forma, a fonte de dados ser qualquer espcie de banco de dados ou sistema legado, e a aplicao vai selecionar dinamicamente a fonte de dados plugando o apropriado DAO. 3.2 Arquitetura da Aplicao proposta A aplicao ser construda com componentes para as camadas cliente, apresentao, negcio, integrao e dados e foi influenciada por Alur, Crupi e Malks (2001), Deshmukh e Malavia (2003) e Paula (2007). A Figura 6 mostra os padres cooperando entre si, formando a arquitetura. A camada do cliente permitir ao cliente interagir com a aplicao, essa pode ser uma aplicao web rodando em um browser, uma aplicao desktop ou at uma aplicao Wirelles rodando em um Palm. A camada de apresentao define o nvel de permisso do usurio, encapsula a lgica da interface, gerencia a sesso do usurio e recebe e envia respostas para o usurio. A camada de negcios o mdulo responsvel pela realizao das regras de negcio da aplicao. A camada de integrao responsvel pela comunicao com os recursos externos. A camada de recursos responsvel por manter os dados persistidos. Dessa forma, o cliente web far sempre uma requisio para um Front Controller, que delegar a um Dispatcher a funo de criar um

action para atender a solicitao e encaminhar a resposta para um View formar a sada para o cliente, essa funcionalidade tambm mostrada na Figura 7. O cliente Desktop acessar o Facade diretamente atravs de uma chamada remota. O padro Service Locator, faz a localizao dos objetos remotos. O Facade um controlador da regra de negcio. Ele conhece o fluxo de atendimento da aplicao, sua principal funo acessar a base de dados atravs dos Dao`s criados pelos Abstracts Factory e Factory, executar a regra de negcio encapsulada pelos objetos de negcios e garantir a resposta para o cliente criando Value Objets apropriados para cada solicitao. O sistema possuir Implementation Dao para cada meio de armazenamento no sistema. Os meios mais comuns so XML, Sistema de arquivo e banco de dados relacional.

25

Figura 6 Arquitetura da aplicao segundo Paula (2007)

4. Resultados
A Figura 7 mostra as classes envolvidas no controlador da camada de apresentao. As classes so empacotadas em um arquivo com extenso jar, nesse caso, a sua reutilizao

Cadernos UniFOA

edio n 11, dezembro/2009

26

feita adicionando o arquivo de nome controle. jar no path da aplicao e a devida configurao do web.xml. Ento, quando o cliente disparar uma URL (Exemplo: pesquisar.do) o servlet FrontController ser acionado pelo servido web e vrias aes ocorreram no servidor:

A Figura 8 evidencia o prottipo construdo para testar o framework.

Figura 8 Estudo de caso

5. Discusso
Temos, ao longo dos anos, vrios casos que indicam insucesso quando se trata de desenvolvimento de software. De forma emprica, constatamos as seguintes situaes relatadas na Figura 9. Temos que unir esforos para atingirmos o topo da pirmide e com um custo, qualidade e prazo dentro da normalidade.

Figura 7 Controlador da camada de apresentao

1.

Uma Thread FrontController disparado. A objeto URIHelp reconhece a URI solicitante. O FrontController solicita uma instncia do objeto Dispatcher. O FrontController delega as demais responsabilidades para o objeto Dispatcher. O Dispatcher solicita uma instncia do objeto FactoryAction. O Dispatcher pede ao FactoryAction o action presente na URI. O Dispatcher executa o objeto Action (Exemplo: pesquisarAction.class) O Dispatcher faz um forward (encaminha o pedido) para o documento (JSP, HTML, etc..) conforme o retorno do Action.

Cadernos UniFOA

2. 3. 4. 5. 6. 7. 8.

Figura 9 Crise do software

Vrios fatores influenciam no desenvolvimento do software e destacamos os mais importantes: alteraes nas metas, falha no gerenciamento de riscos, complexidade do software e projeto da arquitetura. A nossa pesquisa aplicada ao Projeto da Arquitetura e pretende-se, dessa forma, uma arquitetura que permita atender aos princpios bsicos de uma aplicao: Performance; transparncia; flexibilidade; confiabilidade e escalabilidade. Todos os membros da equipe precisam codificar da mesma forma, facilitando a rotatividade dos profissionais, fato concreto na atual escassez de profissionais de TI. Com isso, a nossa proposta contribuir tanto no desenvolvimento devido padronizao imposta na manuteno

edio n 11, dezembro/2009

do sistema devido ao uso dos padres de projeto- quanto na sedimentao do sistema, pois est construdo com boas regras de codificao, conhecidas e usadas mundialmente.

PAULA, A.M.; Gerenciamento, Anlise e Transmisso de imagens, On-Line, Via TCP/IP, Dissertao de Mestrado, Mestrado em Tecnologia, CEFET, Rio de Janeiro, RJ, Brasil, 2007. SDN Sun Developer Network: JavaServer Faces Technology, 2009. Disponvel em:< http://java.sun.com/javaee/javaserverfaces/> Acesso em: 18 Mai. 2009. STRUTS The Apache Software Foundation, 2009. Disponvel em: <http://struts.apache. org> Acesso em: 18 Mai. 2009.

27

6. Concluso
Conclumos que, devido importncia alcanada pelas aplicaes web e a forma que a internet invadiu o nosso cotidiano, seja necessrio realizar pesquisa para auxiliar na construo dos softwares, atravs de solues reutilizveis. Percebemos tambm que no decorrer do desenvolvimento de uma aplicao, comum nos depararmos com problemas que precisam de conhecimentos estratgicos para serem resolvidos. Para cada problema que encontramos, imediatamente, considerado inmeras formas de resolv-lo, incluindo solues de sucesso j vividas ou solues completamente novas. O segredo documentar cada soluo aplicada e medida que reusamos uma soluo com sucesso, considera-se que temos uma soluo para resolver um determinado problema. Dessa forma esse framework apresentado poder ser evoludo para atender a novas especificaes, desde que devidamente documentado e compartilhado na comunidade acadmica de desenvolvedores. Finalizando, esse framework est maduro para ser usado em desenvolvimento de aplicaes web, pois foi desenvolvido com tcnicas j testadas mundialmente.

7. Referncias
ALUR, D.; CRUPI, J.; MALKS, D.; Core J2EE Patterns: Best Practices and Design Strategies, Califrnia, Sun Microsystems Press, 2001. DEITEL, H.M.; DEITEL, P.J.; Java: Como Programar, 6 ed. So Paulo, Pearson, 2006. DESHMUKH, H.; MALAVIA, J.; SCWCD, Exam Study Kit: Java Web component Developer Certification, Greenwich, 2003.

Endereo para Correspondncia: Angelo Mrcio de Paula Coordenao de Sistema de Informao e Engenharia Eltrica angelo.paula@foa.org.br Centro Universitrio de Volta Redonda Campus Trs Poos Av. Paulo Erlei Alves Abrantes, n 1325, Trs Poos - Volta Redonda / RJ CEP: 27240-560

Informaes bibliogrficas: Conforme a NBR 6023:2002 da Associao Brasileira de Normas Tcnicas (ABNT), este texto cientfico publicado em peridico eletrnico deve ser citado da seguinte forma: FILHO, Francisco de Oliveira Dantas; SILVA, Hevanderson da; PAULA, Angelo Mrcio de. Proposta de um Framework para aplicaes web. Cadernos UniFOA. Volta Redonda, ano IV, n. 11, dezembro 2009. Disponvel em: <http://www.unifoa.edu.br/cadernos/edicao/11/19.pdf>

Cadernos UniFOA

edio n 11, dezembro/2009

Вам также может понравиться