Es(UE

stuMLEng

udioL­bgin

o dbasnee

de Ued erin

 UW Wng)

WE Web) 

 

Í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.

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,

Ilustración 1

un esonatribcontsecu

1.4

estáelem

conemospág

la aquesigu

repr

email, un de tipobutos, retacto pueundarios.

4.2 MoEste m

á relaciomentos de

Para electadas strados einas difer

Al mismagenda d introduc

uientes:

Aquí tresenta u

na direcció String yepresentaede tener

odelo d

modelo indnado inte navegac

lo se utipor enlacen la mirentes.

mo tiempoe contacte la meto

steico

na

enemos na agend

ón y un ty los doadas porr una dir

 de nav

dica comternamención.

lizan unidces de nsma pág

o que exptos, podeodología U

ereotypeons

avigationC

index

guidedTo

I

el ejempda de con

teléfono. s últimosr las clarección y

vegació

mo el sistente. Es

dades denavegaciógina web

plicamos emos ir vUWE, los

e-names

Class

our pr

Ilustración

plo de ntactos:

De los cus a son ases Addy un teléf

ón 

ema de decir có

navegacón. Esto, no tien

este modviendo loelemento

and th

menu

query

rocessCla

2

navegació

uales los estructu

dress y fono prin

páginas wómo se

ción llamaos nodosnen porq

delo con eos distintoos introdu

heir

ss

ón del si

dos primras de oPhone, c

ncipal y o

web del enlazan

adas “nos puedenque estar

el ejemplos elemeucidos son

tio web

eros otros cada otros

sitio los

dos” ser r en

o de ntos n los

que

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 de elem

ejem

Presestoemapágformlanz

4.3 Mo En procesos

mentos qu

A complo de la

Comsentation_o significaail, direccina de in

mulario dzar la bús

odelo d este mod que peue introdu

stereoty prese

text

ancho

button

form

ontinuacióa Agenda

mo se pu_Class, ca que pociones y loicio Addree búsque

squeda.

 de predelo se reertenecenuce la me

ype-namntationCla

or

n

Il

ón se mua de Conta

Il

ede ver cubriendoor cada cos teléfonessBook ceda con

esentacepresenta a cadaetodología

mes and tass pre

tex

an

im

pre

lustración 4

uestra el actos:

lustración 5

la clase c tambiéncontacto,nos. Tambcontiene un camp

ción an las cla página a UWE en

their iconesentatio

xtInput

nchoredCo

mage

esentatio

4

diagrama

5

contacto n diferent tiene qbién se pun texto

po de tex

ses de nweb. Es

n este mo

ns onPage

ollection

onGroup

a de pres

es presees textosue ser muede obs de introdxto y un

navegaciótos son

odelo:

entación

entada cos y botonmostrado servar queducción y botón p

ón y los

del

omo nes, un e la un ara

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:

entrdiagexteintrocorrobte

En estere ellas, grama UMensión esoducción respondieener una

e diagramllegando

ML con la s la que de entes. De visión má

steico

na

Il

ma podemo a un e extensiónexplicameste d nuevo inás clara d

ereotypeons

avigationC

index

guidedTo

lustración 1

mos ver entendimin que UW

mos en eldocumentncluimos de esta ex

e-names

Class

our pr

11

como seiento sup

WE aporta modelo to conlos esterextensión.

and th

menu

query

rocessCla

relacionperior qua a este e de nave los eotipos a

heir

ss

an las clue un simstándar,

egación destereot

añadidos

ases mple esta

de la tipos para

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

introy deorieestecorrEsto

7 Mod

En oducción e procesontados a

e caso, vrespondieos estereo

delo d

el mode del docuos que p

a la horavolvemosentes a eotipos son

stereoty prese

text

ancho

butto

form

e Pres

elo de Prmento, s

pertenece de coms a adjuneste moden:

ype-namentationC

or

on

Il

sentac

resentacióse contemn a cadaprender entar los elo, que

mes and tlass pr

te

an

im

pr

lustración 1

ción 

ón, comomplan lasa página el modelsímbolosya explic

their icoresentatio

extInput

nchoredC

mage

resentatio

14

 

o ya expl clases dweb. Paro de pres de los camos an

ons onPage

ollection

onGroup

icamos ee navegara estar

esentación estereotnteriorme

en la ación más n de tipos ente.

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