OOHDM

Existe un acuerdo general creciente sobre el tipo de actividades que deben ser realizados con respecto al producto del software: modelado o anlisis, diseo, implementacin, prueba y mantenimiento. Esto es verdad sin tener en cuenta el modelo de ciclo de vida diferente especificando las secuencias de procesos y productos involucrado en el desarrollo de una aplicacin (ej. la escalera de caracol y modelo de la cascada). En este respecto, el proceso de construccin basado en la aplicaciones web (o ms general hypermedia) las que no son inherentemente diferentes desde que el primero que us cuando construyo aplicaciones convencionales o sistemas de gestin. En el dominio de la hypermedia hay requerimientos contradictorios que deben ser satisfechos en una estructura unificada. En el manual, de la aplicacin final, la navegacin y la conducta funcional debe integrarse transparentemente. Por otro lado, durante el proceso del diseo se debe ser capaz al desacoplar decisiones de diseo relacionadas con la estructura de navegacin de aplicacin de aqullas relacionados con el propio modelo del dominio. Desde que la mayora al que los ambientes de implementacin no dan apoyo completo al soporte de conceptos orientados a objetos, los modelos de diseo deben traducirse fcilmente en las plataformas existentes. Segn OOHDM, el desarrollo de aplicaciones de hypermedia ocurre cuando cuatro actividades se procesan:

El Modelo Conceptual Diseo de la Navegacin Diseo Interfaz Abstracta Implementacin

Que se realiza en una mezcla de estilos de desarrollo iterativo e incremental; en cada paso un modelo ser construido o mejorado. Los principios bsicos del mtodo de OOHDM son: 1. Contempla los objetos que representan la navegacin como vistas de los objetos detallados en el modelo conceptual. 2. El uso de abstracciones apropiadas para organizar el espacio de la navegacin, con la introduccin de contextos de navegacin. 3. La separacin de las caractersticas de interfaz de las caractersticas de la navegacin. 4. Una identificacin explcita que hay en las decisiones de diseo que slo necesitan ser hechos en el momento de la implementacin. OOHDM es una mezcla de estilos de desarrollo basado en prototipos, en desarrollo interactivo y de desarrollo incremental. En cada fase se elabora un modelo orientado a objetos conceptual que recoge las caractersticas a resaltar en la misma incrementando los resaltados de la fase o fases anteriores.

El punto de partida es la elaboracin de modelo del dominio de la aplicacin, qu determina el universo de discurso. Esto se hace durante la fase del Modelo Conceptual y usa principios modelados orientado a objetos bien conocidos [Wirfs-Brock 90, Rumbaugh 91] aument con algunas primitivas como perspectivas del atributo y sub- sistemas. El Modelo Conceptual, representa dos tipos de objetos: aqullas que sern en el futuro percibidos como nodos en el modelo de navegacin (llamados Objetos de la Entidad por Jacobson [Jacobson 92]); y aquellos que proporcionan soporte computacional para la aplicacin de conductas de encapsulamiento como algoritmos y acceso a la base de datos, etc. El modelo resultante puede posiblemente servir como una base para muchas aplicaciones, y no incluye ninguna navegacin de la informacin especfica. Un aspecto esencial distintivo de aplicaciones de hypermedia son las ideas o concepto de navegacin en la que el usuario de una aplicacin en este dominio navega en un espacio extendido de objetos. Estos objetos no son igual que los objetos conceptuales, si no ms bien los objetos personalizados al perfil del usuario y tareas. Esta personalizacin se logr usando el mecanismo de vista entre los objetos, anlogamente las vistas en la base de datos. En esta fase, los atributos de los objetos de navegacin son posiblemente (cortar y pegar) de varios atributos diferentes del objeto conceptual el cual es indicado por las cajas de diseo en Figura 1. Los objetos de la Navegacin tambin pueden tener su propia conducta y pueden llevar a cabo funcionalidades ms all de leer pginas en Internet y la navegacin, ej., actualizaciones y computacin en general. Cuando se usa un ambiente Orientado a Objetos, los nodos pueden ser implementados como observadores de objetos conceptuales. Otro paso estructurado el espacio de la Navegacin es proporcionado coleccionando los objetos del espacio de navegacin en conjuntos significativos llamados Contextos de navegacin. Hay varios posibles criterios por definir tales colecciones de nodos, basados en atributos de la clase y conexiones. Durante el Diseo de navegacin se define tambin la manera en que la navegacin proceder especificando transformaciones en el espacio de navegacin, es decir la coleccin de objetos de navegacin accesibles en un momento dado. Los objetos de la navegacin no son percibidos directamente por el usuario; ms bien, ellos son accedidos mediante los objetos de la interfaz. De acuerdo con el Diseo de la Interfaz Abstracto, especifica objetos de la interfaz que son responsables para mediar interaccin del usuario con objetos de navegacin. El modelo de la interfaz especifica qu objetos de la interfaz el usuario percibir; qu objetos de la interfaz activarn navegacin; cmo los objetos de la interfaz sern sincronizados; y las transformaciones de la interfaz que tendrn lugar. Finalmente, la fase de la implementacin es responsable para trazar objetos conceptuales, los objetos de navegacin de la interfaz sobre un ambiente particular de tiempo de ejecucin que es asignado. Cuando el ambiente de implementacin designado no es totalmente orientado a objetos, se tiene que trazar la interfaz conceptual, de navegacin y abstracta dentro de los objetos concretos, es decir esos disponibles en el ambiente de aplicacin escogida. Esto puede involucrar definiendo pginas HTML, Scripts en algn

lenguaje, consultas en una base de datos relacional, etc., de esta manera el autor produce la hypermedia actual de la aplicacin para ser ejecutado. Modelo conceptual. Figura 1 - Relacin entre Modelo Conceptual, de Navegacin y Objetos de la Interfaz en OOHDM. Las Clases de la Navegacin son vistas sobre de las Clases Conceptuales; Objetos de la interfaz mediante la interaccin de Objetos de la Navegacin con el mundo externo, incluyendo usuarios. (Posicin de las cajas sombreada para los Atributos de la Clase). A continuacin se describir cada actividad con ms detalle y se discutir con ejemplos concretos la manera en la que cada formalismo del diseo ayuda a ganar asimilacin de la hypermedia, y tambin aplicaciones basadas en la Web. Se define cmo el diseador procede desde el Diseo Conceptual a travs del Diseo de la Navegacin al Diseo de la Interfaz y la Implementacin.

Tabla de contenidos
[ocultar]

1 Modelo Conceptual 2 Diseo Navegacional 3 Diseo de Interfaz Abstracta 4 Implementacin 5 Usando OOHDM 6 Conclusiones y Recomendaciones 7 Referencias 8 Enlaces externos

Modelo Conceptual
Durante esta actividad, se construye un esquema conceptual que representa objetos, sus relaciones y colaboraciones que existen en el dominio designado. En aplicaciones de hypermedia convencionales, es decir, aquellos en los que los componentes de la hypermedia no sern modificados durante su ejecucin, se podra usar un modelo semntico estructural [Banerjee87], sin embargo, cuando la base de informacin puede cambiar dinmicamente o si se piensa realizar cmputos complejos o consultas en los objetos o el esquema, se necesita una abundante conducta del modelo orientado a objetos. En OOHDM, el esquema conceptual es construido en las clases, relaciones y subsistemas. Las clases son descritas como de costumbre en el modelo orientado a objetos, sin embargo, pueden multi-digitar atributos representando perspectivas diferentes de la misma entidad del mundo. Se usa una notacin que es similar a UML [OMG 00], la Clase y Tarjetas de las relaciones, similar a las tarjetas de CRC [Wirfs-Brock 90] son usadas como una ayuda de la documentacin, ayudando remontar decisiones de diseo enviados y al revs.

Procesos diferentes de modelo de objeto o modelo Conceptual y el diseo son pensados y discutidos por: Las metodologas orientadas a objetos y bibliografa en el rea. Sin embargo hay algunas decisiones modeladas que aparecen en cualquier proceso en el que puede impactar en la estructura navegacional de aplicaciones de la hypermedia. En este papel, se enfoca en las decisiones de diseo que afectan tal estructura. Se describe un modelo de primitivas brevemente en los prrafos siguientes. Como la mayora de ellos son variaciones ligeras de su equivalente modelo orientado a objetos y mtodos de diseo, no se elaboran ms all. En cambio, se enfoca adelante esos problemas que afectan la actividad del diseo de navegacin. En OOHDM el esquema de la clase consiste en una coleccin de clases conectado por relaciones. Los objetos son instancias de clases, y de esa manera, cuando una relacin se mantiene entre las clases. Las Clases se usarn despus, durante el Diseo de navegacin para derivar Nodos, y las Relaciones que sern usadas para derivar Enlaces (Links). En Figura 2, se observa un modelo conceptual simplificado de un almacn de discos compactos. Los objetos de clase del Cliente sern responsables procesar las peticiones relacionadas con arreglos para requisitos particulares individuales como. El modelo conceptual en OOHDM incluye el modelo de la clase en mtodos orientados al objeto tradicionales. Siendo basado en UML, puede ser complementado obviamente con otros modelos de UML usando casos de uso, diagramas de secuencia, el etc.

Figura 2 Modelo Conceptual para una Tienda de CD's. Fuente: Designing Personalized Web Applications http://www10.org/cdrom/papers/395/index.html

Decidiendo as para expresar una relacin como un atributo, un mtodo o una combinacin de ambos es un problema de diseo que ha sido principalmente discutido en el objeto de comunidad. Como una alternativa, situacional se acerca como responsabilidad de Wirfs-Brocks manejo de diseo [Wirfs-Brock 90] servicio que usa diagramas de la colaboracin en lugar de relaciones en el estilo de UML. Desde el punto de vista diseo de hypermedia las relaciones expresan un aspecto importante del dominio de la aplicacin y ellos no deben esconderse en clase atributos (por lo menos hasta que se necesita llevar a cabo esas clases). Esto significa que una relacin debe especificarse siempre que un atributo represente una entidad conceptual compleja intentada para ser explorada en la hypermedia final. De hecho, cuando la implementacin de aplicaciones usa una arquitectura orientada a objetos proporcionando acceso a las relaciones ser una responsabilidad de la clase fuente y ser implementado como un mtodo y quiz accede a una variable del caso. En [Lange94], una extensin a la clase diagrama de OMT [Rumbaugh91] se presenta para reforzar relaciones. En esta aproximacin de diseo, se proporcionan tres construcciones de abstracciones: Agregacin, Generalizacin / Especializacin y un concepto del empaquetamiento de Subsistemas. El primero es til para describir clases complejas como agregacin es ms simple y el segundo para construir Jerarquas de la Clase y la herencia usando como un mecanismo compartido. Los sub-sistemas son un mecanismo del empaquetamiento por abstracciones de modelo de dominios enteros. Escogiendo usar objetos, agregado, atributos complejos o relaciones son una decisin de modelo que puede variar de la aplicacin a aplicacin. Dado que la agregacin es una relacin estructural importante, se sugiere descomponer un objeto en partes cada tiempo se supone que estas partes son exploradas en la aplicacin de la hypermedia como no-atmico. Existiendo heursticas en el dominio del modelo orientado a objetos puede usarse para identificar estructuras de agregacin. Se usa la misma semntica de herencia como en [Rumbaugh 91] es decir las clases heredan los atributos, parte-estructura, relaciones y conducta de super-clase. En la Figura2, una Historia puede ser un Ensayo o una Traduccin o una Entrevista. La Figura 3, contiene un modelo conceptual simple para CMS Asoajedrene. En este modelo, un usuario puede publicar noticias, comentarios a las noticias propias o publicadas por otras personas y fotos que pertenecen a un tema en especifico.

Figura 3 Modelo bsico conceptual para CMS ASOAJEDRENE. Usando la conducta del modelo orientado a objeto para describir aspectos diferentes de una aplicacin de hypermedia permite expresar una gran variedad de actividades de la informtica como preguntas dinmicas a una base objeto, las modificaciones del objeto onlne, bsquedas basadas en heursticas, etc. El tipo de funcionamiento requerido en el modelo conceptual depende en los aspectos deseados de la aplicacin. Para muchas aplicaciones, en particular, aqulla implementacin que llevan a cabo un Browser (es decir slo leer) la funcionalidad, comportamiento de la clase, ms all de la funcionalidad de conectarse puede parecer innecesario. En este caso, el comportamiento llega a acceder una base de informacin de multimedia navegando encima de las relaciones, y podra ser "integrado" en el propio modelo. En contraste, en aplicaciones en las que la base de informacin subyacente puede que cambie dinmicamente como el efecto de acciones del usuario, o cuando la red de hypermedia es simplemente un componente de una aplicacin corporativa ms grande, se puede necesitar definir mtodos que implemente ese comportamiento en clases conceptuales. Durante el diseo Navegacional y el Diseo de Interfaz, se especifica la manera en que la interfaz de objetos activa el comportamiento de ambos en el modelo de navegacin y conceptual. Desde que OOHDM es un mtodo de Diseo y no un armazn de aplicacin, se asume que los mtodos para lograr el valor de atributos de un objeto son automticamente generados. Cuando deben hacerse otros cmputos y deben corresponderse deben especificarse mtodos. Usando la terminologa de mtodos orientado a objetos se puede decir que el Modelo Conceptual contendr aspectos de Modelos de Anlisis y Diseo. Cuando la aplicacin se ejecute en un ambiente de soporte (distribuido) de objetos, las clases en el modelo conceptual sern implementadas directamente como estn definidos, que especifican perspectivas mltiples como atributos separados. Si no, ellos servirn como

especificaciones de diseo para el de navegacin y actividades de diseo de interfaz. En la Tabla1 se esquematiza esta fase:

Diseo Navegacional
La primera generacin de aplicaciones de multimedia intentaba realizar la navegacin a travs de un espacio de informacin usando un solo modelo de datos de hypermedia. A pesar de estos problemas que son bien conocidos en la comunidad de la hypermedia, ellos raramente han sido tomados en cuenta por los diseadores de Multimedia y Web Sites. El mayor esfuerzo de diseo normalmente se ha puesto en aspectos de interfaz del usuario y la estructura de la navegacin se construye en jerarquas simples. Ahora que los navegadores (Browser) de Web son la interfaz, y a veces el Host, para los tipos diferentes de aplicaciones, hay un riesgo en la navegacin a ser considerada simplemente otro tipo de de comportamiento de aplicacin. En OOHDM, la navegacin es considerada un paso crtico en el diseo de una aplicacin de hypermedia. Un Modelo de navegacin se construye como una vista ms de un modelo conceptual y permite la construccin de modelos diferentes segn los perfiles diferentes de los usuarios. Cada modelo de navegacin proporciona una vista "Subjetiva" del modelo conceptual. Mientras se disea la estructura de navegacin de una aplicacin Web, se tiene en cuenta varios aspectos como: Que objetos sern navegados, que atributos poseen, y que son las relaciones entre estos objetos y los mismos definidos en el esquema conceptual? Se har esto definiendo nodos y enlaces (Links) como vistas orientadas a objetos de objetos conceptuales y relaciones. Qu tipo de estructuras de composicin existe entre los objetos de navegacin y cmo son relacionados? Cul es la estructura fundamental de navegacin? En qu contexto el usuario navegar? Se introducir el concepto de contextos de navegacin, una arquitectura primitiva para organizar el espacio de la navegacin. Se necesita decidir los objetos navegados que pueden parecer diferentes segn el contexto en el que ellos son visitados, y se debe especificar esas diferencias claramente. Cuales conexiones y estructuras de acceso existen entre objetos que sern navegados (enlaces, trayecto de bsqueda, camino o trayecto, ndices, etc.)? Cmo procede la navegacin cuando el usuario salta "Jump" de un objeto a otro, es decir, lo que es el efecto de navegacin en la fuente "source" y en el destino "target object" y posiblemente en otro objeto relacionado tambin?

El diseo de navegacin se expresa en dos esquemas, el esquema de la Clase De navegacin, y el Esquema del Contexto De navegacin. Los objetos navegables de una hypermedia en la aplicacin es definida por un esquema de la clase navegacional cuyas clases reflejan la vista escogida sobre del dominio de la aplicacin. En OOHDM, hay un juego de tipos pre-definidos de clases de navegacin: nodos, links o enlaces, y estructuras de acceso. La semntica de nodos y enlaces es el usual en aplicaciones de hypermedia, y estructuras de acceso, como ndices y recorridos guiados, que represente posibles maneras de acceso a los nodos.

Nodos: Los nodos son contenedores bsicos de informacin de las aplicaciones hipermedia. Se definen como vistas orientadas a objeto de las clases definidas durante el diseo conceptual usando un lenguaje basado en query, permitiendo as que un nodo sea definido mediante la combinacin de atributos de clases diferentes relacionadas en el modelo de diseo conceptual. Los nodos contendrn tanto atributos de tipos bsicos (donde se pueden encontrar tipos como imgenes o sonidos) y enlaces. Enlaces: Los enlaces reflejan la relacin de navegacin que puede explorar el usuario. Ya se sabe que para un mismo esquema conceptual puede haber diferentes esquemas navegacionales y los enlaces van a ser imprescindibles para poder crear esas vistas diferentes. Las clases enlaces sirven para especificar los atributos de enlaces y estos a su vez para representar enlaces entre clases nodos o incluso entre otros enlaces. En cualquier caso, el enlace puede actuar como un objeto intermedio en un proceso de navegacin o como un puente de conexin entre dos nodos. Estructuras de Acceso: Las estructuras de acceso actan como ndices o diccionarios que permiten al usuario encontrar de forma rpida y eficiente la informacin deseada. Los mens, los ndices o las guas de ruta son ejemplos de estas estructuras. Las estructuras de acceso tambin se modelan como clases, compuestas por un conjunto de referencias a objetos que son accesibles desde ella y una serie de criterios de clasificacin de las mismas. Contexto Navegacional: Para disear bien una aplicacin hipermedia, hay que prever los caminos que el usuario puede seguir, as es como nicamente se podr evitar informacin redundante o que el usuario se pierda en la navegacin. En OOHDM un contexto navegacional est compuesto por un conjunto de nodos, de enlaces de clases de contexto y de otros contextos navegacionales. Estos son introducidos desde clases de navegacin (enlaces, nodos o estructuras de acceso), pudiendo ser definidas por extensin o de forma implcita. Clase de Contexto: 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.

La especificacin de las Transformaciones de Navegacin describe la dinmica de la aplicacin, mostrando los cambios espaciales de navegacin cuando el usuario navega, es decir, qu nodos se activan y qu nodos son desactivados cuando un enlace es continuado

(Notese en la Figura 4). La semntica de navegacin predefinida en OOHDM es que cuando un enlace es continuado, el nodo de la fuente se deja desactivado y el nodo objetivo activado. Esta interpretacin normalmente es el valor por defecto encontrado en los navegadores (Browsers) de Web. De una manera anloga, los enlaces reflejan que las relaciones pretenden ser exploradas por el usuario final y tambin se define como vistas en relaciones en el esquema conceptual. Los enlaces conectan objetos de navegacin y pueden ser uno-a-uno o uno-a-muchos.

Figura 4 Esquema bsico navegacional para my.yahoo.com. Fuente: Designing Personalized Web Applications http://www10.org/cdrom/papers/395/index.html El resultado de atravesar un enlace es expresado por cualquier definicin de semntica navegacional proceduralmente como resultado de la conducta del enlace o usando una mquina de transicin de estado orientada a objeto similar a Statecharts [Rossi 96d], las estructuras de Acceso (ndices) son tambin definidos como clases y maneras alternativas presentes para la navegacin en la aplicacin de la hypermedia. En trminos Orientado a Objetos, las relaciones entre los nodos y los objetos conceptuales, y entre los enlaces y relaciones en el esquema, son expresados como instancias del patrn o modelo de diseo del Observador. La sintaxis general para definir los atributos del nodo se muestran debajo (la sintaxis para los enlaces es similar). Donde: El name, es el nombre de la clase de nodos que se est creando. El className, es el nombre de una Clase Conceptual (donde el nodo est trazndose). El nodeClass, es el nombre de la sper-clase Los attri, son los nombres de atributos para esa clase, typei los tipos del atributos. Los namei de son los asuntos para la expresin de la pregunta y los Si se toma en cuenta el ejemplo anterior, sobre producir la definicin del Nodo siguiente: Note que el valor del atributo del toAuthor es un enlace que es el parmetro con la clase de Enlace Is Author of. Al definir la apariencia de la interfaz del Nodo Clase Historia se puede, por ejemplo, hacer aparecer el enlace como un botn invisible sobre del nombre del

autor (autor del atributo). Aunque puede que parezca que ambos atributos tienen la misma conducta, slo el enlace acta en contestacin a un evento de la interfaz. La Figura 3 contiene un esquema de navegacin para el CMS ASOAJEDRENE, como se ejemplific en el prrafo anterior.

Figura 3 Modelo de Clases para CMS ASOAJEDRENE. Las aplicaciones hypermedia bien diseadas deben tomar en cuenta la manera qu el usuario explora el espacio de la hypermedia. La informacin redundante debe ser juiciosamente usada y se debe poder ayudar que el usuario pueda escoger la manera en que l navega de una manera consecuente y controlada. Desgraciadamente, los nodos y enlaces no son suficientes para cumplir este objetivo. Aunque la solucin usual a este problema es llevar a cabo herramientas de orientacin, tambin se piensa que nivel ms alto que deben ser usados por primitivas de navegacin arquitectnicos. Este es el punto donde los contextos de navegacin aparecen. En OOHDM, la estructuracin principal primitiva del espacio de navegacin es el concepto de Contexto de Navegacin. Un contexto de navegacin es un conjunto de nodos, enlaces, contexto, clases y otros contextos de navegacin (anidados). 1. Clase basados en Objetos, en este tipo de contexto pertenecen a la misma clase C y son seleccionados por dar una propiedad P, por el que debe satisfacerse a una propiedad todos los elementos: Contexto = {e | P(e), e C}. Un caso comn es cuando incluye todas las instancias de una clase (P es idnticamente verdad). Como en el ejemplo todas los Storys. 2. Clase basado en grupos - Es un juego de contextos cada uno de los cuales son una clase simple basado en contextos. Es especificado para dar una propiedad del parmetro y permitiendo que el parmetro asuma todo los posibles valores (en un enumerable dominio finito). Si se observa el ejemplo, las Stories by Type son un grupo de contextos; sus elementos es clase simple basados en contextos, uno para

cada posible valor de Type, conteniendo historias cuyo atributo de "Type" iguala a Type. 3. Enlaces basados en Objetos, en este tipo de contexto son de la misma clase y son seleccionados cuando ellos pertenecen a la relacin de 1 a n. Por ejemplo, " All Stories por Bob Woodward". Contexto = {p | Is Author Of(Bob Woodward,p), p Story. Note que un caso particular de este tipo es el contexto formado por todos los elementos que son parte de un objeto compuesto. 1. Enlaces basados en grupo - Es un juego de contextos cada uno de los cuales son un enlace basado en contexto. Es especificado dando una relacin de 1 a n y formando el enlace basado en contextos para cada posible valor de la fuente de la relacin. 2. Enumerar - En este tipo de contexto, se enumeran elementos explcitamente, y puede pertenecer a las clases diferentes. Adems de sus elementos, hay otra dimensin a lo largo de contexto los cuales sern definidos, relativo a una sesin de la navegacin. Si los elementos de un contexto pueden variar como una consecuencia de la navegacin por el usuario, se dice que el contexto es dinmico. Un ejemplo de este tipo de contexto es que "History" mantenido por muchos navegadores; otro ejemplo es un "Shopping basket" que el lector construye mientras navega en otros contextos a travs de los objetos (por ejemplo, libros). Los dos son casos de Contextos Dinmicos enumerados. Si la aplicacin permite la creacin o modificacin de objetos (instancias de clase), todo el contexto derivado desde estos objetos (clases) ser dinmico tambin; el mismo es verdad en el caso de creacin de enlaces y los contextos basados en enlaces. Los contextos navegacionales juegan un papel similar como colecciones [Garzotto 94] y han sido inspirados por el concepto de contextos anidados [Casanova 91]. Los contextos navegacionales organiza el espacio de navegacin en conjuntos consistentes que pueden ser atravesados siguiendo un orden particular; ellos deben ser definidos de la misma manera en lo que se refiere a la ayuda del usuario para realizar su tarea deseada.

Diseo de Interfaz Abstracta

Una vez que las aplicaciones de estructura navegacional han sido definidos, se debe especificar ahora aspectos de la interfaz. Esto significa definir la manera en que diferentes objetos de navegacin aparecern, qu objetos de navegacin de la interfaz se activara y otra funcionalidad de aplicacin, y qu transformaciones de la interfaz tendrn lugar y cuando. Una separacin ordenada entre ambas preocupaciones, de navegacin y diseo de interfaz abstracta, permite construir interfaces diferentes para el mismo modelo de navegacin, llevando a un grado ms alto de independencia de tecnologa de la interfaz de usuario. En suma, esta separacin permite entender mejor la aplicacin global de la estructura para indicar qu transformaciones claramente en la interfaz sern transformaciones navegacionales.

Aunque se ha discutido que el aspecto de la interfaz de usuario de aplicaciones interactivas (en particular las aplicaciones de la web) es un componente crtico, moderno, las metodologas tienden a descuidar este aspecto. Ellos relegan la especificacin para herramientas de implementacin-dependientes, y por consiguiente las decisiones de diseo en este nivel raramente se documentan. Es ms, como llevar a cabo la interfaz de la Web normalmente se hacen aplicaciones por medio de los editores de HTML especializados, muchos crticos pueden ignorar aspectos de la interfaz. En OOHDM, se usa un acercamiento del Diseo de Datos de Vista Abstractos (ADVs), para describir la interfaz del usuario de una aplicacin de hypermedia [Cowan 95]. ADVs son objetos en los que tienen un estado y una interfaz, donde la interfaz puede ser ejercido a travs de mensajes (en particular, eventos externos generados por el usuario). Las ADVs son abstractas en el sentido de que ellos slo representan la interfaz y el estado, y no la aplicacin. Las ADVs han sido usados para representar interfaces entre dos medios de comunicacin diferentes como un usuario, una red o un dispositivo (un cronmetro, por ejemplo) o como una interfaz entre dos u mas Objetos de Datos Abstractos (ADOs). Los ADOs son objetos que no soportan externamente eventos generados por el usuario [Cowan 95]. Desde un punto de vista arquitectnico, las ADVs son observadores para ADOss, para que el protocolo de comunicacin entre la interfaz y los objetos de aplicacin siga las reglas descritas en el Modelo de Diseo de Observador [Gamma 95]. En la Figura 4 se observan los datos abstractos jerarquizados, "cuadro", "descripcin", "interfaz del contexto", "descripcin de la demostracin" y las "referencias de la demostracin" exhiben un comportamiento usuario-perceptible. Por ejemplo cuando el usuario corre la "descripcin de la demostracin" en los ADV se exhibe la "descripcin". la "interfaz del contexto" alternadamente se compone de las anclas que ponen en ejecucin jerarquizadas de ADVs para la navegacin del contexto, bsicamente una vision simple del diseo final de las pantallas.

Figura 4 Diagrama de Configuracin para los nodos ADV. Fuente: OOHDM's Design Process http://www-di.inf.puc-rio.br/schwabe/HT96WWW/section3.html

Un ADV usado en el diseo de aplicaciones Web puede verse como un objeto de interfaz. Comprende un conjunto de atributos (y objetos de interfaz anidado) qu define sus propiedades de percepcin, y el conjunto de eventos que puede manejar, como eventos generados por el usuario. Los ejemplos de eventos generados por el usuario son MouseClick, MouseDoubleClick, MouseOn, etc. Las ADVs pueden ser fcilmente implementadas en ambientes orientados a objetos para el Web o puede traducirse a documentos HTML. Pueden definirse valores del atributo como constantes y pueden definirse estilos particulares de apariencia como posicin, color, o sonido. Los modelos de interfaz ADV unen al modelo que permite tratar estos rasgos de una manera abstracta y los relega al paso de la aplicacin. En general, los ADVs especifican la organizacin y el comportamiento de la interfaz, pero la apariencia fsica real o de los atributos, y el diseo de la ADV en la pantalla real se hace en la fase de la implementacin. En el contexto de OOHDM, los objetos de navegacin como nodos, e ndices actuarn como ADOs, y su ADVs asociados se usar para especificar su apariencia al usuario. A continuacin se usar el trmino ADV para referirse a clases de interfaz y objetos. Cuando sea necesario se hablar sobre las clases de ADV. Las abstracciones diferentes y mecanismos de la composicin son usados en el diseo de ADV; primero las ADVs pueden ser compuestas por agregacin o composicin de ADVs de nivel ms bajo, permitiendo la construccin de usuarios de interfaces as con objetos perceptibles anidados. Por ejemplo, supngase que se tiene una aplicacin sobre pinturas. Figura 9 muestras cmo un ADV que describe una pintura pudiera hacerse fuera de tres ADVs, conteniendo una imagen, texto, y un botn. Adems, ADVs pueden ser organizados en jerarquas del generalizacin/especializacin que proporcionan un poderoso armazn conceptual por definir jerarquas de objetos de la interfaz.

Figura 5 Nodo ADV referente a la pgina de Descargas del CMS ASOAJEDRENE. En Figura 5, "Texto Buscar" es un Objeto de la Interfaz que enva un conjunto de anclas o enlaces al TextField (Campo de texto) ms general. Entretanto el "Botn Buscar" especializado agregando una conducta ms personalizada (no mostrado en la Figura). Cuando se implementa esta aplicacin Web usando un ambiente de soporte de ciertos tipos de objetos de interfaz, se puede usar como ADVs primitivos para producir esta especificacin de diseo. En resumen, ADVs: La manera en que se estructuran objetos de la interfaz usando agregacin y generalizacin/especializacin como mecanismos de abstraccin. ADVs expresan la estructura del esquema esttico que lleva a cabo la metfora de la interfaz [Hannemann 93]. Las ADVs permiten definir la apariencia de la interfaz de objetos de navegacin y otros objetos de la interfaz tiles (como barras del men, botones y mens). Se muestra un ADV correspondiente al Diseo del sitio Web Portinari (http://www.portinari.org.br /) un aplicacin de hypermedia que contiene parte del trabajo y documentos relacionados de Candido Portinari, pintor brasileo famoso. El ADV Painting contiene algunos atributos que describen ciertos aspectos del cuadro y muchos ADVs anidados como Picture (Cuadro), References y People (Referencias y Personas). En la notacin de Figura 8 Referencias y las Personas no se intentan ser mostradas al mismo tiempo y para que sus ADVs son sobrepuestas. ADVs ShowPeople (Mostrar

personas), ShowReferences (Mostrar personas) son mandos activos que permiten mostrar uno de los ADVs previamente mencionado. El ADV de THeme InContext implementa la interfaz de la Clase de InContext Theme y proporciona mandos de la navegacin dentro del Contexto De navegacin: Cuadros de un Tema. Las ADVs similares deben ser especificados por otros Contextos navegacionales como Picture (Cuadros) de una estrategia. Mientras los diagramas de arriba o anteriores muestra la naturaleza esttica de interfaces de Pictures (Cuadros), las dinmicas son descritas usando ADV-mapas, se especifica que cuando ShowPeople es clicked (pulsar el botn), enva la lista al despliegue del mensaje de las personas asociadas con la pintura, y lo mismo ocurre para ShowReference. Nota que ste es una interfaz pura de efecto no involucra navegar a otro nodo. Entretanto, cuando el objeto de la interfaz Anterior "Previous" es clicked (hacer click), enva el mensaje anchorSelected (anterior) a la DIFICULTAD correspondiente, en este caso un Objeto de InContext para que se comunique con el ancla (etiqueta, enlace) correspondiente y as se navega a otra pintura. An cuando la aplicacin no es orientada a objetos, este modelo de comunicacin es fcil de implementar en la mayora de las plataformas. Para acabar esta seccin se muestra la interfaz real del sitio Web Portinari y como los objetos de la interfaz estn relacionados con sus partes equivalentes implementados.

Implementacin
En esta fase, el diseador realmente implementar el diseo. Hasta ahora, todos los modelos fueron deliberadamente construidos de semejante manera en lo que se refiere a ser independiente de la plataforma de implementacin; en esta fase el ambiente particular de (tiempo de ejecucin) runtime se toma el derecho de acceso a un servidor o a la red internet. A continuacin se fijar cmo los diseos de OOHDM pueden ser implementados en el WWW, tener cuidado para no arreglar una sola alternativa, desde que hay muchos acercamientos posibles a travs de los cuales esto puede ser logrado. Cuando la fase de implementacin se alcanza, el diseador ya tiene definido los artculos de informacin que son parte del dominio del problema. Tambin tiene identificado cmo estos artculos deben ser organizados segn el perfil del Usuario y asignaciones; ya que se ha decidido lo que la interfaz se parecer, y cmo se comportar. En orden para implementar todos esto en el ambiente de WWW y aplicaciones de multimedia, el diseador tiene que decidir cmo los artculos de informacin (ambos conceptual y objeto de navegacin) ser almacenada. Tambin debe decidir cmo se comprendern la apariencia de la interfaz y el comportamiento sern realizados usando HTML y posiblemente use algunas extensiones. En general, note que la apariencia actual ser definida por un profesional de diseo grfico que ser parte el equipo de Diseo. Aunque OOHDM es un mtodo en trminos de modelos de OO orientados a objetos, no requiere un ambiente de aplicacin OO; (pero no en la Web) se describe en [Milet 96]; las aplicaciones basadas en Java son de baja tendencia. Tabla 4 obsrvese un resumen de esta fase. Fase Implementacin Productos Aplicacin ejecutable. Herramientas El entorno del lenguaje de programacin. Mecanismos Los ofrecidos por el lenguaje. Objetivo de diseo Obtener la aplicacin ejecutable. Tabla 4: Fase de Implementacin de OOHDM

Mapeo de Informacin de artculos Los artculos de informacin (qu corresponde a los ADOs en el modelo de interfaz abstracta) puede guardarse en archivos o en una base de datos. Debido a la naturaleza y la complejidad de los tipos de aplicaciones para las que en OOHDM sea ms conveniente, recurdese usar una base de datos para guardar los objetos Conceptuales y de Navegacin. Desde la mayora de los DBMSs disponibles en el mercado hoy son relacionales, un mapeo de modelos OO hacia los modelos relacionales equivalentes deben ser hechos. Hay varias tcnicas y heursticas para hacer esto. Los mtodos asociados con las clases son implementados como un conjunto de procedimientos que acceden a la base de datos para ejecutar sus cmputos. Para ilustrar el tipo de decisiones de diseo, se discutir brevemente una alternativa de mapeo. Cada clase en el modelo de OO para ser implementado es enviar hacia una tabla, donde cada columna guarda un atributo, y cada fila corresponde a un objeto de esa clase. Un atributo distinguido puede usarse como una llave de la base de datos, o un identificador interno que corresponden a un puntero (que le permite al programa acceder a un recurso como una funcin) del objeto y pueden usarse como una llave. Para atributos cuyo tipo no se apoya directamente en el DBMS (ej. datos de multimedia), una tabla auxiliar separada debe ser implementada, y los atributos de objetos almacenan el atributo Identificador ID de una fila en la tabla auxiliar correspondiente. Alternativamente, almacenar el nombre de un archivo en el sistema operativo que contiene el valor actual. Ambas alternativas tienen limitaciones; por ejemplo, el primero requiere asociacin extra, y segundo es vulnerable a los cambios fuera del control del DBMS. Desgraciadamente, esto slo puede evitarse si el DBMS ofrece soporte para tipos de datos complejos, como es adecuado lo ms comn en la ltima generacin de productos que llegan al mercado. En seccin se declar que el Modelo de la Navegacin ha terminado una vista del Modelo conceptual. El diseador tiene la opcin de reflejar esta organizacin en la base de datos que corresponden a cada modelo. En otras palabras, l puede definir la base de datos conteniendo los objetos de Navegacin (nodos, links, etc...) como una vista, soportada por el DBMS, de la base de datos que corresponde al modelo Conceptual. En el caso donde el DBMS no soporta el mecanismo de vista directamente, o por las razones de eficacia, el diseador tiene la opcin a la mano la vista de informtica. En este caso, solo quiere llevar a cabo al modelo de la Navegacin, desde que es el primero que el usuario estar accediendo. Evidentemente, esta alternativa tiene limitaciones o anomalas en trminos de evolucin del esquema el cul puede llegar a ser evidente cuando el mismo banco de datos Conceptual se usa como la base para varios aplicaciones. ste es el caso, por ejemplo, cuando las compaas tienen sitios en su intranets, y la parte de estos sitios es visible (normalmente con una interfaz diferente) en el WWW. Adems de trazar definiciones de la clase en el modelo del banco de datos cualquier (correlativo, OO, etc...) usndose, tambin es necesario llevar a cabo clase "InContext" que funcionan como decoradores para los objetos dentro de los contextos particulares. Tpicamente, esto implica enriquecer al modelo de los datos usado en la base de datos para adicionar atributos, y definiendo funciones de control en las que hacen estos atributos accesible en los contextos apropiados. Si la implementacin esta directamente

basada en el sistema del archivo, stos controlan las funciones que accedern a archivos adicionales que contienen la informacin contextual. Una vez que las bases de datos son definidos, ellos deben ser integrados en el WWW. Hay muchas maneras en las que esto puede hacerse, y no se elaborar este extenso; basta decir que cualquiera de estas tcnicas puede emplearse. En este respeto, el criterio para escoger el mtodo de la integracin ser igual que otras aplicaciones, como se discuti en la teora.

Usando OOHDM
Los modelos usados en las cuatro fases abordadas en la seccin anterior son suficientes para permitir el plan de sistemas de informacin basados en la Web. No obstante, como con cualquier mtodo, hay conocimiento adicional en el que es recogido por diseadores en prcticas, que no es parte del propio mtodo. La investigacin acerca de OOHDM incluye varios desarrollos en esta direccin fuera de la que est llevndose, a continuacin se dar un cuadro global brevemente de OOHDM y la investigacin relacionada.

Figura 1. Ambiente OOHDM-Web. Fuente: Ribeiro M. OOHDM-Web Manual do Usurio

Un mtodo que ha sido usado recientemente captura conocimiento del diseo, sobre todo en el campo de OO orientado a objetos, es el uso de Modelos de Diseo los cuales se nombran sistemticamente, explique y evale diseos importantes y recurrentes en sistemas del software. Ellos describen problemas que ocurren repetidamente, y describen el centro de la solucin a ese problema, de semejante manera se puede usar esta solucin muchas veces en diferentes contextos y aplicaciones. Mirando usos conocidos de un modelo del diseo particular, se puede ver cmo un diseador exitoso resuelve problemas recurrentes. De esta manera, se exige esto usando a diseadores de prototipos de diseo pueden ganar desde conocimiento del diseo en el que existe varias comunidades, como hypermedia o diseo de interfase de usuario. Se ha estado coleccionando modelos de diseo conveniente para la aplicacin del diseo de hypermedia [Rossi 97]. El objetivo es desarrollar un sistema de modelos inter-relacionados bastante compactos para poder expresar diseos completos como la aplicacin sucesiva de modelos en este sistema. Se ha estructurado estos modelos en tres sub-grupos, particularmente arquitectnico, navegacin y modelos de la interface. Los modelos arquitectnicos dan pautas para implementar substrates del software para las aplicaciones de hypermedia. Estos modelos son bastante similares a los modelos en [la Gamma 95], desde que ellos se dirigen problemas como navegacin de desacoplar de otros tipos de conductas, organizando jerarquas de links y fin tipos de nodos, desacoplar link de activacin del proceso de determinar el punto extremo del link. Ms detalles pueden encontrarse en [Rossi96a, Garrido 97]. Modelos en la ayuda de categora de navegacin la organizacin de la estructura navegacional de una aplicacin de hypermedia para lograr aclarar y significativo para los lectores deseados. Ellos dirigen problemas recurrentes cuya solucin determina el grado de xito de aplicaciones de hypermedia. Un ejemplo interesante de una navegacin el modelo es el modelo de "Referencia Activa" cuya meta es proporcionar una referencia perceptible y permanente sobre el estado actual de navegacin. Combina herramientas de orientacin con una manera fcil de navegar a un juego de nodos relacionados, al mismo o posicin ms alta en la estructura de la navegacin. Este modelo ayuda construir un camino simple para espectadores actualmente no con tal de que por browsers de WWW actual. El modelo de "Referencia Activa" ha sido usado en muchos sitios Webs para mejorar la navegacin. Por ejemplo, en http://city.net/countries / brazil/rio_de_janeiro, hay una barra con una representacin del camino lgico de la raz al nodo corriente. El lector tiene una manera simple de entender donde l esta, donde l puede ir luego mientras accede a datos sobre una ciudad, en este caso Ro de Janeiro. Vea [Rossi 97] para una descripcin completa de este modelo. Modelos de la interfase significa para diseadores de GUI de Hipermedia. Ellos son abstractos y por consiguiente independientes del ambiente usado para la implementacin. El diseo de la interfase grfica es una tarea compleja, relacionada principalmente con encontrar el combinacin correcta de elementos (ambos en cantidad y en sus relaciones espaciales), de tal manera que esos elementos actan recprocamente para una presentacin eficaz de la informacin.

Tambin pueden aplicarse modelos en este grupo fuera del rea de aplicaciones de hypermedia, en el contexto ms extenso de diseo de GUI. Por ejemplo el diseo de patrones "Desacoplar Informacin/Interaccin" modelo de diseo es apuntar a resolver el problema de cmo hacer la interaccin entre la aplicacin y el usuario, a la interfase grfica de un nodo. Este modelo es particularmente til en sitios Web cuando se generan pginas dinmicamente y no se puede definir etiquetas de links como hotwords empotrado en el texto. El modelo "Information/Interaction Decoupling" da pautas claras con respecto a la colocacin fsica de links de la navegacin. El diseo de patrones de "Behavioral Grouping" ayuda al diseador a construir una interfase de semejante manera que el usuario puede fcilmente entender el tipo de funcionamientos que le permiten realizar en la interfase. Este modelo resuelve el problema de organizar la interfase cuando muchos tipos diferentes de transaccin, deben proporcionarse navegacin y funcionalidades de la interfase simultneamente. Una descripcin ms profunda de modelos de la interfase puede encontrarse en [Garrido 97]. Aunque se ha declarado que ese Diseo de la Navegacin debera hacerse tomando en cuenta a los perfiles de usuario y tareas, el propio OOHDM no proporciona, hasta ahora, cualquier indicacin en cmo esto realmente debe hacerse. Se ha estado investigando [Barroso 98] el uso de escenarios de usuarios-centrados para ayudar identifica a la clase de usuario y tareas tpicas para ser apoyado por la aplicacin. El mtodo pensado empieza con un modelo conceptual preliminar dibujado por el diseador desde su comprensin del dominio. Observando escenarios descritos por clases diferentes de usuarios, el diseador construye la navegacin parcial, y esquemas de Clase de navegacin parcial. Despus de que todos los guiones se han analizado, el diseador empieza un proceso de anexar los senderos parciales y esquemas con los que culminan un Diagrama de Contexto de navegacin y un esquema de Clase de Navegacin actualizado. En el curso de esta investigacin, se ha extendido OOHDM para incorporar un modelo de seguridad para permitir acceso controlado a los objetos. Este modelo toma en cuenta a la clase de usuario y contextos, y define mecanismos para especificar ciertos tipos de contextos dinmicos que se construyen como resultado de acciones del usuario especificadas. Otro problema importante est construyendo ambientes del software para dar soporte al mtodo; ha seguido dos acercamientos diferentes:

Se ha construido un ambiente de un CASO que le permite a un diseador describir el concepto de navegacin y modelos de la interfase que usan la notacin de OOHDM y le proporciona la documentacin automatizada sobre esos modelos. l puede luego generar plantillas de implementacin para las escenas diferentes, como Asymetrixs, Toolbook o HTML. (Vea [Lyardet 96]). Se ha diseado e implementado un prototipo orientado a objetos (OONavigator) para reforzar sistemas de informacin orientados a objetos, mejorando el acceso a sus recursos de informacin agregando un frontal "navigational", transparentemente,

integrando esta funcionalidad de la navegacin con sus propias aplicaciones computacionales. En OONavigator, conceptos del hypermedia (nodos, links, ndices, y contextos) son modelados como componentes que se entrelazan con objetos de la aplicacin y su interfase. La clase de aplicacin presenta el papel de clases conceptuales de OOHDM, mientras los objetos de prototipo (nodos y links) comprendan el componente de navegacin de la aplicacin. Se ha enriquecido los MVC estndar paradigma de interfase [Krasner 88] con fijar medios de semejante manera que el apoyo a la metfora de interfaces de nodos "point y click" del hipertexto. La interfase puede publicarse en los browsers de la Web que usa herramientas como VisualWave. Usando Navegador orientado a objetos, un diseador puede enriquecer la aplicacin -orientada a objetos con caractersticas de hypertext siguiendo pautas de OOHDM. En este caso la hypermedia de "instantiates" de diseador y clases de la interfase (usando una herramienta visual) y conectarlos a sus clases de la aplicacin para permitir navegacin a travs del espacio de informacin de aplicaciones. (Vea [Garrido 96, Rossi, 98a, Rossi98b])

Conclusiones y Recomendaciones
Trabajo relacionado: Cuando se dice previamente, las metodologas para el diseo de aplicaciones Web an en su infancia (con tal de que la Web tambin es); existiendo mtodos tienden a descuidar cualquier navegacin o los aspectos del behavioral (comportamiento) de aplicaciones de la web. En [Takahashi 97] los autores proponen usando una extensin de RM [Izakowitz 95] como el mtodo de apoyo por construir sistemas de informacin de Web. Ellos enriquecen la entidad-relacin basada en modelo con escenarios que muestran las interacciones entre entidades, agentes y productos. Mientras se encuentra su propuesta llamativa, sufren los mismos problemas de extensiones del behavioral (comportamientos) existentes a los modelos de informacin estructurados; en lugar de usar objetos ellos construyen la conducta de aplicaciones de una manera artificial esttica de separacin y los modelos dinmicos. Mtodos similares para la esttica de separacin de aspectos dinmicos y funcionales, incluso en el contexto de modelar orientado a objetos, como Rumbaughs OMT [Rumbaugh 91], ha fallado y se ha desechado por sus proponentes (vea la notacin de UML por ejemplo en [OMG 00]). Esto pasa porque ellos producen sistemas que son difciles extenderse y mantener. Del punto de vista de la hypermedia, el mtodo es ms fuerte porque proporciona nivel ms alto diseo de primitivas, como Contextos de navegacin de los que permiten una organizacin mejor, en el hyper-espacio. Adems, separando el aspecto de diseo de la interfaz del usuario de stas las aplicaciones permiten definir un idioma que se puede compartir con expertos de la interfaz. Los modelos de diseo de interfaz son un paso en esa direccin. De un punto de vista arquitectnico, las preocupaciones de separaciones entre conceptual, de navegacin y auxilios de objetos de interfaz para producir aplicaciones a las

que son ms fciles extindase y/o mantenga. Esto pasa porque las relaciones entre los objetos en los niveles diferentes siguen el tipo de colaboraciones en modelos de diseo bienprobado (tal como el Observador). La metodologa puede usarse como un diseo front-end (o la parte de una aplicacin que es responsable de la interfaz) para esta herramienta de la ingeniera. Adems, cuando se ha discutido sobre esto, la filosofa subyacente detrs de OOHDM que proporciona artefactos de diseo que pueden ser llevado a cabo incluso al no usar orientado a objetos o las herramientas hbridas. Finalmente, cuando se menciona previamente, OOHDM proporciona una dimensin del diseo eso es normalmente abandonado en ambientes orientado a objetos y metodologas: la actividad del diseo de navegacin por ejemplo. Productos buenos orientados a objetos para las aplicaciones de Web, como VisualWave o ClassicBlend, puede usarse con metodologas modernas como OOSE [Jacobson92] o UML [OMG 00]. Sin embargo, no consideran navegacin como un problema de diseo, y se construyen aplicaciones usando las dos particiones de diseo de nivel usual. La nica diferencia es que las interfaces se generan como una combinacin de HTML y applets de Java. Como en otros casos, hay varios y ms recientes herramientas en el mercado, como NetObjects "Fusion" que mira las aplicaciones WWW basados en ("sitios Web") como ms de una coleccin de pginas no estructuradas de HTML. Ellos permiten la definicin de (visual) visuales (plantillas o templates) para ser aplicado uniformemente a las pginas en el sitio que es un camino en la direccin correcta. Sin embargo, ellos todava confunden la topologa de la navegacin con la estructura del directorio fsico usadas para almacenar las pginas en el sitio. Por consiguiente, dada la pgina puede tener slo un "siguiente" para compaginar (o una pgina "parent", padre), independientemente de la manera que el lector ha llegado a l. Adems, se cree firmemente en el diseo de la interfaz debe hacerse separadamente del diseo de la navegacin.