Metodologia OOHDM
-
Upload
gustavo-almeida -
Category
Documents
-
view
133 -
download
6
Transcript of Metodologia OOHDM
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.