Tutorial (Español)
Tutorial sobre UWE
Esta es una introducción práctica a UWE v1.9.
Todos los diagramas fueron realizados con MagicDraw y se recomienda la instalación
del plugin MagicUWE, porque ello simplifica el modelado con UWE en las diferentes
etapas. Véase MagicUWE Reference para información de como usar el plugin.
Que es UWE?
UWE es un método de ingeniería del software para el desarrollo de aplicaciones web
basado en UML. Cualquier tipo de diagrama UML puede ser usado, porque UWE es
una extensión de UML!
(más información sobre UWE)
Queremos presentar UWE y sus modelos típicos con un ejemplo de una agenda de
direcciones para la web. No lo leas aún; queremos desarrollar la aplicación paso a paso
en este tutorial!
Preparación para el ejemplo de la agenda de
direcciones
Crea un nuevo projecto en MagicDraw usando los patrones de UWE.
En nuestra aplicación web simplicada de una libreta de direcciones el usuario debe
poder buscar direcciones, agregar nuevos contactos, borrar contactos existentes y
actualizarlos. Cambios y agregados deben ser archivados.
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 puede ser extendido por
nuevas clases transformando desde el modelo de requisitos o agregando a las
clases existentes nuevos datos que son dependientes del modelo.
Tutorial – Modelo de Contenido
(Español)
Crea un nuevo diagrama de contenido. Este es un diagrama UML normal de clases, por
ello debemos pensar en las clases que son necesarias para nuestro ejemplo. Primero
queremos disponer de una clase agenda ("AddressBook") conteniendo un conjunto de
contactos. Cada contacto debe contener un nombre, y puede contener una dirección de
correo, dos números de teléfono y dos direcciones postales. El nombre y la dirección de
correo son Strings, el teléfono y la dirección postal son clases que representan más
información, como se ilustra en la siguiente figura:
Por qué necesitamos el atributo "introducción" en la clase AddressBook? - Ello es
porque queremos almacenar allí el texto introductorio de la página principal de la
aplicación web.
Tutorial - Modelo de Navegación
(Español)
En un sistema para la web es útil saber cómo están enlazadas las páginas. Ello significa
que necesitamos un diagrama conteniendo nodos (nodes) y enlaces (links).
¿Pero qué es un nodo? Los nodos son unidades de navegación y están conectados por
medio de enlaces. Nodos pueden ser presentados en diferentes páginas o en una misma
página.
UWE provee diferentes estereotipos, los que presentaremos mediante nuestro ejemplo.
La forma más simple de obtener un Diagrama de Navegación básico es utilizando la
Transformación Content to Navigation. En este caso obtenemos para nuestro ejemplo
un diagrama que contiene más 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 dirección o el teléfono? -
No, porque no son relevantes para la navegación. Pues borremos ambos del árbol de
contenido del modelo.
Estereotipos
nombres de estereotipos y sus iconos
clase de navegación menú
índice pregunta
visita guiada clase de proceso
nodo externo
AddressBook será nuestra página principal del sitio web. Lo cuál se indica con el tagged
value {isHome}.
¿Es pensable un sitio web para una agenda de direcciones con la información de todos
los contactos en la misma página web? - No es eso lo que queremos.
El objetivo es una aplicación 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 página 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.
Agrega las otras dos clases usando el panel de MagicUWE:
2. La clase para la búsqueda debe tener un estereotipo «query». Una búsqueda implica
ejecución de código, por ello conectamos esta clase con una asociación «processLink» .
3. ContactCreation es también un proceso, pero no uno predefinido, por ello usamos el
estereotipo «processClass» (modelaremos la acción asociada más adelante).
Si un nuevo contacto es creado, es útil visualizarlo luego, y en el caso de una búsqueda,
se espera la visualización de una lista (ContactList) con los resultados. Usamos un
estereotipo «processLink» para estas asociaciones salientes y dirigidas para prohibir la
navegación hacia atrás como en el caso de ContactCreation. Esto evita la creación por
error de duplicados.
(En este tutorial solamente algunos aspectos de los estereotipos de UWE son
presentados. Por favor véase User Guide and Reference para el uso general de
todos los estereotipos de UWE)
Para completar nuestro Mdelo de Navegación (Navigation Model), tenemos que agregar
la funcionalidad faltante de borrar y actualizar contactos (ContactDeletion y
ContactUpdate) (nuevamente véase diagrama de casos de uso). 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 página de cada
contacto):
Tutorial - Presentation Model (Español)
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. Podemos usar un Diagrama de Presentación con el fin
de proveer esta información!
Agrega una «presentationPage» class y agrega las propiedades con los estereotipos de
UWE en ellos para expresar, que el elemento está ubicado en una página web. Las
propiedades pueden anidarse, por ejemplo cada contacto («presentationGroup»-
property) cubre diferentes textos y botones. Ello significa, 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.
Recordemos el atributo "introduction" en nuestro Diagrama de contenido y agreguemos
la página 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 búsqueda criterion y un botón para lanzar la
búsqueda. Una cantidad arbitraria de contactos pueden ser presentados, lo que es
modelado con la multiplicidad "*".
nombres de estereotipos y sus iconos
grupo de presentación página de presentación
texto entrada de texto
ancla fileUpload
botón imagen
formulario componente de cliente
alternativas de presentación selección
En los siguientes diagramas, los estereotipos son solamente representados por sus
iconos. En MagicDraw se puede configurar la visualización de ambos: nombres e
iconos de los estereotipos.
Mensaje, confirmación y error de validación (Message, Confirmation y ValidationError)
son modelados aquí, tan sólo para mayor claridad aunque en la visión general de nuestro
Diagrama de Navegación (Navigation Diagram) no son visibles. Ellos son páginas
simples visualizando un mensaje o una pregunta.
Creación de contacto (ContactCreation) y actualización de contacto (ContactUpdate)
son similares la una con la otra, solamente el nombre de las páginas y el botón de "ok"
son rotulados de acuerdo con la funcionalidad correspondiente. Por ello, el estereotipo
«presentationAlternatives» es usado nuevamente para evitar el múltiple modelado de
todo el contenido de ambos formularios de ingreso de datos. Parece que una imagen en
el caso de ContactCreation, antes de que la imagen es subida, no tenga sentido. Sin
embargo, puede ser que en la implementación se desee incluir una imagen por defecto...
Los atributos etiquetados {autoCompletion} y {liveValidation} son usados para
especificar que los campos de direcciones proveen funcionalidad de auto
complementación y que el formato de la dirección de correo es chequeada
automáticamente.
Tutorial - Process Model (Español)
Hasta ahora podemos modelar muchos aspectos de nuestro sitio web. Pero no hemos
hablado en ningún momento de que aspecto tienen las acciones de nuestras clases de
proceso. El Modelo de Proceso comprende:
• el Modelo de Estructura del Proceso que describe las relaciones entre
las diferentes clases de proceso y
• el Modelo de Flujo del Proceso que especifica las actividades
conectadas con cada «processClass».
Modelo de Estructura del Proceso
Con el fin de describir las relaciones entre las diferentes clases de proceso, creamos un
diagrama de clases, usando la transformación de navegación a estructura de proceso
(Navigation to Process Structure Transformation). Despues de ejecutar la
transformación tenemos un diagrama de clases con tres clases enmarcadas con un borde
rojo:
Como puede observarse, hemos agregado otras clases para expresar, que las tres
operaciones requieren una confirmación (recuerda nuestro diagrama de presentación)
con una pregunta. Esto significa que si un usuario quiere borrar un contacto, un mensaje
será mostrado, el cuál deberá ser confirmado con un ok para que el contacto sea
borrado. ContactCreation and ContactUpdate funcionan en forma similar, ambos
heredan de la clase abstracta ContactProcessing, asegurando que los campos de texto,
que son atributos de ContactDataInput contienen valores válidos (por ejemplo podemos
pensar en prohibir un nombre en blanco para prevenir entradas inservibles en la base de
datos). No bien los datos han sido validados y no hay errores de validación
(ValidationError) la página de confirmación es presentada al usuario. Para más detalles
sobre las actividades, véase el próximo párrafo!
Modelo de flujo del proceso
Un flujo del proceso (flujo de trabajo) 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
acción de acción de
usuario sistema
Podemos seleccionar nuestro diagrama de navegación y ejecutar la transformación de
navegación 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 página
web iniciando un proceso o respondiendo a un requerimiento explícito de información.
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).
Felicitaciones! :-)
Este es el fin del tutorial, porque solamente se necesita UML standard para expresar lo
to express lo que ocurre en estos tres procesos del diagrama de flujo del proceso.
Véase tambíen los modelos de la sección de ejemplos (example section).
