En UWE el modelado de requisitos consiste de dos partes:

Casos de uso de la aplicacin y sus relaciones Actividades describiendo los casos de uso en detalle

Modelo de 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 aplicacin: el usuario debe poder realizar bsquedas en una 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 aplicacin son modificados o no. "SearchContact" por ejemplo, modela la bsqueda de contactos y por ello lleva el estereotipo browsing pues los datos son solamente ledos y presentados al usuario. Los otros casos de uso por el contrario modelan cambios, lo que se especifica con el estereotipo processing.

Para ejemplificar modelamos lo siguiente. Primero, una actividad para el caso de uso "CreateContact". El mismo muestra un formulario que permite al usuario entrar

su nombre, una direccin de correo, dos direcciones y nmeros de telfono y el descargar un archivo del tipo imagen. La direccin de correo debe ser validada durante la entrada de datos y el nombre de la ciudad completado automticamente en funcin del cdigo postal. El formulario completado por el usuario es finalmente salvado en la base de datos de la aplicacin.

El modelo Dominio)

conceptual para

el contenido

(Modelo del

Es un artefacto de la disciplina de anlisis, construido con las reglas de UML durante la fase de concepcin, en la tarea construccin del modelo de dominio,

presentado como uno o ms diagramas de clases y que contiene, no conceptos propios de un sistema de software sino de la propia realidad fsica. Los modelos de dominio puede utilizarse para capturar y expresar el entendimiento ganado en un rea bajo anlisis como paso previo al diseo de un sistema, ya sea de software o de otro tipo. Similares a los mapas mentales utilizados en el aprendizaje, el modelo de dominio es utilizado por el analista como un medio para comprender el sector industrial o de negocios al cual el sistema va a servir. El siguiente diagrama es un pequeo ejemplo de Modelo de Dominio, en este caso, referido al Metro o sistema de transporte subterrneo de una ciudad cualquiera.

Fig. 1 Ejemplo de Modelo de Dominio de un sistema de subterrneo En este diagrama se ve que un Usuario del Metro tiene cero o ms boletos, comprados estos en una maquina de Venta de Boletos; dicha maquina crea los boletos los cuales son consumidos en un viaje, el cual tiene una estacin de origen y otra de destino. Finalmente se ve que una estacin tiene una o ms maquinas de venta as como empleados de limpieza, seguridad y operaciones. Es posible capturar un mayor grado de detalle en uno de estos modelos; corresponde al analista decidir cunto detalle va a ser necesario y hasta donde

llegar a modelar. El objetivo es capturar lo necesario para comprender donde va a funcionar el sistema que estamos diseando y esto demanda una cantidad distinta de detalles cada vez. El modelo de dominio puede ser tomado como el punto de partida para el diseo del sistema. Esto es as ya que cuando se realiza la programacin orientada a objetos, se supone que el funcionamiento interno del software va a imitar en alguna medida a la realidad, por lo que el mapa de conceptos del modelo de domino constituye una primera versin del sistema.

 Modelo del usuario: modelo de navegacin que incluye modelos estticos y dinmicos En un sistema para la web es til saber cmo estn enlazadas las pginas. Ello significa que necesitamos un diagrama conteniendo nodos (nodes) y enlaces (links). Pero, que es un nodo? Nodos son unidades de navegacin y estn conectados por medio de enlaces. Nodos pueden ser presentados en diferentes pginas o en una misma pgina. UWE provee diferentes estereotipos, los que presentaremos mediante nuestro ejemplo. La forma ms simple de obtener un Diagrama de Navegacin bsico es utilizando la Transformacin Content to Navigation. En este caso obtenemos para nuestro ejemplo un diagrama que contiene ms nodos de los necesarios. Para los nodos y enlaces son usados los estereotipos navigationClass and navigationLink:

Queremos realmente modelar el enlace desde el contacto a la direccin o el telfono? - No, porque no son relevantes para la navegacin. Pues borremos ambos del rbol de contenido del modelo.

AddressBook ser nuestra pgina principal del sitio web. Lo cual se indica con el tagged value {isHome}. Es pensable un sitio web para una agenda de direcciones con la informacin de todos los contactos en la misma pgina web? - No es eso lo que queremos. El objetivo es una aplicacin en la cual se puede acceder a las operaciones de nuestro diagrama de casos de uso. Por este motivo necesitamos un sitio que provee conexiones a diferentes nodos:
1. ContactList - cada contacto debe ser alcanzable usando un enlace desde la pgina principal del sitio web 2. (contact)Search - buscar un contacto 3. ContactCreation - crear un nuevo contacto y visualizarlo

En UWE, puede usarse un menu, para navegar a diferentes clases. Insertar uno y asignarle el nombre "MainMenu": 1. Podemos insertar la lista de contactos (ContactList) casi del mismo modo. El estereotipo index es usado para listar una cantidad de objetos del mismo tipo. 2. La clase para la bsqueda debe tener un estereotipo query. Una bsqueda implica ejecucin de cdigo, por ello conectamos esta clase con una asociacin processLink . 3. ContactCreation es tambin un proceso, pero no uno predefinido, por ello usamos el estereotipo processClass. Si un nuevo contacto es creado, es til visualizarlo luego, y en el caso de una bsqueda, se espera la visualizacin de un lista (ContactList) con los resultados. Usamos un estereotipo processLink para estas asociaciones salientes y

dirigidas para prohibir la navegacin hacia atrs como en el caso de ContactCreation. Esto evita la creacin por error de duplicados.

Nombres de estereotipos y sus iconos clase de navegacin ndice

men

pregunta clase de proceso

visita guiada

nodo externo

Para completar nuestro Modelo de Navegacin (Navigation Model), tenemos que agregar la funcionalidad faltante de borrar y actualizar contactos (ContactDeletion y ContactUpdate). Estas dos clases son ambas accedidas desde el contacto concreto, por ello necesitamos nuevamente un men (y lo nombramos ContactMenu indicando que est ubicado en la pgina de cada contacto):

 Modelo de estructura de presentacin, modelo de flujo de presentacin El Modelo de Navegacin no indica cules son las clases de navegacin y de proceso que pertenecen a una pgina web. Podemos usar un Diagrama de Presentacin con el fin de proveer esta informacin. Agregar una presentationPage class y agregar las propiedades con los estereotipos de UWE en ellos para expresar, que el elemento est ubicado en una pgina web. Las propiedades pueden anidarse, por ejemplo cada contacto (presentationGroup-property) cubre diferentes textos y botones. Ello significa, que para cada contacto la correspondiente direccin de correo y los correspondientes campos de telfonos y direcciones sern visualizados en la pgina. Agreguemos la pgina principal del sitio web AddressBook conteniendo el texto introductorio (estereotipo text). Entonces son necesarios un formulario con un campo para entrada de datos (textInput) para el criterio de bsqueda criterion y un botn para lanzar la bsqueda. Una cantidad arbitraria de contactos pueden ser presentados, lo que es modelado con la multiplicidad "*". Nombres de estereotipos y sus iconos grupo de presentacin texto ancla botn formulario alternativas de presentacin pgina de presentacin entrada de texto fileUpload imagen componente de cliente seleccin

En los siguientes diagramas, los estereotipos son solamente representados por sus iconos. En MagicDraw se puede configurar la visualizacin de ambos: nombres e iconos de los estereotipos.

Mensaje, confirmacin y error de validacin (Message, Confirmation y ValidationError) son modelados aqu, tan slo para mayor claridad. Ellos son pginas simples visualizando un mensaje o una pregunta.

 Modelo abstracto de interfaz de usuario y modelo del ciclo de vida del objeto
Es representado como un diagrama de actividades, describiendo el comportamiento de una clase de proceso, por ejemplo que sucede en detalle, cuando el usuario navega a una clase de proceso (por ejemplo ContactCreation en nuestro ejemplo) Nombres de estereotipos y sus iconos accin de usuario accin de sistema.

Podemos seleccionar nuestro diagrama de navegacin y ejecutar la transformacin de navegacin a flujo del proceso (Navigation to Process Flows Transformation). Se han generado tres diagramas de actividades vacios: ContactCreation ContactDeletion ContactUpdate

El estereotipo user Action es usado para indicar interaciones de usuario con la pgina web iniciando un proceso o respondiendo a un requerimiento explcito de informacin. Por el contrario, system Action describe acciones, que son ejecutadas por el sistema. Ambos tipos de acciones pueden ser agregadas usando la barra de herramientas (toolbar). A continuacin, un diagrama con estos estereotipos en uso:

BIBLIOGRAFA http://uwe.pst.ifi.lmu.de/teachingTutorialProcessSpanish.html http://uwe.pst.ifi.lmu.de/teachingTutorialPresentationSpanish.html http://uwe.pst.ifi.lmu.de/teachingTutorialNavigationSpanish.html http://synergix.wordpress.com/2008/07/10/modelo-de-dominio/ http://uwe.pst.ifi.lmu.de/teachingTutorialContentSpanish.html http://uwe.pst.ifi.lmu.de/teachingTutorialRequirementsSpanish.html