OOHDM - Object Oriented Hypermedia Design Method

1. Introdução

O OOHDM foi criado em 1994 por Schwabe & Rossi e tem se

mostrado eficiente na redução de agravantes como a dificuldade de

manutenção e reusabilidade em relação à construção de sistemas hipermídia,

além de ter atingido uma boa popularidade dentre os modelos de

desenvolvimento de aplicações sendo que o modelo produzido pelo OOHDM

pode ser implementado em qualquer tipo de ambiente de desenvolvimento

disponível no mercado, seja este orientado a objeto ou não (HENNRICHS,

2005).

E, para que se torne mais acessível essa teoria é bom que se

conheça alguns conceitos básicos em torno desse método.

2. Conceitos Básicos

Inicialmente, torna-se importante segundo Oliveira et al.

(2002), uma visão mais específica de alguns conceitos, tais como:

• Hipertexto: sistema ou aplicativo que permite criar, manter e manipular

trechos de informação (texto e gráficos) interligados de forma não-seqüencial

ou não-linear;

• Nós: trechos de informação correspondentes a uma parte de um documento

de hipermídia ou de hipertexto.

• Elos: ligação entre dois nós. A ativação de um elo invoca o nó de destino de

seu relacionamento.

• Hiperdocumento: rede de nós e elos. Uma aplicação pode ser composta por

um ou mais hiperdocumentos relacionados.

• Âncoras: estrutura de ativação de um elo (normalmente botões).

• Estruturas de Acesso: menus ou índices hierárquicos que permitem ao

usuário o desvio do fluxo principal de idéias ou ainda roteiros, podendo ser pré-

definidos ou não.

Segundo Oliveira et al. (2002), modelos como HDM, EORM e

RMM tendem a ignorar o projeto de navegação e da interface do usuário. Além

disso, não podem ser utilizados em domínios “dinâmicos” , como os sistemas

de apoio à decisão, ambientes de engenharia de programas e aplicações

educacionais modernas.

Daí a opção pela modelagem OOHDM para o trabalho proposto

e ainda apresentar a modelagem citada como alternativa às falhas identificadas

nos demais modelos.

Magalhães (2002) comenta, a seguir, as partes constituintes do

método não esquecendo a necessidade de se fazer uma boa análise de

requisitos, ou seja, obter o máximo possível de informações sobre o domínio da

aplicação em voga. É tarefa também da elicitação, identificar os fatos que

compõem os requisitos do sistema, de maneira a prover o entendimento

correto e completo do software a ser desenvolvido.

3. Modelagem Conceitual

A modelagem conceitual ou de domínio destina-se à

compreensão do domínio problema e à construção de modelos adequados

deste domínio, enquanto o projeto lida com abstrações no universo do software

e tende a maximização da modularidade e do reuso. O modelo do projeto é

independente da implementação no sentido em que, embora possa levar em

consideração algumas configurações de implementação, não é condicionado

por um ambiente de implementação em particular.

Ela tem por objetivo a construção de um esquema contendo

classes, objetos, relacionamentos e subsistemas existentes para o domínio

especificado. A descrição de classes segue a notação da orientação a objetos,

mas seus atributos podem ser multi-tipados, representando assim diferentes

perspectivas da mesma entidade real. E Agregação e

Generalização/Especialização são utilizadas para aumentar o poder de

abstração do sistema (MAGALHÃES, 2002).

Figura 01 : Exemplo de esquema conceitual. Fonte: SCHWABE, 1998.

Figura 02 : Exemplo de objeto. Fonte: Schwabe, 1998.

3.1 Esquema Conceitual de Classes

O diagrama resultante da modelagem conceitual, segunda

etapa do OOHDM, é designado de Esquema Conceitual. No esquema

conceitual estão representadas todas as classes e relacionamentos do domínio

da aplicação, bem como também todos os mecanismos de refinamento

descritos nesta etapa da modelagem (HENNRICHS, 2005).

A ilustração abaixo exibe a modelagem conceitual de uma

aplicação hipermídia denominada de RMS Titanic! A compilação de uma

tragédia. Observe que foi descrito no esquema o diagrama do objeto abertura,

relacionado com a classe Menu Principal.

Figura 03: Esquema Conceitual da aplicação RMS Titanic! A compilação de uma tragédia (HENNRICHS, 2000)

4. Modelagem Navegacional

Os aplicativos de hipermídia são projetados para realizar

navegação através de um espaço de informação. Por isso, o projeto da

estrutura de navegação de tais aplicativos é uma etapa crucial no

empreendimento do desenvolvimento. O OOHDM propõe a construção de um

modelo navegacional compartilhado no qual focalizam-se os objetos e

relacionamentos do domínio.

Dentro do Projeto Navegacional, estabelecesse as estratégias

de navegação bem como as visões que um determinado usuário terá ao

navegar pela aplicação. Ao projetar a estrutura de navegação de um aplicativo

de hipermídia serão considerados aspectos como:

Que objetos serão navegados e que atributos possuem? Quais os

relacionamentos entre estes objetos e aqueles definidos no esquema

conceitual? Isto será feito pela definição de nós e elos como visões

orientadas a objetos das classes e relacionamentos conceituais.

Qual é a estrutura subjacente de navegação? Em que contextos o usuário

irá navegar? Apresenta-se o conceito de contexto navegacional que é uma

primitiva arquitetônica para a organização do espaço de navegação.

É preciso decidir se os objetos navegados poderão ter aparências

diferentes de acordo com o contexto em que são visitados e especificar tais

diferenças claramente. Usam-se classes de contexto para decorar os

objetos navegacionais.

Quais são as estruturas de navegação existentes entre os objetos que

serão navegados (elos, caminhos, índices, roteiros guiados, etc.)?

Como procede a navegação quando o usuário pula de um assunto para

o outro, isto é, qual o efeito da navegação nos objetos de origem e destino

e, talvez em outros objetos relacionados? (MAGALHÃES, 2002).

O bloco básico para a noção de navegação é o “nó”, e neste

caso são as classes navegacionais. Estas classes são derivadas das classes

conceituais através do mapeamento dos atributos existentes e se acrescentado

novos atributos, como, por exemplo, âncoras. Apesar de não ser comum, uma

classe navegacional pode conter atributos de mais de uma classe conceitual.

O atributo do tipo “Âncora” é considerado uma classe primitiva

cujo parâmetro é um tipo de elo associado (link). Estes elos podem ser

considerados estruturais define-se um relacionamento entre membros de uma

composição ou agregação, ou considerados de perspectiva se relacionam duas

classes derivados uma mesma classe conceitual (semelhante ao HDM). O

conjunto das classes de nós e elos definidos são chamados de esquema de

classes navegacionais (SCHWABE; ROSSI, 1994).

Dentro do projeto navegacional são desenvolvidas as seguintes

atividades: O esquema das classes navegacionais e o esquema de contextos

navegacionais.

4.1 Classes Navegacionais e Estruturas de Acesso

Quando uma aplicação hipermídia é muito extensa, se torna

interessante a definição de estruturas de acesso. De acordo com Magalhães

(2002), pode-se especificar as estruturas de acesso como classes, pois se

pode dar uma semântica mais precisa de seus comportamentos e estruturas

(pode ser uma linha do tempo, um dicionário). Além de ainda se poder construir

hierarquias de estruturas de acesso, aumentando assim o poder de

modelagem e reutilização.

As estruturas de acesso são um tipo específico de nós, onde as

âncoras são definidas por seletores e os elos para objetos destino são

definidos implicitamente. O predicado expressa quais objetos serão acessíveis

em termos de suas propriedades. Seletores usualmente esperam por algum

atributo dos objetos de destino. Em ambos os casos eles tem que ser

mencionados explicitamente na definição das estruturas de acesso. As

estruturas de acesso funcionam como índices ou dicionários, e ajudam o

usuário final a encontrar a informação desejada.

A idéia de Classe Navegacional é usada como um formalismo

para expressar contextos navegacionais e suas semânticas, representando os

nós, elos e outros artefatos de design. “Nós” possuem atributos, âncoras para

elos e estruturas de acesso. Elos contêm informações sobre os elos de origem

e destino, seus próprios atributos e comportamento. Classes navegacionais

são organizadas em hierarquias e definem contextos para a navegação na

aplicação.

As classes navegacionais são usadas para se definir objetos

navegáveis, e também para representar estruturas de acesso, browsers e

outros tipos de facilidades de navegação não definidas previamente, assim

como as interfaces de consultas. Elas enriquecem o modelo e fornecem uma

transição tranqüila do design de baixo nível, onde os aspectos da interface são

definidos, até a implementação.

O esquema navegacional é derivado do esquema conceitual

através de um conjunto de mecanismos de definição de visões. No entanto,

muitos aplicativos podem exibir um esquema navegacional muito similar ao

esquema conceitual, devido, por exemplo, à simplicidade do domínio ou às

semelhanças entre as tarefas desempenhadas por diferentes tipos de usuários.

Em tais casos, ambos os esquemas podem fundir-se em um

único esquema navegacional. O esquema das classes navegacionais mostra

os relacionamentos entre os objetos navegacionais.

4.2 Contextos Navegacionais

Qualquer aplicativo hipermídia bem projetado deve levar em

conta o modo como o usuário explora o espaço hipermídia.

O contexto navegacional é um conjunto de nós, elos e outros

contextos navegacionais. Inclui, também, um caminho pré-definido entre seus

elementos e o esquema do contexto navegacional mostra a navegação em

geral.

Os contextos também ordenam os objetos, dando significado à

“próximo” e “anterior”, e diferentes tipos de contexto são definidos a partir de

classes e de elos. Mas, além das classes conceituais e navegacionais (nós e

elos), podem surgir outras devido aos contextos nos quais a aplicação irá

enriquecer o esquema das classes navegacionais. Estas classes especiais

(chamadas classes de contexto) permitem que um nó tenha uma aparência

diferente e apresente âncoras distintas quando navegado em um contexto

específico (SCHWABE; ROSSI, 1994).

A idéia de contexto esta relacionada com a noção de coleções

de objetos ou tema abordado que interessam para um determinado domínio da

aplicação. Estes contextos podem ter atributos (informações sobre o contexto),

mais de uma entrada, caminhos conectando seus elementos, um

comportamento específico, a especificação dos elementos visíveis, além do

relacionamento com outros contextos.

Em muitas situações pode-se precisar complementar as

informações básicas dos nós com informações específicas do contexto que se

está navegando, surgindo assim a classe de contexto (CC). Estas classes de

contexto são definidas como sendo um complemento da especificação das

classes navegacionais (NC) e adicionam atributos ao objeto, da mesma forma

que as classes conceituais, (SCHWABE; ROSSI, 1994).

A seguir serão mostradas algumas formas que os Contextos

Navegacionais podem ser representados, no qual cada autor escolhe a que

melhor se encaixar dentro do seu projeto.

Figura 04 - Quadro: Exemplo de cartão de contexto. Fonte: SCHWABE, 1998.

- índice hierárquico

Figura 05: Exemplo de diagrama de contexto. Fonte: SCHWABE, 1998.

- contexto de navegação dinâmico

- Índice de navegação dinâmico

Figura 06: Exemplo de navegação por orientação. Fonte: SCHWABE, 1998.

5. Modelo de Interface Abstrata

A construção de uma interface hipermídia é um aspecto crítico

da criação de um programa aplicativo hipermídia. Para especificar um modelo

abstrato de interface é necessário definir metáforas de interface e descrever

suas propriedades estáticas e dinâmicas e seus relacionamentos com o

modelo navegacional de uma forma independente de implementação. Para isto

é necessário especificar:

a aparência de cada objeto navegacional que será percebido pelo usuário,

isto é, a representação de seus atributos (incluindo as âncoras). O mesmo

objeto navegacional pode ter diferentes representações de interface em

diferentes situações. Por exemplo, um nó pode ter a representação de uma

fotografia de um monumento ou a de um ícone em um mapa que atue como

um índice para monumentos.

outros objetos de interface para oferecer as diversas funções do aplicativo,

como barras de menus, botões de controle e menus.

os relacionamentos entre os objetos de interface e navegacionais, tais como

o modo com que um evento externo, como o fato de o usuário "clicar" o

mouse afetará a navegação.

as transformações de interface que ocorrem pelo efeito da navegação ou de

eventos externos no computador de diferentes objetos de interface.

e finalmente, a sincronização de alguns objetos de interface deve ser

considerada, especialmente quando há meios dinâmicos, como áudio e

vídeo envolvidos.

5.1 Visão Abstrata do Dado (ADV)

Visão Abstrata do dado (ADVs) são classes de interface

utilizadas para especificar a aparência de objetos da aplicação. O modelo ADV

foi originalmente criado para especificar formalmente a separação da interface

do usuário da aplicação e proporcionar principalmente um método de projeto

independente do ambiente e com elevado grau de reuso. ADVs são abstratos e

somente representam a interface e o seu estado, não a implementação. Dessa

forma, em uma aplicação que faça uso de ADVs, há também um conjunto de

ADOs gerenciando estruturas de dados e controle dentro da aplicação, e um

conjunto de objetos de interface (instâncias de ADVs) gerenciando aspectos de

interface do aplicativo, tais como entrada de usuário e saída do sistema ao

usuário.

Um ADO (objeto de dados abstrato, neste caso refere-se aos

objetos do modelo navegacional) possui um ou mais ADVs que representam

algum aspecto de seu estado. Estes dois tipos de relacionamentos são

chamados, respectivamente, de consistência vertical e horizontal como se pode

perceber por meio da figura 08 (SCHWABE, 1998).

Figura 08: ADVs e ADOs

Essa figura demonstra a relação entre ADVs e ADOs. Como os

ADVs fazem o papel de interface com o usuário mas não contém a informação

propriamente dita, eles necessitam dos ADO, que possuem a informação mas

não suportam eventos externos vindos do usuário. Sendo assim, há um

relacionamento horizontal entre os ADVs de um mesmo ADO e um

relacionamento Vertical entre um ADO e seus ADVs. Quando um evento é

solicitado à aplicação por meio de um ADV, este mapeia de seu ADO a

informação solicitada e a entrega ao usuário.

Em OOHDM, objetos navegacionais como os nós, elos ou

estruturas de acesso, agirão como ADOs e os ADVs associados serão

utilizados para especificar suas aparências para o usuário ( HENNRICHS,

2000).

Um ADV contém atributos que definem suas propriedades de

percepção e o conjunto de eventos com os quais pode lidar. Pode-se definir

constantes, para um estilo específico de aparência como posição, cor ou som.

Uma variável reservada, "contexto Perceptivo", é usada para indicar

modificações no espaço perceptivo. E a composição desse ADV é percebida

através da figura a seguir:

Figura 09 : Composição de ADV. Fonte: HENNRICHS, 2000

E, observando a figura abaixo, verifica-se um exemplo de ADV,

oferecendo uma estrutura poderosa para a definição de hierarquias de objetos

de interface, que mostra o uso de herança (SCHWABE; ROSSI, 1994).

Figura 10: Herança em ADV

Aplicação

TextoAncorado ( e um texto)

Âncoras (Âncora )

Botão 1 Botão 2

ADVPintura

ADVImagem

ADVTexto ADVBotão

Em OOHDM usa-se um formalismo visual baseado em

máquinas de estado que suporta a especificação gráfica de projetos baseados

em ADV. (SCHWABE; ROSSI,1994).

6. Implementação

É a última etapa do processo de construção de aplicativos

hipermídia. O sistema hipermídia a ser executado é produzido após o

mapeamento do design abstrato da interface (os objetos perceptíveis e suas

transformações) em objetos de interface concretos (escolhidos no ambiente de

implementação).

E, para que se tenha uma boa aplicação multimídia é

necessário utilizar um software de autoria.