Es udio deUWE stu od UW (UML basedWeb Lb W Eng nee ng) E gin erin )

ndice
1. INTRODUCCIN A UWE
Qu es UWE? .............................................................................................. 3 1.2 UWE y su relacin 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 navegacin .................................................... 7 1.4.3 Modelo de presentacin .................................................. 9 1.4.4 Modelo de Proceso ....................................................... 11

2. CASO PRACTICO: PORTAL MUSICAL

2.1 Introduccin al Cas Prctico ............................................................. 13
2.1.1 Casos de uso referidos a usuarios .................................. 13 2.1.2 Casos de uso referidos a la informacin 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 Navegacin........................................................................ 21 2.6 Modelo de Proceso ............................................................................. 24 2.7 Modelo de Presentacin...................................................................... 27

3. CONCLUSIONES 4. REFERENCIAS

1. IntroduccinaUWE
1.1 QuesUWE?
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 notacin 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 sistematizacin son dos aspectos sobre los que se enfoca UWE. Adems de estar considerado como una extensin del estndar UML, tambin se basa en otros estndares como por ejemplo: XMI como modelo de intercambio de formato, MOF para el metamodelado, los principios de modelado de MDA, el modelo de transformacin 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 navegacin, en el cual se incluyen modelos estticos y modelos dinmicos. 4. Modelo de estructura: en el cual se encuentra la presentacin 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 Adaptacin.

En cuanto a los requisitos, UWE los clasifica dependiendo del carcter de cada uno. Adems distingue entre las fases de captura, definicin y validacin de requisitos.

1.2 UWEysurelacinconUML
UWE define una extensin del Lenguaje Unificado de Modelado (UML). sta, es considerada como una extensin ligera de peso e incluye en su definicin tipos, etiquetas de valores y restricciones para las caractersticas especificas del diseo Web, las cuales, unidas a las definiciones de UML forman el conjuntos de objetos de modelado que se usarn para el desarrollo del modelo utilizado en UWE. Las funcionalidades que cubren UWE abarcan reas relacionadas con la Web como la navegacin, presentacin, los procesos de negocio y los aspectos de adaptacin. Una de las ventajas de que UWE extienda el estndar UML es la flexibilidad de ste para la definicin de un lenguaje de modelado especifico para el dominio web y sobretodo la aceptacin universal de dicho estndar en el campo de la ingeniera del software. Otra gran ventaja es que actualmente existen mltiples de herramientas CASE basadas en UML, con lo cual es relativamente sencillo su utilizacin y ampliacin para utilizar los objetos de modelado definidos en UWE. Estas herramientas se vern en el siguiente punto.

1.3 HerramientasSW
Como se ha explicado en la seccin anterior, para aplicar las funcionalidades que aade UWE, se utilizan las mismas herramientas software de modelado basadas en UML y se les aade una extensin a la aplicacin para que permita estas nuevas funcionalidades. Se ha desarrollado un plugin para una de las herramientas UML ms conocidas, MagicDraw, que es una herramienta que soporta la versin 2.1.2 de este estndar para lenguajes de programacin como por ejemplo Java, C++ o C#. Este plugin llamado MagicUWE, es de libre distribucin pudiendo adquirir gratuitamente y est desarrollado para la versin 16 de MagicDraw. En la pgina oficial de UWE se encuentra disponible as como un manual de instalacin y uso de esta extensin. Tambin se ha desarrollado UWEet, que es un plugin para la herramienta UML de cdigo 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. Tambin 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 extensin del lenguaje UML. UWEet tambin se encuentra disponible de manera gratuita en la pgina web oficial de UWE. Para uno de los entornos de desarrollo ms utilizados en todo el mundo, Eclipse, tambin se ha creado una extensin. Este plugin se denomina UWE4JSF y permite la generacin automtica de aplicaciones web para JavaServer Faces (JSF) platform. Por ltimo destacar que existe una herramienta software basada especficamente en la metodologa UWE, esta herramienta fue desarrollada como una extensin de ArgoUML, herramienta de modelado basada en UML. Se trata de la aplicacin ArgoUWE que permite la semiautomtica generacin de los modelos caractersticos de UWE como son el de navegacin, el de presentacin, el de procesos y el de adaptacin. Est herramienta tambin se encuentra disponible en la pgina web oficial de UWE.

1.4 ModelosdeUWE
En esta seccin se explicarn los modelos para cada una de los aspectos web que cubre la metodologa UWE, recordemos que estos aspectos eran navegacin, presentacin, los procesos de negocio y adaptacin. As procedemos a explicar con un breve ejemplo cada uno de estos modelos.

1.4.1 ModelodeContenido
Este modelo especifica cmo se encuentra relacionados los contenidos del sistema, es decir, define la estructura de los datos que se encuentran alojados en el sitio web. A continuacin se muestra un ejemplo de este modelo contenido en la pgina web de UWE.

Ilustracin 1

En este ejemplo se puede ver representado que el contenido web est formado por una agenda bsica de contactos, est agenda representada por la clase AddressBook contiene un conjunto de uno o ms contactos (clase Contact) , cada uno de ellos tiene un nombre,

un e email, un direcci y un t na n telfono. De los cu uales los dos primeros son de tipo String y los dos ltimos a son estructuras de otros s o atrib butos, re epresenta adas por las cla r ases Add dress y Phone, cada c cont tacto pue ede tener una dir r reccin y un telf fono prin ncipal y otros o secu undarios.

1.4 Mo 4.2 odelod denav vegaci n

Este m modelo ind dica com el siste mo ema de pginas w web del sitio est relacionado int ternamen nte. Es decir c mo se enlazan los elem mentos de navegac e cin. Para ello se utilizan unid dades de navegac cin llama adas nodos cone ectadas por enlac ces de n navegaci n. Esto nodos pueden ser os s mos strados e la misma pg en gina web, no tien nen porq que estar en r pginas difer rentes. Al mism tiempo que exp mo o plicamos este mod delo con e ejemplo de el la a agenda de contact tos, pode emos ir viendo lo distinto elementos v os os que introduce la meto odologa U UWE, los elemento introdu os ucidos son los n sigu uientes: ste ereotype e-names and th heir ico ons na avigationC Class index guidedTo our menu query pr rocessClass

Ilustracin 2 I

Aqu tenemos el ejemp plo de navegaci del sitio web que n n repr resenta una agend de contactos: da

Ilustracin 3

Para empezar tenemos AddressBook como pgina de inicio, as que est etiquetada como {isHome} y como clase de navegacin con el smbolo correspondiente (ver smbolos ms abajo). La pgina de inicio enlaza con un men, que sera nuestra pgina 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 funcin 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 sern 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 tambin cuando se realiza una bsqueda se debe mostrar la lista con los contactos del resultado, de ah que exista otro processLink entre las clases Search y ConctactList, esta ultima adems etiquetada como index, al ser una lista.

1.4 Mo 4.3 odelod depre esentac cin

En este mod delo se re epresenta las clases de n an navegaci y n de procesos que pe ertenecen a cada pgina web. Estos son los elem mentos qu introdu la me ue uce etodologa UWE en este mo a n odelo: stereoty ype-nam mes and their icon t ns presentationCla ass pre esentatio onPage text or ancho button n form tex xtInput an nchoredCo ollection im mage pre esentatio onGroup

Il lustracin 4

A co ontinuaci se mu n uestra el diagrama de presentacin del a ejem mplo de la Agenda de Conta a a actos:

Il lustracin 5

Com se puede ver la clase contacto es prese mo c entada co omo Pres sentation_ _Class, c cubriendo tambin diferentes textos y boton n s nes, esto significa que po cada c o a or contacto, tiene que ser m mostrado un ema direcc ail, ciones y lo telfon os nos. Tamb bin se puede obs servar que la e pgina de inicio Addre essBook c contiene un texto de introd duccin y un form mulario de bsque eda con un camp de tex po xto y un botn para lanz la bs zar squeda.

1.4.4 ModelodeProceso
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 sera:

Ilustracin 6

En este diagrama se puede ver que hay clases para definir 3 operaciones que necesita una confirmacin. As por ejemplo si el usuario quiere borrar un contacto el mensaje ser mostrado y despus haciendo clic en ok el contacto ser borrado. Las operaciones de actualizacin y creacin 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 operacin de borrado de contactos tenemos el siguiente diagrama:

Ilustracin 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 peticin de informacin. Se puede ver el flujo que ocurre en cada operacin con sus distintas rutas en caso de xito en la operacin o en caso de error.

2. CasPrctico:PortalMusical
2.1 IntroduccinalCasPrctico
El caso prctico de web diseada 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 continuacin explicado son: el famoso Itunes de Apple, play.com o el servicio de descargas de msica de Amazon, entre otros muchos que existen actualmente en la red. A continuacin se realizar una breve explicacin 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 diseo de su estructura, que realizaremos en los siguientes apartados, as algunos casos de uso son los siguientes, ordenados por categoras:

2.1.1 Casosdeusoreferidosausuarios
Hay dos tipos de usuarios: o Registrados: son lo que tienen permitido descargar discos. o No Registrados: pueden llegar a ser Registrados, registrndose mediante un nombre de usuario no cdigo ya por otro usuario Registrado y una contrasea, una vez hecho esto para entrar como usuario Registrado, se debe loguear en el sistema. El usuario Registrado puede navegar desde la pgina de inicio a su pgina personal, en la cual se mostrar todos los discos comprados anteriormente y su crdito actual para poder realizar compras. Los links para loguearse y desloguearse son mostrados siempre, en cada pgina del sitio web.

 2.1.2 Casos de uso referidosa la informacin sobrelosdiscos

En este sistema, solo se permite la descarga de discos completos, as el nico mtodo de bsqueda ofrecido es buscar discos por su nombre. El resultado de una bsqueda es una lista de los discos que han coincidido con el campo de bsqueda. Cada elemento de esta lista se corresponde con un link a la pgina detallada de cada disco.

La caja de bsqueda de discos es mostrada siempre, en cada pgina del sitio web.

La pagina detallada de cada disco ofrecer la siguiente informacin: o o o o o Ttulo 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 pgina de compra del disco.

Cada disco solo puede tener un artista, se ha realizado as para reducir la complejidad del modelo de navegacin y de presentacin.

2.1.3 Casos de uso respecto al sistema de compra

Cada usuario tiene una cuenta de crdito asociada, esta tarjeta ser la que se usar para comprar discos. Estas cuentas se pueden recargar realizando pagos con tarjetas de crdito. Para realizar pagos con la tarjeta de crdito, el usuario debe introducir el nmero de la tarjeta de crdito y la cantidad econmica que quiere recargar. Informacin que deber ser validada.

El usuario deber confirmar la transaccin justo antes de producirse el pago.

2.2 ModelodeCasosdeUso
Lo primero que se ha realizado en el diseo 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 diseo de este caso prctico se ha omitido la informacin referente a las transacciones econmicas de las compras por motivos de simplificacin prctica. Con lo cual el modelado de los casos de uso quedara:

Ilustracin 8

En la figura podemos ver que las funciones de un usuario no registrado son limitadas, ya que solo puede buscar informacin 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 ms las funcionalidades adicionales de comprar el disco, descargar el disco y las opciones de administracin de su cuenta de crdito personal: recargar cuenta, ver cuenta y ver historial de discos comprados.

2.3 ModelodeContenido
Como comentamos en puntos anteriores en este documento, el modelo de contenido contiene la informacin relevante almacenada en el sistema, como se estructura y como se relaciona. Esto se representa mediante un diagrama de clases UML. En este caso prctico esta informacin est clara y se muestra en la figura siguiente:

Ilustracin 9

Como podemos ver tendremos 3 entidades de almacenamiento (clases) que son Album con los atributos del disco, Artista y Cancin (con sus atributos correspondientes. A simple vista se puede observar que Artista podra estar metido como un atributo ms de Album, pero se ha puesto independiente para facilitar una posible mejora que sera incluir varios artistas por disco, lo que cubrira aquellos discos que hayan sido producidos por varias personas que no formen un grupo musical entre ellos.

2.4 ModelodeUsuario
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 aplicacin, mientras que el modelo de Usuario tiene dos objetivos diferenciados: Contiene las clases que define que informacin es almacenada en el contexto de una sesin. En este caso prctico una sesin esta formada por el usuario actual y sus discos.

Estas clases contenidas proven de operacioines que puede ser usados en el proceso de negociacin 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 prctico:

Ilustracin 10

Como hemos explicado anteriormente, en este modelo se representa la sesin en la clase (Sessin), 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 crdito (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 ModelodeNavegacin
En este modelo se especifica la relacin interna del sitio web, es decir cmo se relaciona cada pgina web con las dems, con lo cual, en definitiva es como se navega por el sitio web. El modelo que se presenta a continuacin es un modelo simplificado ya que presentar el modelo de navegacin completa de un sitio web es una tarea bastante extensa, y no servira 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 ms legible para el lector. El contenido de las clases de navegacin tampoco se especifica por el mismo motivo. Solo se ha definido un atributo de navegacin que necesita una expresin de seleccin: (Album::artistName). Los dems se pueden sacar mediante las propiedades del contenido de las clases.

Con lo explicado anteriormente mostramos el diagrama de modelo de navegacin reducido de este caso prctico:

Il lustracin 11 1

En este diagram podem e ma mos ver como se relacionan las clases re o entendimi iento sup perior qu un sim ue mple entr ellas, llegando a un e diag grama UM con la extensin que UW aporta a este estndar, esta ML n WE a exte ensin es la que explicam s mos en el modelo de nave egacin de la d intro oduccin de este document d to con los estereot tipos corr respondie entes. De nuevo in ncluimos los estere eotipos a aadidos para obte ener una visin m clara d esta ex s de xtensin. ste ereotype e-names and th heir ico ons na avigationC Class index guidedTo our menu query pr rocessClass

De la extensin de UWE podemos destacar las clases de navegacin marcadas con el atributo <<navigationClass>> , las paginas de ndice marcado con el estereotipo adecuado, tambin podemos ver que en el sitio web tenemos 3 mens (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 observacin importante es en cuanto a las relaciones, se puede ver que las relacionas entre clases de proceso (operacionales) y el resto estn especificadas con un processlink que indica el tipo de relacin que es.

2.6 ModelodeProceso
En este modelo se definen las acciones que realizan las clases de proceso (operacionales) especificadas en el modelo de navegacin, 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 prctico:

Ilustracin 12

En este modelo podemos observar que la operacin 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 operacin recargar (Recharge), cuya clase est relacionada con una clase para determinar los datos de entrada de esta recarga y otra clase de confirmacin de la recarga. As tambin podemos observar que en la clase proceso Login se notifica un mensaje de error en caso de que exista algn fallo en el proceso de loguearse. Modelo de Flujo de Procesos: Como en el diagrama de navegacin de este caso prctica tenemos cinco clases proceso,

se debera 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.

Ilustracin 13

En este diagrama podemos ver el flujo de interno de la operacin de loguearse de nuestro sitio web, se puede observar lo siguiente respecto al flujo: Lo primero que se realiza es la introduccin 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 mtodo user.loadUser(), dependiendo del resultado de la comprobacin 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 mtodo donde se comprueba la contrasea user.checkPassword(). El mtodo user.checkPassword() comprueba que la contrasea coincide con el nombre de usuario, de nuevo se pueden tomar dos alternativas: o En caso de error el flujo ira a mostrar el mensaje de error y a reintroducir los datos. o En caso de coincidencia afirmativa se abrira la sesin del usuario con el mtodo Sessin.CurrentUser(). El mtodo Sessin.CurrentUser() inicia la sesin de usuario en caso de que el proceso de loguearse haya resultado exitoso.

2.7 Mod 7 delodePres sentac cin

En el mode de Pr elo resentaci n, como ya explicamos en la o e oduccin del documento, s contem se mplan las clases de navega acin intro y de proceso que p e os pertenecen a cada pgina web. Par estar ms a ra orientados a la hora de comprender el modelo de pre e esentacin de n este caso, v e volvemos a adjun s ntar los smbolos de los estereot s tipos corr respondie entes a e este mode elo, que ya explic camos an nteriorme ente. Esto estereo os otipos son n: stereoty ype-nam mes and their ico t ons prese entationClass pr resentatio onPage text or ancho butto on form te extInput an nchoredCollection im mage pr resentatio onGroup
Il lustracin 14 1

Para el caso prctico nuestro el diagrama es mostrado como un diagrama de estructura UML, en el cual las propiedades que contiene por composicin se representan como un rectngulo en el que un elemento queda contenido en otro.

Ilustracin 15

Como podemos ver este diagrama es muy extenso, no ha sido reducido para su muestra, en el se muestran todas las pginas de las que se compone el sitio web, que son 13 instancias. Para entender este modelo de presentacin explicaremos tan solo una clase de las trece disponibles, ya que con entender una pgina tan representativa como MusicLibrary se entender perfectamente el resto de ellas, adems aqu no se muestran relaciones entre ellas, esta independencia facilita la explicacin de ellas por separado. As, la pagina MusicLibrary, es una pgina de presentacin (est marcada como tal), que como podemos contendr 3 clases, estas son MainMenu, AlbumQuery y MainRegion. Vamos a ir una por una explicando su representacin: - Clase MainMenu: es una clase de presentacin, lo que indica que contiene informacin 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 navegacin o las clases de proceso mostradas en el Modelo de Procesos. Como podemos ver, tambin 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 presentacin, representa la caja de bsqueda 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 ttulo del disco que se quiere buscar, y la otra propiedad es el botn de bsqueda (marcado como Button), el cual se pulsar para confirmar la bsqueda del texto introducido. MainRegion: Esta clase muestra la regin principal de la pagina de presentacin MusicLibrary, en ella estn situada instancias de todas las principales paginas de presentacin de las que se compone el sitio, estas son: User, Login, Album, Home, AlbumIndex, Recharge, Register y BuyAlbum.

Esta sera una explicacin a la pgina de presentacin Music Library, pero como podemos ver existen otros estereotipos de UWE que estn 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 Descripcin, el Precio y el Link de descarga o compra. Tambin 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 informacin cuando recargamos una cuenta de crdito de un usuario, en el que tenemos que introducir varios textos de entrada y al final tenemos un botn de confirmacin.

3. ConclusionessobreUWE
Tras el estudio de la notacin extendida para UML, UWE, he obtenido algunas conclusiones interesantes sobre las ventajas que produce utilizar esta notacin. Antes de explicar las ventajas, quera 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 continuacin expongo las ventajas de utilizar esta notacin: Ventajas de utilizar UWE En mi opinin la utilizacin de UWE para disear proyectos sobre sitios web, conlleva en su mayor parte, ventajas, estn son: Presenta unos modelos de diseo que se ajustan bastante bien al diseo de sitios web. Por ejemplo el Modelo de Navegacin, como el Modelo de Presentacin, son muy tiles a la hora de poder visualizar como se navegar por un sitio web y como ser mostrada la informacin al usuario. Esta forma de visualizarlo, facilita a los diseadores encontrar errores de diseo, pues de un simple vistazo podemos observar si una pgina es difcilmente alcanzable mediante la navegacin o si hay informacin que no se representa en el sitio web o se representa en un lugar errneo por ejemplo. Otra ventaja que tiene es la notacin especifica que ofrece a UML para representar elementos de una pgina web, as tenemos elementos como: paginas ndices, pagina inicial, pagina men, texto de entrada, formularios web, botones, imgenes, clases de navegacin, 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 informacin. Por ltimo quera resaltar como ventaja la utilidad de todos estos modelos a la hora de transferir la implementacin o el rediseo de la pagina web, a segundas personas, es decir, una persona puede disear una pgina web usando UWE, y transferir este diseo a una segunda persona para su implementacin o rediseo (en caso de que hiciera falta), esta segunda persona tendra 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 notacin es una muy buena prctica que debera ser llevada a cabo a la hora de realizar un proyecto web.

4. Referencias
Pgina del estndar UML de OMC: http://www.uml.org/ Pgina 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