Estudio de UWE - Metodologia de Desarrollo Web

Esstu udio o d de U  UW WE  (UML L­b based  W Web  E gin Eng nee erin 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 metamodelado, 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, re epresenta adas porr las cla ases Add dress y Phone, cada c conttacto pue ede tenerr una dirrección y un teléffono prin ncipal y otros o secu undarios.

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 intternamen nte. Es decir có ómo se enlazan los elem mentos de e navegac ción. Para ello se utilizan unid dades de navegac ción llama adas “nodos” cone ectadas por enlac ces de navegació n ón. Esto os nodos s pueden ser mos strados en e la misma pág gina web, no tien nen porq que estarr en páginas diferrentes. Al mism mo tiempo o que exp plicamos este mod delo con e el ejemplo de la agenda a de contacttos, pode emos ir viendo v lo os distinto os elementos que introduce la meto odología UWE, U los elemento os introdu ucidos son n los sigu uientes: ste ereotype e-names and th heir ico ons na avigationC Class index

menu 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 me etodología a UWE en n este mo odelo: stereoty ype-nam mes and their t icon ns presentationCla ass pre esentatio onPage text

tex xtInput

or ancho

an nchoredCo ollection

button n

im mage

form

pre esentatio onGroup

Illustración 4

A co ontinuació ón se mu uestra el diagrama a de presentación del ejem mplo de la a Agenda a 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 boton nes, esto o significa a que po or cada contacto, c tiene que ser m mostrado un ema ail, direcc ciones y lo os teléfon nos. Tamb bién se puede obs servar 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ús squeda.

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 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 o o o o

-

Título del disco. Nombre del artista del disco. Lista de canciones contenidas en el mismo. Precio de venta del disco. 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 este e diagram ma podem mos ver como se relacionan las clases o a un entendimi e iento sup perior qu ue un sim mple entrre ellas, llegando diag grama UM ML con la extensión n que UW WE aporta a a este estándar, esta exte ensión es s la que explicam mos en el modelo de nave egación de d la intro oducción de este d document to con los estereottipos corrrespondie entes. De nuevo in ncluimos los estere eotipos a añadidos para obte ener una visión má ás clara de d esta ex xtensión. ste ereotype e-names and th heir ico ons na avigationC Class index guidedTo our

menu query prrocessClass

De la extensión de UWE podemos destacar las clases de navegación marcadas con el atributo , 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 mode elo de Prresentació ón, como o ya explicamos en e la oducción del documento, se s contem mplan las clases de navega ación intro y de e proceso os que pertenece p n a cada a 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 corrrespondie entes a este e mode elo, que ya explic camos an nteriorme ente. Esto os estereo otipos son n: stereoty ype-nam mes 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/UMLbased_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 ModelDriven 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