Tutorial - Requirements Model (Spanish)
In UWE el modelado de requisitos consiste de dos partes:
- Casos de uso de la aplicación y sus relaciones
- Actividades describiendo los casos de uso en detalle
Casos de Uso
Nuestro ejemplo es simple, por ello no es absolutamente necesario comenzar modelando los casos de uso, pero sirve para ilustrar las funcionalidades de nuestra aplicación: el usuario debe poder realizar búsquedas en la libreta de direcciones y borrar contactos. Adicionalmente, contactos pueden ser creados y actualizados, cambios deben ser archivados o pueden ser cancelados. En este ejemplo con fines de claridad, nos limitamos a las funcionalidades descriptas, pero aconsejamos modelar tantas como se deseen.
En UWE se distinguen casos de uso estereotipados con «browsing» y con «processing» para ilustrar si los datos persistentes de la aplicación son modificados o no. "SearchContact" por ejemplo, modela la búsqueda de contactos y por ello lleva el esterotipo «browsing» pues los datos son solamente leidos y presentados al usuario. Los otros casos de uso por el contrario modelan cambios, lo que se especifica con el estereotipo «processing».
| stereotype-names and their icons | |
|---|---|
 browsing |
 processing |
 webUseCase |
|
Actividades
Como con casos de uso solamente es posible capturar poca información, cada caso de uso puede ser descripto más detalladamente mediante un proceso. Es decir, las acciones que son parte de un caso de uso asi como los datos presentados al usuario y aquellos requeridos como entrada de datos pueden ser modelados con precisión como actividades.
| nombres de estereotipos y los iconos correspondientes | |
|---|---|
 userAction |
 systemAction |
 displayAction |
 navigationAction |
 displayPin |
 interactionPin |
Los dos esterotipos «user Action» y «system Action» pueden ser usados análogamente al flujo de procesos. El estereotipo «user Action» es usado para indicar interacciones de usuario en la página web initiando un proceso o respondiendo to un explícito requisito de información. Por lo contrario, «system Action» describe acciones que son ejecutados por el sistema. Ambos tipos de acciones pueden ser insertados usando la toolbar.
Detalles de las estructuras de datos usadas pueden ser representadas por objetos de nodos y pins de acciones. El objeto de nodo es usado para modelar clases de contenido y los pines sus atributos.
Durante ingeniería de requisitos es usual determinar que datos son representados donde y cuando. Para modelar grupos de presentación en UWE son usados el estereotipo «display Action», mientras que los dos pines de acción estereotipados «interaction Pin» y «display Pin» son usados para modelar la entrada y la salida de datos.
Finalmente el estereotipo «navigationAction», puede ser usado para modelar opciones de navegación y los elementos asociados de presentación.
Como estos estereotipos se utilizan para indicar elementos de presentación durante la etapa de ingeniería de requisitos, aspectos que caracterizan a RIAs pueden ser especificadas mediante valores etiquetados para estos mismos elementos./p>
Para ejemplificar modelamos dos actividades. Primero, una actividad para el caso de uso "CreateContact". El mismo muestra un formulario que permite al usuario entrar su nombre, una dirección de correo, dos direcciones y números de teléfono y el descargar un archivo del tipo imagen. La dirección de correo debe ser validada durante la entrada de datos y el nombre de la ciudad completado automáticamente en función del código postal. El formulario completado por el usuario es finalmente salvado en la base de datos de la aplicación.
Un segundo caso de uso que refinamos es "SearchContacts". Para este caso de uso solamente elementos de presentación son de interés, nos limitamos en el diagrama a ellos. Inicialmente, la presentación consiste de un simple formulario usado para entrar palabras claves y un butón para el display de la lista de contactos.
La parte principal de la presentación sin embargo, consite en la lista de contactos, que es modelada con una acción "Contacts". Los elementos de presentación pueden ser agrupados adicionalmente creando acciones con una acción de jerarquía mayor, como puede observarse para las direcciones y los númerod de teléfono.
Las dos acciones del estereotipo «navigationAction» modelan transiciones a otros casos de uso. Esto es modelado la actividad del caso de uso destino como comportamiento de la acción.
Transformaciones
Una vez que los requisitos han sido modelados, hay dos maneras de simplificar los pasos siguientes en el modelado de contenido, navegación, presentación y procesos:
- En vez de crear un modelo y el diagrama correspondiente manualmente, el mismo puede ser generado con una transformación de los datos del modelo de requisitos.
- Adicionalmente, un modelo previamente generado puiede ser extendido por nuevas clases transformando desde el modelo de requisitos o agregando a las clases existentes nuevos datos que son dependientes del modelo.
