PDF de programación - Prototipado de interfaces de usuario a partir de escenarios y modelos UML

126

WER2000

Prototipado de interfaces de usuario a partir de

escenarios y modelos UML1

Juan Sánchez Díaz; Alberto Aparicio Vila; Oscar Pastor López; Juan Jose Fons

Departamento de Sistemas Informáticos y Computación

Universidad Politécnica de Valencia.

Camino de Vera s/n. 46022.Valencia (España)

{jsanchez, aparicio, opastor, jjfons} @dsic.upv.es

Abstract. En este artículo presentamos un proceso de ingeniería de
requerimientos que genera de un modo automático prototipos de interfaces de
usuario a partir de escenarios, obteniéndose una especificación formal del
sistema en la forma de diagramas de transición entre estados. Esta
especificación se incluye dentro de un entorno de ejecución, pudiéndose animar
cada uno de los prototipos. Los escenarios se describen mediante message
sequence charts (MSC), enriquecidos con información referente a la interface
de usuario. El proceso utiliza un modelo de casos de uso. Para una familia de
casos, se genera un conjunto de MSC. Los diversos MSC se transforman en
diagramas de transición entre estados para los objetos de interface y de control.
A partir de estos, se genera un prototipo de interface de usuario formado por un
modelo de vistas por actor, un formulario por caso de uso y un modelo de
navegación entre formularios, esto último se obtiene a partir de las relaciones
entre los casos. Basándonos en la ejecución del prototipo y en la realimentación
de los usuarios del mismo, este puede ser modificado de forma iterativa desde
un entorno visual de construcción de interfaces de usuario. La propuesta,
soportada por una herramienta CASE, es apropiada para aplicaciones que
trabajen con bases de datos.

Keywords: Prototipos de interface de usuario, elicitación de requerimientos,
validación de escenarios.

1. Introducción

La primera etapa dentro de la concepción de un sistema informático consiste en
entender y representar de un modo apropiado los requerimientos de usuario. Este
proceso recibe el nombre de ingeniería de requerimientos y ha sido reconocido como

1 Trabajo subvencionado por el programa FEDER, con ref. TIC 1FD97-1102

III Workshop de Engenharia de Requisitos

127

una tarea crucial dentro del proceso de desarrollo (Bennett, 1997;Kotonya et al.
1998). Los errores originados en la etapa de requerimientos pueden permanecer sin
detección hasta la etapa de operación, provocando fallos con serias consecuencias
sobre todo en sistemas críticos.

Los errores en la etapa de elicitación de requerimientos están provocados
principalmente por el gap existente entre los usuarios y el proceso de desarrollo. A los
usuarios se le presenta una especificación abstracta del sistema, que en la mayor parte
de los casos, es incompresible para ellos.

El comportamiento de un sistema puede ser descrito de forma intuitiva mediante
la utilización de escenarios. Un escenario se define como una descripción parcial del
comportamiento de un sistema y su entorno que se da en una determinada situación
(Benner et al. 1993). La parcialidad de la descripción permite que un escenario cubra
o abarque partes del comportamiento del sistema. Esta una característica interesante,
ya que diferentes usuarios pueden percibir el sistema de forma diferente.

Los escenarios

son una herramienta valiosa para captar y comprender
requerimientos y para analizar interacciones hombre-máquina (Nielsen 1995). Un
proceso estándar de ingeniería de requerimientos, basado en escenarios (Somé et al.
1996), contiene dos tareas principales. En la primera, se generan especificaciones a
partir de los escenarios para describir el comportamiento del sistema. La segunda,
consiste en validar estos con los usuarios mediante simulación o prototipación. Las
dos tareas son tediosas si no están soportados por alguna herramienta automática o
semiautomática.

La etapa de validación se suele abordar en algunos casos utilizando herramientas
RAD (Desarrollo Rápido de Aplicaciones) (Kerr et al. 1994). En cualquier forma el
proceso de definir y generar el prototipo de la interface de usuario es un proceso
manual, ya que cada objeto debe crearse de forma explícita.

Nosotros estamos interesados en la validación de escenarios mediante la
generación automática de prototipos de la interface de usuario de la aplicación y la
ejecución simbólica de los mismos.

A diferencia de otras propuestas como las del grupo Gelo (Elkoutbi et al. 1999)
nosotros disponemos de una herramienta visual que permite automatizar casi todo el
proceso. Por otra, el método utilizado (véase sección 3 y posteriores) genera
automáticamente un modelo de navegación entre formularios, basado en las
relaciones usa/incluye y extiende entre los casos de uso.

En este artículo se presenta una propuesta metodológica y la herramienta
asociada que le da soporte, dentro del campo de la ingeniería de requerimientos,
basada en el lenguaje unificado de modelado (UML) y en los message sequence chart
(MSC) (ITU, 1996). La aproximación emplea un proceso iterativo, que permite
derivar de forma semiautomática, prototipos de la interface de usuario a partir de
escenarios, y una especificación formal del sistema en la forma de diagramas de
transición entre estados. Estos diagramas describen el comportamiento dinámico de
los objetos de interface y de los objetos de control asociados a cada caso de uso o
cada MSC. De las cuatro actividades del método, las iniciales no son automáticas,
necesitan la intervención del analista, mientras que las dos úlltimas automatizan el
proceso de validación de escenarios mediante prototipación.

128

WER2000

Este trabajo supone un avance cualitativo con respecto a trabajos nuestros
anteriores (Sánchez 1999, Sánchez et al. 1999), la información de la interfaz de
usuario se introduce en los MSC, los diagramas de transición generados ahora no son
directamente manipulables, la herramienta es más robusta que la herramienta inicial.

El artículo está estructurado como sigue:

la sección segunda introduce los
modelos de UML que utilizamos en nuestra propuesta, junto al ejemplo que ilustrará
el proceso de generación de los prototipos. La sección 3 contiene una discusión
detallada de las actividades y procesos contenidos en nuestra aproximación. Los
trabajos relacionadas se discuten en la sección 4. Finalmente, las secciones 6 y 7
contienen, respectivamente, las futuras líneas de trabajo y las conclusiones.

A lo largo del artículo se incluyen capturas de pantallas de la herramienta CASE

que da soporte al método.

2 El lenguaje unificado de modelado

El lenguaje unificado de modelado (UML) (Booch et al. 1999) se ha impuesto
como un estándar de hecho para la modelización de sistemas orientados a objetos. De
las diversas vistas o modelos que propone, nosotros utilizamos en nuestra
aproximación el modelo de casos de uso, los diagramas de transición entre estados y
una variante de los diagramas de interacción o los diagramas de secuencia: los MSC.
El modelo de objetos o diagramas de clases, que no describiremos, se utiliza en la
etapa de construcción de los MSC para mostrar las clases emisoras y receptoras de
eventos. Para ilustrar la propuesta utilizaremos un sistema de gestión de pedidos
descrito en (Schneider et al 1998).

Alta Cliente

extiende

u sa

Buscar
Cliente

Introducir

Pedido

Obtener
Estado
Pedido

extiende

Empleado

u sa

Cancelar
Pedido

Pago con
tarjeta

Pago en
cuenta

Buscar
Pedido

III Workshop de Engenharia de Requisitos

129

Fig. 1. Modelo de casos de uso para el sistema de pedidos.

2.1 El modelo de casos de uso

El modelo de casos de uso contiene los agentes o los actores que pueden
interactuar con el sistema, esta interacción se muestra en la forma de caso de uso. Un
caso de uso, tal como fue introducido por I. Jacobson et al. (1992), contiene una
secuencia de transacciones/eventos que se intercambian los actores y el sistema
cuando se ejecuta cierta funcionalidad del mismo. La figura 1 muestra el modelo de
casos de uso, simplificado por cuestiones de espacio, para un sistema de generación
de pedidos. El único actor participante es el empleado que se encarga de: introducir
pedidos, cancelarlos, obtener el estado en el que se encuentran (admitido, listo para
enviar, enviado) y finalmente de la devolución de artículos.

Dos relaciones pueden definirse entre casos: usa/incluye y extiende. La relación
usa se emplea cuando un flujo de eventos puede insertarse textualmente dentro de otro
caso de uso. Por el contrario la relación de extensión muestra un flujo alternativo de
ejecución. Se puede considerar como una inclusión bajo ciertas condiciones.

2.2 Los MSC

Los MSC se emplean ampliamente dentro del campo de las telecomunicaciones
para describir el intercambio de información entre las clases de un sistema. En su
forma más simple, sin información de control y sin condiciones, se consideran
equivalentes a los diagramas de interacción de UML. La figura 2 contiene la notación
utilizada dentro de nuestra herramienta.

130

WER2000

Actor

Cla se 1

Event o(atr1,...atrn)

Event o(atr 1,...atrn)

Nombre del diagrama

Alternativa

V

Argumentos (opcional)

Secuencia descrita en otro diagrama

Encapsulación

Inter rupción

V

#

X

Excepción

(n) (a,b) (a,) (,b)

Repetición

Condición

Fig. 2. Notación para los MSC.

Las líneas verticales representan clases o actores del sistema, el envío de eventos o
el intercambio de información se refleja en la forma de líneas horizontales. Cada
evento puede llevar asociado un conjunto de atributos. Estos pueden ser tipos básicos
(enteros, reales, etc.) o tipos clase. Existe una notación adicional que refleja:
repetición de eventos, alternativa, excepciones,
interrupciones y condiciones que
pueden reflejar el estado en el que se encuentra el sistema. Los MSC se pueden
descomponer por niveles, de forma que en cada diagrama el analista puede utilizar el
nivel de abstracción que desee. Para cualquier detalle puede consultarse ITU (1996) o
Telelogic ( 1999, Relesase Notes).

III Workshop de Engenharia de Req