Desenvolvimento Web Metodologias Este documento é uma compilação de várias técnicas, analisadas por autores diversos, utilizadas no desenvolvimento para web. A aplicação das mesmas pode se dar tanto em Aplicações Web como no desenvolvimento de Sites.

2009

Carlos Alan Peres UFCG

10/10/2009

2

1) Metodologia MOEBUS

I. Diagnóstico - documentação do contexto em que se insere a demanda e a empresa

como um todo.

a) Estudo de Key-elements ou elementos chaves –

esmiuçar o público-alvo, mercado, produto (o

que a empresa oferece) e concorrência. Em

seguida mapeia-se as demandas do público

alvo para, finalmente levantar os processos

pelos quais o público alvo passa no

atendimento de suas necessidades;

b) Análise de Cenários – desenhar o cenário propriamente dito, baseado nos

itens acima.

II. Prognóstico – planejamento completo do

projeto com base no diagnóstico.

a) Objetivos – definição dos

objetivos do projeto;

b) Webcore – desenho da

arquitetura técnica e das funcionalidades, ou seja, estruturação de novos

processos de negócios, as funcionalidades;

c) Webcontext – análise da arquitetura da informação, do conteúdo e do

design, nesta ordem, como compor este trinômio;

d) Plano de divulgação – montar o plano de divulgação;

e) Plataforma de aplicação – modelo técnico adequado;

f) Ferramentas vs. Desenvolvimento – posicionamento de processos na matriz

moebius para apontamento de necessidades técnicas;

g) Seleção de desenvolvedores – preparação da concorrência e escolha de

desenvolvedores;

h) Seleção de ferramentas – concorrência de escolha de ferramentas;

i) Webteam ou time gestor – montagem da equipe de gestão ideal para o

projeto.

III. Produção – Desenvolvimento do produto.

a) Produção - colocar em prática tudo que foi

traçado no Prognóstico o que faz desta

etapa algo rápido é o planejamento

conseguido em relação a arquitetura da informação, conteúdo e design na

etapa anterior;

b) Lançamento – publicação do projeto e acompanhamento pelo gestor –

controle de métricas.

O artefato final desta etapa é o Documento de Diagnóstico e o prazo de realização da mesma é um período compreendido entre 6 e 10 dias;

O artefato final é o Documento de Prognóstico e o prazo de conclusão é entre 20 e 40 dias.

Artefatos Documentos de Status. Prazo de conclusão entre 10 e 30 dias.

3

IV. Monitoramento pró-ativo – medição

dos dados e estruturação de ações

para a otimização do projeto.

a) Coleta de Dados – dados

estatísticos fruto da navegação dos usuário;

b) Análise de Resultados - Transformação de dados em índices e taxas e estudo

de métrica.

Um estudo de caso do Método Moebus

Diagnóstico

Coletar informações sobre a empresa

Coletar informações sobre o produto

Coletar informações sobre o mercado

Coletar informações sobre a concorrência

Definir os objetivos gerais do projeto

Definir o público-alvo do projeto

Mapear demandas do público-alvo

Definir formas de rentabilização do site

Definir detalhes técnicos do projeto

Esclarecer sobre linguagens e ferramentas que serão utilizadas

Decidir licença para os direitos autorais

Definir quem será o interlocutor entre cliente e desenvolvedor

Coletar idéias para a arquitetura de informação

Definir objetivo principal para escolher destaque da home

Montar o cronograma detalhado de execução do projeto

Construir cenário compilando as informações coletadas no documento de diagnóstico

Prognóstico

Separar e hierarquizar seções do site

Definir label das seções (taxonomia)

Construir o Mapa do Site

Classificar páginas como estáticas ou dinâmicas

Elaborar Wireframes

Organizar fluxo de navegação

Realizar avaliação heurística da interface

Criar protótipo navegável

Realizar teste informal de usabilidade da interface

Planejar conteúdo e definir responsáveis

Elaborar cronograma com prazo de recebimento do conteúdo

Adaptar conteúdo enviado com técnicas de webwriting

Elaborar Documento de Conteúdo, casando com Arquitetura de Informação

Definir a paleta de cores

Artefato, Documento de Monitoramento. Prazo médio semanal ou mensal.

4

Definir a tipologia

Definir a iconografia

Definir padrões gráficos

Criar layout da home

Criar layout de uma página interna

Verificar acessibilidade no contraste das cores

Submeter layout inicial à aprovação do cliente

Criar layout das demais páginas

Revisar layout com arquitetura de informação

Submeter telas finais à aprovação do cliente

Definir o time de gestão do projeto

Definir controle de métricas

Elaborar o documento de prognóstico

Produção

Elaborar HTMLs seguindo web standards

Validar HTMLs junto ao W3C

Validar HTMLs junto aos avaliadores de acessibilidade

Elaborar folhas de estilo (CSS) para monitor

Elaborar folhas de estilo (CSS) para impressora

Elaborar folhas de estilo (CSS) para dispositivos móveis

Elaborar folhas de estilo (CSS) para leitores de tela

Validar folhas de estilo junto ao W3C

Testar resultados em vários navegadores e plataformas

Revisar navegação geral

Realizar avaliação heurística do projeto

Realizar testes de usabilidade informal

Submeter resultado das páginas estáticas à aprovação do cliente

Implementar páginas dinâmicas

Instalar e configurar o CMS

Alimentar páginas dinâmicas com o conteúdo coletado

Submeter resultado final à aprovação do cliente

Revisar site com sistemas implantado em URL alternativa

Treinar equipe que vai utilizar o sistema

Confirmar com cliente a data de lançamento

Migrar projeto para endereço oficial

Elaborar Documento de Produção

Monitoramento

Monitorar diariamente performance da estrutura tecnológica

Revisar navegação e links mensalmente

Elaborar Relatório Mensal de Navegação Periódica

Realizar atendimento das solicitações do cliente

Verificar satisfação do cliente

Registrar alterações no Histórico do Atendimento

Monitorar inovações disponíveis

Certificar que o cliente tenha a versão mais recente do CMS

Oferecer e/ou implementar as inovações

5

Controlar periodicamente métricas definidas através do Google Analytics

Elaborar mensalmente Relatórios de Controle de Métricas

Analisar métricas para sugerir ajustes e melhorias

6

2) UWE – UML-based Web Engineering

Esta metodologia foi desenvolvida na Universidade de Munique – Alemanha e aborda as

três dimensões de um projeto de aplicações Web: conteúdo, navegação e apresentação,

utilizando elementos padrões da UML juntamente com a notação UWE e define uma

seqüência de passos para a modelagem de uma aplicação Web.

A modelagem para desenvolvimento de aplicações Web pode ser realizada usando

técnicas propiciadas pela UML junto com a sua notação UWE. Desenvolvedores de

aplicações Web normalmente fazem uma separação do contexto em conteúdo,

navegação e apresentação, ou seja, dividem, mesmo que involuntariamente, o

desenvolvimento nos seguintes passos: projeto conceitual, de navegação e de

apresentação.

Parte das atividades do projeto conceitual, de navegação e de apresentação é a

construção

de modelos e sua representação gráfica. Esses modelos consistem de elementos de

modelagem da UML padrão ou elementos de modelagem especificados – estereótipos –

definidos através do mecanismo de extensão da UML (Nota 1).

Projeto Conceitual

O Projeto Conceitual produz um Modelo Conceitual que descreve o domínio do

problema através de classes e suas associações entre essas classes. É representado

através de um Diagrama de Classe da UML.

Projeto Navegacional

A base no Projeto Navegacional é o Modelo Conceitual, e seu resultado é o Modelo

Navegacional que pode ser visto como uma visão definida do modelo conceitual. O

modelo navegacional é definido em dois passos. No primeiro passo o Modelo de espaço

navegacional é definido mostrando quais as classes do modelo conceitual podem ser

visitadas por navegação na aplicação Web. Um diagrama de classe da UML é utilizado

para representar graficamente o modelo conceitual. Este modelo que é construído com

estereótipos de classes – classe navegacional – e associação – navegabilidade

direcionada.

O Modelo de estrutura navegacional define a navegação da aplicação, isto é, como

os objetos navegacionais são visitados. Este modelo é baseado no modelo de espaço

navegacional, mas elementos de modelagem adicionais são incluídos no diagrama de

classe

para representar a navegação entre objetos navegacionais: menus, guide tours e

queries. Todos esses estereótipos serão definidos ao longo desta seção.

7

Projeto de apresentação

O projeto de apresentação suporta a modelagem de uma interface abstrata de usuário

exibindo como a estrutura navegacional é apresentada ao usuário. Projeto de

apresentação como os nós de navegação aparecerão, selecionando objetos de interface

de usuário a

serem exibidos e determinando as transformações que ocorrerão em cada interface

definida. Esta notação propõe a construção de um modelo de apresentação.

O Modelo de apresentação é representado por um diagrama de composição da UML que

descreve como as interfaces de usuários são construídas. Um objeto de interface de

usuário pode ser um objeto de interface de usuário primitivo como texto, imagem e

botão, ou uma composição de objetos de interface de usuários. Para a definição de

objetos de interface de usuário foram definidos estereótipos de acordo com o mecanismo

de extensão propiciado

pela UML. Esses objetos são: âncora, texto, imagem, áudio, vídeo, botão, coleção,

coleção ancorada.

Estereótipos para modelagem de aplicações Web

Esta extensão da UML define um conjunto de estereótipos que são usados na construção

dos modelos definidos para o desenvolvimento de aplicações Web. A seguir serão

apresentados os estereótipos definidos para a modelagem de aplicação Web segundo a

notação UWE

separados pelo modelo já definido anteriormente.

Modelo navegacional

Classe Navegacional: representam uma classe conceitual cuja instância

podem ser visitadas por usuários durante a navegação.O ícone usado para o estereótipo

«navigational class» é mostrado na Figura 8. Navegabilidade Direcionada: associação no modelo navegacional é

interpretada como navegabilidade direcionada da classe navegacional de origem para a

classe navegacional de destino. Possui semântica diferente de uma associação no

modelo conceitual. Ela

determina a direção de navegação entre as classes, e são exibidas por setas

direcionadas ou bidirecionadas (navegação em ambos os sentidos). Index: é modelado por um objeto composto que contém um número

arbitrário de

itens de index. Cada item de index possui um nome e um link para uma instância de

uma

classe navegacional. Qualquer index é um membro de alguma classe index que é

estereotipada por «index» com um ícone correspondente como mostrado na Figura 8.

8

Guide Tour: é um objeto que permite acesso seqüencial para as instâncias de

uma classe navegacional. O ícone correspondente para o estereótipo «guide Tour» é

mostrado na Figura 8. qualquer classe guide tour será conectada a uma classe

navegacional por uma associação direcionada que tenha a propriedade {ordered}. Query: é representado por um objeto que tenha uma string de consulta como

atributo. O ícone para o estereótipo «query» é mostrado na Figura 8. Menu: é um objeto composto que contém um número fixo de itens. Cada item

de

menu tem um nome e um link para a instancia de uma classe navegacional, index, guide

tour

ou query. Qualquer menu é uma instancia de uma classe menu que é estereotipada por

«menu» com um ícone correspondente mostrado na Figura 8.

Figura 8. Estereótipos para o modelo navegacional

Modelo de apresentação Classe de apresentação: modela a apresentação de uma classe

navegacional ou primitiva de acesso, como index, guide tour, query ou menu. Instancias

de classes de apresentação recebem elementos de modelagem como texto, imagens,

vídeos, áudio, âncoras, coleções, coleções ancoradas, etc. A Figura 9 mostra o ícone

correspondente. Frameset e Frame: é um elemento de alto nível que é modelado por uma

composição de objetos de apresentação ou outros framesets. Uma área de um frameset

é associada a cada elemento de baixo nível, chamado frame. Os ícones para os

estereótipos «frameset» e «frame» são apresentados na Figura 9. Janela: é a área de interface de usuário onde framesets e objetos de

apresentação são exibidos. Uma janela pode ser movida, maximizada ou minimizada a

um ícone. Ela possui

dois pequenos botões, um para transformar a janela em ícone (minimizar) e outro para

fechar

a janela. A Figura 9 apresenta o estereótipo de classe para janela.

Figura 9. Estereótipos que compõem o modelo de apresentação

9

Figura 10. Estereótipos de apresentação

A Figura 10 mostra os ícones escolhidos para os estereótipos de elementos de

modelagem apresentados abaixo. Eles são usados no projeto de apresentação de

aplicações Web em

adição aos objetos de apresentação, janelas, frameset e frames.

Texto: é uma seqüência de caracteres. Âncora: é um texto que pode ser clicado que é o ponto de partida para o

relacionamento entre outros nós. Botão: é uma área que pode ser clicada que tem uma ação associada a ela. Imagem, vídeo, áudio: são objetos multimídia. Uma imagem pode ser exibida.

Áudio e vídeo podem ser iniciados, parados, podemos voltá-los, ou adiantá-los. Form: é usado para receber informações do usuário que passam informações

em um

ou mais campos de entrada ou opções de seleção do browser ou checkbox. Coleção: é uma lista de elementos de texto que é introduzida como estereótipo

que prover uma representação conveniente desta composição. Coleção ancorada: é uma lista de âncoras que é introduzida como estereótipo

que prover uma representação conveniente de uma coleção de âncoras.

Aplicação de UWE no estudo de caso

A modelagem de uma aplicação seguindo a metodologia apresentada por UWE para o

estudo

de caso consiste na definição de três modelos: Modelo conceitual (idêntico ao da Figura

3), Modelo navegacional (Figura 11) e Modelo de apresentação (A Figura 12 apresenta

o

modelo de apresentação para a página de veículos).

10

Figura 11. modelo navegacional O modelo navegacional da Figura 11 indica que a classe navegacional Loja é composta

por um item menu (Menu Principal) com 4 links para a classe Categoria, que apresenta a

lista de veículos de acordo com a categoria (Index – Lista de Veículos). A partir desta

lista pode ser acessada um veículos específicos (classe Veículo).

Figura 12. modelo de apresentação

O modelo de apresentação para a página de veículo apresenta os elementos desta

página de acordo com o seu tipo. A página é composta pelas informações de Veículos

(Classe de apresentação Veículo) que contem seus dados (fotos, ano, cor, etc) e por um

menu principal (Classe de apresentação Menu Principal) com links para outras áreas do

site. Nota 2 – Ferramentas de modelagem das metodologias O desenvolvimento de uma aplicação Web através das metodologias apresentadas neste

artigo requer a utilização de ferramentas CASE para facilitar a tarefa de modelagem

através de cada uma das metodologias. Abaixo, apresento uma descrição sobre

ferramentas existentes para as metodologias.

11

ArgoUWE: O ArgoUWE é uma ferramenta CASE que permite a modelagem de

aplicações Web através da metodologia UWE . Esta ferramenta é instalada como

extensão da ferramenta de modelagem ArgoUML através de bibliotecas especiais para a

notação UWE. A ferramenta ArgoUML é gratuita e está disponível no endereço

http://argouml.tigris.org. A biblioteca de extensão para a metodologia UWE está

disponível em: http://www.pst.informatik.uni-muenchen.de/projekte/argouwe/. Este

endereço apresenta as informações necessárias para a instalação destas bibliotecas ao

ArgoUML. Obs: a ferramenta neste momento não suporta a modelagem do modelo de

apresentação. Estereótipos para o Rational Rose: O Rational Rose é uma ferramenta CASE

proprietária desenvolvida pela empresa IBM que permite a modelagem de sistemas

utilizando-se a notação UML. Para que seja possível a modelagem de sistemas utilizando

a notação WAE, é necessária a instalação dos estereótipos estendidos da UML através

desta ferramenta. O arquivo de instalação dos estereótipos da notação WAE para o

Rational Rose está disponível no endereço http://www.wae-uml.org. Caso vocês não

consigam acessar o endereço, entrem em contato com o autor do artigo. Visual UML: O Visual UML é uma ferramenta CASE proprietária desenvolvida pela

empresa Visual Object Modelers, que é uma empresa membro da OMG (Object

Management Group), que permite a modelagem de objetos para todos os diagramas da

UML 1.3 e 1.4. Visual UML inclui extensões da UML para modelagem de objeto de

negócio, modelagem de aplicações Web (usando a notação WAE) e modelagem XML. Os

responsáveis pela ferramenta disponibilizam uma versão de teste do Visual UML para ser

utilizado por 30 dias. Esta versão está disponível no endereço

http://www.visualuml.com. WebRatio: é uma ferramenta CASE que permite a modelagem e a geração de

aplicações Web utilizando como base a notação WebML. O WebRatio é uma ferramenta

proprietária desenvolvida pela empresa WebModels S.r.I. com o auxílio dos criadores da

WebML. Esta ferramenta possui uma versão de teste disponível no endereço eletrônico:

http:///www.webratio.com.

Conclusão

Este artigo tem como objetivo apresentar ao leitor as principais diferenças no

desenvolvimento de uma aplicação que utiliza a Web como plataforma, destacando três

metodologias de desenvolvimento dessas aplicações. A importância destas metodologias

se dá devido à necessidade de definição de aspectos particulares destas aplicações e que

não podem ser desenvolvidos como sistemas convencionais. Atualmente, não há um padrão de modelagem de aplicação Web (como existe para

aplicações tradicionais através da UML). Várias metodologias com características e

notações distintas estão disponíveis e podem ser utilizadas no projeto dessas aplicações.

12

3) WebML – Web Modeling Language

A WebML é uma notação para especificação de Web sites em nível conceitual e permite a

descrição alto nível de um Web site sobre distintas dimensões ortogonais: seu conteúdo

de dados (modelo estrutural), a páginas que compõe o site (modelo de composição), a

topologia de links entre as páginas (modelo navegacional) e a customização das

características de conteúdo de acordo com o perfil do usuário (modelo de

personalização).

A especificação da WebML é feita com a definição de modelos, sendo que cada um deles

já tem uma sintaxe XML definida, facilitando dessa forma a manipulação dos resultados

da modelagem para a geração automática de páginas. Sendo esses modelos: Modelo

Estrutural, Modelo de Hipertexto (formado pelos modelos de Composição e Modelo

Navegacional), Modelo de Personalização.

Modelo Estrutural

O Modelo Estrutural consiste no conteúdo de dados da aplicação Web. A WebML não

propõe uma nova notação de modelagem para essa estrutura, permitindo a utilização de

notações como a Modelo de Entidade e Relacionamento ou Diagrama de Classes UML.

Os elementos fundamentais para a Definição do Modelo Estrutural são entidades que

contêm os dados armazenados, e relacionamentos que permitem a ligação semântica de

entidades. As entidades são formadas por um nome e atributos associados a um tipo de

dado. Os relacionamentos são definidos através do nome e da cardinalidade das

entidades que o compõem.

O modelo conceitual para o estudo de caso AutoLopes Multimarca é idêntico ao

apresentado na Figura 3.

Modelo de Composição

O Modelo de Composição permite a definição de unidades de conteúdo e das páginas. As

unidades de conteúdo determinam a forma pelo quais os dados de uma determinada

entidade vão ser exibidos, customizando os atributos desejados. As principais unidades

de conteúdo disponíveis na WebML são as seguintes (Figura 5):

o Data unit: Mostram informações relativas a um simples objeto, por exemplo, uma

instância de uma entidade. São definidos através da definição dos atributos de uma

entidade. Mais de um data unit pode ser criado para uma mesma entidade, oferecendo

várias maneiras de se ver um mesmo dado. o Multidata units: Mostram a informação referente a um conjunto de objetos, por

exemplo, todos as instâncias de uma determinada entidade. o Index units: Mostram os objetos de uma entidade em uma lista, denotando cada

objeto como um link para outra unidade de conteúdo. o Scroller units: Mostram comandos para acessar os elementos ordenados em uma

lista de objetos, por exemplo, todas as instâncias de uma entidade ou todos os objetos

associados com outro através um determinado relacionamento. Estes comandos são:

primeiro, último, próximo e anterior. o Filter units: Mostram campos que permitem que o usuário entre com valores para

uma pesquisa, resultando apenas nos objetos validados por uma condição. Normalmente

são usados em conjunto com o index unit ou multidata unit, que apresentam os valores

correspondentes a pesquisa realizada.

13

Figura 5. Principais elementos da WebML

Ainda no modelo de composição, a WebML apresenta um suporte à entrada de dados e

operações. Para a inclusão dos mesmos, o modelo de composição apresenta links com

propriedades de ativar a operações. As unidades de entrada de dados são formadas por

campos que fornecem parâmetros para as operações a serem processadas. As unidades

de operação recebem informações por meios um ou mais links, sendo que um deles tem

que ser declarado como ativador da operação para quando a navegação pelo link

ocorrer, este possa executar a operação. A WebML apresenta algumas unidades de

operações definidas, sendo elas responsável por criar, atualizar e remover uma entidade

e de criar e remover um relacionamento.

Modelo Navegacional

As unidades de conteúdo e as páginas formadas nos modelo de composição não podem

existir isoladamente, devem estar conectadas para formar o modelo de hipertexto. Esse

é o propósito do modelo navegacional, especificar a maneira pela qual as unidades de

conteúdo e as páginas estão relacionadas, definindo os seus links que podem ser de

duas formas:

o Links Contextuais: Conectam as unidades com informações semânticas referentes

à aplicação, dessa forma carregando informação da unidade de origem para a de destino

(Figura 6).

Figura 6. Exemplo de link usado para definir o contexto de um data unit o Links Não Contextuais: Conectam páginas totalmente livres, independentemente

das unidades que estão contidas nas páginas ou suas relações semânticas.

Modelo de personalização

14

Define características individuais do conteúdo de cada usuário ou grupo de usuário.

WebML fornece o conceito de entidades de Usuários e Grupo de Usuários, permitindo

modelar esquemas personalizados de conteúdo e apresentação, regras de acesso,

segurança, atualização do conteúdo.

A separação entre o modelo estrutural e o de hipertexto permite que a WebML forneça

meios de especificar várias visões de um mesmo site, possibilitando o atendimento de

requisitos mais complexos. Essas diferentes visões do site podem estar associadas ao

dispositivo pelo qual se está acessando o site ou por grupos de usuários.

Aplicação de WebML no estudo de caso

A modelagem de uma aplicação seguindo a metodologia apresentada por WebML para o

estudo de caso consiste na definição do modelo de Hipertexto (Figura 7).

Figura 7. Modelo de Hipertexto para AutoLopes Multimarca

O modelo representa a existência de uma página principal (AutoLopes Multimarca) com

uma lista de opções com links para as páginas das categorias (Motos, Vans, carros, Off-

roads) que contêm, cada uma, a lista de veículos (Index Unit Veículos). Essa lista possui

um link contextual para a página de detalhe de um veículo (AutoLopes – Detalhes),

indicando que o veículo escolhido é passado como parâmetro para a página de detalhe.

O envio de e-mail é feito através da página Contatos que possuem um formulário a ser

preenchido e enviado para a criação de um novo objeto do tipo Contato.

15

4) WAE – Web Application Extension

Web Application Extension consiste em uma extensão da notação UML proposta a partir

de 1998. É uma forma de usar a especificação padrão UML, que estende estereótipos

(Nota 1) para mapear estruturas típicas da arquitetura Web, como páginas, applets,

componentes servlets, etc.

Esta extensão busca solucionar o problema da semântica de representação dos

elementos presentes na modelagem de aplicações Web através da modelagem

conceitual (dados do sistema) e arquitetural (composição física). Estes estereótipos

representam a composição física da aplicação a ser desenvolvida e o relacionamento

dos seus componentes (modelo navegacional).

Uma metodologia proposta para aplicação de WAE no desenvolvimento de um sistema é

na seguinte: inicialmente desenvolve-se um modelo conceitual representado pelo

diagrama de classes da UML; após isto é desenvolvido um modelo navegacional

utilizando os estereótipos de classes estendidas pela notação WAE através do

relacionamento entre essas classes para representação navegacional e arquitetural da

aplicação. Eventualmente, para a representação da iteratividade entre as classes do

modelo navegacional pode ser utilizado o diagrama de seqüência da UML.

Os elementos de WAE são: estereótipos de páginas, relacionamentos entre páginas,

forms e framset.

Estereótipo de Páginas

As páginas existentes em uma aplicação Web apresentam características distintas de

acordo com o local onde seus métodos são executados. Uma página que roda no

servidor é completamente diferente de páginas que rodam em browsers de clientes,

possui acesso a informações que não são acessíveis ao cliente e são controladas de

maneira distinta.

A extensão da UML (WAE) representa essas páginas no modelo como duas classes

distintas: Página servidora «server page» e Página Cliente «client page» (Figura 2).

Uma página servidora relaciona-se com componentes que existem no servidor e serão

utilizados nestas páginas. Uma página cliente relaciona-se com componentes que

existem no cliente (browsers).

Relacionamento entre páginas

Existe um fundamental relacionamento entre páginas clientes e servidoras, entre

páginas servidoras e entre páginas clientes visando à comunicação entre essas classes.

O relacionamento entre as páginas ajuda a definir o mapa do site. Existem diferentes

mecanismos de relacionamento entre essas classes, são eles:

o Builds: relacionamento unidirecional entre uma «server page» e uma «client

page», indicando que uma página servidora geralmente é responsável pela construção

de páginas clientes. Representado pelo estereótipo «build». o Redirect: outra facilidade das tecnologias de desenvolvimento de aplicações Web é

a habilidade para redirecionar o processamento para outra «server page». Este

relacionamento pode ser expresso no modelo com o estereótipo de associação

«redirects». o Links: um relacionamento adicional e fundamental no projeto de aplicações Web é

hyper link. Páginas Clientes possuem hyper links (âncoras) para outras páginas Web

(páginas servidoras ou clientes). O estereótipo: «links» é definido pra associação entre

páginas clientes e outras páginas.

16

Forms (Formulários)

Formulários (Figura 2) são expressos no modelo como uma agregação de páginas

clientes. Um objeto «form» existe somente no contexto de páginas clientes. Este objeto

é uma coleção de elementos de entrada padrão que aceita entradas do usuário e

submete à página servidora para processamento. Em uma mesma página pode haver

diversos forms, cada um possuindo uma ação diferente na página.

Uma classe form tem como atributos campos a serem preenchidos pelos usuários.

Métodos em uma página cliente têm acesso a todos os atributos do forms que estão

associados página. Portanto, páginas clientes contêm forms.

Um estereótipo de associação «submits» representa o relacionamento entre um

formulário e a página Web que a processa.

Frameset

Frames permitem que o projetista Web possa dividir a janela do browser em sub-áreas

retangulares, cada uma com uma diferente página (Figura 2).

Coordenar atividades entre páginas em frames requer habilidade para referenciar

páginas contendo frames. Target é o termo usado quando uma página cliente referencia

outra página Web ou frame. Um target não tem propriedades ou atributos, ele é

simplesmente uma referência possível para uma página cliente. Uma classe frameset

pode conter um target, ou um target pode existir independentemente (como no caso de

janelas de browser separadas).

Um estereótipo precisa ser definido para associação que indica que uma página cliente

está requerendo um link para ser rodado em uma outra janela. Um estereótipo

«targeted link» é aplicado para associação entre páginas clientes e targets com quem

elas interagem. Parâmetros que são passados para o servidor com o targeted link

podem ser identificados com um atributo link da UML.

Figura 2. Estereótipos na notação WAE Nota 1 – Estereótipo da UML Estereótipo consiste em um mecanismo de extensão da UML que permite a

classificação de seus elementos originais de uma outra forma a partir da definição de

restrições a esses elementos. Ex: Página cliente é um estereótipo do elemento Classe

da UML, pois é um tipo de classe restrita ao domínio de aplicações Web.

Aplicação de WAE no estudo de caso AutoLopes Multmarca

A modelagem de uma aplicação seguindo a metodologia apresentada para WAE resultou

17

em dois modelos: modelo conceitual (Figura 3) e modelo navegacional (Figura 4).

O modelo conceitual (diagrama de classes) representa a estrutura dos dados do sistema,

onde temos informações sobre a loja, contato (e-mails), veículo e categorias

representados através de classes e seus relacionamentos.

Figura 3. Modelo conceitual para AutoLopes Multimarca

O modelo navegacional gerado a partir da notação WAE representa a estrutura da

aplicação através das páginas da aplicação e seus relacionamentos. A página

principal da aplicação é composta um menu com links para as páginas de cada de

categoria de veículos (Figura 4-[marca azul]: pgVans, pgOff-roads, pgCarro e

pgMoto) e um link para envio de e-mails através da aplicação (pgContato).

Para cada página de uma categoria é carregada a lista de veículos. Caso o usuário

escolha um veículo específico, o sistema construirá (build) a página específica do

veículo (pgVeiculo) com as suas informações através de um processamento feito

na página servidora IdentificarVeiculo (Figura 4 – [marca amarela]). Para o envio

e e-mail, o sistema apresenta um formulário (frmContato) para preenchimento

dos dados do e-mail (Email, TipoContato e CorpoEmail) e após confirmação, envia

o e-mail aos responsáveis pelo sistema através da página servidora

GravarContato (Figura 4 – [marca vermelha]).

18

Figura 4. Modelo navegacional para AutoLopes Multimarca

19

10

2.2 O Método OOHDM O OOHDM é um método integrado para autoria de aplicações hipermídia. Ele provê primitivas de projeto de alto nível e mecanismos de abstração, baseados no paradigma da orientação a objetos, que permitem representar o projeto de aplicações hipermídia complexas que manipulam grande quantidade de informações estruturadas, tais como aplicações para a web, apresentações multimídia, quiosques, etc. O método OOHDM propõe as seguintes atividades para o processo de desenvolvimento de aplicações hipermídia: § Levantamento de Requisitos, § Projeto Conceitual, § Projeto de Navegação, § Projeto da Interface Abstrata e § Implementação. Essas atividades não seguem o modelo de desenvolvimento em cascata, mas sim, uma mistura de estilos iterativos, incrementais e de prototipação rápida. Em cada passo, um modelo é construído ou enriquecido e ao final do projeto, a aplicação hipermídia é implementada utilizando-se as informações obtidas durante todo o processo.

2.2.1 Levantamento de Requisitos A atividade de Levantamento de Requisitos apresenta as seguintes fases: identificação de atores e tarefas, especificação de cenários, especificação de usecases, especificação dos diagramas de interação com o usuário, validação dos use cases e diagramas de interação com o usuário. Na fase de identificação de atores e tarefas, o projetista interage com o domínio da aplicação para identificar atores e tarefas. Esta interação é alcançada através da análise de documentos disponíveis e entrevistas com os usuários. O principal objetivo é perceber e capturar as necessidades dos usuários. Um exemplo de ator para o domínio de vendas de CDs, apresentado posteriormente como

um dos exemplos dessa dissertação, é o cliente . Cliente é o usuário que compra CDs através de uma loja virtual. Algumas tarefas relacionadas ao ator cliente são: compra de um CD a partir de seu nome, compra de um CD a partir do nome de uma música e compra de um CD a partir do nome de um artista. Na fase de especificação de cenários, cada usuário especifica os cenários que descrevem as tarefas que ele deseja realizar no domínio em questão. Cenários são descrições narrativas de como a aplicação pode ser usada pelo usuário. O usuário pode descrever o cenário textualmente ou verbalmente. A seguir é apresentado um exemplo de cenário especificado por um usuário. Este cenário descreve um usuário comprando um CD baseado no nome de um artista. 11

Cenário: Comprar um CD a partir do nome de um artista. Entro com o nome do artista ou as iniciais dele (ex. Caetano ou Ca) e o sistema me retorna um ou mais artista que contém o nome informado. Então, eu seleciono o artista que eu quero e são apresentados os CDs do artista com a capa do CD ao lado. Se um dos CDs apresentados é o CD procurado, eu seleciono o CD e este é anexado à minha lista de compras. Seria desejável que o preço de cada CD também fosse apresentado. Eu posso comprar mais de um CD se eu desejar bastando clicar em mais de um. Na fase de especificação de use cases, o projetista especifica os use cases a partir dos cenários dos usuários. Um use case é uma forma de usar o sistema [Jacobson 1999]. Use cases tratam apenas a interação entre o usuário e a aplicação ou a informação visível ao usuário. A especificação de use cases requer o agrupamento de todos os cenários que têm uma mesma função. Assim, a descrição de um use case deve incluir a informação apresentada em todos os cenários relacionados. A seguir é apresentado um exemplo de um use case definido a partir da análise dos cenários que tratam a compra de um CD baseado no nome de um artista.

20

Use Case: Selecionar um CD baseado no nome do artista. Cenários: <lista dos cenários analisados> Descrição: 1. O usuário entra com todo ou parte do nome do artista e, se desejar, o ano ou período do CD procurado. 2. O sistema retorna uma lista de artistas que combinam com a entrada. Se existir somente um artista com aquele nome, é mostrada diretamente o conjunto de CDs (passo 4). 3. O usuário seleciona o artista procurado. 4. O sistema retorna uma lista de CDs do artista. Para cada CD é apresentado o nome, artista, ano, preço, disponibilidade e capa. 5. Se o usuário desejar, ele pode acessar mais informações de um CD (use case Mostrar CD). 6. Caso o usuário deseje comprar um ou mais CDs, ele seleciona o(s) CD(s) desejado(s) e inclui na lista de compras para mais tarde efetuar a compra (use case Comprar). 7. Se o usuário tiver interesse, ele pode retornar para o passo 5 para comprar outro CD do mesmo artista. Na fase de especificação dos diagramas de interação do usuário, os diagramas que representam os use cases são especificados. Um diagrama de interação do usuário representa a interação entre o usuário e a aplicação descrita textualmente em um use case. A interação representada descreve a troca de informações entre o usuário e o sistema, sem entrar em detalhes relativos à interface com o usuário. 12

[2..N artistas] [1 artista] 1 (mostrar CD) nome ou parte do nome do artista ano 1 (escutar trecho) nome do CD X Gênero, país, gravadora, etc. . Música (nome, tempo, artista, compositor, letra) nome do artista . CD (nome, artista, ano, preço, disponibilidade e capa) 1..N (inclusão na lista de compras nome do artista . Artista 1

Figura 2.5 . Diagrama de Interação do usuário

A figura 2.5 mostra o diagrama de interação do usuário do use case Selecionar um CD baseado no nome do artista. Na fase de validação dos use cases e dos diagramas de interação do usuário, o projetista interage com cada usuário para validar os uses cases e diagramas de interação do usuário.

2.2.2 Projeto Conceitual O projeto conceitual é a atividade responsável pela construção de um modelo do domínio da aplicação, utilizando os princípios da modelagem orientada a objetos, com o acréscimo de algumas primitivas, como perspectivas (múlt iplos tipos) de atributo e subsistemas (abstrações de um esquema conceitual completo). O modelo conceitual é definido a partir das descrições dos diagramas de interação do usuário dos use cases simples. Ele é composto por classes de objetos, atributos, relacionamentos, agregação e hierarquia de generalização/ especialização. O propósito principal dessa atividade é capturar a semântica do domínio, ou seja, engloba todo o universo de informações relevantes para a aplicação em questão, mesmo que apenas um subconjunto dessas informações venha a ser considerado posteriormente na sua implementação. O produto desta atividade é um esquema conceitual, representado segundo a notação descrita em [Vilain 1999]. Essa notação é similar a UML [UML 1997]. 13 CD nome: string

21

descrição: text ano_gravação: string preço: real disponibilidade: string capa: imagem procedência: string gravadora: string gênero: string local_gravação:string Música nome: string trecho: som tempo: string Pedido tipo_pgto: string forma_pgto: string transporte: string número: interger endereço_entrega: string preço_total: real prazo_entrega: real 1..*possui1..* 0..* possui 1..* Item num_cópias: integer 0..* grava 1..* Artista descrição: [text+, foto] ano_nascimento: string Cliente senha: string telefone: string endereço: string Pessoa nome: string e-mail: string compositor compõe 0..* 0..* intérprete interpreta trabalha com 0..* 0..* faz 1..* 1..* 1..*

Figura 2.6 . Esquema Conceitual para o domínio de vendas de CDs

A figura 2.6 mostra o esquema conceitual de uma aplicação para o domínio de vendas de CDs. A perspectiva é indicada através da enumeração dos tipos possíveis, com um símbolo +

ao lado do tipo default . Por exemplo, na classe artista o atributo descrição: [text+, foto] significa que o atributo descrição tem uma representação textual (sempre presente) e pode ter uma representação gráfica, contendo uma foto.

2.2.3 Projeto de Navegação No método OOHDM, uma aplicação é vista como uma visão navegacional sobre o esquema conceitual, possibilitando que diferentes modelos de navegação sejam construídos sobre o mesmo domínio da aplicação, de acordo com o perfil dos usuários e tarefas que eles irão desempenhar [Moura 1999]. O projeto de navegação é a atividade responsável pela definição da estrutura de navegação de uma aplicação hipermídia, que é composta por: classes navegacionais, elos, âncoras, estruturas de acesso, contextos de navegação e classes em contexto. Os produtos desta atividade são: o esquema navegacional, o esquema de contextos de navegação e os cartões de especificação de contextos e estruturas de acesso. Um esquema navegacional define o conjunto de classes navegacionais (ou nós) e elos que fazem parte de uma visão navegacional da aplicação. As classes navegacionais são vistas como uma visão das classes conceituais, uma vez que uma classe navegacional pode não ter todo o conteúdo de informação de uma classe conceitual, ou pode unir conteúdos de mais de uma classe conceitual. A figura 2.7 ilustra o esquema navegacional de uma aplicação para

22

o domínio de vendas de CDs. 14 CD nome: string descrição: text ano_gravação: string preço: real disponibilidade: string capa: imagem gravadora: string músicas: list of <nome:string> gênero: string ind_artista: Idx (Artista por CD) grava 0..* trabalha com Artista nome: string descrição: text foto: imagem ano_nascimento: string ind_cds: Idx (CD por Artista) 1..* 0..* 0..*

Figura 2.7 . Esquema Navegacional para o domínio de vendas de CDs

Dependendo da tarefa a ser realizada, o usuário pode navegar por diferentes conjuntos de

objetos de classes navegacionais chamados de contextos de navegação . Por exemplo, o usuário poderia navegar pelos CDs dos Beatles ou pelos CDs de Rock lançados este ano. Um contexto de navegação é um conjunto de objetos (nós, elos e outros contextos de navegação) que estão relacionados de acordo com algum aspecto. A definição de um contexto inclui: os elementos pertencentes ao contexto; a especificação da navegação entre esses elementos; o ponto de entrada do contexto; as restrições de acesso; e as estruturas de acesso (índices) associadas ao contexto. O OOHDM classifica os contextos de navegação da seguinte forma:

§ contexto simples: inclui todos os elementos de uma classe que satisfazem uma

determinada propriedade (derivado de classe), ou todos os objetos relacionados a

um dado objeto (derivado de elo ). Por exemplo, o contexto .CDs gravados no ano 1990. é um contexto simples derivado de classe, e o contexto .CDs gravados pelos Beatles. é um contexto simples derivado de elo.

§ grupo de contexto : é um conjunto de contextos simples, que podem ser contextos derivados de classe ou derivados de elo. No grupo de contextos derivados de classe, a propriedade definidora de cada contexto é parametrizada. Por exemplo,

no contexto .CDs por ano. a propriedade ano_gravação pode variar. Já no grupo de contextos derivados de elo, cada contexto do grupo é obtido variando o

elemento origem do elo. Por exemplo, .CDs por artista. (o artista varia).

§ contexto arbitrário : neste tipo de contexto, os elementos são escolhidos explicitamente pelo autor do contexto, podendo ser elementos que pertencem a classes navegacionais diferentes. Os roteiros guiados são exemplos deste tipo.

§ contexto dinâmico : é um contexto cujos elementos são definidos ou alterados em tempo de execução. Podemos utilizar este tipo de contexto para criação, modificação ou exclusão das instâncias de uma classe navegacional. Histórico de navegação e cesta de compras são exemplos deste tipo. Um tipo especial de

contexto dinâmico é o contexto baseado em sessão (ou temporário), que só existe durante a sessão de navegação. Representação gráfica para os tipos de contexto: Contexto Simples ou Grupo de Contextos Contexto Dinâmico Contexto com Orden ação Múltipla Contexto de Criação de Instâncias 15

Para todos tipos de contexto descritos acima pode haver uma estrutura de acesso definida. As estruturas de acesso são índices que permitem o acesso ao contexto. Elas são

23

representadas graficamente da seguinte forma: Índice Simples Índice Dinâmico Índice com Ordenação Múltipla A especificação da navegação entre os elementos do contexto define como será a navegação dentro do contexto, caracterizando a forma como se pode percorrer os elementos de um dado contexto. Quando um usuário entra num dado contexto de navegação, o tipo de trilhas navegacionais que ele pode seguir dependerá da natureza do contexto e do tipo de especificação que for feita. Por exemplo, podemos fornecer âncoras (e elos de contextos correspondentes), permitindo o acesso ao nó seguinte (ou anterior) no contexto. Em alguns contextos, pode-se oferecer acesso somente ao índice, tendo o usuário que escolher outro item do índice para prosseguir a navegação. Os tipos de navegação interna ao contexto definidos pelo OOHDM são:

§ navegação seqüencial: após a entrada no contexto, o usuário pode navegar por todos os elementos do contexto seguindo uma ordem seqüencial e pré- estabelecida de navegação. São definidos os conceitos de primeiro, último, próximo e anterior para os elementos do contexto;

§ navegação circular: os elementos podem ser vistos como se estivessem dispostos em uma lista circular. Unicamente são definidos os conceitos de próximo e anterior;

§ navegação limitada ao índice: a navegação é feita apenas do índice para um elemento do contexto e vice-versa. Não existe a possibilidade de navegação entre os outros elementos do contexto, a não ser através do índice de entrada do contexto;

§ combinação da navegação por índice e seqüencial: os elementos do contexto podem ser acessados indistintamente por índice ou através das âncoras .Anterior. e .Próximo.;

§ navegação livre: todos os elementos do contexto podem ser acessados diretamente a todo momento, não havendo a necessidade de se percorrer nenhum caminho pré-determinado para atingir um dado elemento. A estrutura navegacional da aplicação é definida no esquema de contextos, que mostra todas as estruturas de acesso e contextos definidos para a aplicação, e as possíveis navegações entre eles. 16 Alfabético CD Menu Principal por Artista Favoritos

Anos por Ano por Consulta por Promoção Alfabético Artista por CD Artistas CDs Músicas por Música Criação

Figura 2.8 . Esquema de Contextos para o domínio de vendas de CDs

A figura 2.8 mostra o esquema de contextos de navegação de uma aplicação para o domínio

de vendas de CDs. O pequeno retângulo preto no canto superior esquerdo do contexto .CDs por Artista. representa um índice associado a este contexto. A seta com um círculo em uma

das extremidades que aparece no lado esquerdo do contexto .Favoritos. representa o

.design pattern. landmark [Rossi 1999], indicando que um contexto ou um índice pode ser acessado em qualquer local da aplicação. Já a pequena elipse associada ao contexto

.Criação. indica que o acesso a esse contexto é protegido, ou seja, somente usuários com permissão poderão acessá-lo. Os contextos de navegação e as estruturas de acesso são especificadas utilizando-se os

cartões de especificação . As propriedades mais relevantes para caracterizar um contexto de

24

navegação são: os elementos que compõem o contexto; a ordenação desses elementos; os pontos de entrada do contexto; e a navegação entre os elementos do contexto. Para uma estrutura de acesso, as propriedades mais importantes a especificar são: os seletores (atributos que são âncoras na estrutura); os demais atributos exibidos na estrutura; a ordenação dos elementos na estrutura; e o destino da estrutura de acesso (pode ser um contexto ou outra estrutura de acesso). As classes navegacionais podem apresentar características específicas dentro de diferentes

contextos de navegação. Por exemplo, se um CD é acessado no contexto .CDs por Ano., o nó CD exibe também a foto e um resumo da biografia do artista que gravou o CD. Se este

mesmo CD é acessado no contexto .CDs por Artista. essa informação não é exibida. Por esta 17

razão, classes em contexto são definidas para representar as características específicas que um objeto pode apresentar dentro de um contexto particular. As classes em contexto são classes especiais que decoram os nós, permitindo que um mesmo nó tenha uma aparência diferente e apresente âncoras e funcionalidades distintas quando é mostrado em um contexto específico. Classes em contexto também são utilizadas para especificar os atributos com múltiplas perspectivas, que não possuem uma perspectiva default, definidos no modelo conceitual. Cada perspectiva do atributo deve ser mapeada para um atributo em uma classe em contexto.

2.2.4 Projeto da Interface Abstrata O projeto da interface abstrata especifica como os objetos de navegação serão percebidos e apresentados. Especifica, também, os objetos de interface que representam as interações. Esta atividade é desenvolvida antes de iniciar a implementação e de forma independente do ambiente de implementação. Entretanto, deve considerar também algumas características do ambiente para que possa ser implementado. O OOHDM utiliza Abstract Data View (ADV), diagramas de configuração e ADVCharts para especificar o projeto da interface abstrata.

2.2.5 Implementação A atividade de implementação é a última atividade proposta pelo método OOHDM e é responsável pela tradução do projeto da aplicação para um ambiente de implementação. Se a aplicação for implementada na Web, o ambiente OOHDM-XWeb proposto neste trabalho pode ser utilizado. O ambiente OOHDM-XWeb é composto por um programa chamado OOHDM-Translation e pelo sub-ambiente OOHDM-Web 2.0. Ele permite a geração automática da descrição do projeto OOHDM de uma aplicação hipermídia para o ambiente OOHDM-Web 2.0, utilizando o documento XML que contém a especificação declarativa do projeto, definida utilizando-se a linguagem OOHDM-ML.

2.3 A DTD OOHDM-ML Nesta seção, descrevemos a DTD OOHDM-ML, que contém as regras que devem ser obedecidas na criação de documentos XML para a especificação declarativa do projeto OOHDM de aplicações hipermídia. A DTD OOHDM-ML se encontra listada no apêndice I e em [Medeiros 2001] pode ser encontrada a especificação completa e detalhada da linguagem OOHDM-ML, que contém a descrição de todos os elementos e atributos definidos nesta DTD.

2.3.1 Especificação da Linguagem OOHDM-ML Um documento XML, criado utilizando-se a linguagem OOHDM-ML, é sempre formado por

um elemento raiz denominado OOHDM. Este elemento contém todas as marcações que representam a especificação declarativa de uma aplicação hipermídia, projetada de acordo com as primitivas do método OOHDM. Seu conteúdo é formado por um elemento

OOHDM_BASE e por um elemento opcional OOHDM_WEB. A figura 2.9 ilustra o conteúdo do elemento raiz OOHDM e um exemplo de sua definição na DTD.