En 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

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 aplicación: el usuario debe poder realizar búsquedas 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 aplicación son modificados o no. "SearchContact" por ejemplo, modela la búsqueda de contactos y por ello lleva el estereotipo «browsing» pues los datos son solamente leídos 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

➢ El modelo Dominio) conceptual para el contenido (Modelo del Es un artefacto de la disciplina de análisis. dos direcciones y números de teléfono y el descargar un archivo del tipo imagen. construido con las reglas de UML durante la fase de concepción. una dirección de correo. . El formulario completado por el usuario es finalmente salvado en la base de datos de la aplicación. en la tarea construcción del modelo de dominio. 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.su nombre.

Finalmente se ve que una estación tiene una o más maquinas de venta así como empleados de limpieza. Similares a los mapas mentales utilizados en el aprendizaje. en este caso. corresponde al analista decidir cuánto detalle va a ser necesario y hasta donde . dicha maquina “crea” los boletos los cuales son consumidos en un viaje. referido al Metro o sistema de transporte subterráneo de una ciudad cualquiera. El siguiente diagrama es un pequeño ejemplo de Modelo de Dominio. no conceptos propios de un sistema de software sino de la propia realidad física. Los modelos de dominio puede utilizarse para capturar y expresar el entendimiento ganado en un área bajo análisis como paso previo al diseño de un sistema.presentado como uno o más diagramas de clases y que contiene. Fig. 1 – Ejemplo de Modelo de Dominio de un sistema de subterráneo En este diagrama se ve que un Usuario del Metro tiene cero o más boletos. el cual tiene una estación de origen y otra de destino. ya sea de software o de otro tipo. 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. comprados estos en una maquina de Venta de Boletos. seguridad y operaciones. Es posible capturar un mayor grado de detalle en uno de estos modelos.

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

No.➢ Modelo del usuario: modelo de navegación que incluye modelos estáticos y dinámicos En un sistema para la web es útil saber cómo están enlazadas las páginas. los que presentaremos mediante nuestro ejemplo. Nodos pueden ser presentados en diferentes páginas o en una misma página. ¿que es un nodo? Nodos son unidades de navegación y están conectados por medio de enlaces. UWE provee diferentes estereotipos. Pero. porque no son relevantes para la navegación. . Pues borremos ambos del árbol de contenido del modelo. En este caso obtenemos para nuestro ejemplo un diagrama que contiene más nodos de los necesarios. Ello significa que necesitamos un diagrama conteniendo nodos (nodes) y enlaces (links). Para los nodos y enlaces son usados los estereotipos «navigationClass» and «navigationLink»: ¿Queremos realmente modelar el enlace desde el contacto a la dirección o el teléfono? . La forma más simple de obtener un Diagrama de Navegación básico es utilizando la Transformación Content to Navigation.

buscar un contacto 3.AddressBook será nuestra página principal del sitio web. Insertar uno y asignarle el nombre "MainMenu": 1. ContactList . puede usarse un «menu». Una búsqueda implica ejecución de código. Por este motivo necesitamos un sitio que provee conexiones a diferentes nodos: 1. ContactCreation .No es eso lo que queremos. Lo cual se indica con el tagged value {isHome}. por ello conectamos esta clase con una asociación «processLink» . El estereotipo «index» es usado para listar una cantidad de objetos del mismo tipo. ¿Es pensable un sitio web para una agenda de direcciones con la información de todos los contactos en la misma página web? . ContactCreation es también un proceso. 3. pero no uno predefinido. y en el caso de una búsqueda. La clase para la búsqueda debe tener un estereotipo «query».crear un nuevo contacto y visualizarlo En UWE.cada contacto debe ser alcanzable usando un enlace desde la página principal del sitio web 2. es útil visualizarlo luego. (contact)Search . Si un nuevo contacto es creado. se espera la visualización de un lista (ContactList) con los resultados. por ello usamos el estereotipo «processClass». 2. El objetivo es una aplicación en la cual se puede acceder a las operaciones de nuestro diagrama de casos de uso. para navegar a diferentes clases. Podemos insertar la lista de contactos (ContactList) casi del mismo modo. Usamos un estereotipo «processLink» para estas asociaciones salientes y .

por ello necesitamos nuevamente un menú (y lo nombramos ContactMenu indicando que está ubicado en la página de cada contacto): .dirigidas para prohibir la navegación hacia atrás como en el caso de ContactCreation. Estas dos clases son ambas accedidas desde el contacto concreto. tenemos que agregar la funcionalidad faltante de borrar y actualizar contactos (ContactDeletion y ContactUpdate). Esto evita la creación por error de duplicados. Nombres de estereotipos y sus iconos clase de navegación índice menú pregunta clase de proceso visita guiada nodo externo Para completar nuestro Modelo de Navegación (Navigation Model).

.

. lo que es modelado con la multiplicidad "*". Las propiedades pueden anidarse. Podemos usar un Diagrama de Presentación con el fin de proveer esta información. que para cada contacto la correspondiente dirección de correo y los correspondientes campos de teléfonos y direcciones serán visualizados en la página. los estereotipos son solamente representados por sus iconos.➢ Modelo de estructura de presentación. Entonces son necesarios un formulario con un campo para entrada de datos (textInput) para el criterio de búsqueda criterion y un botón para lanzar la búsqueda. Agregar una «presentationPage» class y agregar las propiedades con los estereotipos de UWE en ellos para expresar. modelo de flujo de presentación El Modelo de Navegación no indica cuáles son las clases de navegación y de proceso que pertenecen a una página web. En MagicDraw se puede configurar la visualización de ambos: nombres e iconos de los estereotipos. que el elemento está ubicado en una página web. Nombres de estereotipos y sus iconos grupo de presentación texto ancla botón formulario alternativas de presentación página de presentación entrada de texto fileUpload imagen componente de cliente selección En los siguientes diagramas. Ello significa. Una cantidad arbitraria de contactos pueden ser presentados. por ejemplo cada contacto («presentationGroup»-property) cubre diferentes textos y botones. Agreguemos la página principal del sitio web AddressBook conteniendo el texto introductorio (estereotipo «text»).

Confirmation y ValidationError) son modelados aquí. . confirmación y error de validación (Message. Ellos son páginas simples visualizando un mensaje o una pregunta. tan sólo para mayor claridad.Mensaje.

describiendo el comportamiento de una clase de proceso. Ambos tipos de acciones pueden ser agregadas usando la barra de herramientas (toolbar). cuando el usuario navega a una clase de proceso (por ejemplo ContactCreation en nuestro ejemplo) Nombres de estereotipos y sus iconos acción de usuario acción de sistema. Por el contrario. «system Action» describe acciones.➢ Modelo abstracto de interfaz de usuario y modelo del ciclo de vida del objeto Es representado como un diagrama de actividades. A continuación. Podemos seleccionar nuestro diagrama de navegación y ejecutar la transformación de navegación a flujo del proceso (Navigation to Process Flows Transformation). un diagrama con estos estereotipos en uso: . por ejemplo que sucede en detalle. que son ejecutadas por el sistema. Se han generado tres diagramas de actividades vacios: • • • ContactCreation ContactDeletion ContactUpdate El estereotipo «user Action» es usado para indicar interaciones de usuario con la página web iniciando un proceso o respondiendo a un requerimiento explícito de información.

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

Sign up to vote on this title
UsefulNot useful