Ti - Engenharia Web - Capitulo 2

8/6/2019 Ti - Engenharia Web - Capitulo 2

1/39

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 sub-

rea 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 GatewayInterface (CGI), programas em linguagens como C ou PERL poderiam ser at ivados 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


2/39

de servios automticos, como gerenciamento de persistncia, controle de transaes, etc.

Em particular, destaca-se para ns o surgimento de diversosframeworks que provem uma

slida infra-estrutura para o desenvolvimento de WISs. O uso dessesframeworks, com o passar

do tempo, tornou-se estado-da-prtica e at mesmo influenciou na definio de padres paradesenvolvimento 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 (osframeworks j foram extensivamente testados por seus criadores).

Este captulo apresenta uma reviso geral das metodologias eframeworks 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 WebNesta 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


3/39

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 SoluoWeb Orientada a Objetos, a Engenharia Web Baseada em UML, a metodologia de apoio ao uso

do FrameworkJAFAR2 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 (Mockup-

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

aes, 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.

4


4/39

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 (server-

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


5/39

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 domximo 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 comcomponentes 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

6


6/39

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 Produto

Projeto Conceitual Definio da estrutura lgica Diagrama EstruturalEstudo das funes do sistema Diagrama Navegacional

Especificaes Funcionais

Especificao das entidades Diagramas InternosCatlogo de AtributosCatlogo de Eventos

Modelagem de usurios Diagrama de Usurios

Definio da poltica de segurana Catlogo de CategoriasTabela de Acesso

Projeto Detalhado Identificao das instncias Diagrama de Instncias de NsDiagrama de Instncias de Usurios

Especificao de funes Especificao de Estruturas de AcessoEspecificao Detalhada de Funes

Especificao de instncias Diagramas Internos Detalhados

7


7/39

Fase Atividade Produto

Regras de AutorizaoDelegao de Usurios

Definio de requisitos deapresentao Especificao de Apresentao

Avaliao Desenvolvimento de um prottipo Prottipo

Avaliao Documento de AvaliaoRelatrio de Concluso

O mtodoAriadne 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 ConallenJim 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 ICONIX-

UP) (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 sub-

processo 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

8


8/39

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,

9


9/39

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


10/39

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 aocontexto 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


11/39

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 completamenteautomtica 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


12/39


13/39

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 oespao 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


14/39

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 soespecificados 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 metodologiasResumimos 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


15/39

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-to-

consumer 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) umframework para construo de aplicaes Web de comrcio eletrnico utilizando

Java 2 Enterprise Edition (J2EE), verso 1.4 (SHANNON, 2003). Oframeworkprov solues

tcnicas para problemas comuns no desenvolvimento desse tipo de aplicao e prov padres que

simplificam o trabalho do desenvolvedor.

Oframeworkfunciona como um prottipo para explorao do domnio de transformao de

modelos dentro da pesquisa em torno de MEDAL (UML Generic Model Transformer Tool)

(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 WebDescrevemos 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


16/39

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 aslinguagens 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 para anexar

informaes textuais arbitrrias a elementos de modelo; e

restrio (constraint) condio ou restrio que permite a especificao de novasemntica 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 deabstrao, 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


17/39

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 aparnciagrfica 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 umacaixa 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


18/39

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, seuscaminhos 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 , um compartimento de

tela (ex.: um frame HTML) modelado como e um formulrio

recebe a denominao , como ilustra o exemplo da Figura 2.7.

19


19/39

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


20/39

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 emvista 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


21/39

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

Esteretipo O que a classe estereotipada representa

Uma pgina Web dinmica que efetua processamento no servidor egera um resultado possivelmente diferente a cada requisio. Suasoperaes representam funes do script e seus atributosrepresentam variveis visveis no escopo da pgina.

Uma pgina Web esttica que simplesmente retornada ao clientequando requisitada, sem gerar processamento. Pode conter scriptsdo lado do cliente (client-side), portanto seus atributos e operaesreferem-se a tais scripts.

Formulrios HTML para entrada de dados. Seus atributosrepresentam os campos do formulrio. Tais formulrios nopossuem operaes. Qualquer operao que interaja co m oformulrio deve ser propriedade da pgina que o contm.

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 ), alvo de link (classe com

esteretipo ), link de destino (associao mltipla com esteretipo ), bibliotecas de script (classe com esteretipo ) e objeto de script(classe com esteretipo ).

22


22/39

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

Esteretipo O que a associao estereotipada representa

Um link normal entre pginas, representado em HTML pela tag.Parmetros codificados como parte da URL segundo o protocolo HTTPpodem ser representados como atributos da associao.

Relacionamento direcional entre uma server page e uma client page queindica que a sada HTML do processamento da pgina do servidor apgina do cliente.

Relacionamento direcional entre um html form e uma server page,representando o envio dos dados dos campos do formulrio para apgina do servidor para processamento.

Ao de redirecionamento de uma pgina para outra.

Ao de delegao de uma pgina para outra. Difere doredirecionamento por manter o contexto da requisio feita primeirapgina.

Relacionamento de confinamento entre uma pgina e um objeto, comouma Applet ou controle ActiveX.

Uma associao direcional entre uma server page e uma outra pginaque indica que o contedo desta ltima ser processado (somente nocaso de uma pgina do servidor) e includo na primeira.

Para a viso de componentes, so definidos trs esteretipos para o elemento de modelo

componente da UML: , componente que representa pginas estticas, ou seja,

sem processamento no lado do servidor; , componente que representa pginas

dinmicas; e , pacote de componentes representando uma abstrao de uma

hierarquia de arquivos que contm recursos disponveis solicitao no servidor Web.

23


23/39

Figura 2.8: Diagrama de classes de viso lgica da camadaWeb

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 daspginas do cliente Home ou ErroLogin feita pela pgina dinmicaprocessaLogin.php.

Figura 2.9: Diagrama de componentes ligando a viso lgica aos componentes fsicos

24


24/39

Alm dos esteretipos bsicos, para o projeto avanado, Conallen define tambm:

biblioteca de script (componente com esteretipo ), raiz virtual (pacote

com esteretipo ), recurso HTTP (componente com esteretipo ), biblioteca de tags JSP (pacote com esteretipo ) e tag JSP

(classe com esteretipo ), sendo esta ltima composta por um elemento que

representa o corpo da tag (dependncia com esteretipo ) e opcionalmente um elemento

que rene informaes extras (dependncia com esteretipo - 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 ): 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 ): 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 ): consiste em um objeto que prov

acesso seqencial s instncias de uma classe de navegao;

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

utilizado para selecionar instncias de classes de navegao mediante um determinado

25


25/39

filtro embutido na consulta;

Menu (esteretipo ): 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


26/39

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, umframework visto como um artefato de

cdigo que prov componentes prontos que podem ser reutilizados mediante configurao,

composio ou herana. Quando combinados, essesframeworks 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 containerpara aplicaes distribudas,

como os containers da plataforma Java Enterprise Edition (SHANNON, 2003), gerenciamobjetos 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


27/39

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 paraimplementao. Conclumos com uma breve anlise das arquiteturas baseadas em containers e

sua relao com osframeworks 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


28/39

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 nessaplataforma, 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 paraprocessamento. 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


29/39

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 oframework, 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 50frameworks 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


30/39

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 deframework 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


31/39

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 aoframework de

Mapeamento Objeto/Relacional como transformar objetos e seus atributos em tabelas e colunas e

chamar mtodos simples, como salvar(), excluir() e recuperarPorId(), disponveis noframework.

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

diversosframeworks 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


32/39

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

frameworkORM, 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 comoframeworks de Inverso de Controle

33


33/39

(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 doframework, todas as suas dependncias j tenham sido

satisfeitas ou, em outras palavras, injetadas. O termo IoC tambm utilizado pelo fato docontrole 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 deframeworks 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, permitindoque 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 umsistema, 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


34/39

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


35/39

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 umframework, 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 umaaplicao. 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


36/39

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 deframeworks como Hibernate, Spring e Struts, o desenvolvimento

de aplicaes com necessidades de distribuio, escalabilidade e robustez era guiado por padres

como a plataforma JavaEnterprise 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 deframeworks que realizam um servio j provido

por containers, porm de forma independente, se deu em grande parte por deficincias nasespecificaes 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 dosframeworks 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 persistnciade componentes (Enterprise JavaBeans) com base noframework 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


37/39

containers cujos servios so baseados em idias similares a dosframeworks.

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 esemanticamente rica para troca de conhecimento sobre projetos em andamento ou j implantados.

Em (TAM et al., 2000), umframeworkde 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 dezfatores-chave para o desenvolvimento bem sucedido de WebApps.

Novos desafios para a colaborao no desenvolvimento de aplicaesWeb 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


38/39

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 deframeworks 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


39/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 daInternet. Para fundamentarmos nossa discusso sobre este assunto, apresentamos uma reviso dos

conceitos e trabalhos desta rea no captulo seguinte.

Ti - Engenharia Web - Capitulo 2

Documents

Transcript of Ti - Engenharia Web - Capitulo 2