Modelo web
Upcoming SlideShare
Loading in...5
×
 

Modelo web

on

  • 321 views

 

Statistics

Views

Total Views
321
Views on SlideShare
321
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Modelo web Modelo web Document Transcript

  • 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, SpainABSTRACTEl artículo que aquí se presenta propone una metodología de diseño basada en la selección de un conjunto dediagramas UML y en la especificación de una arquitectura software. De este modo se pretende resolver lossiguientes problemas: (1) qué diagramas UML son los más relevantes y qué secuencia es la más idónea paraabordar un diseño complejo, (2) cómo definir las comunicaciones entre entidades o clases de alto nivelcuando no existe un diagrama para tal fin en UML, y (3) como llegar a una arquitectura software quesintetice los diagramas UML. La metodología se ha probado con éxito en dos proyectos correspondientes alGraduado Superior en Tecnologías de la Información y las Comunicaciones (GSTIC) de la Universidad deSantiago de Compostela.1. INTRODUCCIÓNEste trabajo tiene como objetivo proponer una metodología de diseño de alto nivel que resuelva el problemade cómo llegar a la arquitectura software [8]. La metodología está basada en los diagramas UML [3] eimplica solucionar dos problemas previos: (1) qué diagramas UML son los más relevantes y qué secuencia esla más idónea para abordar un diseño complejo, y (2) cómo definir las comunicaciones entre entidades oclases 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 unconjunto de modelos o diagramas, pero no constituye de por sí una metodología de diseño. Existenpropuestas metodológicas que pretenden resolver este problema, pero unas pecan por ser excesivamentepesadas, 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 larecientemente popular eXtreme Programming [1]. En un punto medio, podemos referenciar la metodologíade Larman [19], que propone la utilización de UML con patrones de diseño. Ninguna de estas metodologíasaborda el problema de cómo llegar a describir la arquitectura software del sistema, definida en base a unconjunto de componentes, un conjunto de conectores y una topología [2,7,13,14]. Por otra parte, lasaproximaciones 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 concretoa la definición de tipos de comunicación. Como es sabido, el origen de UML está íntimamente asociado a laprogramación orientada a objetos. Aquí las comunicaciones o interacciones entre objetos se resuelvennormalmente con llamadas a métodos, ya bien de forma local, ya bien de forma remota. El problema surgecuando en un diseño se pretende abordar otros tipos de comunicaciones como el paso de mensajes o elstreaming 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, elcómo llegar a la arquitectura software, es uno de los grandes temas de debate dentro de la comunidad dearquitectos de software. Los más expertos utilizan la inspiración, es decir, su experiencia, para llegar a laarquitectura del sistema [8]. Los que tienen menos experiencia, por el contrario, suelen basarse enarquitecturas 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 2004objetivo definir procesos y metodologías para hacer que el desarrollo del software sea una ingeniería y no unarte. 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 dosproyectos donde se ha utilizado dicha metodología; finalmente, realizamos una breve discusión de lasexperiencias obtenidas.2. METODOLOGÍA DE DISEÑOA continuación describimos la secuencia propuesta para el diseño de alto nivel, comenzando por el modelo odiagrama de actividad, y finalizando con el diagrama de secuencia. A partir de aquí comienza el diseño debajo 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 actividadPartimos aquí de que en la fase de análisis del proyecto se han generado un conjunto de casos de uso. Estoscasos de uso deben ser la base para definir los requisitos funcionales del sistema. Una vez hecho esto, paracada funcionalidad del sistema se debe definir un modelo o diagrama de actividad, que consiste en elconjunto de pasos necesario para resolver la funcionalidad o tarea seleccionada. Estos diagramas formanparte 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 consisteen seleccionar un conjunto de productos y realizar el pago de los mismos. Los pasos básicos para realizar estatarea 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 entidadesque 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ásprecisa posible. Figura 1. Diagrama de actividad para una compra sencilla2.2 Modelo o diagrama de entidadesEste diagrama describe las entidades que participan en el problema en cuestión. Este lo podemos definircomo un diagrama de clases donde sólo se consideran aquellas clases que tienen representación en el dominiodel problema. Así evitamos mezclar entidades propias del dominio, con entidades que son propias deldominio de la computación. Para continuar el ejemplo discutido en la sección anterior, ilustramos eldiagrama de entidades en la figura 2. Se observa que hemos especificado tanto las operaciones como losdatos que cada entidad va a manejar. Estas decisiones son fáciles de realizar en esta fase, y sobre todo, muyintuitivas 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 J2EE2.3 Modelo o diagrama de comunicaciónEl siguiente paso consiste en indicar como se comunican o interaccionan las entidades descritas en eldiagrama 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 diferentesmodos de comunicación. Es muy común ver proyectos que fracasan cuando el diseño implica un cierto tipode comunicación que se contradice con el tipo implícito en el middleware escogido para la fase deimplementación. Una revisión sobre los diferentes tipos de comunicación, tipos de conectores y tecnologíasasociadas para su implementación está fuera del objetivo de este artículo (ver [12] para una taxonomía deconectores). Por ello, comentamos a continuación una clasificación gruesa de los tipos principales decomunicació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 yabien por el usuario, ya bien por alguna de las entidades del problema, y síncronas, ya que tanto la seleccióndel producto, como su almacenamiento en el carro y el cálculo del precio final de los productos (ver figura1), son tareas que pueden realizarse de forma prácticamente instantánea. En la figura 4 ilustramos, a modo deejemplo, 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 softwareLlegados a este punto, tenemos caracterizadas las entidades principales que participan en el problema y eltipo de comunicación que existe entre ellas. Es el momento de definir la arquitectura software de nuestrosistema. Se denomina arquitectura software a un conjunto de componentes, conectados entre sí por conectores, yorganizados según una cierta topología espacial [2,7,13,14]. En nuestra metodología los componentes puedenasociarse fácilmente con las entidades del modelo de entidad, y los conectores con los modelos decomunicación discutidos en la sección anterior. De este modo, la arquitectura software puede considerarsecomo la vista estática del sistema a construir y que integra todos los elementos del problema analizados hastaeste momento. En la figura 5 se describe la arquitectura software asociada al ejemplo de tienda virtual con elque 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 comouna entidad en el modelo de entidades porque es un componente puramente computacional, que por supuestono existe en el dominio real del problema. Aquí lo incluimos para explicar como interactúa el usuario con lasdiferentes entidades de la tienda. Por otra parte, la entidad producto se representa aquí a través del componente “Repositorio deproductos”, que se encarga de la persistencia de la información asociada a los productos. La representacióntemporal de cada producto seleccionado necesitará, como parece evidente, un nuevo tipo de entidad. Es eneste punto donde comienza el diseño de bajo nivel, y donde habrá que incorporar esta clase y otras que seannecesarias antes de comenzar la implementación. Pero este nivel de detalle es irrelevante para ilustrar lacolumna 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 tienda2.5 Modelo o diagrama de secuenciaLa vista estática del sistema debe complementarse con una vista dinámica. Aquí es donde necesitamos losdiagramas 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 lasarquitecturas software. La figura 6 muestra el diagrama de secuencia asociado a la arquitectura software de la figura 5. En laparte superior se sitúan los componentes de la arquitectura y las líneas verticales indican la evolucióntemporal 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. EJEMPLOSLa metodología de diseño que aquí presentamos se ha probado con éxito en dos proyectos correspondientesal Graduado Superior en Tecnologías de la Información y las Comunicaciones (GSTIC) de la Universidad deSantiago de Compostela. Los proyectos consistían, uno en el desarrollo de un servicio de almacenamiento ytransferencia de ficheros para la Universidad de Santiago, y el otro en un portal para el grupo deinvestigación GSI. En la fase de diseño se utilizaron patrones de diseño J2EE y la implementación fuerealizada completamente con tecnología J2EE. Por último, decir que los proyectos se finalizaron de formasatisfactoria cumpliendo el requisito temporal que exigía la asignatura: 15 semanas. A continuación 517
  • Conferência IADIS Ibero-Americana WWW/Internet 2004describimos brevemente ambos proyectos, indicando el diseño de alto nivel para cada uno de ellos, y losresultados más destacados.4. DISCUSIÓNExisten 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 existeuna cierta coincidencia entre su propuesta y la nuestra en los primeros pasos del proceso, existen sustancialesdiferencias: (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 laarquitecturas software, (2) Larman no incluye un modelo que describa los tipos de comunicación, y (3) nomenciona ni utiliza el concepto de arquitectura software. De hecho, una de las ideas clave de nuestrapropuesta reside en utilizar los diagramas UML para generar una vista estática del sistema, la arquitecturasoftware, y una vista dinámica, los diagramas de secuencia. Esto por supuesto, es muy diferente a lapropuesta 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 arquitecturasoftware, por otra, para establecer una metodología de diseño más completa. Esta es una diferenciafundamental respecto a otros trabajos que pretenden extender UML para describir elementos de arquitecturassoftware [6]. Por último, el modelo de comunicación propuesto sigue la línea comenzada por trabajos de análisis deconectores [12] y que es bastante más compleja que la proporcionada en UML 2.0, donde los conectores sonmeros enlaces entre partes de un componente [15], y que semánticamente son diferentes a los utilizados enarquitecturas software [4].AGRADECIMIENTOSLos 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