2009

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.

Carlos Alan Peres

UFCG
10/10/2009
1) Metodologia MOEBUS
I. Diagnóstico - documentação do contexto em que se insere a demanda e a empresa
como um todo.
O artefato final desta
a) Estudo de Key-elements ou elementos chaves – etapa é o Documento de
esmiuçar o público-alvo, mercado, produto (o Diagnóstico e o prazo de
que a empresa oferece) e concorrência. Em realização da mesma é
seguida mapeia-se as demandas do público um período
compreendido entre 6 e
alvo para, finalmente levantar os processos
10 dias;
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.
O artefato final é o Documento de
Prognóstico e o prazo de conclusão é
a) Objetivos – definição dos entre 20 e 40 dias.
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.

Artefatos Documentos de
Status. Prazo de
a) Produção - colocar em prática tudo que foi conclusão entre 10 e 30
traçado no Prognóstico o que faz desta dias.
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.

2
 IV. Monitoramento pró-ativo – medição
dos dados e estruturação de ações Artefato, Documento de
para a otimização do projeto. Monitoramento. Prazo médio semanal
ou mensal.

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

3
 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

4
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

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

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

7
 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

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

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

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

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

12
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

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

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

15
 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

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

17
Figura 4. Modelo navegacional para AutoLopes Multimarca

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

19
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

20
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

21
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

22
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

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

24