Captulo 2: Engenharia Web

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.

2.1. Metodologias para Engenharia Web

Nesta seo so apresentadas algumas metodologias propostas para a Engenharia Web. Foram consideradas metodologias as propostas que definem um processo, obrigatrio ou sugerido, listando atividades a serem executadas e artefatos a serem produzidos e apresentando ou indicando a notao a ser utilizada na construo de tais artefatos. 3

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.

2.1.1. Metodologia de Prototipao Rpida Dirigida a Modelos em Escala Real

A Metodologia de Prototipao Rpida Dirigida a Modelos em Escala Real (MockupDriven Fast-Prototyping Methodology MODFM) (ZHANG et al., 2003a) (ZHANG et al., 2003b) uma metodologia baseada em prototipao que tem como objetivo ajudar no levantamento e elaborao dos requisitos, alm de facilitar o ajuste a mudanas de requisitos, agilizando, assim, o desenvolvimento de aplicaes Web. Seus componentes essenciais so uma arquitetura de duas camadas (front-end e back-end) organizadas segundo um padro Modelo Viso - Controlador (MVC) (GAMMA et al., 1994) e geradores automticos de cdigo. MODFM incorpora tecnologias apropriadas para a Web, tais como J2EE (SHANNON, 2003) e XML (HAROLD et al, 2004). A metodologia baseia-se na crena de que qualquer mdulo a ser desenvolvido para uma aplicao Web pode ser implementado pela composio de elementos de sete categorias de artefatos de cdigo: pginas JSP (JavaServer Pages), beans de formulrios (form beans), praes, ps-aes, mtodos de servio, componentes EJB (Enterprise JavaBeans) e esquemas de banco de dados. Tal estruturao meticulosa permite a aplicao de geradores automticos de cdigo. MODFM conta com um gerador de cdigos (WGenerator) e um gerador de menus para ligao entre as pginas. Ambos esto integrados num ambiente de suporte, chamado WGWeb. O processo dividido em oito etapas, mostradas na Figura 2.1.

Figura 2.1: Processo de Anlise e Projeto do MODFM (ZHANG et al., 2003b) .

2.1.2. A metodologia de Lee & Shirani

Seung Lee e Ashraf Shirani (LEE et al., 2004) propem uma metodologia baseada em componentes para o desenvolvimento de aplicaes Web. Os autores defendem a idia de que a natureza das aplicaes Web facilita a componentizao e propem mtodos para anlise de requisitos e projeto de sistema utilizando tanto tcnicas estruturadas quanto orientadas a objetos. Nessa metodologia, as pginas Web so os blocos de construo fundamentais da aplicao. Elas podem ser visveis ou invisveis para o usurio e so divididas em diversos tipos de pgina. Alm disso, podem ou no envolver a execuo de lgica de negcio do lado do servidor (serverside). Elas so conectadas entre si por hiperlinks ou outros tipos de associao. Pginas relacionadas podem ser agrupadas em compndios, que so pequenos, porm completos, conjuntos de itens relacionados a um assunto particular (ex.: o processamento de um pedido 5

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.

2.1.3. Mtodo de Desenvolvimento Ariadne

O Mtodo de Desenvolvimento Ariadne (Ariadne Development Method ADM) (DAZ et al., 2004) prope um processo sistemtico, flexvel, integrador e independente de plataforma para especificao e avaliao de sistemas hipermdia e aplicaes Web. ADM considera seis vises de projeto distintas: estrutura, navegao, apresentao, comportamento, processo e segurana. Seu processo composto de trs fases: projeto conceitual, focado na identificao de tipos abstratos de componentes, relacionamentos e funes; projeto detalhado, referente especificao de funcionalidades, processos e comportamentos do sistema em detalhe suficiente para que o mesmo seja gerado automaticamente em seguida; e avaliao, que se preocupa com o uso de prottipos e especificaes para avaliar a usabilidade do sistema em relao a uma srie de critrios bem definidos. Cada uma dessas fases dividida em atividades, gerando artefatos. A Tabela 2.1 resume as atividades e artefatos produzidos. Tabela 2.1: Fases, atividades e produtos de ADM Fase Atividade Estudo das funes do sistema Especificao das entidades Produto Diagrama Estrutural Diagrama Navegacional Especificaes Funcionais Diagramas Internos Catlogo de Atributos Catlogo de Eventos Diagrama de Usurios Catlogo de Categorias Tabela de Acesso Diagrama de Instncias de Ns Diagrama de Instncias de Usurios Especificao de Estruturas de Acesso Especificao Detalhada de Funes Diagramas Internos Detalhados

Projeto Conceitual Definio da estrutura lgica

Modelagem de usurios Definio da poltica de segurana

Projeto Detalhado Identificao das instncias Especificao de funes Especificao de instncias

Fase

Atividade

Produto Regras de Autorizao Delegao de Usurios

Definio de requisitos de apresentao Avaliao Desenvolvimento de um prottipo Avaliao

Especificao de Apresentao Prottipo Documento de Avaliao Relatrio de Concluso

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.

2.1.4. A metodologia proposta por Conallen

Jim Conallen, em seu livro Desenvolvendo Aplicaes Web com UML (CONALLEN, 2002), descreve um processo de desenvolvimento de software iterativo, incremental e centrado em casos de uso, baseado no Processo Unificado Rational (Rational Unified Process RUP) (KRUTCHEN, 2000) e no Processo Unificado ICONIX (ICONIX Unified Process ICONIXUP) (ROSENBERG et al., 1999, apud CONALLEN, 2002). Apesar de enfatizar que no h uma receita pronta para um bom processo de software, Conallen indica um processo que poderia ser aplicado no desenvolvimento de WebApps, definindo seu fluxo de trabalho, atividades, artefatos e operadores. As atividades do processo so mostradas na Figura 2.4. O processo comea com uma anlise do negcio, que acontece em paralelo com o desenvolvimento de um modelo do domnio. Em seguida, feita uma anlise mais profunda do problema e construdo o documento de viso, o qual expressa o escopo e a finalidade de todo o projeto e a partir do qual todos os outros artefatos so derivados. Ento, o plano de projeto elaborado, esboando as atividades do processo e definindo os eventos principais e documentos padro, incluindo o plano de gerncia de configurao. A atividade Reiterar representa um subprocesso iterativo de construo de software, expandido na Figura 2.5. Aps terminada a execuo desse sub-processo, o software implantado e inicia-se a atividade de manuteno (atualizar sistema). A atividade Gerenciar verses de artefatos ocorre em paralelo ao processo e

corresponde gerncia de alteraes e ao uso de um sistema de controle de verso.

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.

2.1.5. Soluo Web Orientada a Objetos

A Soluo Web Orientada a Objetos (Object Oriented Web Solution OOWS) uma extenso da metodologia OO-Method (PASTOR et al., 2001, apud FONS et al., 2003) que tem por objetivo permitir a especificao de uma aplicao Web em um framework integrado, capturando os requisitos em modelos conceituais e gerando prottipos operacionais a partir das

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

2.1.6. Engenharia Web Baseada em UML

A metodologia Engenharia Web Baseada em UML (UML-based Web Engineering UWE) (KOCH et al., 2001) (KOCH et al., 2002) define um conjunto de modelos a serem construdos no desenvolvimento de uma aplicao Web, uma linguagem de modelagem para a elaborao desses artefatos (discutida na Seo 2.2.3) e um processo para construo dos modelos. Segundo o processo proposto, as atividades principais de modelagem so: anlise de requisitos, projeto conceitual, projeto de navegao, projeto de apresentao, modelagem de tarefas e modelagem de implantao. A abordagem UWE apia o desenvolvimento de aplicaes Web com foco especial na sistematizao, personalizao e gerao automtica de cdigo. Ela indica a utilizao de casos de uso para a especificao de requisitos e, baseado nos casos de uso especificados, o projeto conceitual produz um modelo conceitual do problema, definido em termos de classes e associaes entre classes relevantes do domnio.O projeto de navegao utiliza o modelo conceitual como base e definido em duas etapas: definio do modelo de espao de navegao e construo do modelo de estrutura de navegao. O primeiro modelo mostra quais objetos podem ser vistos atravs da navegao pela aplicao Web e , portanto, um modelo de anlise. O segundo modelo baseado no primeiro e define como os objetos so visitados,sendo construdo na fase de projeto. O projeto de apresentao consiste na modelagem de interfaces com o usurio abstratas, mostrando como a estrutura de navegao definida anteriormente apresentada ao usurio. Ele dividido em uma parte esttica e outra dinmica. A parte esttica representada por uma forma particular de diagrama de classes que usa uma notao de composio de classes. Elementos de apresentao so representados por classes estereotipadas e suas partes internas so representadas graficamente dentro do elemento de modelo classe, podendo ter vrios nveis de aninhamento de elementos grficos. Ferramentas CASE comuns no conseguem representar esse tipo de notao, porm, segundo os autores, ela a mais apropriada para a modelagem de interfaces grficas, por permitir a representao espacial do elemento de interface com o usurio. As classes que representam tais elementos podem ser ligadas num diagrama de seqncia ou de comunicao da UML formando roteiros (storyboards) que compem a parte dinmica do projeto de apresentao. Para refinar os casos de uso, diagramas de atividade podem ser 13

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.

2.1.7. Mtodo de Projeto Hipermdia Orientado a Objetos

Segundo DAZ et. al (2004), o paradigma hipermdia se baseia na idia de organizar as informaes como uma rede de ns inter-relacionados que podem ser navegados livremente pelos usurios via links ou outras estruturas avanadas de navegao, como ndices e mapas. OOHDM (Object Oriented Hypermedia Design Method) (SCHWABE et al., 1998) nasceu da necessidade de abstraes capazes de facilitar a especificao de aplicaes hipermdia. Metodologias tradicionais de engenharia de software no proviam a noo de links e pouco era dito sobre como incorporar texto interface. Tambm faltavam primitivas para especificar navegao, que uma das chaves para o sucesso de uma aplicao Hipermdia . O processo de construo de uma aplicao hipermdia com OOHDM se d em quatro etapas: Projeto Conceitual, Projeto de Navegao, Projeto de Interfaces Abstratas e

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).

2.1.8. Outras metodologias

Resumimos a seguir outras metodologias encontradas durante a reviso bibliogrfica e que consideramos menos relevantes nossa pesquisa. A Metodologia Baseada em Processos de Negcio (Business Process-Based Methodology BPBM) (ARCH-INT et al., 2003) uma metodologia para desenvolvimento de sistemas de informao na Web a partir de componentes. A BPBM combina as vantagens dos paradigmas estruturado e orientado a objetos para identificao e modelagem de componentes de negcio e atividades de negcio. BPBM d ivide-se em modelagem de componentes de negcio e modelagem de implementao Web. A primeira parte decompe o sistema em um conjunto de processos de negcio que, por sua vez, so tambm decompostos em atividades de negcio. Usando modelos de Entidades e Relacionamentos (ER) estendidos, representam tais objetos de negcio, que,

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.

2.2. Linguagens de modelagem para a Web

Descrevemos nesta seo algumas linguagens de modelagem propostas para a Engenharia Web. Linguagens de modelagem definem notaes a serem usadas na criao de modelos abstratos da soluo de problemas a serem resolvidos. A Linguagem de Modelagem Unificada (Unified Modeling Language UML) (BOOCH et al., 2006), por exemplo, uma linguagem de 16

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:
?

esteretipo ( stereotype) definio de um novo tipo de elemento de modelo

baseado em um j existente;
?

valor etiquetado (tagged values) uso de pares <etiqueta, valor> para anexar

informaes textuais arbitrrias a elementos de modelo; e

?

restrio (constraint) condio ou restrio que permite a especificao de nova

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.

2.2.1. Linguagem de Modelagem Web

A Linguagem de Modelagem Web (Web Modeling Language WebML) (CERI et al., 2000) (CERI et al., 2002) (CERI et al., 2002b) uma linguagem de modelagem para aplicaes Web que permite que projetistas modelem as funcionalidades de um site em um alto nvel de abstrao, sem se comprometerem com detalhes de alguma arquitetura especfica. WebML uma linguagem baseada em XML, mas remete a representaes grficas intuitivas e pode ser facilmente suportada por uma ferramenta CASE, alm de poder ser usada para comunicao com pessoal no-tcnico (clientes, etc.). Sua sintaxe XML a torna apta a servir de entrada para geradores automticos, produzindo a implementao do website

automaticamente. A especificao de um site em WebML consiste de quatro perspectivas ortogonais:

Modelo Estrutural (Structural Model): expressa os dados do site, ou seja, suas

entidades e relacionamentos, compatvel com notaes clssicas como diagramas de Entidades e Relacionamentos ou diagrama de classes da UML;

Modelo de Hipertexto (Hypertext Model): descreve os documentos hipertexto que

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);

Modelo de Apresentao (Presentation Model): descreve o leiaute e a aparncia

grfica das pginas, independentemente da linguagem final que representar as pginas (HTML, WML, etc.);

Modelo de Personalizao (Personalization Model): modela explicitamente os

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

2.2.2. As Extenses de Aplicaes Web

As Extenses de Aplicaes Web (Web Application Extensions WAE) (CONALLEN, 2002) so extenses ao meta-modelo da UML para a modelagem de caractersticas especficas de aplicaes Web. A WAE define extenses apropriadas para modelar diversos componentes tpicos do desenvolvimento de aplicaes Web, usando elementos do meta-modelo da UML adicionados de esteretipos pr-definidos para simbolizar os conceitos necessrios. Alm dos esteretipos, a WAE prev a definio de valores etiquetados (tag values), representados entre colchetes, e restries (constraints), representadas entre chaves, para alguns elementos. Em relao s extenses propostas para apoiar a elaborao de modelos de anlise, merece destaque a notao para o modelo de experincia do usurio (User Experience UX), discutido na Seo 2.1.4. O modelo UX se prope a definir a aparncia de uma aplicao Web, seus caminhos de navegao e a estrutura das pginas, sendo composto de dois artefatos principais: mapas de navegao e roteiros. Mapas de navegao mostram as telas que compem o sistema. Uma tela algo que apresentado ao usurio, contendo uma infra-estrutura padro de interface Web (texto, links, formulrios, etc.) e possuindo nome, descrio, contedo (esttico, de lgica de negcio ou gerenciado), campos de entrada e possveis aes a serem executadas. Telas so modeladas como classes estereotipadas. Uma tela comum recebe o esteretipo <<screen>>, um compartimento de tela (ex.: um frame HTML) modelado como <<screen compartment>> e um formulrio recebe a denominao <<input form>>, como ilustra o exemplo da Figura 2.7.

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

e senha. A navegao modelada por associaes. Por exemplo, se o cliente for

corretamente identificado, segue para a tela Home, que possui dois compartimentos: Menu e Tela
Inicial.

Esta ltima possui um texto de boas-vindas, esttico (a incluso de contedo esttico no

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

Tabela 2.2: Esteretipos de classe utilizados na viso lgica do projeto Esteretipo

<<server page>>

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>>),

bibliotecas de script (classe com esteretipo <<script library>>) e objeto de script

(classe com esteretipo <<script object>>).

22

Tabela 2.3: Esteretipos de associao utilizados na viso lgica do projeto Esteretipo

<<link>>

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,

enquanto toda a parte dinmica, desde o processamento do login at a gerao das

pginas do cliente Home ou ErroLogin feita pela pgina dinmica processaLogin.php.

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).

2.2.3. A linguagem de modelagem da UWE

A linguagem de modelagem associada metodologia Engenharia Web Baseada em UML (UML-based Web Engineering UWE) (KOCH et al., 2000) (KOCH et al., 2002) utiliza como base a UML e seus mecanismos de extenso (esteretipos, valores etiquetados e restries), produzindo um perfil UML (UML Profile) especfico para a metodologia. Segundo seus autores, a notao leve, no sentido de ser facilmente apoiada por ferramentas e no causar impacto nos formatos de troca de dados. Esse perfil UML utilizado na construo de modelos de anlise e projeto dentro da metodologia UWE para o desenvolvimento de WebApps, descrita na Seo 2.1.6. A Figura 2.10 mostra um modelo de estrutura de navegao de uma biblioteca virtual, exibindo os seguintes elementos do perfil UML da UWE:

Classe de navegao (esteretipo <<navigational class>>): representa um conceito

do domnio do problema, cujas instncias so visveis aos usurios durante a navegao;

Navegao direta (associao com indicao de navegabilidade): indica a

possibilidade de navegao de um elemento de navegao a outro;

ndice (esteretipo <<index>>): um objeto composto que contm um nmero

qualquer de itens de ndice, ou seja, objetos que possuem um nome e que fazem ligao com alguma classe de navegao;

Passeio guiado (esteretipo <<guidedTour>>): consiste em um objeto que prov

acesso seqencial s instncias de uma classe de navegao;

Consulta (esteretipo <<query>>): possui uma frase de consulta como atributo e

utilizado para selecionar instncias de classes de navegao mediante um determinado 25

filtro embutido na consulta;

Menu (esteretipo <<menu>>): representa um nmero fixo de itens de menu que

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

2.3. Frameworks para desenvolvimento Web

Na rea de pesquisa de Engenharia Web, existem diversas propostas de metodologias, linguagens e ferramentas que alcanam vrias atividades do processo de desenvolvimento de um WIS. No entanto, se separssemos as propostas por atividade, provavelmente veramos que a atividade de implementao possui o maior nmero de propostas, reunindo um amplo conjunto de ferramentas que visam a facilitar a atividade de codificao de um WIS. Os WISs possuem uma infra-estrutura arquitetnica muito similar. Conseqentemente, pouco tempo depois que os primeiros sistemas comearam a ser construdos, foram desenvolvidos vrios frameworks que generalizavam essa infra-estrutura e poderiam ser utilizados para seu desenvolvimento . Neste contexto, um framework visto como um artefato de cdigo que prov componentes prontos que podem ser reutilizados mediante configurao, composio ou herana. Quando combinados, esses frameworks permitem que sistemas Web de grande porte sejam construdos com arquiteturas de mltiplas camadas sem muito esforo de codificao. A unio de diversas solues de infra-estrutura (frameworks) d origem ao que denominamos arquiteturas baseadas em containers. Um container um sistema que gerencia objetos que possuem um ciclo de vida bem definido. Um container para aplicaes distribudas, como os containers da plataforma Java Enterprise Edition (SHANNON, 2003), gerenciam objetos e lhes prestam servios, como persistncia, gerncia de transaes, distribuio, servios de diretrios, dentre outros. A partir de nossa experincia no desenvolvimento de WISs utilizando a plataforma Java, nos deparamos com diversos desses frameworks e pudemos organiz-los em seis categorias diferentes, a saber:

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.

2.3.1. Frameworks MVC (Controladores Frontais)

MVC a abreviatura de Modelo-Viso-Controlador (Model-View-Controller) (GAMMA et al., 1994), uma arquitetura de software desenvolvida pelo Centro de Pesquisas da Xerox de Palo Alto (Xerox PARC) para a linguagem Smalltalk em 1979 (REENSKAUG, 1979). Desde ento, a arquitetura se desenvolveu e ganhou aceitao em diversas reas da Engenharia de Software e hoje , talvez, a arquitetura mais utilizada para construo de aplicaes Web. O esquema da Figura 2.11 mostra como funciona esse padro arquitetural.

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).

2.3.2. Frameworks Decoradores

Frameworks Decoradores surgiram para automatizar a trabalhosa tarefa de manter toda 30

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:

SiteMesh (http://www.opensymphony.com/sitemesh); Tiles (http://struts.apache.org/struts-tiles).

2.3.3. Frameworks de Mapeamento Objeto/Relacional

Sistemas de Bancos de Dados Relacionais (SGBDR) tm sido h dcadas o padro de fato

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.

2.3.4. Frameworks de Injeo de Dependncia (Inverso de Controle)

O paradigma orientado a objetos trouxe conceitos como modularidade e coeso como guias para o desenvolvimento de aplicaes bem estruturadas. Existem inmeras formas de dividir uma arquitetura em camadas, mas que, de forma geral, se assemelham arquitetura de Coad e Yourdon (COAD et al., 1993), j citada anteriormente. Classes relacionadas ao domnio do problema (representando conceitos do mundo real), gerncia de tarefas (implementando casos de uso), gerncia de dados (responsveis pela persistncia dos objetos) e interao humana (interface com o usurio) ficam em camadas diferentes. No entanto, elas precisam estar integradas, pois aes do usurio na CIH devem acionar casos de uso implementados na CGT, que manipulam objetos da CDP que, por sua vez, possivelmente, so armazenados de forma persistente pela CGD. Segundo (FOWLER, 2006), quando criamos classes cujas instncias dependem de objetos de outras classes para a realizao de um determinado servio, interessante que estejam relacionadas apenas s interfaces dos objetos das quais dependem, e no a uma implementao especfica daquele servio. Esse aspecto tambm tratado por GAMMA et al. (1994) com seus padres de projeto de criao, como Mtodo Fbrica (Factory Method), Fbrica Abstrata (Abstract Factory) e Construtor (Builder). Por exemplo, se uma classe de gerncia de tarefas, que implementa um determinado caso de uso, necessita de uma classe de gerncia de dados para que esta realize a persistncia de um determinado objeto, a classe da CGT no precisa saber como a classe da CGD realizar a persistncia, que pode ser comunicando-se diretamente com um SGBDR, utilizando um framework ORM, convertendo dados em arquivos XML, etc. Ela precisa saber somente que, ao chamar um mtodo cuja assinatura salvar(objeto), o objeto passado como parmetro ser gravado em mdia persistente. Em outras palavras, precisa conhecer a interface do objeto da CGD. Seguindo essa abordagem, surgiram vrios frameworks de Injeo de Dependncia (Dependency Injection DI), tambm conhecidos como frameworks de Inverso de Controle

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.

2.3.5. Frameworks para Programao Orientada a Aspectos (AOP)

A Orientao a Aspectos considerada por muitos uma evoluo da Orientao a Objetos que complementa esta ltima de modo a simplificar o desenvolvimento de sistemas, permitindo que softwares cada vez mais complexos possam ser criados e mantidos com menor esforo. Assim como seu predecessor, esse novo paradigma abrange todo o processo de software, porm sua maior influncia tem sido na fase de codificao, em torno da qual surge a Programao Orientada a Aspectos (Aspect Oriented Programming AOP). O paradigma da Orientao a Aspectos est centrado na idia da separao de preocupaes (separation of concerns). Segundo Resende et al. (2005), separao de preocupaes pode ser definida como a teoria que investiga como separar as diversas preocupaes pertinentes a um sistema, propiciando que cada uma das preocupaes seja tratada separadamente, a fim de reduzir a complexidade do desenvolvimento, evoluo e integrao do software. Em termos prticos, podemos citar como exemplos os sistemas que tm como preocupaes serem distribudos, acessarem bancos de dados ou registrarem suas aes em 34

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).

2.3.6. Frameworks para Autenticao e Autorizao

Uma outra caracterstica que bastante comum em sistemas de informao Web a presena de mecanismos de segurana para autenticao e autorizao. Autenticar consiste em verificar se uma chave de acesso (geralmente um par login / senha) vlida para o acesso a uma aplicao. Autorizar, por sua vez, consiste em verificar qual o nvel de acesso do usurio autenticado, permitindo que ele use somente as funcionalidades autorizadas para o seu nvel. Como de se esperar, existem frameworks que realizam essas duas tarefas mediante configurao em meta-dados. Tais ferramentas apiam diversos tipos de autenticao (bancos de 36

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

de aplicao Java EE (http://java.sun.com/products/jaas).

2.3.7. Arquiteturas baseadas em containers

Antes da popularizao de frameworks como Hibernate, Spring e Struts, o desenvolvimento de aplicaes com necessidades de distribuio, escalabilidade e robustez era guiado por padres como a plataforma Java Enterprise Edition (Java EE) (SHANNON, 2003). Tais padres definem servios que devem ser prestados por containers, que funcionam como servidores gerenciando objetos projetados pelo desenvolvedor e provendo servios d iversos, como gerncia de persistncia, gerncia de transaes, servio de diretrio, acesso a sistemas legados, dentre outros. O surgimento de uma grande quantidade de frameworks que realizam um servio j provido por containers, porm de forma independente, se deu em grande parte por deficincias nas especificaes que, dentre outros problemas, tornava burocrtica a tarefa de construo de um componente, impunha uma srie de restries para os mesmos e os tornava muito dependente dos containers, impedindo que fossem reutilizados em outros contextos (JOHNSON et al., 2004). Com a adoo dos frameworks por grande parte dos desenvolvedores, novos padres para arquiteturas baseadas em containers foram adequando-se s preferncias dos usurios. A verso 5.0 da plataforma Java EE (SHANNON, 2006), lanada recentemente, tem como arquitetura Web um padro semalhante arquitetura MVC (JavaServer Faces), define seu modelo de persistncia de componentes (Enterprise JavaBeans) com base no framework ORM Hibernate e faz uso da tcnica de Injeo de Dependncias para satisfazer dependncias entre componentes gerenciados pelo container. Grande parte das aplicaes Web de mdio a grande porte utilizam frameworks ou

37

containers cujos servios so baseados em idias similares a dos frameworks.

2.4. Outros trabalhos relacionados

Durante a pesquisa realizada, foram encontrados alguns trabalhos relacionados com o desenvolvimento de aplicaes Web que, contudo, no se enquadravam propriamente como metodologias, frameworks ou linguagens de modelagem. Tais trabalhos so citados brevemente na seqncia. Em (SCHARL, 2001), o autor examina o papel da modelagem conceitual de sistemas Web como o meio principal e padronizado de comunicao visual entre organizaes e departamentos de uma mesma organizao. Ele apresenta a Tcnica de Projeto Estendida da Web (extended World Wide Web Design Technique eW3DT) como uma linguagem consistente e semanticamente rica para troca de conhecimento sobre projetos em andamento ou j implantados. Em (TAM et al., 2000), um framework de linguagem de script para o desenvolvimento rpido e sistemtico de aplicaes Web proposto. O trabalho incluiu o desenvolvimento de um prottipo de um analisador de scripts e um ambiente integrado de desenvolvimento (Integrated Development Environment IDE) para desenvolvimento rpido de aplicaes Web. Uden (2002) prope um modelo de projeto para desenvolvimento de WebApps baseado em projeto de interface com o usurio orientado a objetos e cincias cognitivas. A tcnica de Anlise de Tarefas Cognitiva Aplicada (Applied Cognitive Task Analysis ACTA) aplicada no levantamento de requisitos e produz resultados que so usados no projeto de interface grfica. Richardson (2000) discute o uso de mtricas simples para pequenos sistemas desenvolvidos para a Web, focando em como uma anlise dessas informaes pode auxiliar na reconstruo do projeto da aplicao de forma mais adequada. As mtricas sugeridas pelo artigo incluem contadores de acesso, livros de visitas e analisadores de clientes. Ginige et al. (2001) exploram prticas de desenvolvimento de sistemas Web e apresentam perspectivas multidisciplinares que podem ajudar a melhorar essa rea. Os autores resumem dez fatores-chave para o desenvolvimento bem sucedido de WebApps. Novos desafios para a colaborao no desenvolvimento de aplicaes Web o tema de (VOGELSAN et al., 2001), que apresenta resultados preliminares de um projeto de desenvolvimento de um sistema Web em andamento, discutindo o que os autores consideram 38

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.

2.5. Consideraes finais do captulo

Como podemos ver, a quantidade de propostas para a rea de Engenharia Web bastante vasta, o que demonstra que acadmicos e profissionais da rea de Engenharia de Software ainda no elegeram uma metodologia ou linguagem de modelagem padro para o desenvolvimento de aplicaes Web. Alm disso, no h nenhuma indicao de que isso ocorrer nos prximos anos, dado que existem vrias propostas para contextos especficos como desenvolvimento baseado em componentes (a proposta de Lee & Shirani seo 2.1.2), desenvolvimento baseado em prototipao (MODFM seo 2.1.1) ou desenvolvimento de aplicaes B2C (ICDM seo 2.1.8). Apesar de notarmos um crescimento na utilizao de frameworks ou arquiteturas baseadas em containers para o desenvolvimento de WISs, no encontramos nenhuma abordagem voltada para essa categoria de WebApps. Esse contexto motivou-nos a propor um novo mtodo, apresentado no captulo 4. Ao final deste, na seo 4.4, comparamos nossa proposta com outras 39

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