Es udio de UWE  stu o d  UW (UML based Web  L­b  W Eng nee ng) E gin erin ) 

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

2 UWE y su relación con UML  UWE define una extensión del Lenguaje Unificado de Modelado (UML). las cuales. con lo cual es relativamente sencillo su utilización y ampliación para utilizar los objetos de modelado definidos en UWE. Ésta. 1. 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. 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.En cuanto a los requisitos. . Otra gran ventaja es que actualmente existen múltiples de herramientas CASE basadas en UML. definición y validación de requisitos. UWE los clasifica dependiendo del carácter de cada uno. es considerada como una extensión ligera de peso e incluye en su definición tipos. Las funcionalidades que cubren UWE abarcan áreas relacionadas con la Web como la navegación. presentación. Además distingue entre las fases de captura. los procesos de negocio y los aspectos de adaptación. etiquetas de valores y restricciones para las características especificas del diseño Web. Estas herramientas se verán en el siguiente punto.

que es un plugin para la herramienta UML de código abierto UMLet. 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. Por último destacar que existe una herramienta software basada específicamente en la metodología UWE. el de presentación. Este plugin se denomina UWE4JSF y permite la generación automática de aplicaciones web para JavaServer Faces (JSF) platform. En la página oficial de UWE se encuentra disponible así como un manual de instalación y uso de esta extensión. Eclipse. Este plugin llamado MagicUWE. 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. herramienta de modelado basada en 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. este plugin proporciona a UWEet de una paleta en su interfaz con todos los elementos que son definidos por UWE. Esta herramienta se caracteriza por una interfaz simple para el usuario y por su compatibilidad con Eclipse a la hora de compartir diagramas UML. MagicDraw.1. C++ o C#. para aplicar las funcionalidades que añade UWE. . es de libre distribución pudiendo adquirir gratuitamente y está desarrollado para la versión 16 de MagicDraw. También puede exportar estos a distintos formado como el archiconocido PDF.1. que es una herramienta que soporta la versión 2. el de procesos y el de adaptación. Se ha desarrollado un plugin para una de las herramientas UML más conocidas. Está herramienta también se encuentra disponible en la página web oficial de UWE. Dicho esto. también se ha creado una extensión.3 Herramientas SW  Como se ha explicado en la sección anterior. También se ha desarrollado UWEet.2 de este estándar para lenguajes de programación como por ejemplo Java. esta herramienta fue desarrollada como una extensión de ArgoUML. permitiendo así la extensión del lenguaje UML.

es decir.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. define la estructura de los datos que se encuentran alojados en el sitio web.1 Modelo de Contenido  Este modelo especifica cómo se encuentra relacionados los contenidos del sistema. 1. los procesos de negocio y adaptación. A continuación se muestra un ejemplo de este modelo contenido en la página web de UWE. presentación. está agenda representada por la clase AddressBook contiene un conjunto de uno o más contactos (clase Contact) .1. Ilustración 1 En este ejemplo se puede ver representado que el contenido web está formado por una agenda básica de contactos. Así procedemos a explicar con un breve ejemplo cada uno de estos modelos. recordemos que estos aspectos eran navegación.4. . cada uno de ellos tiene un nombre.

un direcció y un t na ón teléfono. Para ello se utilizan unid dades de navegac ción llama adas “nodos” cone ectadas por enlac ces de n navegació ón.2 odelo d  de nav vegació ón  Este m modelo ind dica com el siste mo ema de páginas w web del sitio está relacionado int á ternamen nte.un e email. no tien nen porq que estar en r páginas difer rentes. Es decir có ómo se enlazan los elem mentos de navegac e ción. Esto nodos pueden ser os s mos strados e la misma pág en gina web. cada c cont tacto pue ede tener una dir r rección y un teléf fono prin ncipal y otros o secu undarios. 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.4 Mo 4. 1. pode emos ir viendo lo distinto elementos v os os que introduce la meto odología 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 Ilustración 2 I Aquí tenemos el ejemp plo de navegació del sitio web que n ón repr resenta una agend de contactos: da . Al mism tiempo que exp mo o plicamos este mod delo con e ejemplo de el la a agenda de contact tos.

La página de inicio enlaza con un menú.Ilustración 3 Para empezar tenemos AddressBook como página de inicio. para ello la clase Main Menu esta etiquetada como pagina Menu. de ahí que exista otro processLink entre las clases Search y ConctactList. así ambos enlaces serán del tipo process link. este se debe mostrar. que sería nuestra página de índice. al ser una lista. y con la clase ConctactCreation (que creará un contacto). 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. . esta clase es un proceso no definido con lo cual llevará la etiqueta de processClass. Como también cuando se realiza una búsqueda se debe mostrar la lista con los contactos del resultado. esta ultima además etiquetada como index. Para finalizar vemos que la clase ConctactCreation está enlazada con Conctact ya que cuando se crea un nuevo contacto. así que está etiquetada como {isHome} y como clase de navegación con el símbolo correspondiente (ver símbolos más abajo).

c cubriendo también diferentes textos y boton n s nes.1. . esto significa que po cada c o a or contacto.3 odelo d  de pre esentac ción  En este mod delo se re epresenta las clases de n an navegació y ón de procesos que pe ertenecen a cada página web. Estos son los elem mentos qu introdu la me ue uce etodología 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 lustración 4 A co ontinuació se mu ón uestra el diagrama de presentación del a ejem mplo de la Agenda de Conta a a actos: Il lustración 5 Com se puede ver la clase contacto es prese mo c entada co omo Pres sentation_ _Class. tiene que ser m mostrado un ema direcc ail. ciones y lo teléfon os nos.4 Mo 4. Tamb bién se puede obs servar que la e página de inicio Addre essBook c contiene un texto de introd ducción y un form mulario de búsque eda con un camp de tex po xto y un botón para lanz la bús zar squeda.

.

asegurando que los campos de datos tienen valores validos. 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. Describe los comportamientos de una clase proceso. en este modelo se incluye: Modelo de Estructura de Procesos: que define las relaciones entre las diferentes clases proceso. ambas heredan de ConctacProcessing. Las operaciones de actualización y creación funcional de manera similar.4 Modelo de Proceso  Este modelo especifica las acciones que realiza cada clase de proceso.1. Modelo de Flujo de Procesos: que especifica las actividades conectadas con cada 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.4. Lo que ocurre en detalle dentro de cada .

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

así algunos casos de uso son los siguientes. Ejemplos reales de portales similares al a continuación explicado son: el famoso Itunes de Apple. El usuario Registrado puede navegar desde la página de inicio a su página personal. 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. play. o No Registrados: pueden llegar a ser Registrados.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. que realizaremos en los siguientes apartados. se debe loguear en el sistema.2. en la cual se mostrará todos los discos comprados anteriormente y su crédito actual para poder realizar compras. Casó Práctico: Portal Musical  2.1 Casos de uso referidos a usuarios  Hay dos tipos de usuarios: o Registrados: son lo que tienen permitido descargar discos. registrándose mediante un nombre de usuario no código ya por otro usuario Registrado y una contraseña. Los links para loguearse y desloguearse son mostrados siempre. - - . donde el usuario puede descargarse discos en formato mp3. ordenados por categorías: 2.1. en cada página del sitio web. una vez hecho esto para entrar como usuario Registrado. entre otros muchos que existen actualmente en la red.com o el servicio de descargas de música de Amazon.

solo se permite la descarga de discos completos.1.1.  2. Cada elemento de esta lista se corresponde con un link a la página detallada de cada disco. - Cada disco solo puede tener un artista.2 Casos  de  uso  referidos a  la  información  sobre los discos  En este sistema.3 Casos  de  uso  respecto  al  sistema  de  compra  . Lista de canciones contenidas en el mismo. así el único método de búsqueda ofrecido es buscar discos por su nombre. Precio de venta del disco. en cada página del sitio web. El resultado de una búsqueda es una lista de los discos que han coincidido con el campo de búsqueda. Link de descarga del disco en el caso de que el usuario le haya comprado. Nombre del artista del disco. - La pagina detallada de cada disco ofrecerá la siguiente información: o o o o o Título del disco. - - La caja de búsqueda de discos es mostrada siempre. 2. se ha realizado así para reducir la complejidad del modelo de navegación y de presentación. o en su defecto link que le lleva a la página de compra del disco.

- Cada usuario tiene una cuenta de crédito asociada. . - - El usuario deberá confirmar la transacción justo antes de producirse el pago. el usuario debe introducir el número de la tarjeta de crédito y la cantidad económica que quiere recargar. Estas cuentas se pueden recargar realizando pagos con tarjetas de crédito. esta tarjeta será la que se usará para comprar discos. Para realizar pagos con la tarjeta de crédito. Información que deberá ser validada.

registrarse y loguearse. .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. 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.2. así en la siguiente imagen se muestra estas posibilidades. ya que solo puede buscar información sobre los disco. para obtener una idea general de lo que un usuario puede o no puede hacer en el sistema. 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. para llegar a ser usuario Registrado.

descargar el disco y las opciones de administración de su cuenta de crédito personal: recargar cuenta. son las mismas que el usuario no registrado más las funcionalidades adicionales de comprar el disco. ver cuenta y ver historial de discos comprados. .En cuanto a las funciones del usuario Registrado.

pero se ha puesto independiente para facilitar una posible mejora que sería incluir varios artistas por disco. A simple vista se puede observar que Artista podría estar metido como un atributo más de Album. Esto se representa mediante un diagrama de clases UML. Artista y Canción (con sus atributos correspondientes. . 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. el modelo de contenido contiene la información relevante almacenada en el sistema.3 Modelo de Contenido  Como comentamos en puntos anteriores en este documento. como se estructura y como se relaciona. lo que cubriría aquellos discos que hayan sido producidos por varias personas que no formen un grupo musical entre ellos.2.

pero tiene que ser implementado por separado. En la siguiente imagen tenemos el modelo de Usuario realizado para este casó práctico: . 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. es que el modelo de Contenido define el contenido de los datos almacenados por la aplicación.2. - Estas clases contenidas proven de operacioines que puede ser usados en el proceso de negociación de procesos. El comportamiento de estos metodos se puede describir de multiples formas.4 Modelo de Usuario  La diferencia entre el modelo de Contenido y este modelo no explicado anteriormente. El comportamiento de estas operaciones no es modelado. en la siguiente imagen se ha usado OCL (Object Constraint Language) para ello.

Ilustración 10 Como hemos explicado anteriormente. . como hemos indicado anteriormente. en este modelo se representa la sesión en la clase (Sessión). 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. las operaciones de las clases. esto esta especificado en las notas blancas de la derecha de la imagen.

con lo cual. Solo se ha definido un atributo de navegación que necesita una expresión de selección: (Album::artistName). El contenido de las clases de navegación tampoco se especifica por el mismo motivo. Con lo explicado anteriormente mostramos el diagrama de modelo de navegación reducido de este caso práctico: . Los demás se pueden sacar mediante las propiedades del contenido de las clases. y no serviría de mucho mostrar el funcionamiento de sus elementos. es decir cómo se relaciona cada página web con las demás.5 Modelo de Navegación  En este modelo se especifica la relación interna del sitio web. 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 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. en definitiva es como se navega por el sitio web.2.

llegando a un e diag grama UM con la extensión que UW aporta a este estándar. De nuevo in ncluimos los estere eotipos a añadidos para obte ener una visión má clara d esta ex ás de xtensión. ste ereotype e-names and th heir ico ons na avigationC Class index guidedTo our menu query pr rocessClass . esta ML n WE a exte ensión es la que explicam s mos en el modelo de nave egación de la d intro oducción de este document d to con los estereot tipos corr respondie entes.Il lustración 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.

estas son: loguearse.De la extensión de UWE podemos destacar las clases de navegación marcadas con el atributo <<navigationClass>> . el de usuario y el de los discos). las paginas de índice marcado con el estereotipo adecuado. desloguearse. Otra observación importante es en cuanto a las relaciones. también podemos ver que en el sitio web tenemos 3 menús (el principal. registrarse. . comprar álbum y recargar cuenta del usuario. así como varias clases operacionales (processClass) que representan operaciones que pueden ser realizadas. 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.

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. 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.2. está relacionada son subclases proceso para indicar que el saldo es insuficiente o para confirmar la compra. en el que se incluyen las actividades relacionadas con cada proceso. 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.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. Modelo de Flujo de Procesos: Como en el diagrama de navegación de este caso práctica tenemos cinco clases proceso. como se explico anteriormente. . al igual que la operación recargar (Recharge). representada por la clase BuyAlbum. la primera el Modelo de Estructura de Procesos. el modelo de Proceso se divide en dos partes. describiendo el comportamiento interno de cada clase proceso. en el cual se incluyen las relaciones entre las clases de proceso y la segunda parte es el Modelo de Flujo de Procesos.

pero para simplificar el documento. y con la consigna de que para entender los flujos vale con explicar uno solo. . 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 mostrará el flujo de la clase proceso para loguearse. 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”.se debería especificar un flujo interno para cada una de ellas.

checkPassword().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.   . El método user.loadUser(). o En caso de respuesta positiva.CurrentUser() inicia la sesión de usuario en caso de que el proceso de loguearse haya resultado exitoso. el nombre es correcto. El método Sessión. 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 coincidencia afirmativa se abriría la sesión del usuario con el método Sessión.CurrentUser(). se manda el nombre al método donde se comprueba la contraseña user.- - - Seguido de ello se realizan las comprobaciones de los mismos. así “userName” es comprobado con el método user.

s contem se mplan las clases de navega ación intro y de proceso que p e os pertenecen a cada página web. Par estar más a ra orientados a la hora de comprender el modelo de pre e esentación de n este caso. 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 lustración 14 1 .2. v e volvemos a adjun s ntar los símbolos de los estereot s tipos corr respondie entes a e este mode elo.7 Mod 7 delo de Pres sentac   ción  En el mode de Pr elo resentació ón. como ya explicamos en la o e oducción del documento.

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 .Para el caso práctico nuestro el diagrama es mostrado como un diagrama de estructura UML.

estas son MainMenu. Register y BuyAlbum. un texto de entrada (marcado como “textInput”) en el que se introducirá el texto a buscar. Clase AlbumQuery: Esta clase de presentación. es decir. Logout y User). además aquí no se muestran relaciones entre ellas. en ella están situada instancias de todas las principales paginas de presentación de las que se compone el sitio. representa la caja de búsqueda de los discos. la pagina MusicLibrary. MainRegion: Esta clase muestra la región principal de la pagina de presentación MusicLibrary. es una página de presentación (está marcada como tal). esta clase tiene 4 anclas (Login. Así. el cual se pulsará para confirmar la búsqueda del texto introducido. Vamos a ir una por una explicando su representación: . Login.Clase MainMenu: es una clase de presentación. tiene dos propiedades. Recharge. pero como podemos ver existen otros estereotipos de UWE que están situados en otras clases. AlbumIndex. en el se muestran todas las páginas de las que se compone el sitio web. para entenderlos explicaremos un ejemplo de cada uno: . y la otra propiedad es el botón de búsqueda (marcado como “Button”). AlbumQuery y MainRegion. es decir el título del disco que se quiere buscar. un ancla significa que contiene un enlace a una instancia de cada una de las 4 clases cuyo nombre coincide con el ancla. Album. Login y Register (cuando el usuario no está logueado) y Logout y User (cuando el usuario esta logueado).Como podemos ver este diagrama es muy extenso. Como podemos ver. lo que indica que contiene información que será mostrada al usuario. esta independencia facilita la explicación de ellas por separado. Home. que pueden ser clases de navegación o las clases de proceso mostradas en el Modelo de Procesos. - Esta sería una explicación a la página de presentación Music Library. como podemos ver. Para entender este modelo de presentación explicaremos tan solo una clase de las trece disponibles. estas son: User. que son 13 instancias. no ha sido reducido para su muestra. también se ha representado mediante notas aclarativas cuando tiene que ser mostrada cada enlace y cuando no. Register. ya que con entender una página tan representativa como MusicLibrary se entenderá perfectamente el resto de ellas. que como podemos contendrá 3 clases.

esto significa que ese elemento contiene una imagen. en este caso se usa para almacenar la caratula del disco. También en la clase Album tenemos un elemento marcado con el estereotipo “Image”. para explicar el Titulo. En la clase RechargeDataInput tenemos un elemento marcado con el estereotipo “form”. . el Artista. esto indica que este elemento es un formulario. la Descripción. el Precio y el Link de descarga o compra. en este caso nos referimos al formulario de entrada de información cuando recargamos una cuenta de crédito de un usuario. esto significa que ese elemento es un texto.- - - En la clase Album tenemos dos instancias de elementos marcados con “Text”. en el que tenemos que introducir varios textos de entrada y al final tenemos un botón de confirmación. en concreto es esta clase hay 5 elementos de este tipo.

imágenes. 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.3. a segundas personas. 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. solo la comento aquí. Antes de explicar las ventajas. texto de entrada. es decir. Conclusiones sobre UWE  Tras el estudio de la notación extendida para UML. quería comentar que no explicare las desventajas en un apartado. pagina inicial. UWE. y transferir este diseño a una segunda persona para su implementación o rediseño (en caso de que hiciera falta). botones. para los que tenemos un estereotipo para representarlos. Esta forma de visualizarlo. facilita a los diseñadores encontrar errores de diseño. clases de navegación. pagina menú. formularios web. ya que no he encontrado ninguna salvo la que implica conseguir el conocimiento de UWE para poder entender sus modelos. Otra ventaja que tiene es la notación especifica que ofrece a UML para representar elementos de una página web. conlleva en su mayor parte. así con UWE queda solucionada dicha carencia y podemos representar esta información. clases de proceso o links entre otros muchos. como el Modelo de Presentación. Por ejemplo el Modelo de Navegació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. ventajas. esto es una carencia de UML que no contempla estos elementos. una persona puede diseñar una página web usando UWE. pero como esto no es una actividad que requiera de un esfuerzo amplio. esta segunda persona tendría con los modelos de UWE muchas facilidades para llevar a cabo su labor. así tenemos elementos como: paginas índices. ya que UML y UWE se . están son: Presenta unos modelos de diseño que se ajustan bastante bien al diseño de sitios web. he obtenido algunas conclusiones interesantes sobre las ventajas que produce utilizar esta notación. 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.

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. .caracterizan por su simplicidad y buena legibilidad.

org/ Página oficial de UWE: http://uwe. Referencias  Página del estándar UML de OMC: http://www.de/ UWE en Wikipedia: http://en.ifi. Daniel Schwabe.lmu.magicdraw.org/wiki/UMLbased_Web_Engineering_(UWE) MagicDraw.lmu.de/toolMagicUWE.lmu.uml.html Manual de MagicUWE: http://uwe. software de modelado: http://www.html Material docente: “Transformation Techniques in the ModelDriven Development Process of UWE at the Second Workshop on Model-Driven Web Engineering”: http://www. Oscar Pastor.ifi.com/ MagicUWE.pst.pst. Luis Olsina .lmu.de/personen/kochn/presentations/mdwe 2006_norakoch.pst.de/toolMagicUWEReference.ifi.pst.pdf Libro sobre UWE: “Web Engineering: Modelling and Implementing Web Applications” de Gustavo Rossi.4.ifi.wikipedia. plugin para MagicDraw: http://uwe.

Sign up to vote on this title
UsefulNot useful