RESEA HISTORICA DEL OOHDM

EL MODELO OOHDM U OBJECT ORIENTED HYPERMEDIA DESIGN METHODOLOGY, PARA DISEO DE APLICACIONES HIPERMEDIA Y PARA LA WEB, FUE DISEADO POR D. SCHWABE, G. ROSSI, AND S. D. J. BARBOSA

HA SIDO USADA PARA DISEAR DIFERENTES TIPOS DE APLICACIONES HIPERMEDIA COMO GALERAS INTERACTIVAS, PRESENTACIONES MULTIMEDIA Y, SOBRE TODO, NUMEROSOS SITIOS WEB.

ESTAS METOLOGIAS CONSIDERAN UN DISEO PREVIO A LA CONSTRUCCIN DEL SISTEMA Y OFRECEN UNA SERIE DE TCNICAS

TOMA SU NOMBRE DE LA SUMA DE HIPERTEXTO Y MULTIMEDIA, UNA RED HIPERTEXTUAL EN LA INCLUYE NO SLO TEXTO, SINO OTROS MEDIOS

HIPERMEDIA

LA MULTIMEDIA PROPORCIONA UNA RIQUEZA EN LOS TIPO DE DATOS EL HIPERTEXTO APORTA UNA ESTRUCTURA

ESTRUCTURA DE UNA HIPERMEDIA: FORMADA POR NODOS CONECTADOS ENTRE SI SON DE DIFERENTES MEDIOS O MORFOLOGIAS ES MAS COMPLEJA QUE LA DE HIPERTEXTO INTERACCION DE LOS MEDIOS Y SINCRONIZACION ENTRE ELLOS SUELEN SER COMPLICADO

OBJECT ORIENTED HYPERMEDIA DESIGN METHOD

OOHDM COMO YA SE HA COMENTADO ES UNA METODOLOGA DE DESARROLLO PARA APLICACIONES MULTIMEDIA, ANTES DE COMENZAR A DETALLAR CADA UNA DE LAS FASES QUE PROPONE, ES NECESARIO RESALTAR ALGUNAS DE SUS CARACTERSTICAS

C O N C E P T O S
B A S I C O S

CARACTERISTICAS DEL OOHDM

BASADA EN EL PARADIGMA DE ORIENTACION A OBJETOS NO PROPONE SOLO UN MODELO EN LA APLIACION MULTIMEDIA PROPONE UN PROCESO PREDETERMINADO INDICANDO LAS ACTIVIDADES A REALIZAR TOMA EL MODELO DE CLASES DEL ANALISIS DEL PROCESO UNIFICADO DE UML (MODELO CONCEPTUAL) AADE ASPECTOS DE NAVEGACIN (MODELO NAVEGACIONAL) DEFINE EL ARGOT (MODELO DE INTERFAZ ABSTRACTA)

EL OOHDM COMO TCNICA DE DISEO

SCHWAB, ROSSI Y SIMONE PROPONEN UN CONJUNTO DE TAREAS SON COSTOSO A CORTO PLAZO A MEDIANO Y A LARGO PLAZO REDUCE EL TIEMPO DE DESARROLLO REUSABILIDAD DEL DISEO Y SIMPLIFICAR EL COSTE DE EVOLUCION Y MANTENIMIENTO

OBJECT ORIENTED HYPERMEDIA DESIGN METHOD

PROPUESTA POR SCHWABE (1995) Y ROSSI (1996)
SUPERA A SU ANTECESOR EL HDM

o DEFINE PAUTAS DE TRABAJO

EL OOHDM
o SE CENTRA EN EL DISEO o DESARROLLA APLICACIONES MULTIMEDIA DE FORMA METODOLOGICA

ELABORACIN DE APLICACIONES MULTIMEDIA Y TIENE COMO OBJETIVO SIMPLIFICAR Y A LA VEZ HACER MS EFICAZ EL DISEO DE APLICACIONES HIPERMEDIA

Introduccin
En la actualidad son pocas las metodologas existentes que permiten a los desarrolladores conseguir productos de software hipermedia reusables y fciles de mantener. A pesar de ello, ha nacido una tendencia a considerar el desarrollo hipermedial con un enfoque de proceso de ingeniera (del software), por lo que ya se han propuesto algunas metodologas para este fin.

Introduccin
Una de ellas es OOHDM (Object Oriented Hypermedia Design Method), la cual ser analizada con el principal objetivo de identificar sus ventajas, desventajas y su real aplicacin a este tipo de aplicaciones.

Caractersticas
OOHDM est basada en la orientacin a objetos. En esto se diferencia de su antecesor HDM. OOHDM propone un modelo para representar a las aplicaciones multimedia, a su vez propone un proceso predeterminado para el que indica las actividades a realizar y los productos que se deben obtener en cada fase del desarrollo. OOHDM toma como partida el modelo de clases que se obtiene en el anlisis del Proceso Unificado de UML. A este modelo lo denomina modelo

Caractersticas
OOHDM aade caractersticas que permitan incorporar a esta representacin del sistema todos los aspectos propios de aplicaciones multimedia. OOHDM no propone un modelo enriquecido para el dominio de la aplicacin, por lo que deja libre al diseador para elegir el modelo de especificacin del dominio.

Existen 5 fases de desarrollo en OOHDM:

Determinacin de Requerimiento s
Diseo Conceptua l Diseo Navegacion al

Diseo de Interfaz Abstract o

Implementaci n

OOHDM es una mezcla de estilos de desarrollo basados en:

Prototipos

Desarrollo Interactivo
Desarrollo Incremental

Fase 1- Determinacin de Requerimientos

La mayora de los estudios entregan resultados claros que los errores ms caros son los que se cometen en esta etapa.
Por lo cual esta etapa esta dividida en cuatro subetapas: Identificacin de roles y tareas Especificacin de escenarios Especificacin de casos de uso Especificacin de UIDs

IDENTIFICACIN DE ROLES Y TAREAS

Esta subetapa se introduce cuidadosamente en el dominio del sistema, identificamos los diferentes roles que podran cumplir cada uno de los potenciales usuarios de la aplicacin. Los usuarios juegan roles importantes en cada intercambio de informacin con el sistema. Luego para cada rol se identifico las tareas que deber soportar la aplicacin identificacin de roles y tareas.

ESPECIFICACIN DE ESCENARIOS Los escenarios son descripciones narrativas de cmo la aplicacin ser utilizada. ESPECIFICACIN DE LOS CASOS DE USO
Un caso de uso es una forma de utilizar la aplicacin. Especficamente representa la interaccin entre el usuario y el sistema, agrupando las tareas representadas en los escenarios existentes.

ESPECIFICACIN DE UIDS
De acuerdo a UML, los diagramas de secuencia, de colaboracin y de estado son capaces de representar un caso de uso. Sin embargo, la especificacin de casos de usos usando estas tcnicas es un amplio trabajo y puede anticiparse inesperadamente a tomar algunas decisiones de diseo (VILAIN 2000).

Para evitar esto OOHDM propone la utilizacin de una herramienta, llamada UID, que permite representar en forma rpida y sencilla los casos de uso generados en la etapa anterior. Para obtener un UIDs desde un caso de uso, la secuencia de informacin intercambiada entre el usuario y el sistema debe ser identificada y organizada en las interacciones. Identificar la informacin de intercambio es crucial ya que es la base para la definicin de los UIDs.

Fase 1- Determinacin de Requerimientos

Diagramas de casos de uso

Fundamentan

Primero que todo es necesaria la recopilacin de requerimientos.

Escenari o
Actores Tareas Tipo actor

Los casos de uso , sern luego representados mediante los Diagramas de Interaccin de Usuario (UIDs)

Proveen de una representacin grfica concisa de la interaccin entre el usuario y el sistema durante la ejecucin de alguna tarea.

Con este tipo de diagramas se capturan los requisitos de la aplicacin de manera independiente de la implementacin. sta es una de las fases ms importantes, debido a que es aqu donde se realiza la recogida de datos, para ello se deben de proporcionar las respuestas a las siguientes interrogantes:

Nivel de profundidad de la recoleccin de datos Construccin de una aplicacin hipermedial exitosa

Probabilidad de realizar una aplicacin adecuada al usuario

Fase 2- Diseo Conceptual

Se construye un modelo orientado a objetos que represente el dominio de la aplicacin usando las tcnicas propias de la orientacin a objetos. La finalidad principal durante esta fase es capturar el dominio semntico de la aplicacin en la medida de lo posible, teniendo en cuenta el papel de los usuarios y las tareas que desarrollan.

El resultado de esta fase es un modelo de clases relacionadas que se divide en subsistemas. Fase Diseo conceptual Productos: Diagrama de Clases, Divisin en subsistemas y relaciones . Herramientas: Tcnicas de modelado O.O, patrones de diseo . Mecanismos: Clasificacin, agregacin, generalizacin y especializacin . Objetivo de diseo: Modelo semntico de la aplicacin .

FASE DE DISEO CONCEPTUAL DE OOHDM

Fase 3- Diseo Navegacional Se debe disear la aplicacin teniendo en cuenta las tareas que el usuario va a realizar sobre el sistema Hay que tener en cuenta que sobre un mismo esquema conceptual se pueden desarrollar diferentes La estructura de navegacin de una aplicacin hipermedia est definida por un esquema de clases de navegacin

En OOHDM se conocen como clases navegacionales: Nodos, Enlaces y Estructuras de acceso La semntica de los nodos y los enlaces son comunes a todas las aplicaciones hipermedia, las estructuras de acceso representan diferentes modos de acceso a esos nodos y enlaces de forma especfica en cada aplicacin.

Los nodos son contenedores bsicos de informacin de las aplicaciones hipermedia Los nodos contendrn atributos de tipos bsicos como imgenes o sonidos

Los enlaces reflejan la relacin de navegacin que puede explorar el usuario. para un mismo esquema conceptual puede haber diferentes esquemas Navegacionales. y los enlaces van a ser imprescindibles para poder crear esas vistas diferentes

Las estructuras de acceso actan como ndices o diccionarios que permiten al usuario encontrar de forma rpida y eficiente la informacin deseada

hay que prever los caminos que el Usuario puede seguir, as es como nicamente podremos evitar informacin redundante o que el usuario se pierda en la navegacin

Es otra clase especial que sirve para complementar la definicin de una clase de navegacin. Por ejemplo, sirve para indicar qu informacin est accesible desde un enlace y desde dnde se puede llegar a l

Fase 4- Diseo de Interfaz Abstracta

Una vez definida la estructura navegacional, hay que prepararla para que sea perceptible por el usuario y esto es lo que se intenta en esta fase Esto consiste en definir qu objetos de interfaz va a percibir el usuario, y en particular el camino en el cul aparecern los diferentes objetos de navegacin Qu objeto de interfaz actuarn en la navegacin, la forma de sincronizacin de los objetos multimedia y el interfaz de

Al haber una clara separacin entre la fase anterior y esta fase se pueden definir diferentes modelos de interfaces permitiendo un ajuste mejor a las necesidades del usuario

MODELOS DE VISTAS ABSTRACTAS DE DATOS (ADVs): los modelos de los ADVs no son ms que representaciones formales que se usan para mostrar: La forma en que se estructura la interfaz. La forma en que la interfaz se relaciona con las clases navegacionales La forma en que la aplicacin reacciona

Fase 5- Implementacin Una vez obtenido el modelo conceptual, el modelo de navegacin y el modelo de interfaz abstracta slo queda llevar los objetos a un lenguaje concreto de programacin para obtener as la implementacin ejecutable de la aplicacin.

Tabla 5

posee una notacin diagramtica bastante completa

nodos, anclas, vnculos, imgenes, estructuras de acceso y contextos

usuario es considerado un integrante fundamental en la validacin del producto obtenido

genera una cantidad considerable de documentacin a travs de sus distintas etapas de desarrollo

ofrece la posibilidad de crear estructuras de reuso, tales como los esqueletos o frameworks

utiliza una herramienta diagramtica llamada UID

Desventajas

intento de mecanizacin puede traer como consecuencia el olvido de detalles fundamentales por parte del desarrollador.

El diseo navegacional es un tanto tedioso, para resolverlo adecuadamente es necesario realizar una gran cantidad de diagramas que muchas veces entregan informacin similar a la entregada por los UIDs y las ADVs

Modelo de Ciclo de Vida OOHDM

Modelo conceptua l

Clases Relaciones Atributos

Requeri mientos
OOHDM

Diseo de navegacin

Eventos externos
Interfaz abstracta

Implementacin

Diseo de la aplicacin con metodologa OOHDM Modelo conceptual

En este paso definimos los objetos del domino. Estos son:

Frasco colonia Ficha producto Compra Video Catalogo Promociones Usuario

Diseo navegacional Diseo de clases navegacionales

Objetos navegacionales

Diseo de interfaz abstracta

Implementacin

Gracias
Por su atencin