Tutorial (Espaol)

Tutorial sobre UWE

Esta es una introduccin prctica a UWE v1.9.

Todos los diagramas fueron realizados con MagicDraw y se recomienda la instalacin del
pluginMagicUWE, porque ello simplifica el modelado con UWE en las diferentes etapas.
Vase MagicUWE Reference para informacin de como usar el plugin.

Que es UWE?

UWE es un mtodo de ingeniera del software para el desarrollo de aplicaciones web basado
enUML. Cualquier tipo de diagrama UML puede ser usado, porque UWE es una extensin de
UML!
(ms informacin sobre UWE)
Queremos presentar UWE y sus modelos tpicos con un ejemplo de una agenda de
direcciones para la web. No lo leas an; queremos desarrollar la aplicacin paso a paso en este
tutorial!

Preparacin para el ejemplo de la agenda de direcciones

Crea un nuevo projecto en MagicDraw usando los patrones de UWE.

En nuestra aplicacin 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 aplicacin 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 aplicacin: el usuario debe
poder realizar bsquedas 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 aplicacin son modificados o no. "SearchContact" por
ejemplo, modela la bsqueda 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 informacin, cada caso de uso puede
ser descripto ms 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 precisin 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 anlogamente al flujo
de procesos. El estereotipo user Action es usado para indicar interacciones de usuario en la
pgina web initiando un proceso o respondiendo to un explcito requisito de informacin. 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 ingeniera de requisitos es usual determinar que datos son representados donde y
cuando. Para modelar grupos de presentacin en UWE son usados el estereotipo display
Action, mientras que los dos pines de accin 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

navegacin y los elementos asociados de presentacin.

Como estos estereotipos se utilizan para indicar elementos de presentacin durante la etapa de
ingeniera 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
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.
Un segundo caso de uso que refinamos es "SearchContacts". Para este caso de uso solamente
elementos de presentacin son de inters, nos limitamos en el diagrama a ellos. Inicialmente, la
presentacin consiste de un simple formulario usado para entrar palabras claves y un butn para
el display de la lista de contactos.

La parte principal de la presentacin sin embargo, consite en la lista de contactos, que es

modelada con una accin "Contacts". Los elementos de presentacin pueden ser agrupados
adicionalmente creando acciones con una accin de jerarqua mayor, como puede observarse
para las direcciones y los nmerod de telfono.

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 accin.
 Transformaciones

Una vez que los requisitos han sido modelados, hay dos maneras de simplificar los pasos
siguientes en el modelado de contenido, navegacin, presentacin y procesos:

En vez de crear un modelo y el diagrama correspondiente manualmente, el mismo puede

ser generado con una transformacin de los datos del modelo de requisitos.
Adicionalmente, un modelo previamente generado puiede ser extendido por nuevas
clasestransformando desde el modelo de requisitos o agregando a las clases existentes nuevos
datos que son dependientes del modelo.

Continuar

Tutorial - Content Model (Espaol)

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 direccin de correo, dos nmeros de
telfono y dos direcciones postales. El nombre y la direccin de correo son Strings, el telfono y
la direccin postal son clases que representan ms informacin, como se ilustra en la siguiente
figura:

Por qu necesitamos el atributo "introduccin" en la clase AddressBook? - Ello es porque

queremos almacenar all el texto introductorio de la pgina principal de la aplicacin web.

Continuar

Tutorial - Navigation Model (Espaol)

En un sistema para la web es til saber como 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 utilzando 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 cul 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 cul 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.
Agrega las otras dos clases usando el panel de MagicUWE:
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 (modelaremos la accin asociada ms adelante).

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 men
ndice pregunta
visita guiada clase de proceso
nodo externo
(En este tutorial solamente algunos aspectos de los estereotipos de UWE son presentados.
Por favor vase User Guide and Reference para el uso general de todos los estereotipos de
UWE)
Para completar nuestro Mdelo de Navegacin (Navigation Model), tenemos que agregar la
funcionalidad faltante de borrar y actualizar contactos (ContactDeletion y ContactUpdate)
(nuevamente vase 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 pgina de cada contacto):
 Continuar

Tutorial - Presentation Model (Espaol)

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!

Agrega una presentationPage class y agrega 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.

Recordemos el atributo "introduction" en nuestro Diagrama de contenido y 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 pgina de presentacin

texto entrada de texto

ancla fileUpload

botn imagen

formulario componente de cliente

alternativas de presentacin 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 aunque en la visin general de nuestro Diagrama
de Navegacin(Navigation Diagram) no son visibles. Ellos son pginas simples visualizando un
mensaje o una pregunta.
Creacin de contacto (ContactCreation) y actualizacin de contacto (ContactUpdate) son
similares la una con la otra, solamente el nombre de las pginas y el botn de "ok" son rotulados
de acuerdo con la funcionalidad correspondiente. Por ello, el estereotipo
presentationAlternatives es usado nuevamente para evitar el mltiple 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 implementacin 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 complementacin y que el formato de
la direccin de correo es chequeada automticamente.

Continuar

Tutorial - Process Model (Espaol)

 Hasta ahora podemos modelar muchos aspectos de nuestro sitio web. Pero no hemos hablado en
ningn 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 transformacin de navegacin a estructura de proceso (Navigation to
Process Structure Transformation). Despues de ejecutar la transformacin 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 confirmacin (recuerda nuestro diagrama de presentacin) con una pregunta.
Esto significa que si un usuario quiere borrar un contacto, un mensaje ser mostrado, el cul
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 vlidos (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 validacin (ValidationError) la pgina de confirmacin es presentada al usuario. Para
ms detalles sobre las actividades, vase el prximo prrafo!

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

accin de accin de
usuario 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).

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.
Vase tamben los modelos de la seccin de ejemplos (example section).