Metodología de Desarrollo
De Tesis Asoajedrene, la enciclopedia libre.
Existe un acuerdo general creciente sobre el tipo de actividades que deben ser realizados con respecto al producto del software: modelado o análisis, diseño, implementación, 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 aplicación (ej. la escalera de caracol y modelo de la cascada). En este respecto, el proceso de construcción basado en la aplicaciones web (o más general hypermedia) las que no son inherentemente diferentes desde que el primero que usó cuando construyo aplicaciones convencionales o sistemas de gestión.
En el dominio de la hypermedia hay requerimientos contradictorios que deben ser satisfechos en una estructura unificada. En el manual, de la aplicación final, la navegación y la conducta funcional debe integrarse transparentemente. Por otro lado, durante el proceso del diseño se debe ser capaz al desacoplar decisiones de diseño relacionadas con la estructura de navegación de aplicación de aquéllas relacionados con el propio modelo del dominio. Desde que la mayoría al que los ambientes de implementación no dan apoyo completo al soporte de conceptos orientados a objetos, los modelos de diseño deben traducirse fácilmente en las plataformas existentes.
Según OOHDM, el desarrollo de aplicaciones de hypermedia ocurre cuando cuatro actividades se procesan:
- El Modelo Conceptual
- Diseño de la Navegación
- Diseño Interfaz Abstracta
- Implementación
Que se realiza en una mezcla de estilos de desarrollo iterativo e incremental; en cada paso un modelo será construido o mejorado.
Los principios básicos del método de OOHDM son:
- Contempla los objetos que representan la navegación como vistas de los objetos detallados en el modelo conceptual.
- El uso de abstracciones apropiadas para organizar el espacio de la navegación, con la introducción de contextos de navegación.
- La separación de las características de interfaz de las características de la navegación.
- Una identificación explícita que hay en las decisiones de diseño que sólo necesitan ser hechos en el momento de la implementación.
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 características a resaltar en la misma incrementando los resaltados de la fase o fases anteriores.
El punto de partida es la elaboración de modelo del dominio de la aplicación, 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: aquéllas que serán en el futuro percibidos como nodos en el modelo de navegación (llamados Objetos de la Entidad por Jacobson [Jacobson 92]); y aquellos que proporcionan soporte computacional para la aplicación 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 navegación de la información específica.
Un aspecto esencial distintivo de aplicaciones de hypermedia son las ideas o concepto de navegación en la que el usuario de una aplicación en este dominio navega en un espacio extendido de objetos. Estos objetos no son igual que los objetos conceptuales, si no más bien los objetos personalizados al perfil del usuario y tareas. Esta personalización se logró usando el mecanismo de vista entre los objetos, análogamente las vistas en la base de datos.
En esta fase, los atributos de los objetos de navegación son posiblemente (cortar y pegar) de varios atributos diferentes del objeto conceptual el cual es indicado por las cajas de diseño en Figura 1. Los objetos de la Navegación también pueden tener su propia conducta y pueden llevar a cabo funcionalidades más allá de leer páginas en Internet y la navegación, ej., actualizaciones y computación 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 Navegación es proporcionado coleccionando los objetos del espacio de navegación en conjuntos significativos llamados Contextos de navegación. Hay varios posibles criterios por definir tales colecciones de nodos, basados en atributos de la clase y conexiones. Durante el Diseño de navegación se define también la manera en que la navegación procederá especificando transformaciones en el espacio de navegación, es decir la colección de objetos de navegación accesibles en un momento dado.
Los objetos de la navegación no son percibidos directamente por el usuario; más bien, ellos son accedidos mediante los objetos de la interfaz. De acuerdo con el Diseño de la Interfaz Abstracto, especifica objetos de la interfaz que son responsables para mediar interacción del usuario con objetos de navegación. El modelo de la interfaz especifica qué objetos de la interfaz el usuario percibirá; qué objetos de la interfaz activarán navegación; cómo los objetos de la interfaz serán sincronizados; y las transformaciones de la interfaz que tendrán lugar.
Finalmente, la fase de la implementación es responsable para trazar objetos conceptuales, los objetos de navegación de la interfaz sobre un ambiente particular de tiempo de ejecución que es asignado. Cuando el ambiente de implementación designado no es totalmente orientado a objetos, se tiene que trazar la interfaz conceptual, de navegación y abstracta dentro de los objetos concretos, es decir esos disponibles en el ambiente de aplicación escogida. Esto puede involucrar definiendo paginas HTML, Scripts en algún lenguaje, consultas en una base de datos relacional, etc., de esta manera el autor produce la hypermedia actual de la aplicación para ser ejecutado.
Modelo conceptual. Figura 1 - Relación entre Modelo Conceptual, de Navegación y Objetos de la Interfaz en OOHDM. Las Clases de la Navegación son vistas sobre de las Clases Conceptuales; Objetos de la interfaz mediante la interacción de Objetos de la Navegación con el mundo externo, incluyendo usuarios. (Posición de las cajas sombreada para los Atributos de la Clase).
A continuación se describirá cada actividad con más detalle y se discutirá con ejemplos concretos la manera en la que cada formalismo del diseño ayuda a ganar asimilación de la hypermedia, y también aplicaciones basadas en la Web. Se define cómo el diseñador procede desde el Diseño Conceptual a través del Diseño de la Navegación al Diseño de la Interfaz y la Implementación.
Tabla de contenidos |
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 serán modificados durante su ejecución, se podría usar un modelo semántico estructural [Banerjee87], sin embargo, cuando la base de información puede cambiar dinámicamente o si se piensa realizar cómputos 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 sub-sistemas. 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 notación 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 documentación, ayudando remontar decisiones de diseño enviados y al revés.
Procesos diferentes de modelo de objeto o modelo Conceptual y el diseño son pensados y discutidos por:
Las metodologías orientadas a objetos y bibliografía 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 diseño que afectan tal estructura.
Se describe un modelo de primitivas brevemente en los párrafos siguientes.
Como la mayoría de ellos son variaciones ligeras de su equivalente modelo orientado a objetos y métodos de diseño, no se elaboran más allá. En cambio, se enfoca adelante esos problemas que afectan la actividad del diseño de navegación.
En OOHDM el esquema de la clase consiste en una colección de clases conectado por relaciones. Los objetos son instancias de clases, y de esa manera, cuando una relación se mantiene entre las clases. Las Clases se usarán después, durante el Diseño de navegación para derivar Nodos, y las Relaciones que serán usadas para derivar Enlaces (Links).
En Figura 2, se observa un modelo conceptual simplificado de un almacén de discos compactos. Los objetos de clase del Cliente serán responsables procesar las peticiones relacionadas con arreglos para requisitos particulares individuales como. El modelo conceptual en OOHDM incluye el modelo de la clase en métodos 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 relación como un atributo, un método o una combinación de ambos es un problema de diseño que ha sido principalmente discutido en el objeto de comunidad. Como una alternativa, situacional se acerca como responsabilidad de Wirfs-BrockÕs manejo de diseño [Wirfs-Brock 90] servicio que usa diagramas de la colaboración en lugar de relaciones en el estilo de UML.
Desde el punto de vista diseño de hypermedia las relaciones expresan un aspecto importante del dominio de la aplicación y ellos no deben esconderse en clase atributos (por lo menos hasta que se necesita llevar a cabo esas clases). Esto significa que una relación debe especificarse siempre que un atributo represente una entidad conceptual compleja intentada para ser explorada en la hypermedia final. De hecho, cuando la implementación 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 método y quizá accede a una variable del caso. En [Lange94], una extensión a la clase diagrama de OMT [Rumbaugh91] se presenta para reforzar relaciones.
En esta aproximación de diseño, se proporcionan tres construcciones de abstracciones: Agregación, Generalización / Especialización y un concepto del empaquetamiento de Sub-sistemas. El primero es útil para describir clases complejas como agregación es más simple y el segundo para construir Jerarquías 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 decisión de modelo que puede variar de la aplicación a aplicación. Dado que la agregación es una relación estructural importante, se sugiere descomponer un objeto en partes cada tiempo se supone que estas partes son exploradas en la aplicación de la hypermedia como no-atómico. Existiendo heurísticas en el dominio del modelo orientado a objetos puede usarse para identificar estructuras de agregación.
Se usa la misma semántica 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 Traducción 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 basico conceptual para CMS ASOAJEDRENE.
Usando la conducta del modelo orientado a objeto para describir aspectos diferentes de una aplicación de hypermedia permite expresar una gran variedad de actividades de la informática como preguntas dinámicas a una base objeto, las modificaciones del objeto on-líne, búsquedas basadas en heurísticas, etc. El tipo de funcionamiento requerido en el modelo conceptual depende en los aspectos deseados de la aplicación. Para muchas aplicaciones, en particular, aquélla implementación que llevan a cabo un Browser (es decir sólo leer) la funcionalidad, comportamiento de la clase, más allá de la funcionalidad de conectarse puede parecer innecesario. En este caso, el comportamiento llega a acceder una base de información de multimedia navegando encima de las relaciones, y podría ser "integrado" en el propio modelo.
En contraste, en aplicaciones en las que la base de información subyacente puede que cambie dinámicamente como el efecto de acciones del usuario, o cuando la red de hypermedia es simplemente un componente de una aplicación corporativa más grande, se puede necesitar definir métodos que implemente ese comportamiento en clases conceptuales. Durante el diseño Navegacional y el Diseño de Interfaz, se especifica la manera en que la interfaz de objetos activa el comportamiento de ambos en el modelo de navegación y conceptual.
Desde que OOHDM es un método de Diseño y no un armazón de aplicación, se asume que los métodos para lograr el valor de atributos de un objeto son automáticamente generados. Cuando deben hacerse otros cómputos y deben corresponderse deben especificarse métodos. Usando la terminología de métodos orientado a objetos se puede decir que el Modelo Conceptual contendrá aspectos de Modelos de Análisis y Diseño.
Cuando la aplicación se ejecute en un ambiente de soporte (distribuido) de objetos, las clases en el modelo conceptual serán implementadas directamente como están definidos, que especifican perspectivas múltiples como atributos separados. Si no, ellos servirán como especificaciones de diseño para el de navegación y actividades de diseño de interfaz. En la Tabla1 se esquematiza esta fase:
Diseño Navegacional
La primera generación de aplicaciones de multimedia intentaba realizar la navegación a través de un espacio de información 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 diseñadores de Multimedia y Web Sites.
El mayor esfuerzo de diseño normalmente se ha puesto en aspectos de interfaz del usuario y la estructura de la navegación se construye en jerarquías 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 navegación a ser considerada simplemente otro tipo de de comportamiento de aplicación.
En OOHDM, la navegación es considerada un paso crítico en el diseño de una aplicación de hypermedia. Un Modelo de navegación se construye como una vista más de un modelo conceptual y permite la construcción de modelos diferentes según los perfiles diferentes de los usuarios. Cada modelo de navegación proporciona una vista "Subjetiva" del modelo conceptual.
Mientras se diseña la estructura de navegación de una aplicación Web, se tiene en cuenta varios aspectos como:
¿Que objetos serán 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 composición existe entre los objetos de navegación y cómo son relacionados?
¿Cuál es la estructura fundamental de navegación?
¿En qué contexto el usuario navegará?
Se introducirá el concepto de contextos de navegación, una arquitectura primitiva para organizar el espacio de la navegación. Se necesita decidir los objetos navegados que pueden parecer diferentes según 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 serán navegados (enlaces, trayecto de búsqueda, camino o trayecto, índices, etc.)? ¿Cómo procede la navegación cuando el usuario salta "Jump" de un objeto a otro, es decir, lo que es el efecto de navegación en la fuente "source" y en el destino "target object" y posiblemente en otro objeto relacionado también?
El diseño de navegación se expresa en dos esquemas, el esquema de la Clase De navegación, y el Esquema del Contexto De navegación. Los objetos navegables de una hypermedia en la aplicación es definida por un esquema de la clase navegacional cuyas clases reflejan la vista escogida sobre del dominio de la aplicación. En OOHDM, hay un juego de tipos pre-definidos de clases de navegación: nodos, links o enlaces, y estructuras de acceso. La semántica 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 básicos de información de las aplicaciones hipermedia. Se definen como vistas orientadas a objeto de las clases definidas durante el diseño conceptual usando un lenguaje basado en query, permitiendo así que un nodo sea definido mediante la combinación de atributos de clases diferentes relacionadas en el modelo de diseño conceptual. Los nodos contendrán tanto atributos de tipos básicos (donde se pueden encontrar tipos como imágenes o sonidos) y enlaces.
- Enlaces: Los enlaces reflejan la relación de navegación 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 navegación o como un puente de conexión entre dos nodos.
- Estructuras de Acceso: Las estructuras de acceso actúan como índices o diccionarios que permiten al usuario encontrar de forma rápida y eficiente la información deseada. Los menús, los índices o las guías de ruta son ejemplos de estas estructuras. Las estructuras de acceso también se modelan como clases, compuestas por un conjunto de referencias a objetos que son accesibles desde ella y una serie de criterios de clasificación de las mismas.
- Contexto Navegacional: Para diseñar bien una aplicación hipermedia, hay que prever los caminos que el usuario puede seguir, así es como únicamente se podrá evitar información redundante o que el usuario se pierda en la navegación. 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 navegación (enlaces, nodos o estructuras de acceso), pudiendo ser definidas por extensión o de forma implícita.
- Clase de Contexto: Es otra clase especial que sirve para complementar la definición de una clase de navegación. Por ejemplo, sirve para indicar qué información está accesible desde un enlace y desde dónde se puede llegar a él.
La especificación de las Transformaciones de Navegación describe la dinámica de la aplicación, mostrando los cambios espaciales de navegación 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 semántica de navegación predefinida en OOHDM es que cuando un enlace es continuado, el nodo de la fuente se deja desactivado y el nodo objetivo activado. Esta interpretación normalmente es el valor por defecto encontrado en los navegadores (Browsers) de Web.
De una manera análoga, los enlaces reflejan que las relaciones pretenden ser exploradas por el usuario final y también se define como vistas en relaciones en el esquema conceptual. Los enlaces conectan objetos de navegación y pueden ser uno-a-uno o uno-a-muchos.
Figura 4 Esquema basico 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 definición de semántica navegacional proceduralmente como resultado de la conducta del enlace o usando una máquina de transición de estado orientada a objeto similar a Statecharts [Rossi 96d], las estructuras de Acceso (índices) son también definidos como clases y maneras alternativas presentes para la navegación en la aplicación de la hypermedia. En términos 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 patrón o modelo de diseño 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á trazándose). El nodeClass, es el nombre de la súper-clase Los attri, son los nombres de atributos para esa clase, typei los tipos del atributos. Los namei de · son los asuntos para la expresión de la pregunta y los
Si se toma en cuenta el ejemplo anterior, sobre producirá la definición del Nodo siguiente:
Note que el valor del atributo del toAuthor es un enlace que es el parámetro 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 botón invisible sobre del nombre del autor (autor del atributo). Aunque puede que parezca que ambos atributos tienen la misma conducta, sólo el enlace actúa en contestación a un evento de la interfaz.
La Figura 3 contiene un esquema de navegación para el CMS ASOAJEDRENE, como se ejemplificó en el párrafo anterior.
Figura 3 Modelo de Clases para CMS ASOAJEDRENE.
Las aplicaciones hypermedia bien diseñadas deben tomar en cuenta la manera qué el usuario explora el espacio de la hypermedia. La información 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 solución usual a este problema es llevar a cabo herramientas de orientación, también se piensa que nivel más alto que deben ser usados por primitivas de navegación arquitectónicos.
Este es el punto donde los contextos de navegación aparecen.
En OOHDM, la estructuración principal primitiva del espacio de navegación es el concepto de Contexto de Navegación. Un contexto de navegación es un conjunto de nodos, enlaces, contexto, clases y otros contextos de navegación (anidados).
- 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 común es cuando incluye todas las instancias de una clase (P es idénticamente verdad). Como en el ejemplo todas los Storys.
- 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 parámetro y permitiendo que el parámetro 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.
- Enlaces basados en Objetos, en este tipo de contexto son de la misma clase y son seleccionados cuando ellos pertenecen a la relación 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.
- Enlaces basados en grupo - Es un juego de contextos cada uno de los cuales son un enlace basado en contexto. Es especificado dando una relación de 1 a n y formando el enlace basado en contextos para cada posible valor de la fuente de la relación.
- Enumerar - En este tipo de contexto, se enumeran elementos explícitamente, y puede pertenecer a las clases diferentes. Además de sus elementos, hay otra dimensión a lo largo de contexto los cuales serán definidos, relativo a una sesión de la navegación. Si los elementos de un contexto pueden variar como una consecuencia de la navegación por el usuario, se dice que el contexto es dinámico. 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 través de los objetos (por ejemplo, libros). Los dos son casos de Contextos Dinámicos enumerados. Si la aplicación permite la creación o modificación de objetos (instancias de clase), todo el contexto derivado desde estos objetos (clases) será dinámico también; el mismo es verdad en el caso de creación 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 navegación 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.
Diseño 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 navegación aparecerán, qué objetos de navegación de la interfaz se activara y otra funcionalidad de aplicación, y qué transformaciones de la interfaz tendrán lugar y cuando.
Una separación ordenada entre ambas preocupaciones, de navegación y diseño de interfaz abstracta, permite construir interfaces diferentes para el mismo modelo de navegación, llevando a un grado más alto de independencia de tecnología de la interfaz de usuario. En suma, esta separación permite entender mejor la aplicación global de la estructura para indicar qué transformaciones claramente en la interfaz serán 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 crítico, moderno, las metodologías tienden a descuidar este aspecto. Ellos relegan la especificación para herramientas de implementación-dependientes, y por consiguiente las decisiones de diseño en este nivel raramente se documentan. Es más, como llevar a cabo la interfaz de la Web normalmente se hacen aplicaciones por medio de los editores de HTML especializados, muchos críticos pueden ignorar aspectos de la interfaz.
En OOHDM, se usa un acercamiento del Diseño de Datos de Vista Abstractos (ADVs), para describir la interfaz del usuario de una aplicación de hypermedia [Cowan 95]. ADVs son objetos en los que tienen un estado y una interfaz, donde la interfaz puede ser ejercido a través de mensajes (en particular, eventos externos generados por el usuario). Las ADVs son abstractas en el sentido de que ellos sólo representan la interfaz y el estado, y no la aplicación. Las ADVs han sido usados para representar interfaces entre dos medios de comunicación diferentes como un usuario, una red o un dispositivo (un cronómetro, 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 arquitectónico, las ADVs son observadores para ADOss, para que el protocolo de comunicación entre la interfaz y los objetos de aplicación siga las reglas descritas en el Modelo de Diseño de Observador [Gamma 95].
En la Figura 4 se observan los datos abstractos jerarquizados, "cuadro", "descripción", "interfaz del contexto", "descripción de la demostración" y las "referencias de la demostración" exhiben un comportamiento usuario-perceptible. Por ejemplo cuando el usuario corre la "descripción de la demostración" en los ADV se exhibe la "descripción". la "interfaz del contexto" alternadamente se compone de las anclas que ponen en ejecucion jerarquizadas de ADVs para la navegación del contexto, basicamente una vision simple del diseño final de las pantallas.
Figura 4 Diagrama de Configuracion 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 diseño 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 percepción, 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 fácilmente 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 posición, 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 aplicación. En general, los ADVs especifican la organización y el comportamiento de la interfaz, pero la apariencia física real o de los atributos, y el diseño de la ADV en la pantalla real se hace en la fase de la implementación.
En el contexto de OOHDM, los objetos de navegación como nodos, e índices actuarán como ADOs, y su ADVs asociados se usará para especificar su apariencia al usuario. A continuación se usará el término 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 composición son usados en el diseño de ADV; primero las ADVs pueden ser compuestas por agregación o composición de ADVs de nivel mas bajo, permitiendo la construcción de usuarios de interfaces así con objetos perceptibles anidados. Por ejemplo, supóngase que se tiene una aplicación sobre pinturas. Figura 9 muestras cómo un ADV que describe una pintura pudiera hacerse fuera de tres ADVs, conteniendo una imagen, texto, y un botón. Además, ADVs pueden ser organizados en jerarquías del generalización/especialización que proporcionan un poderoso armazón conceptual por definir jerarquías de objetos de la interfaz.
Figura 5 Nodo ADV referente a la pagina de Descargas del CMS ASOAJEDRENE.
En Figura 5, "Texto Buscar" es un Objeto de la Interfaz que envia un conjunto de anclas o enlaces al TextField (Campo de texto) más general. Entretanto el "Boton Buscar" especializado agregando una conducta más personalizada (no mostrado en la Figura). Cuando se implementa esta aplicación Web usando un ambiente de soporte de ciertos tipos de objetos de interfaz, se puede usar como ADVs primitivos para producir esta especificación de diseño.
En resumen, ADVs:
La manera en que se estructuran objetos de la interfaz usando agregación y generalización/especialización como mecanismos de abstracción. ADVs expresan la estructura del esquema estático que lleva a cabo la metáfora de la interfaz [Hannemann 93]. Las ADVs permiten definir la apariencia de la interfaz de objetos de navegación y otros objetos de la interfaz útiles (como barras del menú, botones y menús).
Se muestra un ADV correspondiente al Diseño del sitio Web Portinari (http://www.portinari.org.br /) un aplicación de hypermedia que contiene parte del trabajo y documentos relacionados de Candido Portinari, pintor brasileño 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 notación 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 navegación dentro del Contexto De navegación: 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 estática de interfaces de Pictures (Cuadros), las dinámicas son descritas usando ADV-mapas, se especifica que cuando ShowPeople es clicked (pulsar el botón), envía 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), envía 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. Aún cuando la aplicación no es orientada a objetos, este modelo de comunicación es fácil de implementar en la mayoría de las plataformas. Para acabar esta sección se muestra la interfaz real del sitio Web Portinari y como los objetos de la interfaz están relacionados con sus partes equivalentes implementados.
Implementación
En esta fase, el diseñador realmente implementará el diseño. Hasta ahora, todos los modelos fueron deliberadamente construidos de semejante manera en lo que se refiere a ser independiente de la plataforma de implementación; en esta fase el ambiente particular de (tiempo de ejecución) runtime se toma el derecho de acceso a un servidor o a la red internet. A continuación se fijará cómo los diseños de OOHDM pueden ser implementados en el WWW, tener cuidado para no arreglar una sola alternativa, desde que hay muchos acercamientos posibles a través de los cuales esto puede ser logrado. Cuando la fase de implementación se alcanza, el diseñador ya tiene definido los artículos de información que son parte del dominio del problema. También tiene identificado cómo estos artículos deben ser organizados según el perfil del Usuario y asignaciones; ya que se ha decidido lo que la interfaz se parecerá, y cómo se comportará. En orden para implementar todos esto en el ambiente de WWW y aplicaciones de multimedia, el diseñador tiene que decidir cómo los artículos de información (ambos conceptual y objeto de navegación) será almacenada. También debe decidir cómo se comprenderán la apariencia de la interfaz y el comportamiento serán realizados usando HTML y posiblemente use algunas extensiones. En general, note que la apariencia actual será definida por un profesional de diseño gráfico que será parte el equipo de Diseño. Aunque OOHDM es un método en términos de modelos de OO orientados a objetos, no requiere un ambiente de aplicación OO; (pero no en la Web) se describe en [Milet 96]; las aplicaciones basadas en Java son de baja tendencia. Tabla 4 obsérvese un resumen de esta fase.
Fase Implementación Productos Aplicación ejecutable. Herramientas El entorno del lenguaje de programación. Mecanismos Los ofrecidos por el lenguaje. Objetivo de diseño Obtener la aplicación ejecutable. Tabla 4: Fase de Implementación de OOHDM
Mapeo de Información de artículos
Los artículos de información (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 mas conveniente, recuérdese usar una base de datos para guardar los objetos Conceptuales y de Navegación.
Desde la mayoría 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 técnicas y heurísticas para hacer esto. Los métodos asociados con las clases son implementados como un conjunto de procedimientos que acceden a la base de datos para ejecutar sus cómputos.
Para ilustrar el tipo de decisiones de diseño, 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 función) 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 asociación extra, y segundo es vulnerable a los cambios fuera del control del DBMS. Desgraciadamente, esto sólo puede evitarse si el DBMS ofrece soporte para tipos de datos complejos, como es adecuado lo más común en la última generación de productos que llegan al mercado. En sección se declaró que el Modelo de la Navegación ha terminado una vista del Modelo conceptual. El diseñador tiene la opción de reflejar esta organización en la base de datos que corresponden a cada modelo. En otras palabras, él puede definir la base de datos conteniendo los objetos de Navegación (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 diseñador tiene la opción a la mano la vista de informática. En este caso, solo quiere llevar a cabo al modelo de la Navegación, desde que es el primero que el usuario estará accediendo. Evidentemente, esta alternativa tiene limitaciones o anomalías en términos de evolución del esquema el cuál 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 compañías tienen sitios en su intranets, y la parte de estos sitios es visible (normalmente con una interfaz diferente) en el WWW. Además de trazar definiciones de la clase en el modelo del banco de datos cualquier (correlativo, OO, etc...) usándose, también es necesario llevar a cabo clase "InContext" que funcionan como decoradores para los objetos dentro de los contextos particulares. Típicamente, 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 implementación esta directamente basada en el sistema del archivo, éstos controlan las funciones que accederán a archivos adicionales que contienen la información 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 técnicas puede emplearse. En este respeto, el criterio para escoger el método de la integración será igual que otras aplicaciones, como se discutió en la teoría.
Usando OOHDM
Los modelos usados en las cuatro fases abordadas en la sección anterior son suficientes para permitir el plan de sistemas de información basados en la Web. No obstante, como con cualquier método, hay conocimiento adicional en el que es recogido por diseñadores en prácticas, que no es parte del propio método. La investigación acerca de OOHDM incluye varios desarrollos en esta dirección fuera de la que está llevándose, a continuación se dará un cuadro global brevemente de OOHDM y la investigación relacionada.
Figura 1. Ambiente OOHDM-Web. Fuente: Ribeiro M. OOHDM-Web Manual do Usuário
Un método que ha sido usado recientemente captura conocimiento del diseño, sobre todo en el campo de OO orientado a objetos, es el uso de Modelos de Diseño los cuales se nombran sistemáticamente, explique y evalúe diseños importantes y recurrentes en sistemas del software. Ellos describen problemas que ocurren repetidamente, y describen el centro de la solución a ese problema, de semejante manera se puede usar esta solución muchas veces en diferentes contextos y aplicaciones. Mirando usos conocidos de un modelo del diseño particular, se puede ver cómo un diseñador exitoso resuelve problemas recurrentes. De esta manera, se exige esto usando a diseñadores de prototipos de diseño pueden ganar desde conocimiento del diseño en el que existe varias comunidades, como hypermedia o diseño de interfase de usuario. Se ha estado coleccionando modelos de diseño conveniente para la aplicación del diseño de hypermedia [Rossi 97]. El objetivo es desarrollar un sistema de modelos inter-relacionados bastante compactos para poder expresar diseños completos como la aplicación sucesiva de modelos en este sistema. Se ha estructurado estos modelos en tres sub-grupos, particularmente arquitectónico, navegación y modelos de la interface. Los modelos arquitectónicos 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 navegación de desacoplar de otros tipos de conductas, organizando jerarquías de links y fin tipos de nodos, desacoplar link de activación del proceso de determinar el punto extremo del link. Más detalles pueden encontrarse en [Rossi96a, Garrido 97].
Modelos en la ayuda de categoría de navegación la organización de la estructura navegacional de una aplicación de hypermedia para lograr aclarar y significativo para los lectores deseados. Ellos dirigen problemas recurrentes cuya solución determina el grado de éxito de aplicaciones de hypermedia. Un ejemplo interesante de una navegación el modelo es el modelo de "Referencia Activa" cuya meta es proporcionar una referencia perceptible y permanente sobre el estado actual de navegación. Combina herramientas de orientación con una manera fácil de navegar a un juego de nodos relacionados, al mismo o posición más alta en la estructura de la navegación. 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 navegación. Por ejemplo, en http://city.net/countries / brazil/rio_de_janeiro, hay una barra con una representación del camino lógico de la raíz 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 Río de Janeiro. Vea [Rossi 97] para una descripción completa de este modelo.
Modelos de la interfase significa para diseñadores de GUI de Hipermedia. Ellos son abstractos y por consiguiente independientes del ambiente usado para la implementación.
El diseño de la interfase gráfica es una tarea compleja, relacionada principalmente con encontrar el combinación correcta de elementos (ambos en cantidad y en sus relaciones espaciales), de tal manera que esos elementos actúan recíprocamente para una presentación eficaz de la información.
También pueden aplicarse modelos en este grupo fuera del área de aplicaciones de hypermedia, en el contexto más extenso de diseño de GUI. Por ejemplo el diseño de patrones "Desacoplar Información/Interacción" modelo de diseño es apuntar a resolver el problema de cómo hacer la interacción entre la aplicación y el usuario, a la interfase gráfica de un nodo. Este modelo es particularmente útil en sitios Web cuando se generan páginas dinámicamente 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 colocación física de links de la navegación. El diseño de patrones de "Behavioral Grouping" ayuda al diseñador a construir una interfase de semejante manera que el usuario puede fácilmente 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 transacción, deben proporcionarse navegación y funcionalidades de la interfase simultáneamente. Una descripción más profunda de modelos de la interfase puede encontrarse en [Garrido 97].
Aunque se ha declarado que ese Diseño de la Navegación debería hacerse tomando en cuenta a los perfiles de usuario y tareas, el propio OOHDM no proporciona, hasta ahora, cualquier indicación en cómo 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 típicas para ser apoyado por la aplicación.
El método pensado empieza con un modelo conceptual preliminar dibujado por el diseñador desde su comprensión del dominio. Observando escenarios descritos por clases diferentes de usuarios, el diseñador construye la navegación parcial, y esquemas de Clase de navegación parcial. Después de que todos los guiones se han analizado, el diseñador empieza un proceso de anexar los senderos parciales y esquemas con los que culminan un Diagrama de Contexto de navegación y un esquema de Clase de Navegación actualizado.
En el curso de esta investigación, 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 dinámicos que se construyen como resultado de acciones del usuario especificadas.
Otro problema importante está construyendo ambientes del software para dar soporte al método; ha seguido dos acercamientos diferentes:
- Se ha construido un ambiente de un CASO que le permite a un diseñador describir el concepto de navegación y modelos de la interfase que usan la notación de OOHDM y le proporciona la documentación automatizada sobre esos modelos. Él puede luego generar plantillas de implementación para las escenas diferentes, como Asymetrixs, Toolbook o HTML. (Vea [Lyardet 96]).
- Se ha diseñado e implementado un prototipo orientado a objetos (OONavigator) para reforzar sistemas de información orientados a objetos, mejorando el acceso a sus recursos de información agregando un frontal "navigational", transparentemente, integrando esta funcionalidad de la navegación 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 aplicación y su interfase. La clase de aplicación presenta el papel de clases conceptuales de OOHDM, mientras los objetos de prototipo (nodos y links) comprendan el componente de navegación de la aplicación. Se ha enriquecido los MVC estándar paradigma de interfase [Krasner 88] con fijar medios de semejante manera que el apoyo a la metáfora 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 diseñador puede enriquecer la aplicación -orientada a objetos con características de hypertext siguiendo pautas de OOHDM. En este caso la hypermedia de "instantiates" de diseñador y clases de la interfase (usando una herramienta visual) y conectarlos a sus clases de la aplicación para permitir navegación a través del espacio de información de aplicaciones. (Vea [Garrido 96, Rossi, 98a, Rossi98b])
Conclusiones y Recomendaciones
Trabajo relacionado:
Cuando se dice previamente, las metodologías para el diseño de aplicaciones Web aún en su infancia (con tal de que la Web también es); existiendo métodos tienden a descuidar cualquier navegación o los aspectos del behavioral (comportamiento) de aplicaciones de la web.
En [Takahashi 97] los autores proponen usando una extensión de RM [Izakowitz 95] como el método de apoyo por construir sistemas de información de Web. Ellos enriquecen la entidad-relación 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 información estructurados; en lugar de usar objetos ellos construyen la conducta de aplicaciones de una manera artificial estática de separación y los modelos dinámicos. Métodos similares para la estática de separación de aspectos dinámicos 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 notación de UML por ejemplo en [OMG 00]). Esto pasa porque ellos producen sistemas que son difíciles extenderse y mantener. Del punto de vista de la hypermedia, el método es más fuerte porque proporciona nivel más alto diseño de primitivas, como Contextos de navegación de los que permiten una organización mejor, en el hyper-espacio. Además, separando el aspecto de diseño 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 diseño de interfaz son un paso en esa dirección.
De un punto de vista arquitectónico, las preocupaciones de separaciones entre conceptual, de navegación y auxilios de objetos de interfaz para producir aplicaciones a las que son más fáciles extiéndase y/o mantenga. Esto pasa porque las relaciones entre los objetos en los niveles diferentes siguen el tipo de colaboraciones en modelos de diseño bien-probado (tal como el Observador). La metodología puede usarse como un diseño front-end (o la parte de una aplicación que es responsable de la interfaz) para esta herramienta de la ingeniería. Además, cuando se ha discutido sobre esto, la filosofía subyacente detrás de OOHDM que proporciona artefactos de diseño que pueden ser llevado a cabo incluso al no usar orientado a objetos o las herramientas híbridas.
Finalmente, cuando se menciona previamente, OOHDM proporciona una dimensión del diseño eso es normalmente abandonado en ambientes orientado a objetos y metodologías: la actividad del diseño de navegación por ejemplo. Productos buenos orientados a objetos para las aplicaciones de Web, como VisualWave o ClassicBlend, puede usarse con metodologías modernas como OOSE [Jacobson92] o UML [OMG 00]. Sin embargo, no consideran navegación como un problema de diseño, y se construyen aplicaciones usando las dos particiones de diseño de nivel usual. La única diferencia es que las interfaces se generan como una combinación de HTML y applets de Java. Como en otros casos, hay varios y más recientes herramientas en el mercado, como NetObjects "Fusion" que mira las aplicaciones WWW basados en ("sitios Web") como más de una colección de páginas no estructuradas de HTML. Ellos permiten la definición de (visual) visuales (plantillas o templates) para ser aplicado uniformemente a las páginas en el sitio que es un camino en la dirección correcta. Sin embargo, ellos todavía confunden la topología de la navegación con la estructura del directorio físico usadas para almacenar las páginas en el sitio. Por consiguiente, dada la página puede tener sólo un "siguiente" para compaginar (o una pagina "parent", padre), independientemente de la manera que el lector ha llegado a él. Además, se cree firmemente en el diseño de la interfaz debe hacerse separadamente del diseño de la navegación.
