DISEÑO DE APLICACIONES WEB CON UML Y

ARQUITECTURAS SOFTWARE: APLICACIÓN EN DOS

PROYECTOS BASADOS EN TECNOLOGÍA J2EE

E. Sánchez y P. Jorge
Grupo de Sistemas Intelixentes (GSI)
Departamento de Electrónica e Ciencias da Computación, Facultade de Física.
Universidade de Santiago de Compostela
15782 Santiago de Compostela, Spain

ABSTRACT
El artículo que aquí se presenta propone una metodología de diseño basada en la selección de un conjunto de
diagramas UML y en la especificación de una arquitectura software. De este modo se pretende resolver los
siguientes problemas: (1) qué diagramas UML son los más relevantes y qué secuencia es la más idónea para
abordar un diseño complejo, (2) cómo definir las comunicaciones entre entidades o clases de alto nivel
cuando no existe un diagrama para tal fin en UML, y (3) como llegar a una arquitectura software que
sintetice los diagramas UML. La metodología se ha probado con éxito en dos proyectos correspondientes al
Graduado Superior en Tecnologías de la Información y las Comunicaciones (GSTIC) de la Universidad de
Santiago de Compostela.

1. INTRODUCCIÓN
Este trabajo tiene como objetivo proponer una metodología de diseño de alto nivel que resuelva el problema
de cómo llegar a la arquitectura software [8]. La metodología está basada en los diagramas UML [3] e
implica solucionar dos problemas previos: (1) qué diagramas UML son los más relevantes y qué secuencia es
la más idónea para abordar un diseño complejo, y (2) cómo definir las comunicaciones entre entidades o
clases de alto nivel cuando no existe un diagrama para tal fin en UML.
El primer problema surge cuando el diseñador que recurre a UML descubre que éste sólo define un
conjunto de modelos o diagramas, pero no constituye de por sí una metodología de diseño. Existen
propuestas metodológicas que pretenden resolver este problema, pero unas pecan por ser excesivamente
pesadas, ya que intentan definir un marco general y flexible, como el Proceso Unificado de Rational Rose
[9], y otras por ser excesivamente ligeras, donde la fase de diseño apenas se documenta, como la
recientemente popular eXtreme Programming [1]. En un punto medio, podemos referenciar la metodología
de Larman [19], que propone la utilización de UML con patrones de diseño. Ninguna de estas metodologías
aborda el problema de cómo llegar a describir la arquitectura software del sistema, definida en base a un
conjunto de componentes, un conjunto de conectores y una topología [2,7,13,14]. Por otra parte, las
aproximaciones basadas en la utilización de lenguajes semi-formales de descripción de arquitecturas [11]
presentan el gran inconveniente de que no utilizan UML, el standard de facto actual en el diseño de software.
El segundo problema se presenta debido a las limitaciones en el conjunto de modelos de UML, y en concreto
a la definición de tipos de comunicación. Como es sabido, el origen de UML está íntimamente asociado a la
programación orientada a objetos. Aquí las comunicaciones o interacciones entre objetos se resuelven
normalmente con llamadas a métodos, ya bien de forma local, ya bien de forma remota. El problema surge
cuando en un diseño se pretende abordar otros tipos de comunicaciones como el paso de mensajes o el
streaming de datos. Esta descripción resulta fundamental, por ejemplo, para seleccionar el middleware
(sockets, RMI, JMS, JDBC, ODBC, etc.) más apropiado para nuestro proyecto. El problema original, el
cómo llegar a la arquitectura software, es uno de los grandes temas de debate dentro de la comunidad de
arquitectos de software. Los más expertos utilizan la inspiración, es decir, su experiencia, para llegar a la
arquitectura del sistema [8]. Los que tienen menos experiencia, por el contrario, suelen basarse en
arquitecturas de otros sistemas como guía para su proyecto. El campo de la ingeniería de software tiene como

513
Conferência IADIS Ibero-Americana WWW/Internet 2004

objetivo definir procesos y metodologías para hacer que el desarrollo del software sea una ingeniería y no un
arte. Este trabajo pretende contribuir en este punto fundamental.
En la siguiente sección explicamos la metodología de diseño propuesta; a continuación, describimos dos
proyectos donde se ha utilizado dicha metodología; finalmente, realizamos una breve discusión de las
experiencias obtenidas.

2. METODOLOGÍA DE DISEÑO
A continuación describimos la secuencia propuesta para el diseño de alto nivel, comenzando por el modelo o
diagrama de actividad, y finalizando con el diagrama de secuencia. A partir de aquí comienza el diseño de
bajo nivel. Por cuestiones de espacio y porque es fácil encontrar abundante información respecto a esta fase,
no entraremos en más detalle en este trabajo.

2.1 Modelo o diagrama de actividad

Partimos aquí de que en la fase de análisis del proyecto se han generado un conjunto de casos de uso. Estos
casos de uso deben ser la base para definir los requisitos funcionales del sistema. Una vez hecho esto, para
cada funcionalidad del sistema se debe definir un modelo o diagrama de actividad, que consiste en el
conjunto de pasos necesario para resolver la funcionalidad o tarea seleccionada. Estos diagramas forman
parte del UML y existe abundante literatura que explica como construirlos [3].
Supongamos, por ejemplo, que queremos desarrollar una tienda virtual. Una de las tareas básicas consiste
en seleccionar un conjunto de productos y realizar el pago de los mismos. Los pasos básicos para realizar esta
tarea podrían describirse a través de un diagrama de actividad como el mostrado en la figura 1.
Como se puede observar, los diagramas de actividad permiten identificar de forma sencilla las entidades
que tienen un determinado rol o papel en el problema, así como el tipo de interacción entre dichas entidades.
El siguiente paso en el diseño consiste, precisamente, en describir las entidades del problema de la forma más
precisa posible.

Figura 1. Diagrama de actividad para una compra sencilla

2.2 Modelo o diagrama de entidades

Este diagrama describe las entidades que participan en el problema en cuestión. Este lo podemos definir
como un diagrama de clases donde sólo se consideran aquellas clases que tienen representación en el dominio
del problema. Así evitamos mezclar entidades propias del dominio, con entidades que son propias del
dominio de la computación. Para continuar el ejemplo discutido en la sección anterior, ilustramos el
diagrama de entidades en la figura 2. Se observa que hemos especificado tanto las operaciones como los
datos que cada entidad va a manejar. Estas decisiones son fáciles de realizar en esta fase, y sobre todo, muy
intuitivas a partir de los diagramas de actividad caracterizados en el paso anterior.

514
 DISEÑO DE APLICACIONES WEB CON UML Y ARQUITECTURAS SOFTWARE: APLICACIÓN EN DOS
PROYECTOS BASADOS EN TECNOLOGÍA J2EE

2.3 Modelo o diagrama de comunicación

El siguiente paso consiste en indicar como se comunican o interaccionan las entidades descritas en el
diagrama de entidades. Esto se consigue con un modelo de comunicación que, desafortunadamente, no está
considerado en UML, y que nos parece fundamental para modelar un sistema.

Figura 2. Diagrama de entidades donde se indican las propiedades y las funciones de cada una. También se indican las
relaciones entre las entidades (en cursiva) y la multiplicidad de la relación.
La explicación radica en que diferentes tecnologías o middleware de comunicación conllevan diferentes
modos de comunicación. Es muy común ver proyectos que fracasan cuando el diseño implica un cierto tipo
de comunicación que se contradice con el tipo implícito en el middleware escogido para la fase de
implementación. Una revisión sobre los diferentes tipos de comunicación, tipos de conectores y tecnologías
asociadas para su implementación está fuera del objetivo de este artículo (ver [12] para una taxonomía de
conectores). Por ello, comentamos a continuación una clasificación gruesa de los tipos principales de
comunicación:
1. Tipos de comunicación

o Activo. Cuando una entidad inicia el proceso de comunicación mediante una petición a otra
entidad y espera una respuesta de esta última. En general, este tipo de comunicación puede ser
síncrono, cuando el emisor, el que inicia la comunicación, espera a que el receptor envíe la
respuesta, o asíncrono, cuando el emisor no espera una respuesta inmediata. En el contexto del
dominio de una tienda, podríamos citar como ejemplo de comunicación activa y síncrona la
consulta de un determinado producto en un catálogo. Como ejemplo de comunicación activa y
asíncrona podríamos pensar en la solicitud de un presupuesto de una obra, tarea que requiere un
cierto tiempo y que difícilmente puede resolverse de forma síncrona. En la figura 3 ilustramos el
concepto de comunicación activa y síncrona.
o Pasivo. Cuando una entidad recibe algún tipo de información o dato sin haber iniciado la
comunicación con una petición.
o Indirecto. Cuando la comunicación entre el emisor y el receptor se realiza a través de una
entidad mediadora que hace de puente entre ambos.

Figura 3. Comunicación activa y síncrona

515
Conferência IADIS Ibero-Americana WWW/Internet 2004

2. Mecanismos de comunicación
o Llamada a método. Este es uno de los mecanismos de comunicación más populares y
usualmente utilizado en el paradigma orientado a objetos. Asociado a comunicaciones de tipo
activo y síncrono.
o Acceso a datos. Íntimamente ligado a las entidades que son repositorio de datos. Asociado a una
comunicación activa y síncrona.
o Paso de mensajes. Este es un paradigma de comunicación de creciente popularidad, básico para
desacoplar sistemas. Asociado a comunicaciones tanto activas y síncronas, como pasivas a través
de mensajes discretos.
o Generación de eventos. Asociado a comunicaciones de tipo pasivo para mensajes discretos.
o Flujo de datos. Mecanismo indicado para comunicaciones pasivas donde la información a
transferir sea cuantiosa y se produzca de forma continua.
o Datos compartidos. Este mecanismo está asociado a comunicaciones de tipo indirecto.

En el ejemplo que venimos desarrollando, todas las interacciones que se producen son activas, iniciadas ya
bien por el usuario, ya bien por alguna de las entidades del problema, y síncronas, ya que tanto la selección
del producto, como su almacenamiento en el carro y el cálculo del precio final de los productos (ver figura
1), son tareas que pueden realizarse de forma prácticamente instantánea. En la figura 4 ilustramos, a modo de
ejemplo, la descripción del tipo de interacción entre el “carro de la compra” y el “cajero”.

Figura 4. Descripción del tipo y mecanismo de comunicación entre las entidades “carro de la compra” y “cajero”

2.4 Arquitecturas software

Llegados a este punto, tenemos caracterizadas las entidades principales que participan en el problema y el
tipo de comunicación que existe entre ellas. Es el momento de definir la arquitectura software de nuestro
sistema.
Se denomina arquitectura software a un conjunto de componentes, conectados entre sí por conectores, y
organizados según una cierta topología espacial [2,7,13,14]. En nuestra metodología los componentes pueden
asociarse fácilmente con las entidades del modelo de entidad, y los conectores con los modelos de
comunicación discutidos en la sección anterior. De este modo, la arquitectura software puede considerarse
como la vista estática del sistema a construir y que integra todos los elementos del problema analizados hasta
este momento. En la figura 5 se describe la arquitectura software asociada al ejemplo de tienda virtual con el
que hemos estado trabajando. Se observa que hemos añadido un componente nuevo, la interfaz de usuario,
que permite al usuario indicar sus acciones y visualizar la información. La interfaz no es considerada como
una entidad en el modelo de entidades porque es un componente puramente computacional, que por supuesto
no existe en el dominio real del problema. Aquí lo incluimos para explicar como interactúa el usuario con las
diferentes entidades de la tienda.
Por otra parte, la entidad producto se representa aquí a través del componente “Repositorio de
productos”, que se encarga de la persistencia de la información asociada a los productos. La representación
temporal de cada producto seleccionado necesitará, como parece evidente, un nuevo tipo de entidad. Es en
este punto donde comienza el diseño de bajo nivel, y donde habrá que incorporar esta clase y otras que sean
necesarias antes de comenzar la implementación. Pero este nivel de detalle es irrelevante para ilustrar la
columna vertebral del sistema, es decir, su arquitectura software.

516
 DISEÑO DE APLICACIONES WEB CON UML Y ARQUITECTURAS SOFTWARE: APLICACIÓN EN DOS
PROYECTOS BASADOS EN TECNOLOGÍA J2EE

Figura 5. Arquitectura software propuesta para el ejemplo de la tienda

2.5 Modelo o diagrama de secuencia

La vista estática del sistema debe complementarse con una vista dinámica. Aquí es donde necesitamos los
diagramas de secuencia. Estos indican la secuencia de interacción entre todos los componentes del sistema.
Los diagramas de secuencia forman parte de UML y en nuestra opinión son un complemento óptimo a las
arquitecturas software.
La figura 6 muestra el diagrama de secuencia asociado a la arquitectura software de la figura 5. En la
parte superior se sitúan los componentes de la arquitectura y las líneas verticales indican la evolución
temporal de las interacciones.

Figura 6. Diagrama de secuencia asociado a la arquitectura software de la figura 7. Las flechas hacia la derecha
indican peticiones (llamadas a método o acceso a datos), y las flechas hacia la izquierda indican respuestas.

3. EJEMPLOS
La metodología de diseño que aquí presentamos se ha probado con éxito en dos proyectos correspondientes
al Graduado Superior en Tecnologías de la Información y las Comunicaciones (GSTIC) de la Universidad de
Santiago de Compostela. Los proyectos consistían, uno en el desarrollo de un servicio de almacenamiento y
transferencia de ficheros para la Universidad de Santiago, y el otro en un portal para el grupo de
investigación GSI. En la fase de diseño se utilizaron patrones de diseño J2EE y la implementación fue
realizada completamente con tecnología J2EE. Por último, decir que los proyectos se finalizaron de forma
satisfactoria cumpliendo el requisito temporal que exigía la asignatura: 15 semanas. A continuación

517
Conferência IADIS Ibero-Americana WWW/Internet 2004

describimos brevemente ambos proyectos, indicando el diseño de alto nivel para cada uno de ellos, y los
resultados más destacados.

4. DISCUSIÓN
Existen propuestas de diseño que presentan ciertas similitudes con la nuestra. La metodología de Larman
[10], por ejemplo, comienza por “casos de uso” y termina por un diagrama de clases refinado. Aunque existe
una cierta coincidencia entre su propuesta y la nuestra en los primeros pasos del proceso, existen sustanciales
diferencias: (1) en la propuesta de Larman se introducen los diagramas de secuencia en el tercer paso,
mientras que en nuestra propuesta se dejan para el final, ya que representa la vista dinámica de la
arquitecturas software, (2) Larman no incluye un modelo que describa los tipos de comunicación, y (3) no
menciona ni utiliza el concepto de arquitectura software. De hecho, una de las ideas clave de nuestra
propuesta reside en utilizar los diagramas UML para generar una vista estática del sistema, la arquitectura
software, y una vista dinámica, los diagramas de secuencia. Esto por supuesto, es muy diferente a la
propuesta de Larman, que no pretende especificar ninguna arquitectura software.
Por otra parte, es necesario indicar que nuestro trabajo no persigue extender el diagrama UML de clases.
Lo que se propone es la utilización de los diagramas UML, por una parte, y del concepto de arquitectura
software, por otra, para establecer una metodología de diseño más completa. Esta es una diferencia
fundamental respecto a otros trabajos que pretenden extender UML para describir elementos de arquitecturas
software [6].
Por último, el modelo de comunicación propuesto sigue la línea comenzada por trabajos de análisis de
conectores [12] y que es bastante más compleja que la proporcionada en UML 2.0, donde los conectores son
meros enlaces entre partes de un componente [15], y que semánticamente son diferentes a los utilizados en
arquitecturas software [4].

AGRADECIMIENTOS
Los autores quieren agradecer la ayuda de la Xunta de Galicia por su apoyo a través del proyecto PGIDT02TIC20601PR.

REFERENCIAS
[1] Beck, K. “Extreme programming explained: embrace change”. Addison-Wesley publications. 2000.
[2] Fielding R. T. “Architectural Styles and the Design of Network-based Software Architectures”. PhD Thesis,
University of California, Irvine, 2000.
[3] Fowler M. y Scott K. “UML Distilled: A Brief Guide to the Standard Object Modeling Language”. Addison-Wesley
publications. 1999.
[4] Goulão M. y Brito e Abreu F. “Bridging the gap between Acme and UML for CBD”. Proceedings of Specification
and Verification of Component-Based Systems (SAVCBS´03). 2003.
[5] Jorge, P. y Sánchez E. “Una experiencia práctica: creación de un portal web empleando Hibernate y Webwork”. Actas
congreso JavaHispano. 2003.
[6] Kandé, M. M. y Strohmeier, A. “Towards a UML profile for software architecture descriptions”. UML 2000 -- The
Unified Modeling Language: Advancing the Standard. Third International Conference. 2000.
[7] Kazman, R. "A Challenge for Software Architecture: Distributed Flight Simulation", in Parallel and Distributed
Computing Handbook, A. Zomaya (ed.), McGraw-Hill, 1996.
[8] Kruchten, P. “Mommy, Where Do Software Architectures Come from?” 1st International Workshop on Architectures
for Software Systems, Seattle, WA, 1995.
[9] Kruchten, P. “The Rational Unified Process: an introduction”. Addison-Wesley publications. 2000.
[10] Larman C. “Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified
Process (2nd Edition). Prentice Hall PTR. 2001.
[11] Medvidovic N. y Taylor R. N. “A Framework for Classifying and Comparing Architecture Description Languages”.
6th European Software Engineering Conference with the 5th ACM SIGSOFT Symposium on the Foundations of
Software Engineering, Zurich, Switzerland, September. 1997.
[12] Mehta N. R., Medvidovic N. y Phadke S. “Towards a taxonomy of software connectors”. Proceedings of the 22nd
International Conference on Software Engineering, 2000
[13] Perry, D. E. y Wolf A. L. “Foundations for the Study of Software architecture”. Software engineering notes. ACM
SIGSOFT. 40-52, 1992.
[14] Shaw M. y Garlan D. “Software architectures: perspectives on an emerging discipline”. Prentice Hall. 1996.
[15] UML 2.0 Specifications. http://www.uml.org.

518