TIENDA VIRTUAL

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, 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 DO S 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

o

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. Pasivo. Cuando una entidad recibe algún tipo de información o dato sin haber iniciado la comunicación con una petición. 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 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. Acceso a datos. Íntimamente ligado a las entidades que son repositorio de datos. Asociado a una comunicación activa y síncrona. 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. Generación de eventos. Asociado a comunicaciones de tipo pasivo para mensajes discretos. Flujo de datos. Mecanismo indicado para comunicaciones pasivas donde la información a transferir sea cuantiosa y se produzca de forma continua. Datos compartidos. Este mecanismo está asociado a comunicaciones de tipo indirecto. o

o

o

o o

o

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 DO S 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