Académique Documents
Professionnel Documents
Culture Documents
Com o advento da World Wide Web, ou simplesmente Web, pginas e aplicativos comearam a popular o universo de sites disponveis. Nesta poca, websites eram desenvolvidos de maneira ad-hoc, sem uma metodologia ou processo para apoiar seus criadores. No entanto, medida que eles cresceram em complexidade e tornaram-se verdadeiras aplicaes na Web, tornou-se necessrio aplicar mtodos disciplinados de Engenharia de Software, adaptados para essa nova plataforma de implementao. Caractersticas do ambiente Web, como concorrncia, carga imprevisvel, disponibilidade, sensibilidade ao contedo, evoluo dinmica, imediatismo, segurana e esttica (PRESSMAN, 2005) imprimiram uma nova dinmica aos processos j existentes, dando origem a uma nova subrea da Engenharia de Software, a Engenharia Web. MURUGESAN et al. (1999) a definem como o estabelecimento e uso de princpios de engenharia e abordagens disciplinadas para o desenvolvimento, implantao e manuteno de aplicaes baseadas na Web. Existem diversos tipos de website. H pginas que so estritamente informativas (ex.: pgina de um professor da universidade), algumas vezes com uma grande carga de elementos multimdia (ex.: website de um museu ou enciclopdia online). Outras, no entanto, so verdadeiros sistemas de informao baseados na Web, como o caso de lojas virtuais, ambientes cooperativos, sistemas de gerncia empresarial, dentre muitos outros. Neste trabalho, nos referimos a esse tipo de website como Sistemas de Informao Web (Web-based Information Systems - WISs) e ao conjunto amplo de todas as aplicaes Web como WebApps (abreviao de Web Applications). Em se tratando de WISs, tecnologias para implementao deste tipo de aplicao Web vm se desenvolvendo de forma rpida e consistente. Em 1994, com o advento do Common Gateway Interface (CGI), programas em linguagens como C ou PERL poderiam ser ativados por requisies de navegadores Web, fazendo com que um servidor Web pudesse retornar ao cliente o que fosse impresso pelo programa em sua sada padro. Hoje, existem containers que gerenciam automaticamente componentes criados em linguagens orientadas a objetos, provendo uma srie 2
de servios automticos, como gerenciamento de persistncia, controle de transaes, etc. Em particular, destaca-se para ns o surgimento de diversos frameworks que provem uma slida infra-estrutura para o desenvolvimento de WISs. O uso desses frameworks, com o passar do tempo, tornou-se estado-da-prtica e at mesmo influenciou na definio de padres para desenvolvimento de aplicaes distribudas. Seu uso (ou reso) auxilia a equipe de desenvolvimento a construir software mais rapidamente (vrios componentes j esto prontos) e com maior qualidade (os frameworks j foram extensivamente testados por seus criadores). Este captulo apresenta uma reviso geral das metodologias e frameworks propostos pela comunidade de Engenharia Web. A partir dessa reviso, foi possvel observar prticas bem sucedidas e extrair idias que poderiam ser reproduzidas no contexto da proposta de um novo mtodo de projeto. Tal reviso foi feita a partir de diversas fontes, sendo a principal delas o relatrio tcnico da reviso sistemtica conduzida por CONTE et al. (2005), no qual diversos artigos extrados dos acervos digitais da Elsevier (http://www.sciencedirect.com) e IEEE
(http://www.ieee.org/web/publications/home) so referenciados e brevemente descritos, no contexto de uma pesquisa por metodologias Web que incluam atividades de garantia da qualidade. Outras fontes foram as bibliotecas digitais da ACM (http://portal.acm.org/dl.cfm) e Kluwer (http://www.springerlink.com), alm de mecanismos de busca regulares da Internet (ex.: Google), trocas de experincia em congressos da rea e conhecimento prvio do autor deste trabalho e de seus orientadores. Para uma melhor organizao do captulo, dividimos a apresentao dos trabalhos pesquisados em quatro sees: metodologias (seo 2.1), linguagens de modelagem (seo 2.2), frameworks (seo 2.3) e outros trabalhos relacionados (seo 2.4). Na seo 2.5 conclumos com uma breve anlise dos trabalhos citados.
So apresentadas a seguir as seguintes propostas: a Metodologia Baseada em Processos de Negcio, a Metodologia de Prototipao Rpida Dirigida a Modelos em Escala Real, a metodologia proposta por Lee & Shirani, o Mtodo de Desenvolvimento Ariadne, a Metodologia de Desenvolvimento de Comrcio na Internet, a metodologia proposta por Conallen, a Soluo Web Orientada a Objetos, a Engenharia Web Baseada em UML, a metodologia de apoio ao uso do Framework JAFAR2 e o mtodo OOHDM.
numa loja virtual). A metodologia divide-se em duas fases principais: anlise de requisitos de componentes e especificao de componentes. A anlise inicia com a identificao das funes da aplicao (em abstraes de alto-nvel e detalhamentos de nvel mais baixo) e segue para a determinao do mximo denominador comum entre as funes requeridas e os componentes disponveis. Finalizando, modelos de anlise dos compndios identificados so construdos, utilizando uma notao prpria da metodologia, mostrada na Figura 2.2.
Figura 2.2: Notao para modelos de requisitos de componentes de baixo-nvel (LEE et al., 2004) A fase de especificao de componentes possui trs atividades. Na primeira - especificao de renderizao - as pginas invisveis, que so responsveis pela renderizao das pginas visveis, so modeladas utilizando a notao mostrada na Figura 2.3. A segunda atividade especificao de integrao - identifica relacionamentos de um compndio com outros e com componentes externos. A ltima fase - especificao de interface - rene as interfaces dos compndios para localizao dos componentes em um ambiente distribudo.
Figura 2.3: Notao para modelos de especificao de componentes (LEE et al., 2004) Apesar de propor sua prpria notao para anlise de requisitos e especificao de
componentes, a metodologia aceita a utilizao da notao de casos de uso para a modelagem dos compndios e de diagramas de classes para a modelagem das pginas.
Fase
Atividade
O mtodo Ariadne no impe nenhuma seqncia rgida para as fases ou suas atividades, deixando a cargo do desenvolvedor escolher a melhor forma de conduzir seus projetos.
Figura 2.4: Processo de desenvolvimento de software proposto por Conallen (CONALLEN, 2002) O sub-processo Reiterar inicia com a reviso e refinamento do plano da iterao. A seguir, as seguintes atividades so executadas em paralelo: levantamento de requisitos, anlise, projeto da arquitetura, projeto detalhado, implementao, testes, gerncia de alteraes,
desenvolvimento do ambiente e desenvolvimento do projeto. Finalizada a iterao, o progresso alcanado at o momento apresentado s partes interessadas (stakeholders) e a iterao atual avaliada, ajustando o plano da prxima iterao, se necessrio.
Figura 2.5: Detalhamento da atividade "Reiterar" (CONALLEN, 2002) No que tange ao levantamento e anlise de requisitos, o grande diferencial da metodologia de Conallen em relao ao desenvolvimento convencional a definio de um novo modelo, chamado Modelo de Experincia do Usurio, que tem como objetivo definir diretrizes para a construo de pginas Web, especificando regras de aparncia e navegao que visam a manter toda a aplicao num mesmo estilo visual e fornecer uma interface mais amigvel para os futuros usurios da WebApp. A modelagem da experincia do usurio (User Experience UX) realizada pela equipe de UX, liderada pelo Arquiteto da Informao, um novo papel em processos de software, especfico para a Engenharia Web. O objetivo a criao do documento de diretrizes de UX, que comea a
10
ser construdo logo na fase de anlise e descreve tudo que um desenvolvedor de pginas Web precisaria saber para especificar e criar uma nova tela que, quando adicionada ao restante do sistema, parea ser uma parte integrante do mesmo. A equipe de UX tem o desafio de manter a interface com o usurio consistente com os paradigmas atuais e, principalmente, adequada ao contexto no qual se espera que o sistema seja executado. A modelagem UX complementa os casos de uso, mostrando de forma abstrata como as informaes sero trocadas entre o sistema Web e seus usurios. Seus artefatos principais so mapas de navegao e roteiros. Como a modelagem UX e a anlise so feitas em paralelo por duas equipes distintas, Conallen sugere que se faa um mapeamento entre as classes limtrofes (boundary) do modelo de anlise e as telas do modelo UX. Assim, garante-se que ambas as equipes esto trabalhando na soluo do mesmo problema. Conallen retrata a importncia do modelo UX ao dizer que formalizar a experincia do usurio em um modelo UML uma maneira de estabelecer esse acordo de modo que seja compreensvel pelas equipes criativas que tendem a ser aparentemente menos treinadas em cincia da computao. A UML visual o bastante para que muitos membros no tcnicos a compreendam e formal o suficiente para ter valor semntico significativo. A outra vantagem [...] que possvel para as equipes de engenharia estabelecer e manter mapeamentos diretamente entre um caso de uso e modelos de projeto para o modelo UX (CONALLEN, 2002). O projeto, segundo a metodologia de Conallen, dividido em duas vises: lgica e de componentes. A primeira possui um nvel de abstrao mais alto (classes e associaes), enquanto a segunda trata de arquivos que efetivamente comporo o sistema implementado (pginas e diretrios). Finalmente, Conallen prope a utilizao de um perfil UML para modelar diversos artefatos sugeridos por sua metodologia. Esse perfil descrito com mais detalhes na Seo 2.2.2.
11
especificaes (FONS et al., 2003). Seguindo a metodologia definida por OO-Method, existem dois passos principais para a construo de um sistema orientado a objetos: Especificao do Problema e Desenvolvimento da Soluo. Na primeira fase devem-se capturar as peculiaridades e o comportamento que o sistema deve oferecer para satisfazer os requisitos identificados. Esse passo inclui a atividade de especificao de requisitos utilizando a abordagem de casos de uso e posteriormente as atividades de modelagem conceitual, nas quais derivam-se abstraes do problema em termos de classes com estrutura, comportamento e funcionalidade definidas. Em OOWS, os seguintes modelos so construdos: de Objetos, Dinmico, Funcional, de Navegao e de Apresentao (FONS et al., 2002). O Modelo de Navegao captura os requisitos de navegao da aplicao, definindo um mapa de navegao para cada tipo de usurio do sistema. Sua construo dividida em duas etapas: Identificao e Categorizao do Usurio e Especificao do Diagrama de Navegao. O mapa de navegao, que criado para cada usurio na segunda etapa, representado por um grafo dirigido, cujos vrtices representam as unidades bsicas de interao os contextos de navegao (graficamente representados por pacotes da UML) e os arcos denotam os caminhos de navegao vlidos pr-definidos. Cada contexto de navegao posteriormente modelado na forma de um diagrama de classes, exibindo as classes de navegao que dele fazem parte. O modelo de apresentao usa os contextos de navegao como principais insumos para a definio dos requisitos de apresentao, que so especificados por meio de padres de apresentao (presentation patterns) que podem ser associados aos elementos do contexto de navegao. Na segunda fase, Desenvolvimento da Soluo, prope-se uma estratgia de gerao de cdigo baseada em componentes para implantar um prottipo operacional da aplicao Web, com funcionalidade equivalente especificao inicial. Essa fase se d de maneira completamente automtica por um compilador de modelos conceituais, facilitando as tarefas de manuteno e evoluo (FONS et al., 2002). A aplicao Web gerada dividida em uma arquitetura de trs camadas: camada de apresentao (interface com o usurio), camada de aplicao (lgica de negcio) e camada de persistncia (acesso a repositrios de dados). 12
utilizados, modelando de forma mais detalhada a interao com o usurio. Por fim, diagramas de implantao podem ser usados para documentar a distribuio dos componentes da aplicao Web.
Implementao. Tais atividades so precedidas pela especificao de requisitos e so executadas numa mistura de ciclo de vida incremental e iterativo, construindo e evoluindo os modelos pouco a pouco a cada passo. Os fundamentos da abordagem OOHDM so: (i) a noo de que objetos de navegao so vises de objetos conceituais; (ii) o uso de abstraes apropriadas para organizar o espao de navegao, com a introduo de contextos de navegao; (iii) a separao de questes de interface das questes de navegao; e (iv) uma identificao explcita de que algumas decises de projeto s precisam ser feitas no momento da implementao (SCHWABE et al., 1998). Durante o Projeto Conceitual, constri-se um esquema conceitual representando objetos, suas relaes e colaboraes existentes no domnio em questo. Tal esquema conceitual descrito em termos de classes, relacionamentos e sub-sistemas, podendo ser modelado em UML. O Projeto de Navegao subdividido em trs fases. O Projeto de Navegao de Tarefas utiliza os casos de uso e o modelo conceitual para produzir diagramas de contexto e cartes de especificao. Em seguida, o Projeto de Navegao da Aplicao refina esses produtos para culminar na Especificao de Navegao da Aplicao OOHDM, produzindo esquemas de
14
navegao de classes, esquemas de classes dentro de um contexto (in-context), tabela de mapeamento navegao-conceitual, diagrama de contexto e cartes de especificao (GELL et. al, 2000). Depois que a estrutura de navegao foi definida, seus aspectos de interface so especificados no Projeto de Interfaces Abstratas, definindo a forma na qual diferentes objetos de navegao sero apresentados, quais objetos de interface ativaro uma navegao e outras funcionalidades da aplicao e quando as transformaes de interface sero feitas. Por fim, na Implementao, os modelos construdos at ento so mapeados para objetos de implementao a partir de modelos (templates). Nessa fase, o ambiente de execuo especfico ser levado em conta e o projetista deve decidir como os itens de informao sero armazenados e como a interface, aparncia e comportamento do sistema sero implementados em HTML (e suas possveis extenses). O mtodo OOHDM foi estendido, dando origem ao mtodo SHDM (Semantic Hypermedia Design Method). SHDM mantm os modelos definidos em OOHDM, estendendo-os com algumas primitivas, tais como subrelaes e classes annimas, inspiradas nas linguagens RDF e DAML+OIL (LIMA et. al, 2003). O objetivo propor uma abordagem para a criao de aplicaes hipermdia para a Web Semntica (ver Seo 3.1).
15
posteriormente, do origem a componentes de projeto. A segunda parte da metodologia, modelagem de implementao Web, um guia para implementao do modelo criado durante a fase anterior em uma infra-estrutura especfica baseada em tecnologia Web. A Metodologia de Desenvolvimento de Comrcio na Internet (Internet Commerce Development Methodology ICDM) (STANDING, 2002) uma metodologia para o desenvolvimento de aplicaes de comrcio eletrnico negcio-consumidor (business-toconsumer B2C) para a Web. ICDM prov um conjunto de diretrizes para guiar o desenvolvedor nessa tarefa. ICDM enfatiza tanto os aspectos tcnicos quanto questes estratgicas, de negcio, gerenciais e da cultura organizacional. ICDM envolve toda a organizao, provendo diretrizes que podem ser adaptadas da forma que for mais adequada. Atividades de gerncia so realizadas em trs nveis (gerencial, componentes e implementao) continuamente durante todo o processo. JAFAR2 (J2EE Architectural Framework 2.0) (RIES et al., 2003, apud GUELFI et al., 2003) um framework para construo de aplicaes Web de comrcio eletrnico utilizando Java 2 Enterprise Edition (J2EE), verso 1.4 (SHANNON, 2003). O framework prov solues tcnicas para problemas comuns no desenvolvimento desse tipo de aplicao e prov padres que simplificam o trabalho do desenvolvedor. O framework funciona como um prottipo para explorao do domnio de transformao de modelos dentro da pesquisa em torno de MEDAL (UML Generic Model Transformer Too l) (GUELFI et al., 2003), uma ferramenta de transformao de modelos em desenvolvimento dentro do contexto do projeto FIDJI (PERROUIN et al., 2002, apud GUELFI et al., 2003). Para apoiar o uso de JAFAR2, uma metodologia proposta, sendo esta bastante voltada para a automatizao em uma ferramenta CASE para desenvolvimento de projetos com JAFAR2, usando MEDAL como ferramenta de transformao de modelos.
modelagem que define em seu meta-modelo notaes padronizadas para diversos tipos de diagramas, dentre eles diagramas de classes, diagramas de casos de uso, diagramas de estado, etc., sem, no entanto, definir quando e com que propsito tais diagramas devem ser utilizados. De fato, por ser amplamente utilizada, muitas vezes a UML usada como base para as linguagens apresentadas nesta seo. Ela possui mecanismos de extenso que nos permitem definir uma nova linguagem com base em sua notao, a saber:
?
baseado em um j existente;
?
valor etiquetado (tagged values) uso de pares <etiqueta, valor> para anexar
semntica a um elemento de modelo em uma linguagem formal ou informal. So apresentadas a seguir, as seguintes linguagens de modelagem: a Linguagem de Modelagem Web, as Extenses de Aplicaes Web e a linguagem de modelagem da UWE.
entidades e relacionamentos, compatvel com notaes clssicas como diagramas de Entidades e Relacionamentos ou diagrama de classes da UML;
17
podem ser publicados no site. Cada hipertexto define uma viso do site, que descrita em dois submodelos: de composio (especifica as pginas) e de navegao (especifica o relacionamento entre as pginas);
grfica das pginas, independentemente da linguagem final que representar as pginas (HTML, WML, etc.);
usurios e grupos de usurios para armazenamento de informaes especficas dos mesmos. A Figura 2.6 mostra um modelo de hipertexto representado pelos sub-modelos de composio (elementos internos s caixas pontilhadas) e de navegao de pginas (setas de uma caixa pontilhada a outra). Os elementos grficos nos diagramas de composio representam unidades de dados (cilindro), unidades direcionais (seta) e unidade de ndices (linhas). A WebML define diversos outros tipos de unidades, tais como unidades multidados, unidades de rolagem, unidades de filtragem, etc.
Figura 2.6: Exemplo de diagrama de hipertexto (composio e navegao) em WebML (CERI et al., 2000) Informaes mais atuais sobre a WebML e uma lista de artigos e outros tipos de documentao podem ser encontradas em http://www.webml.org.
18
19
Figura 2.7: Um exemplo de mapa de navegao do modelo de UX No exemplo dessa figura, uma Tela de Login possui um texto de abertura como contedo gerenciado (esteretipo <<managed>>) por algum sistema de gerncia de contedo (Content Management System CMS). Nessa tela possvel que o usurio efetue seu login no sistema por meio da operao homnima e do Formulrio de Login, que possui dois campos de texto:
login
corretamente identificado, segue para a tela Home, que possui dois compartimentos: Menu e Tela
Inicial.
modelo opcional), e exibe a foto do cliente, que um contedo do tipo lgica de negcio, ou seja, proveniente da camada de negcio. Telas podem ter a elas associadas classes normais do domnio do problema, como o caso da associao entre Tela Inicial e CarrinhoCompras, simbolizando que os itens do carrinho podem ser exibidos nessa tela. Para cada classe estereotipada, um cone especial atribudo, sendo que algumas ferramentas CASE do apoio a esses cones especiais, como o caso da ferramenta Rational Rose (http://www.ibm.com/software/rational/) da IBM. Um roteiro, por sua vez, uma maneira de contar uma histria atravs do uso de imagens
20
estticas discretas. Um roteiro pode ser capturado por um diagrama de colaborao da UML, por se parecer mais com um roteiro tradicional (teatro, cinema, etc.), mas pode tambm ser modelado por meio de diagramas de seqncia ou de atividade. A WAE, contudo, mais voltada para apoiar a elaborao de modelos de projeto, tendo em vista que essa fase mais suscetvel tecnologia. Conforme discutido na Seo 2.1.4, a fase de projeto dividida em duas vises: a viso lgica, que est em um nvel mais alto de abstrao, definindo classes e associaes, e a viso de componentes, que trata dos arquivos que efetivamente comporo o sistema implementado (pginas e diretrios). Para a viso lgica, so definidos trs esteretipos principais aplicados sobre o elemento classe do meta-modelo da UML e diversos esteretipos de associao, como mostram as Tabelas 2.2 e 2.3, respectivamente. Tais esteretipos podem ser utilizados para a criao de diagramas de classes que representem os elementos Web que compem o sistema, chegando a um nvel de detalhes maior do que os diagramas de classe da fase de anlise (pois j incluem informaes da plataforma de desenvolvimento), mas ainda num nvel de abstrao lgico. A Figura 2.8 mostra o diagrama de classes do formulrio de login usado no exemplo anterior. Assim como no modelo UX, Conallen sugere cones especiais para cada esteretipo de classe proposto.
21
O que a classe estereotipada representa Uma pgina Web dinmica que efetua processamento no servidor e gera um resultado possivelmente diferente a cada requisio. Suas operaes representam funes do script e seus atributos representam variveis visveis no escopo da pgina. Uma pgina Web esttica que simplesmente retornada ao cliente quando requisitada, sem gerar processamento. Pode conter scripts do lado do cliente (client-side), portanto seus atributos e operaes referem-se a tais scripts. Formulrios HTML para entrada de dados. Seus atributos representam os campos do formulrio. Tais formulrios no possuem operaes. Qualquer operao que interaja c o m o formulrio deve ser propriedade da pgina que o contm.
<<client page>>
<<HTML form>>
Alm desses elementos bsicos, para o que Conallen chama de Projeto Avanado, existem esteretipos para representao de outros elementos da viso lgica da camada Web, a saber: conjunto de quadros (classe com esteretipo <<frameset>>), alvo de link (classe com esteretipo <<target>>), link de destino (associao mltipla com esteretipo <<target
link>>),
22
O que a associao estereotipada representa Um link normal entre pginas, representado em HTML pela tag <a>. Parmetros codificados como parte da URL segundo o protocolo HTTP podem ser representados como atributos da associao. Relacionamento direcional entre uma server page e uma client page que indica que a sada HTML do processamento da pgina do servidor a pgina do cliente. Relacionamento direcional entre um html form e uma server page, representando o envio dos dados dos campos do formulrio para a pgina do servidor para processamento. Ao de redirecionamento de uma pgina para outra. Ao de delegao de uma pgina para outra. Difere do redirecionamento por manter o contexto da requisio feita primeira pgina. Relacionamento de confinamento entre uma pgina e um objeto, como uma Applet ou controle ActiveX. Uma associao direcional entre uma server page e uma outra pgina que indica que o contedo desta ltima ser processado (somente no caso de uma pgina do servidor) e includo na primeira.
<<build>>
<<submit>>
<<redirect>> <<forward>>
<<object>>
<<include>>
Para a viso de componentes, so definidos trs esteretipos para o elemento de modelo componente da UML: <<static page>>, componente que representa pginas estticas, ou seja, sem processamento no lado do servidor; <<dinamic page>>, componente que representa pginas dinmicas; e <<physical root>>, pacote de componentes representando uma abstrao de uma hierarquia de arquivos que contm recursos disponveis solicitao no servidor Web.
23
Figura 2.8: Diagrama de classes de viso lgica da camada Web do sistema Por meio de diagramas de componentes, a viso de componentes busca modelar o mapeamento entre os arquivos fsicos (representados pelos componentes com os trs esteretipos citados) e as representaes lgicas apresentadas na viso lgica (representadas por classes estereotipadas, conforme discutido anteriormente). A Figura 2.9 mostra um diagrama de componentes com os arquivos que fisicamente implementam as pginas lgicas de login da Figura 2.8. A tela de login e o formulrio so ambos implementados pela pgina esttica
index.htm,
Figura 2.9: Diagrama de componentes ligando a viso lgica aos componentes fsicos 24
Alm dos esteretipos bsicos, para o projeto avanado, Conallen define tambm: biblioteca de script (componente com esteretipo <<script library>> ), raiz virtual (pacote com esteretipo <<virtual root>> ), recurso HTTP (componente com esteretipo <<HTTP
resource>>),
biblioteca de tags JSP (pacote com esteretipo <<JSP tag library>>) e tag JSP
(classe com esteretipo <<JSP tag>>), sendo esta ltima composta por um elemento que representa o corpo da tag (dependncia com esteretipo <<tag>>) e opcionalmente um elemento que rene informaes extras (dependncia com esteretipo <<tei>> - tag extra info).
qualquer de itens de ndice, ou seja, objetos que possuem um nome e que fazem ligao com alguma classe de navegao;
fazem ligao com uma classe de navegao, ndice, passeio guiado ou consulta.
Figura 2.10: Exemplo de modelo de estrutura de navegao em UWE (KOCH et al, 2000) Estes so somente alguns dos elementos definidos pelo perfil UML da UWE, que inclui vrios outros, como contexto, classe de apresentao, quadro, conjunto de quadros, janela, texto, ncora, boto, imagem, udio, vdeo, formulrio, etc. Muitos destes representam conceitos bastante conhecidos para desenvolvedores de pginas Web. A definio de todas essas extenses vem acompanhada de cones especiais que ferramentas CASE podem escolher dar apoio (KOCH et al., 2001).
26
Frameworks MVC (Controladores Frontais); Frameworks Decoradores; Frameworks de Mapeamento Objeto/Relacional; Frameworks de Injeo de Dependncia (Inverso de Controle); Frameworks para Programao Orientada a Aspectos (AOP); Frameworks para Autenticao e Autorizao.
27
Nas subsees seguintes, explicamos cada uma dessas categorias e sua influncia na arquitetura de um sistema de informao Web, citando exemplos de frameworks de cdigo-aberto ou gratuitos que podem ser utilizados, caso a linguagem Java seja a plataforma escolhida para implementao. Conclumos com uma breve anlise das arquiteturas baseadas em containers e sua relao com os frameworks j citados.
Figura 2.11: Funcionamento do padro Modelo-Viso-Controlador Elementos da viso representam informaes de modelo e as exibem ao usurio, que pode enviar, por meio deles, estmulos ao sistema, que so tratados pelo controlador. Este ltimo altera o estado dos elementos do modelo e pode, se apropriado, selecionar outros elementos de viso a 28
serem exibidos ao usurio. O modelo, por sua vez, notifica alteraes em sua estrutura viso para que esta consulte novamente os dados e se atualize automaticamente. Essa arquitetura veio ao encontro das necessidades dos aplicativos Web. No entanto, se formos primar pelo purismo, veremos que a arquitetura MVC no se encaixa perfeitamente nessa plataforma, visto que a camada de modelo, situada no servidor Web, no pode notificar a camada de viso sobre alteraes, j que esta encontra-se no navegador do lado do cliente e a comunicao sempre iniciada no sentido cliente servidor. Portanto, apesar de MVC ser um nome muito difundido, o nome correto para esse padro arquitetnico, quando aplicado Web, seria Controlador Frontal (Front Controller) (ALUR et al., 2003, p. 166). Neste trabalho, usaremos ambos os nomes indistintamente. O padro Controlador Frontal funciona como mostra a Figura 2.12.
Figura 2.12: Funcionamento do padro arquitetnico Controlador Frontal O navegador do lado do cliente efetua uma requisio HTTP ao servidor Web, que pode ser tanto um pedido de leitura de uma determinada pgina quanto o envio de dados para processamento. O servidor Web, ento, delega essa requisio para o controlador frontal, que passa a gerenciar todo o processo. Com base em uma configurao pr-determinada, o controlador cria uma instncia de uma classe de ao especfica e pede a esse objeto que execute seu servio, similar ao que acontece com padro de projeto Comando (Command) (GAMMA et 29
al., 1994). Esse objeto deve retornar uma chave representando um dos resultados possveis da execuo e o controlador, novamente se referindo sua configurao, escolhe um tipo de resultado, que pode ser a renderizao de uma pgina, redirecionamento a outra pgina, montagem e exibio de um relatrio, dentre vrias possibilidades. Frameworks MVC implementam exatamente essa arquitetura, fornecendo o controlador, uma superclasse base ou interface para as aes, tipos de resultado e uma sintaxe bem definida para o arquivo de configurao (geralmente escrito em XML), deixando para o desenvolvedor a tarefa de configurar o framework, escrever as classes de ao e as pginas Web. Via de regra, o framework tambm fornece uma srie de facilidades, como converso automtica de tipos, validao de dados de entrada, internacionalizao de pginas Web, etc. Note que o padro Controlador Frontal aplicado apenas camada Web da aplicao, que possivelmente pode ter sido dividida em outras camadas arquitetnicas. Se tomarmos a arquitetura definida por Coad & Yourdon (COAD et al., 1993), dentre as quatro camadas por eles definidas, Domnio do Problema (CDP), Gerncia de Tarefas (CGT), Gerncia de Dados (CGD) e Interao Humana (CIH), a camada Web (e, portanto, toda a arquitetura MVC apresentada) encontra-se inserida na CIH. Desta maneira, responsabilidade das classes de ao, e no mais das pginas Web, comunicarem-se com as classes da CGT para execuo das tarefas (casos de uso), manipulando os objetos da CDP para exibio nas pginas Web. Tal organizao de cdigo evita que a lgica de negcio seja espalhada em scripts embutidos em pginas Web, aumentando a modularidade, coeso e manutenibilidade do cdigo. Somente para a plataforma Java, podemos encontrar mais de 50 frameworks MVC de cdigo aberto implementados. Os mais notveis so:
WebWork (http://www.opensymphony.com/webwork); Struts (http://struts.apache.org); Spring MVC (http://www.springframework.org); VRaptor2 (projeto brasileiro http://vraptor2.sourceforge.net); Wicket (http://wicket.sourceforge.net).
uma aplicao Web com o mesmo visual, ou seja, cabealho, rodap, barra de navegao, esquema de cores e demais elementos grficos de leiaute integrados num mesmo projeto de apresentao, elaborado pela equipe de Web Design. Esse tipo de framework funciona como o padro de projeto Decorador (Decorator) (GAMMA et al., 1994), se posicionando como um filtro entre uma requisio do cliente e um servidor Web, como mostra a Figura 2.13.
Figura 2.13: Funcionamento de um Framework Decorador Tal soluo superior a outras comumente encontradas, como o uso de incluso de pginas ou replicao do cdigo HTML responsvel pelo desenho do site em todas as pginas, pois alm de diminuir custos de manuteno no caso da troca do leiaute, permite a seleo dinmica do decorador, de forma a facilitar a implementao de verses alternativas das pginas, como, por exemplo, uma verso para impresso. Dentre os Frameworks Decoradores livres para a plataforma Java, destacamos:
31
para armazenamento de dados. Por contarem com uma base terica bastante formal (lgebra relacional) e uma indstria forte por trs, no h indicaes de que esse cenrio v mudar to cedo. Por conseguinte, mesmo aplicaes desenvolvidas no paradigma orientado a objetos (OO) tm utilizado bancos de dados relacionais para persistncia de seus objetos. Tal combinao produz o que Christian Bauer e Gavin King chamam de incompatibilidade de paradigmas (paradigm mismatch), visto que operaes de SQL [linguagem estruturada de consultas para SGBDRs] como projeo sempre unem resultados em uma representao em tabelas de dados resultantes. Isso bem diferente do grafo de objetos interconectados usados para executar uma lgica de negcio em um aplicativo Java! (BAUER et al., 2005). Tal incompatibilidade se manifesta no uso de conceitos OO, como herana, identidade, associao e navegao pelo grafo de objetos. Dentre as diversas opes para tratar esse problema, surgiu na dcada de 1980 a idia do Mapeamento Objeto/Relacional (Object/Relational Mapping ORM), que vem ganhando muita aceitao desde o final da dcada de 1990. ORM a persistncia automtica (e transparente) de objetos de um aplicativo OO para tabelas de um banco de dados relacional, utilizando meta-dados que descrevem o mapeamento entre o mundo dos objetos e o mundo relacional (BAUER, et al., 2005). Em outras palavras, ao invs de obter os dados dos objetos e mescl-los a uma string de consulta SQL que ser enviada ao SGBDR, o desenvolvedor deve informar ao framework de Mapeamento Objeto/Relacional como transformar objetos e seus atributos em tabelas e colunas e chamar mtodos simples, como salvar(), excluir() e recuperarPorId(), disponveis no framework. Em geral, esses frameworks disponibilizam tambm uma linguagem de consulta similar SQL, porm orientada a objetos, para que consultas possam ser realizadas com igual facilidade. A idia j vem sendo adotada na plataforma Java h alguns anos e hoje em dia existem diversos frameworks maduros para ORM, cada vez mais se firmando como boas opes para todos os tipos e tamanhos de aplicativos. Dentre eles, destacamos:
Hibernate (http://www.hibernate.org); Java Data Objects JDO (http://java.sun.com/products/jdo); Apache ObjectRelationalBridge OJB (http://db.apache.org/ojb/); Oracle Toplink (http://www.oracle.com/technology/products/ias/toplink). 32
Naturalmente, Frameworks ORM no so exclusividade de sistemas de informao Web, podendo ser utilizados em diversas plataformas diferentes.
33
(Inversion of Control IoC). O objetivo deles permitir que o desenvolvedor especifique por meio de meta-dados todas as dependncias entre classes que existem em seu sistema e, ao obter instncias dessas classes por meio do framework, todas as suas dependncias j tenham sido satisfeitas ou, em outras palavras, injetadas. O termo IoC tambm utilizado pelo fato do controle de criao de objetos ter sido invertido, saindo da classe que depende diretamente do objeto a ser criado para um elemento externo, no caso, o framework. Destacam-se no universo de frameworks de Injeo de Dependncia livres em Java os seguintes:
Spring Framework (http://www.springframework.org); PicoContainer (http://www.picocontainer.org); Apache Excalibur (http://excalibur.apache.org); Apache HiveMind (http://jakarta.apache.org/hivemind).
Assim como os Frameworks ORM, Frameworks IoC tambm podem ser utilizados em diversos tipos de plataforma, apesar de integrarem-se mais suavemente a aplicativos que executam dentro de containers, como o caso dos WISs.
relatrios (logs). Com a programao orientada a objetos, tais tarefas demandariam que trechos de cdigo relacionados a essas tarefas de infra-estrutura fossem repetidos (ou em terminologia AOP: espalhados) pelos vrios mdulos da aplicao, algo que pode ser feito automaticamente por uma ferramenta orientada a aspectos. A Figura 2.14 ilustra essa situao.
35
No quadro superior, vemos um cdigo orientado a objetos no qual as classes de aplicao necessitam realizar tarefas relacionadas ao acesso ao banco de dados: iniciar a transao antes de realizar suas operaes e confirm-la (commit) ou cancel-la (rollback) ao final. Com o uso da AOP, essas tarefas idnticas, que se encontram espalhadas pelo cdigo, denominadas aspectos, so retiradas dos vrios mdulos do sistema e implementadas uma s vez, num s lugar, como demonstra o quadro intermedirio. Por fim, o quadro inferior explica o papel do framework AOP: interceptar a requisio aos mtodos que necessitam do aspecto relacionado ao banco de dados e garantir que o cdigo seja executado antes e depois do mtodo, resultando na mesma execuo que havamos anteriormente, porm com o cdigo mais bem estruturado, sem repeties. Esse espalhamento automtico dos aspectos chamado de entrelaamento ou costura (weaving) e pode ser feito em tempo de execuo por um framework, como descrevemos, ou em tempo de compilao, por um compilador AOP. Neste segundo caso, o cdigo compilado o resultado da unio do cdigo-fonte original e o cdigo dos aspectos. Em ambos os casos, o desenvolvedor precisa informar ferramenta em quais pontos do cdigo chamados de pontos de corte (pointcuts) determinados aspectos devem ser entrelaados. A popularidade de ferramentas relacionadas AOP cresce a cada dia, e dentre as ferramentas de cdigo aberto que podem ser utilizadas na plataforma Java, destacamos:
Spring Framework (http://www.springframework.org); AspectJ (http://www.eclipse.org/aspectj); AspectWerkz (http://aspectwerkz.codehaus.org); JBoss AOP (http://labs.jboss.com/portal/jbossaop).
dados, arquivos, servidores de diretrio, etc.) e autorizao (geralmente via meta-dados e mapeamento de URLs). Os frameworks de Autenticao e Autorizao de cdigo aberto e para a plataforma Java mais conhecidos so:
Acegi Security for Spring (http://www.acegisecurity.org); Apache Cocoon Authentication (http://cocoon.apache.org); Java Authentication and Authorization Services JAAS, utilizado pelos servidores
37
como um dos maiores desafios da rea: a cooperao entre grupos heterogneos no desenvolvimento de aplicaes. Scott (2003) explora diversas prticas de gerncia e planejamento estratgico, mostrando sua aplicabilidade para a rea de desenvolvimento de sistemas Web. Por fim, Chang et al. (2004) apresentam um framework para o desenvolvimento de aplicaes Web adaptveis e independentes de plataforma. Os autores justificam que, devido grande quantidade de sistemas operacionais e navegadores Web (browsers) com caractersticas diferentes, se faz necessria uma maneira de construir um sistema independente de ambiente de execuo, que pode ser convertido automaticamente por um tradutor para diversos ambientes diferentes. Alm desses trabalhos, tambm no nos aprofundamos em mtodos hipermdia por consider-los uma categoria de propostas fora do escopo deste trabalho. Mtodos hipermdia focam mais nas pginas Web e sua navegao ao invs de funcionalidades, sendo mais adequados para aplicaes Web com foco em contedo. O mtodo OOHDM, descrito na seo 2.1.7, por ser o mais citado representante dessa categoria de mtodos, foi o nico includo nesta reviso bibliogrfica.
que no se enquadrem em contextos especficos, como as que acabamos de citar, para justificar a necessidade de um novo mtodo para o projeto de sistemas de informao Web. Nossa proposta, no entanto, se estende tambm rea da Web Semntica, sugerindo uma abordagem para construo de WISs preparados para o que por muitos considerado o futuro da Internet. Para fundamentarmos nossa discusso sobre este assunto, apresentamos uma reviso dos conceitos e trabalhos desta rea no captulo seguinte.
40