10.

1 The OOHDM approach An Overview

The Object-Oriented Hypermedia Design Method (OOHDM) is a model-based approach to the
development of Web applications. OOHDM uses different abstraction and composition
mechanisms in an object oriented framework to, on one hand, allow a concise description of
complex infor-mation items, and on the other hand, allow the specification of complex
navigation patterns and interface transformations.
OOHDM provides a clear roadmap that allows answering the following key questions, gener-ally
asked when building Web applications:
What constitutes an information unit with respect to navigation?
How does one establish what are the meaningful links between information units?
How does one organise the navigation space, i.e., establish the possible sequences of
information units the user may navigate through?
How will navigation operations be distinguished from interface operations and from data
processing (i.e., application operations)?
In OOHDM, a hypermedia application is built in a five-step process supporting an incremental or
prototype process model. Each step focuses on a particular design concern, and an object-
oriented model is built. Classification, aggregation and generalisation/specialisation are used
throughout the process to enhance abstraction power and reuse opportunities.
Table 10.1 summarises the steps, products, mechanisms and design concerns in OOHDM.

10.1.1 Requirements Gathering

The first step during requirements gathering is to gather stakeholders requirements. To achieve
this, it is necessary to first identify the actors (stakeholders) and the tasks they must perform.
Next, scenarios are collected (or Model-Based Web Application Development 305 drafted), for
each task and type of actor. The scenarios are then used to form use cases, which are
represented using User Interaction Diagrams (UIDs).
These diagrams provide a concise graphical representation of the interaction between the user
and the system during the execution of a task. UIDs are validated with the actors, and
redesigned if necessary. In sequence, a set of guidelines are applied to the UIDs to extract a
conceptual model. Details about UIDs can be found in [9].

10.1.2 Conceptual Design

During the conceptual design, an application domains conceptual model is built using object-
oriented modelling principles, augmented with primitives, such as attribute perspectives
(multiple valued attributes, similar to HDM perspectives). Conceptual classes may be built using
aggregation and generalisation/specialisation hierarchies. There is no concern for the types of
users and tasks, only for the application domain semantics. A conceptual schema is built out of
sub-systems, classes and relationships. OOHDM uses UML (with slight extensions) for
expressing the conceptual design.

10.1.3 Navigational Design

In OOHDM, an application is seen as a navigational view over the conceptual model. This
reflects a major innovation of OOHDM, which recognises that the objects (items) the user
navigates are notthe conceptual objects, but objects that are built from one or more
conceptual objects.
For each user profile we can define a different navigational structure, which will reflect objects
and relationships in the conceptual schema according to the tasks a user must perform. The
navigational class structure f a Web application is defined by a schema containing navigational
classes. In OOHDM, there is a set of pre-defined types of navigational classes: nodes, links,
anchors and access structures. The semantics of nodes, links and anchors are as usual in
hypermedia applications. Nodes in OOHDM represent logical windows (or views) on
conceptual classes, defined during conceptual design. Links are the hypermedia realisation of
conceptual relationships, as well as task-related links. Access structures, such as indexes,
represent possible ways to start a navigation.
Different applications (in the same domain) may contain different linking topologies according to
a users profile. For example, in an academic Web application we may have a view to be used
by students and researchers, and another view for use by administrators. In the second view, a
professor's node may contain salary information, which would not be visible in the students
view.
The main difference between our approach and others, in relation to object viewing
mechanisms, is that while others consider Web pages mainly as user interfaces built by
observing conceptual objects, we favour the explicit representation of navigational objects
(nodes and links) during design.
The navigational structure of a Web application is described in terms of navigational contexts,
which are generated from navigation classes, such as nodes, links, indices and guided tours.
Navigational contexts are sets of related nodes that possess similar navigation alternatives
(options), and that are meaningful for a certain step in a task pursued by a user. For example,
we can model the set of courses in a semester, the paintings of a painter, the products in a
shopping cart, etc.

10.1.4 Abstract Interface Design

The abstract interface design defines perceptible objects (e.g. a picture, a city map) in terms of
interface classes. Interface classes are aggregations of primitive classes (e.g. text fields,
buttons) and, recursively, of other interface classes. Interface objects are mapped to
navigational objects in order to have a perceptible appearance. An interface behaviour is
defined by specifying how to handle external and user-generated events, and how the
communication between interface and navigational objects is to take place.

10.1.5 Implementation
Implementation maps interface and navigation objects to implementation
objects, and may involve elaborated architectures (e.g. clientserver), in
which applications are clients to a shared database server containing con-
ceptual objects. A number of CD-ROM-based applications, as well as Web
applications, have been developed using OOHDM, and employing numer-
ous technologies, such as Java (J2EE), .NET (aspx), Windows (asp), Lua
(CGILua), ColdFusion and Ruby (RubyOnRails).
An open source environment for OOHDM, based on a variation of Ruby
on Rails, is available at:
http://server2.tecweb.inf.puc-rio.br:8000/projects/hyperde/trac.cgi/wiki.
10.1 a abordagem OOHDM viso geral
O mtodo de Design de Hipermdia orientada a objetos (OOHDM) uma abordagem baseada
em modelo para o desenvolvimento de aplicaes Web. OOHDM usa diferente abstrao e
mecanismos de composio em um quadro de objeto orientado para, por um lado, permitem
uma descrio concisa dos itens complexos informao e por outro lado, permitem a
especificao de padres complexos de navegao e as transformaes da interface.
OOHDM fornece um roteiro claro que permite responder as seguintes questes-chave,
Gonalves de Sousa-aliado perguntou ao criar aplicativos da Web:
O que constitui uma unidade de"informao" no que diz respeito a navegao?
Como que se estabelecer quais so as conexes significativas entre unidades de
informao?
Como que se organizar o espao de navegao, ou seja, estabelecer as possveis
sequncias de unidades de informao, o usurio pode navegar atravs de?
Operaes de navegao de vontade como distinguir-se de operaes de interface e de
"processamento de dados" (ou seja, operaes de aplicao)?
Em OOHDM, um aplicativo de Hipermdia construdo em um processo de cinco etapas,
apoiando um incremental ou o modelo de processo do prottipo. Cada passo concentra-se em
uma preocupao particular do projeto e um modelo orientado a objeto construdo.
Classificao, agregao e generalizao/especializao so usados durante todo o processo
para aumentar o poder de abstrao e reutilizao de oportunidades.
10.1 tabela resume as etapas, produtos, mecanismos e preocupaes de projeto em OOHDM.

10.1.1 requisitos Gathering

A primeira etapa durante o levantamento de requisitos reunir requisitos de partes
interessadas. Para conseguir isso, necessrio primeiro identificar os atores (stakeholders) e
as tarefas que devem desempenhar. Em seguida, cenrios so coletados (ou desenvolvimento
de aplicativos de Web baseados em modelo 305 elaborado), para cada tipo de ator e tarefa. Os
cenrios so usados para casos de uso do formulrio, que so representados usando
diagramas de interao do usurio (UIDs).
Esses diagramas fornecem uma representao grfica concisa da interao entre o usurio e o
sistema durante a execuo de uma tarefa. UIDs so validadas com os atores e remodelados
se necessrio. Na sequncia, um conjunto de orientaes so aplicadas para as UIDs para
extrair um modelo conceitual. Detalhes sobre UIDs podem ser encontrados em [9].

10.1.2 projeto conceitual

Durante o projeto conceitual, modelo conceitual de um domnio aplicativo construdo usando
princpios, aumentados com primitivos, tais como perspectivas de atributo (atributos valorizados
mltiplas, semelhantes a perspectivas HDM) de modelagem orientada a objeto. Classes
conceituais podem ser construdas usando hierarquias de agregao e
generalizao/especializao. No h nenhuma preocupao com os tipos de usurios e
tarefas, somente para a semntica do domnio de aplicativo. Uma esquema conceitual
construda de subsistemas, classes e relaes. OOHDM usa UML (com pequenas extenses)
para expressar o projeto conceitual.

10.1.3 navegao Design

Em OOHDM, um aplicativo visto como um modo de exibio navegao sobre o modelo
conceitual. Isto reflecte uma grande inovao da OOHDM, que reconhece que os objetos
(itens) que o usurio navega so objetos conceituais no a, mas objetos que so
"construdos" de um ou mais objetos conceituais.
Para cada perfil de usurio podemos definir uma estrutura de navegao diferente, o que ir
refletir objetos e relacionamentos no esquema conceitual de acordo com as tarefas que um
usurio deve executar. A estrutura de navegao classe f um aplicativo da Web definido por
uma esquema contendo classes navegacionais. Em OOHDM, h um conjunto de tipos
predefinidos de classes navegacionais: ns, estruturas de links, ncoras e acesso. A semntica
de ns, links e ncoras como de costume em aplicaes hipermdia. Ns em OOHDM
representam lgico "windows" (ou vistas) em classes conceituais, definidas durante o projeto
conceitual. Os links so a realizao de hipermdia de relaes conceituais, bem como links
relacionados tarefa. Estruturas de acesso, tais como ndices, representam possveis
maneiras de iniciar uma navegao.
Aplicaes diferentes (no mesmo domnio) podem conter diferentes topologias de vinculao
de acordo com o perfil de um usurio. Por exemplo, em um aplicativo Web acadmico talvez
tenhamos uma viso a ser usado por estudantes e investigadores e outra vista para utilizao
pelos administradores. Na segunda viso, n do professor pode conter informaes de salrio,
que no esto visveis na exibio do aluno.
A principal diferena entre a dos outros e a nossa abordagem em relao ao objeto
visualizao mecanismos, que, enquanto outros consideram pginas Web principalmente
como interfaces de usurio, construdas pela "observao" objetos conceituais, favorecemos a
representao explcita de objetos navegacionais (ns e links) durante o projeto.
A estrutura de navegao de um aplicativo Web descrito em termos de contextos
navegacionais, geradas a partir de classes de navegao, como ns, links, ndices e visitas
guiadas. Contextos de navegao so conjuntos de ns relacionados que possuem alternativas
de navegao semelhante (opes), e que so significativos para uma certa etapa em uma
tarefa, perseguida por um usurio. Por exemplo, podemos modelar o conjunto de cursos em
um semestre, as pinturas de um pintor, os produtos em um carrinho de compras, etc.

10.1.4 abstract Interface Design

O design de interface abstrata define objetos perceptveis (por exemplo, uma imagem, um
mapa da cidade) em termos de classes de interface. Classes de interface so agregaes de
primitivas (por exemplo, campos de texto, botes) e classes, recursivamente, de outras classes
de interface. Objetos de interface so mapeados para objetos de navegao a fim de ter uma
aparncia perceptvel. Um comportamento de interface definido especificando como
identificador externo e eventos gerados pelo usurio, e como a comunicao entre a interface e
navegao objetos tomar lugar.

10.1.5 implementao
Implementao mapeia objetos de interface e navegao para implementao
objetos e pode envolver arquiteturas elaboradas (por exemplo, cliente-servidor), em
quais aplicativos so clientes para um servidor de banco de dados compartilhado contendo con
-
ceptual objetos. Um nmero de aplicativos baseados em CD ROM, bem como Web
aplicaes, foram desenvolvidas usando OOHDM e empregando numer-
tecnologias de unidades organizacionais, tais como Java (J2EE), .NET (aspx), Windows (asp),
Lua
(CGILua), ColdFusion e Ruby (RubyOnRails).
Um ambiente de cdigo aberto para OOHDM, baseado em uma variao do Ruby
nos trilhos, est disponvel em:
http://Server2.tecweb.inf.PUC-Rio.br:8000/Projects/HyperDE/trac.cgi/wiki.