Esstu

udio
o d
de U
 UWWE 
(UML L­b
based  W
Web 
E gin
Eng neeerin
ng)) 
Índice 
1. INTRODUCCIÓN A UWE

¿Qué es UWE? .............................................................................................. 3 

1.2  UWE y su relación con UML ................................................................. 4 
1.3  Herramientas SW .................................................................................. 5 
1.4  Modelos de UWE .................................................................................. 6 
1.4.1  Modelo de Contenido ...................................................... 6 
1.4.2  Modelo de navegación .................................................... 7 
1.4.3  Modelo de presentación .................................................. 9 
1.4.4  Modelo de Proceso ....................................................... 11

2. CASO PRACTICO: PORTAL MUSICAL

2.1  Introducción al Casó Práctico ............................................................. 13 
2.1.1  Casos de uso referidos a usuarios .................................. 13 
2.1.2  Casos de uso referidos a la información sobre los discos.... 14 
2.1.3  Casos de uso respecto al sistema de compra ................... 14 
2.2  Modelo de Casos de Uso .................................................................... 16 
2.3  Modelo de Contenido .......................................................................... 18 
2.4  Modelo de Usuario .............................................................................. 19 
2.5  Modelo de Navegación........................................................................ 21 
2.6  Modelo de Proceso ............................................................................. 24 
2.7 Modelo de Presentación...................................................................... 27 

3. CONCLUSIONES

4. REFERENCIAS
 1. Introducción a UWE 

1.1 ¿Qué es UWE? 

UWE (UML-Based Web Engineering) es una propuesta basada

en UML y en el proceso unificado para modelar aplicaciones web. Esta
propuesta está formada por una notación para especificar el dominio
(basada en UML) y un modelo para llevar a cabo el desarrollo del
proceso de modelado. Los sistemas adaptativos y la sistematización
son dos aspectos sobre los que se enfoca UWE.

Además de estar considerado como una extensión del estándar

UML, también se basa en otros estándares como por ejemplo: XMI
como modelo de intercambio de formato, MOF para el meta-
modelado, los principios de modelado de MDA, el modelo de
transformación del lenguaje QVT y XML.

El modelo que propone UWE está compuesto por 6 etapas o

sub-modelos:

1. Modelo de Casos de Uso: modelo para capturar los requisitos

del sistema.
2. Modelo de Contenido: es un modelo conceptual para el
desarrollo del contenido.
3. Modelo de Usuario: es modelo de navegación, en el cual se
incluyen modelos estáticos y modelos dinámicos.
4. Modelo de estructura: en el cual se encuentra la presentación
del sistema y el modelo de flujo.
5. Modelo Abstracto: incluye el modelo a de interfaz de usuario
y el modelo de ciclo de vida del objeto.
6. Modelo de Adaptación.
 En cuanto a los requisitos, UWE los clasifica dependiendo del
carácter de cada uno. Además distingue entre las fases de captura,
definición y validación de requisitos.

1.2 UWE y su relación con UML 
UWE define una extensión del Lenguaje Unificado de Modelado
(UML). Ésta, es considerada como una extensión ligera de peso e
incluye en su definición tipos, etiquetas de valores y restricciones
para las características especificas del diseño Web, las cuales, unidas
a las definiciones de UML forman el conjuntos de objetos de
modelado que se usarán para el desarrollo del modelo utilizado en
UWE.

Las funcionalidades que cubren UWE abarcan áreas

relacionadas con la Web como la navegación, presentación, los
procesos de negocio y los aspectos de adaptación.

Una de las ventajas de que UWE extienda el estándar UML es la

flexibilidad de éste para la definición de un lenguaje de modelado
especifico para el dominio web y sobretodo la aceptación universal de
dicho estándar en el campo de la ingeniería del software.

Otra gran ventaja es que actualmente existen múltiples de

herramientas CASE basadas en UML, con lo cual es relativamente
sencillo su utilización y ampliación para utilizar los objetos de
modelado definidos en UWE. Estas herramientas se verán en el
siguiente punto.
1.3 Herramientas SW 
Como se ha explicado en la sección anterior, para aplicar las
funcionalidades que añade UWE, se utilizan las mismas herramientas
software de modelado basadas en UML y se les añade una extensión
a la aplicación para que permita estas nuevas funcionalidades.

Se ha desarrollado un plugin para una de las herramientas UML

más conocidas, MagicDraw, que es una herramienta que soporta la
versión 2.1.2 de este estándar para lenguajes de programación como
por ejemplo Java, C++ o C#. Este plugin llamado MagicUWE, es de
libre distribución pudiendo adquirir gratuitamente y está desarrollado
para la versión 16 de MagicDraw. En la página oficial de UWE se
encuentra disponible así como un manual de instalación y uso de esta
extensión.

También se ha desarrollado UWEet, que es un plugin para la

herramienta UML de código abierto UMLet. Esta herramienta se
caracteriza por una interfaz simple para el usuario y por su
compatibilidad con Eclipse a la hora de compartir diagramas UML.
También puede exportar estos a distintos formado como el
archiconocido PDF. Dicho esto, este plugin proporciona a UWEet de
una paleta en su interfaz con todos los elementos que son definidos
por UWE, permitiendo así la extensión del lenguaje UML. UWEet
también se encuentra disponible de manera gratuita en la página web
oficial de UWE.

Para uno de los entornos de desarrollo más utilizados en todo el

mundo, Eclipse, también se ha creado una extensión. Este plugin se
denomina UWE4JSF y permite la generación automática de
aplicaciones web para JavaServer Faces (JSF) platform.

Por último destacar que existe una herramienta software

basada específicamente en la metodología UWE, esta herramienta fue
desarrollada como una extensión de ArgoUML, herramienta de
modelado basada en UML. Se trata de la aplicación ArgoUWE que
permite la semiautomática generación de los modelos característicos
de UWE como son el de navegación, el de presentación, el de
procesos y el de adaptación. Está herramienta también se encuentra
disponible en la página web oficial de UWE.
1.4 Modelos de UWE 
En esta sección se explicarán los modelos para cada una de los
aspectos web que cubre la metodología UWE, recordemos que estos
aspectos eran navegación, presentación, los procesos de negocio y
adaptación. Así procedemos a explicar con un breve ejemplo cada
uno de estos modelos.

1.4.1 Modelo de Contenido 
Este modelo especifica cómo se encuentra relacionados los
contenidos del sistema, es decir, define la estructura de los datos que
se encuentran alojados en el sitio web. A continuación se muestra un
ejemplo de este modelo contenido en la página web de UWE.

Ilustración 1

En este ejemplo se puede ver representado que el contenido

web está formado por una agenda básica de contactos, está agenda
representada por la clase AddressBook contiene un conjunto de uno o
más contactos (clase Contact) , cada uno de ellos tiene un nombre,
un email,
e un
na direcció
ón y un teléfono.
t De los cu
uales los dos primeros
son de tipo String y los dos últimos s a son estructuras de otros
o
atrib
butos, reepresenta
adas porr las cla ases Add dress y Phone, cada
c
conttacto pue
ede tenerr una dirrección y un teléffono prinncipal y otros
o
secuundarios.

1.4
4.2 Mo
odelo d
 de nav
vegació
ón 
Este modelo
m ind
dica com
mo el siste
ema de páginas w
web del sitio
está
á relacionado intternamennte. Es decir có
ómo se enlazan los
elem
mentos dee navegac
ción.

Para ello se utilizan unid

dades de navegac
ción llamaadas “nodos”
ectadas por enlac
cone ces de navegació
n ón. Estoos nodos s pueden ser
mosstrados en
e la misma pág gina web, no tien
nen porq que estarr en
páginas diferrentes.

Al mism
mo tiempoo que expplicamos este moddelo con eel ejemplo de
la agenda
a de contacttos, pode
emos ir viendo
v lo os elementos
os distinto
que introduce la meto
odología UWE,
U los elemento
os introduucidos son
n los
sigu
uientes:

ste
ereotype
e-names and th
heir
ico
ons

menu
na
avigationC
Class

index query

guidedTo
our prrocessClass

I
Ilustración 2

Aquí tenemos el ejemp plo de navegació

n ón del sitio web que
reprresenta una agend
da de contactos:
 Ilustración 3

Para empezar tenemos AddressBook como página de inicio, así

que está etiquetada como {isHome} y como clase de navegación con
el símbolo correspondiente (ver símbolos más abajo). La página de
inicio enlaza con un menú, que sería nuestra página de índice, para
ello la clase Main Menu esta etiquetada como pagina Menu.

Desde la clase Main Menu enlazamos con las clases Search (que
implementará la función de buscar un contacto y es etiquetada con la
etiqueta de query) que es un proceso predefinido, y con la clase
ConctactCreation (que creará un contacto), esta clase es un proceso
no definido con lo cual llevará la etiqueta de processClass, así ambos
enlaces serán del tipo process link.

Para finalizar vemos que la clase ConctactCreation está

enlazada con Conctact ya que cuando se crea un nuevo contacto,
este se debe mostrar. Como también cuando se realiza una búsqueda
se debe mostrar la lista con los contactos del resultado, de ahí que
exista otro processLink entre las clases Search y ConctactList, esta
ultima además etiquetada como index, al ser una lista.
1.4
4.3 Mo
odelo d
 de pre
esentacción 
En este mod delo se re
epresenta
an las clases de n
navegació
ón y
de procesos que pe ertenecen a cada página web. Estos son los
elem
mentos qu
ue introdu
uce la meetodología
a UWE enn este mo
odelo:

stereotyype-nammes and their

t iconns
presentationCla
ass preesentatio
onPage
text tex
xtInput
or
ancho an
nchoredCo
ollection
button
n im
mage
form pre
esentatio
onGroup

Illustración 4

A coontinuació
ón se mu a de presentación del
uestra el diagrama
ejem
mplo de la
a Agendaa de Conta
actos:

Illustración 5

Com
mo se puede ver la clase contacto
c es prese
entada co
omo
Pres
sentation_ _Class, cubriendo
c también
n diferentes textos
s y botonnes,
esto
o significaa que po or cada contacto,
c tiene que ser mmostrado un
emaail, direcc
ciones y lo
os teléfon
nos. Tambbién se puede obsservar que
e la
página de inicio Addre essBook contiene
c un texto de introd
ducción y un
form
mulario de búsque eda con un camp po de tex xto y un botón para
lanz
zar la bússqueda.
1.4.4 Modelo de Proceso 
Este modelo especifica las acciones que realiza cada clase de
proceso, en este modelo se incluye:
- Modelo de Estructura de Procesos: que define las
relaciones entre las diferentes clases proceso. Un ejemplo de
diagrama de clases de este modelo siguiendo el caso de la
Agenda de contactos sería:

Ilustración 6

En este diagrama se puede ver que hay clases para definir 3

operaciones que necesita una confirmación. Así por ejemplo
si el usuario quiere borrar un contacto el mensaje será
mostrado y después haciendo clic en “ok” el contacto será
borrado. Las operaciones de actualización y creación
funcional de manera similar, ambas heredan de
ConctacProcessing, asegurando que los campos de datos
tienen valores validos.

- Modelo de Flujo de Procesos: que especifica las actividades

conectadas con cada proceso. Describe los comportamientos
de una clase proceso. Lo que ocurre en detalle dentro de cada
 una. Por ejemplo para la operación de borrado de contactos
tenemos el siguiente diagrama:

Ilustración 7

Aquí podemos ver que la etiqueta <<userAction>> es

usada para indicar las interaccione entre el usuario y la pagina
web iniciando un proceso o respondiendo a una petición de
información. Se puede ver el flujo que ocurre en cada operación
con sus distintas rutas en caso de éxito en la operación o en
caso de error.
 2. Casó Práctico: Portal Musical 

2.1 Introducción al  Casó Práctico 

El caso práctico de web diseñada con UWE es una web que

representa la estructura de un portal musical, donde el usuario puede
descargarse discos en formato mp3. Ejemplos reales de portales
similares al a continuación explicado son: el famoso Itunes de Apple,
play.com o el servicio de descargas de música de Amazon, entre
otros muchos que existen actualmente en la red.

A continuación se realizará una breve explicación de los casos

de uso de este portal musical, con el objetivo de que el lector quede
familiarizado con las funcionalidades que este ofrece a la hora de
entender las explicaciones detallas del diseño de su estructura, que
realizaremos en los siguientes apartados, así algunos casos de uso
son los siguientes, ordenados por categorías:

2.1.1 Casos de uso referidos a usuarios 
- Hay dos tipos de usuarios:
o Registrados: son lo que tienen permitido descargar
discos.
o No Registrados: pueden llegar a ser Registrados,
registrándose mediante un nombre de usuario no código
ya por otro usuario Registrado y una contraseña, una vez
hecho esto para entrar como usuario Registrado, se debe
loguear en el sistema.
- El usuario Registrado puede navegar desde la página de inicio a
su página personal, en la cual se mostrará todos los discos
comprados anteriormente y su crédito actual para poder
realizar compras.
- Los links para loguearse y desloguearse son mostrados
siempre, en cada página del sitio web.
  
2.1.2 Casos  de  uso  referidos a  la  información 
sobre los discos 

- En este sistema, solo se permite la descarga de discos

completos, así el único método de búsqueda ofrecido es buscar
discos por su nombre.

- El resultado de una búsqueda es una lista de los discos que han

coincidido con el campo de búsqueda. Cada elemento de esta
lista se corresponde con un link a la página detallada de cada
disco.

- La caja de búsqueda de discos es mostrada siempre, en cada

página del sitio web.

- La pagina detallada de cada disco ofrecerá la siguiente

información:

o Título del disco.

o Nombre del artista del disco.
o Lista de canciones contenidas en el mismo.
o Precio de venta del disco.
o Link de descarga del disco en el caso de que el usuario le
haya comprado, o en su defecto link que le lleva a la
página de compra del disco.

- Cada disco solo puede tener un artista, se ha realizado así para

reducir la complejidad del modelo de navegación y de
presentación.

2.1.3 Casos  de  uso  respecto  al  sistema  de 

compra 
- Cada usuario tiene una cuenta de crédito asociada, esta tarjeta
será la que se usará para comprar discos. Estas cuentas se
pueden recargar realizando pagos con tarjetas de crédito.

- Para realizar pagos con la tarjeta de crédito, el usuario debe

introducir el número de la tarjeta de crédito y la cantidad
económica que quiere recargar. Información que deberá ser
validada.

- El usuario deberá confirmar la transacción justo antes de

producirse el pago.
2.2 Modelo de Casos de Uso 
Lo primero que se ha realizado en el diseño de la web es
modelar los casos de uso, para obtener una idea general de lo que un
usuario puede o no puede hacer en el sistema, así en la siguiente
imagen se muestra estas posibilidades, hay que decir que en el
diseño de este caso práctico se ha omitido la información referente a
las transacciones económicas de las compras por motivos de
simplificación práctica. Con lo cual el modelado de los casos de uso
quedaría:

Ilustración 8

En la figura podemos ver que las funciones de un usuario no

registrado son limitadas, ya que solo puede buscar información sobre
los disco, registrarse y loguearse, para llegar a ser usuario
Registrado.
 En cuanto a las funciones del usuario Registrado, son las
mismas que el usuario no registrado más las funcionalidades
adicionales de comprar el disco, descargar el disco y las opciones de
administración de su cuenta de crédito personal: recargar cuenta, ver
cuenta y ver historial de discos comprados.
2.3 Modelo de Contenido 
Como comentamos en puntos anteriores en este documento, el
modelo de contenido contiene la información relevante almacenada
en el sistema, como se estructura y como se relaciona. Esto se
representa mediante un diagrama de clases UML. En este caso
práctico esta información está clara y se muestra en la figura
siguiente:

Ilustración 9

Como podemos ver tendremos 3 entidades de almacenamiento

(clases) que son Album con los atributos del disco, Artista y Canción
(con sus atributos correspondientes. A simple vista se puede observar
que Artista podría estar metido como un atributo más de Album, pero
se ha puesto independiente para facilitar una posible mejora que
sería incluir varios artistas por disco, lo que cubriría aquellos discos
que hayan sido producidos por varias personas que no formen un
grupo musical entre ellos.
2.4 Modelo de Usuario 
La diferencia entre el modelo de Contenido y este modelo no
explicado anteriormente, es que el modelo de Contenido define el
contenido de los datos almacenados por la aplicación, mientras que el
modelo de Usuario tiene dos objetivos diferenciados:

- Contiene las clases que define que información es almacenada

en el contexto de una sesión. En este caso práctico una sesión
esta formada por el usuario actual y sus discos.

- Estas clases contenidas proven de operacioines que puede ser

usados en el proceso de negociación de procesos. El
comportamiento de estas operaciones no es modelado, pero
tiene que ser implementado por separado. El comportamiento
de estos metodos se puede describir de multiples formas, en la
siguiente imagen se ha usado OCL (Object Constraint
Language) para ello.

En la siguiente imagen tenemos el modelo de Usuario

realizado para este casó práctico:
 Ilustración 10

Como hemos explicado anteriormente, en este modelo se

representa la sesión en la clase (Sessión), las operaciones de las
clases, en nuestro caso las que puede realizar el usuario (User) y las
que se pueden realizar con la tarjeta de crédito (CreditCard). Por otro
lado tenemos el comportamiento definido para algunas operaciones
en el lenguaje OCL, como hemos indicado anteriormente, esto esta
especificado en las notas blancas de la derecha de la imagen.
2.5 Modelo de Navegación 
En este modelo se especifica la relación interna del sitio web, es
decir cómo se relaciona cada página web con las demás, con lo cual,
en definitiva es como se navega por el sitio web. El modelo que se
presenta a continuación es un modelo simplificado ya que presentar
el modelo de navegación completa de un sitio web es una tarea
bastante extensa, y no serviría de mucho mostrar el funcionamiento
de sus elementos. Algunas de estas simplificaciones son las
siguientes:

- El estereotipo «navigationLink» no se muestra sobre las

asociaciones con el objetivo de hacer el diagrama más legible
para el lector.
- El contenido de las clases de navegación tampoco se especifica
por el mismo motivo.
- Solo se ha definido un atributo de navegación que necesita una
expresión de selección: (Album::artistName). Los demás se
pueden sacar mediante las propiedades del contenido de las
clases.

Con lo explicado anteriormente mostramos el diagrama de modelo de

navegación reducido de este caso práctico:
 Illustración 11
1

En estee diagram
ma podem mos ver como se relacionan las clases
entrre ellas, llegandoo a un entendimi
e iento sup
perior quue un simmple
diag
grama UM ML con la extensiónn que UW
WE aporta a a este estándar, esta
exteensión ess la que explicam mos en el modelo de nave egación de
d la
intro
oducción de este d
documentto con los estereottipos
corrrespondieentes. De nuevo in ncluimos los estere
eotipos a
añadidos para
obteener una visión má ás clara de
d esta ex
xtensión.

ste
ereotype
e-names and th
heir
ico
ons

menu
na
avigationC
Class

index query

guidedTo
our prrocessClass
 De la extensión de UWE podemos destacar las clases de navegación
marcadas con el atributo <<navigationClass>> , las paginas de
índice marcado con el estereotipo adecuado, también podemos ver
que en el sitio web tenemos 3 menús (el principal, el de usuario y el
de los discos), así como varias clases operacionales (processClass)
que representan operaciones que pueden ser realizadas, estas son:
loguearse, desloguearse, registrarse, comprar álbum y recargar
cuenta del usuario. Otra observación importante es en cuanto a las
relaciones, se puede ver que las relacionas entre clases de proceso
(operacionales) y el resto están especificadas con un “processlink”
que indica el tipo de relación que es.
2.6 Modelo de Proceso 

En este modelo se definen las acciones que realizan las clases

de proceso (operacionales) especificadas en el modelo de navegación,
como se explico anteriormente, el modelo de Proceso se divide en dos
partes, la primera el Modelo de Estructura de Procesos, en el cual se
incluyen las relaciones entre las clases de proceso y la segunda parte
es el Modelo de Flujo de Procesos, en el que se incluyen las
actividades relacionadas con cada proceso, describiendo el
comportamiento interno de cada clase proceso.
- Modelo de Estructura de Procesos: En la siguiente imagen
se muestra el Modelo de Estructura de Procesos del caso
práctico:

Ilustración 12

En este modelo podemos observar que la operación de comprar

un disco, representada por la clase BuyAlbum, está relacionada
son subclases proceso para indicar que el saldo es insuficiente o
para confirmar la compra, al igual que la operación recargar
(Recharge), cuya clase está relacionada con una clase para
determinar los datos de entrada de esta recarga y otra clase de
confirmación de la recarga. Así también podemos observar que
en la clase proceso Login se notifica un mensaje de error en
caso de que exista algún fallo en el proceso de loguearse.

- Modelo de Flujo de Procesos: Como en el diagrama de

navegación de este caso práctica tenemos cinco clases proceso,
 se debería especificar un flujo interno para cada una de ellas,
pero para simplificar el documento, y con la consigna de que
para entender los flujos vale con explicar uno solo, se mostrará
el flujo de la clase proceso para loguearse, en nuestro caso
“Login”.

Ilustración 13

En este diagrama podemos ver el flujo de interno de la

operación de loguearse de nuestro sitio web, se puede observar
lo siguiente respecto al flujo:
- Lo primero que se realiza es la introducción de datos del
usuario esto es el “userName” y el “password”.
- Seguido de ello se realizan las comprobaciones de los mismos,
así “userName” es comprobado con el método user.loadUser(),
dependiendo del resultado de la comprobación el flujo puede
tomar varias alternativas:
o Se generara un error (dando la posibilidad de
reintroducir los datos al usuario) si el nombre introducir
no coincide con alguno asignado en la base de datos.
o En caso de respuesta positiva, el nombre es correcto, se
manda el nombre al método donde se comprueba la
contraseña user.checkPassword().
- El método user.checkPassword() comprueba que la contraseña
coincide con el nombre de usuario, de nuevo se pueden tomar
dos alternativas:
o En caso de error el flujo iría a mostrar el mensaje de
error y a reintroducir los datos.
o En caso de coincidencia afirmativa se abriría la sesión del
usuario con el método Sessión.CurrentUser().
- El método Sessión.CurrentUser() inicia la sesión de usuario en
caso de que el proceso de loguearse haya resultado exitoso.

 
2.7
7 Mod
delo de Pressentacción  

En el modeelo de Prresentació
ón, comoo ya explicamos ene la
oducción del documento, se
intro s contem mplan las clases de navegaación
y de e procesoos que pertenece
p n a cadaa página web. Parra estar más
orientados a la hora de comprender el e modelo de pre esentación
n de
este
e caso, volvemos
v s a adjun
ntar los símbolos s de los estereottipos
corrrespondieentes a este
e mode elo, que ya explic
camos an nteriorme
ente.
Estoos estereo
otipos son
n:

stereotyype-nammes and their

t ico
ons
prese
entationClass prresentatio
onPage
text te
extInput
or
ancho an
nchoredCollection
butto
on im
mage
form prresentatio
onGroup
Illustración 14
1
 Para el caso práctico nuestro el diagrama es mostrado como un
diagrama de estructura UML, en el cual las propiedades que contiene
por composición se representan como un rectángulo en el que un
elemento queda contenido en otro.

Ilustración 15
 Como podemos ver este diagrama es muy extenso, no ha sido
reducido para su muestra, en el se muestran todas las páginas de las
que se compone el sitio web, que son 13 instancias. Para entender
este modelo de presentación explicaremos tan solo una clase de las
trece disponibles, ya que con entender una página tan representativa
como MusicLibrary se entenderá perfectamente el resto de ellas,
además aquí no se muestran relaciones entre ellas, esta
independencia facilita la explicación de ellas por separado.

Así, la pagina MusicLibrary, es una página de presentación (está

marcada como tal), que como podemos contendrá 3 clases, estas son
MainMenu, AlbumQuery y MainRegion. Vamos a ir una por una
explicando su representación:
- Clase MainMenu: es una clase de presentación, lo que indica
que contiene información que será mostrada al usuario, esta
clase tiene 4 anclas (Login, Register, Logout y User), un ancla
significa que contiene un enlace a una instancia de cada una de
las 4 clases cuyo nombre coincide con el ancla, que pueden ser
clases de navegación o las clases de proceso mostradas en el
Modelo de Procesos. Como podemos ver, también se ha
representado mediante notas aclarativas cuando tiene que ser
mostrada cada enlace y cuando no, es decir, Login y Register
(cuando el usuario no está logueado) y Logout y User (cuando
el usuario esta logueado).

- Clase AlbumQuery: Esta clase de presentación, representa la

caja de búsqueda de los discos, como podemos ver, tiene dos
propiedades, un texto de entrada (marcado como “textInput”)
en el que se introducirá el texto a buscar, es decir el título del
disco que se quiere buscar, y la otra propiedad es el botón de
búsqueda (marcado como “Button”), el cual se pulsará para
confirmar la búsqueda del texto introducido.

- MainRegion: Esta clase muestra la región principal de la pagina

de presentación MusicLibrary, en ella están situada instancias
de todas las principales paginas de presentación de las que se
compone el sitio, estas son: User, Login, Album, Home,
AlbumIndex, Recharge, Register y BuyAlbum.

Esta sería una explicación a la página de presentación Music

Library, pero como podemos ver existen otros estereotipos de UWE
que están situados en otras clases, para entenderlos explicaremos un
ejemplo de cada uno:
- En la clase Album tenemos dos instancias de elementos
marcados con “Text”, esto significa que ese elemento es un
texto, en concreto es esta clase hay 5 elementos de este tipo,
para explicar el Titulo, el Artista, la Descripción, el Precio y el
Link de descarga o compra.
- También en la clase Album tenemos un elemento marcado con
el estereotipo “Image”, esto significa que ese elemento
contiene una imagen, en este caso se usa para almacenar la
caratula del disco.
- En la clase RechargeDataInput tenemos un elemento marcado
con el estereotipo “form”, esto indica que este elemento es un
formulario, en este caso nos referimos al formulario de entrada
de información cuando recargamos una cuenta de crédito de un
usuario, en el que tenemos que introducir varios textos de
entrada y al final tenemos un botón de confirmación.
 3. Conclusiones sobre UWE 

Tras el estudio de la notación extendida para UML, UWE, he

obtenido algunas conclusiones interesantes sobre las ventajas que
produce utilizar esta notación.

Antes de explicar las ventajas, quería comentar que no

explicare las desventajas en un apartado, ya que no he encontrado
ninguna salvo la que implica conseguir el conocimiento de UWE para
poder entender sus modelos, pero como esto no es una actividad que
requiera de un esfuerzo amplio, solo la comento aquí. A continuación
expongo las ventajas de utilizar esta notación:

Ventajas de utilizar UWE

En mi opinión la utilización de UWE para diseñar proyectos

sobre sitios web, conlleva en su mayor parte, ventajas, están son:

Presenta unos modelos de diseño que se ajustan bastante bien

al diseño de sitios web. Por ejemplo el Modelo de Navegación, como
el Modelo de Presentación, son muy útiles a la hora de poder
visualizar como se navegará por un sitio web y como será mostrada
la información al usuario. Esta forma de visualizarlo, facilita a los
diseñadores encontrar errores de diseño, pues de un simple vistazo
podemos observar si una página es difícilmente alcanzable mediante
la navegación o si hay información que no se representa en el sitio
web o se representa en un lugar erróneo por ejemplo.

Otra ventaja que tiene es la notación especifica que ofrece a

UML para representar elementos de una página web, así tenemos
elementos como: paginas índices, pagina inicial, pagina menú, texto
de entrada, formularios web, botones, imágenes, clases de
navegación, clases de proceso o links entre otros muchos, para los
que tenemos un estereotipo para representarlos, esto es una carencia
de UML que no contempla estos elementos, así con UWE queda
solucionada dicha carencia y podemos representar esta información.

Por último quería resaltar como ventaja la utilidad de todos

estos modelos a la hora de transferir la implementación o el rediseño
de la pagina web, a segundas personas, es decir, una persona puede
diseñar una página web usando UWE, y transferir este diseño a una
segunda persona para su implementación o rediseño (en caso de que
hiciera falta), esta segunda persona tendría con los modelos de UWE
muchas facilidades para llevar a cabo su labor, ya que UML y UWE se
caracterizan por su simplicidad y buena legibilidad, así el uso de esta
notación es una muy buena práctica que debería ser llevada a cabo a
la hora de realizar un proyecto web.
4. Referencias 
- Página del estándar UML de OMC: http://www.uml.org/

- Página oficial de UWE: http://uwe.pst.ifi.lmu.de/

- UWE en Wikipedia: http://en.wikipedia.org/wiki/UML-

based_Web_Engineering_(UWE)

- MagicDraw, software de modelado:

http://www.magicdraw.com/

- MagicUWE, plugin para MagicDraw:

http://uwe.pst.ifi.lmu.de/toolMagicUWE.html

- Manual de MagicUWE:

http://uwe.pst.ifi.lmu.de/toolMagicUWEReference.html

- Material docente: “Transformation Techniques in the Model-

Driven Development Process of UWE at the Second Workshop

on Model-Driven Web Engineering”:

http://www.pst.ifi.lmu.de/personen/kochn/presentations/mdwe

2006_norakoch.pdf

- Libro sobre UWE: “Web Engineering: Modelling and

Implementing Web Applications” de Gustavo Rossi, Oscar

Pastor, Daniel Schwabe, Luis Olsina