2.3-Ingeniería del software de multimedia

Las metodologías tradicionales de ingeniería de software, o las metodologías para sistemas de desarrollo de información, no contienen una buena abstracción capaz de facilitar la tarea de especificar aplicaciones hipermedia. El tamaño, la complejidad y el número de aplicaciones crecen en forma acelerada en la actualidad, por lo cual una metodología de diseño sistemática es necesaria para disminuir la complejidad y admitir evolución y reusabilidad.

En hipermedia existen requerimientos que deben ser satisfechos en un entorno de desarrollo unificado. Por un lado, la navegación y el comportamiento funcional de la aplicación deberían ser integrados. Por otro lado, durante el proceso de diseño se debería poder desacoplar las decisiones de diseño relacionadas con la estructura navegacional de la aplicación, de aquellas relacionadas con el modelo del dominio. OOHDM propone el desarrollo de aplicaciones hipermedia a través de un proceso compuesto por cinco etapas: determinación de Requerimientos, diseño conceptual, diseño navegacional, diseño de interfaces abstractas e implementación.

2.3.1 Etapa de Análisis

OOHDM es una metodología orientada a objetos que propone un proceso de desarrollo de cinco fases donde se combinan notaciones gráficas UML con otras propias de la metodología. En la siguiente figura se grafican las cinco etapas de OOHDM.

fig. 2.8 . Las cinco etapas de la metodología OOHDM

Obtención de requerimientos

Como en todo proyecto informático la obtención de requerimientos es una de las etapas más importantes, la mayoría de los estudios entregan resultados claros que los errores más caros son los que se cometen en esta etapa.

Para enfrentar esta dificultad, dividiremos esta etapa en cuatro subetapas: Identificación de roles y tareas, Especificación de escenarios, Especificación de casos de uso y Especificación de UIDs

Requisitos de la multimedia

Requisitos funcionales

1. Acceder por Unidad

1.1 Acceder por Tema

Requisitos de interfaz (al usuario

• Interfaz grafica didáctica y de fácil manejos para el estudiante

.

Requisitos navegacionales.

• Permitirle al estudiante una navegación libre por la multimedia, no necesariamente secuencial

Identificación de roles y tareas

En esta subetapa se introduce cuidadosamente en el dominio del sistema, identificamos los diferentes roles que podrían cumplir cada uno de los potenciales usuarios de la aplicación.

Los usuarios juegan roles importantes en cada intercambio de información con el sistema.

Luego para cada rol se identifico las tareas que deberá soportar la aplicación

Identificación de roles y tareas

Roles

Alumnos- son los únicos usuarios que tendrá la multimedia ya que toda el que la use tendrá como objetivo el aprendizaje de la metodología RUP.

Tareas

1. Acceder por Unidades

1.1 Acceder por Temas

Representación en diagramas

fig. 2.9 Diagrama de casos de uso

Especificación de escenarios

Los escenarios son descripciones narrativas de cómo la aplicación será utilizada

• Acceder por Unidades – Un alumno podrá ver todos las unidades y dentro de el acceder a el Tema deseado.

Acceder por Tema – El alumno podrá una vez escogido la Unidad ir al epígrafe deseado y así llegar a los contenidos

Especificación de los casos de uso

Un caso de uso es una forma de utilizar la aplicación. Específicamente representa la interacción entre el usuario y el sistema, agrupando las tareas representadas en los escenarios existentes.

• Acceder por Unidades

Roles: Alumnos

Descripción

1. El alumno accede a una Unidad

2. Dentro de el tema accede a un Tema

3. Sigue de forma secuencial accediendo por todos los contenidos de el epígrafe

• Acceder por Tema

Roles: Alumnos

Descripción

1 Una vez que el alumno halla accedido al tema puede acceder a cualquier epígrafe.

2 Cuando termine el Tema no tiene que seguir de forma secuencial por los contenidos sino que puede acceder a otro Tema.

Especificación de UIDs

De acuerdo a UML, los diagramas de secuencia, de colaboración y de estado son capaces de representar un caso de uso. Sin embargo, la especificación de casos de usos usando estas técnicas es un amplio trabajo y puede anticiparse inesperadamente a tomar algunas decisiones de diseño (VILAIN October 2000). Para evitar esto OOHDM propone la utilización de una herramienta, llamada UID, que permite representar en forma rápida y sencilla los casos de uso generados en la etapa anterior.

Para obtener un UIDs desde un caso de uso, la secuencia de información intercambiada entre el usuario y el sistema debe ser identificada y organizada en las interacciones. Identificar la información de intercambio es crucial ya que es la base para la definición de los UIDs.

fig. 2.10 UID correspondiente al caso de uso “Acceder por Unidades

fig. 2.11 . UID correspondiente al caso de uso “Acceder por tema