|
Artículo |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Modelando Procesos de Negocio Web desde una Perspectiva Orientada a Aspectos
Resumen En este artículo presentamos una propuesta orientada a aspectos para definir el aspecto de navegación en procesos de negocio Web. Los procesos de negocio Web introducen importantes modificaciones dentro del espacio y la estructura de navegación de las aplicaciones de comercio electrónico. Desde una perspectiva orientada a aspectos, los procesos de negocio Web constituyen propósitos, cuyos elementos se encuentran esparcidos y dispersos a lo largo del resto de elementos de navegación de los sistemas o aplicaciones de comercio electrónico. Actualmente, el modelado que se realiza de los procesos de negocio Web reduce considerablemente la modularidad global de este tipo de aplicaciones, complicando de esta forma la comprensibilidad y adaptabilidad de los sistemas. En este artículo se presenta una propuesta orientada a aspectos para el modelado de procesos de negocio Web reutilizables. Se hace constar también cómo las propuestas de ingeniería Web deben ser conscientes de los nuevos conceptos y técnicas que la comunidad Orientada a Aspectos está introduciendo.
1.- Introducción EN la mayoría de sistemas y aplicaciones Web de comercio electrónico se pueden encontrar estructuras de navegación similares implementadas mediante varios procesos de negocio o workflows comunes. Los investigadores en el campo hipermedia han definido algunas de estas estructuras como patrones de diseño hipermedia [15]. Además, recientemente, han aparecido propuestas muy interesantes para el modelado de procesos de negocio y workflows [10]. Estas propuestas facilitan una definición explícita de los procesos de negocio, que permiten a éstos una rápida adaptación a los continuos cambios que se producen en los requisitos del negocio. Actualmente, las propuestas de Ingeniería Web utilizan métodos y técnicas heredados de la comunidad Orientada a Objetos (OO). El hecho de dividir un sistema en objetos y utilizar técnicas y herramientas OO, ha permitido simplificar considerablemente el desarrollo de aplicaciones Web de gran tamaño, mejorando así su extensibilidad, adaptabilidad y reutilización. Las técnicas de orientación a objetos presentan importantes ventajas y beneficios para el desarrollo de sistemas Web a gran escala. Sin embargo, como se demuestra en [2], el paradigma OO aún presenta importantes limitaciones a la hora de enfrentarse al desarrollo de un sistema de estas características. Así, muchos requisitos de estos sistemas no pueden ser divididos de una manera clara en una única pieza software que encapsule todo su comportamiento. De esta forma, las tecnologías de objetos presentan ciertas dificultades para localizar aspectos de nuestro software que traten restricciones globales, separar de una manera adecuada los distintos propósitos que aparecen en el sistema y aplicar el conocimiento específico de un dominio. Estas limitaciones han sido parcialmente heredadas también por las propuestas de desarrollo Web actuales. La comunidad de Desarrollo Software Orientado a Aspectos (Aspect Oriented Software Development, AOSD) [4] [18] ha estado estudiando durante más de una década cómo incrementar y mejorar la expresividad de los paradigmas OO. Las principales propuestas de AOSD se basan en la idea de desarrollar un software de mayor calidad mediante la separación de propósitos, especificando cada uno de ellos de forma separada y las relaciones existentes entre los mismos, para posteriormente, utilizando un mecanismo adecuado, componerlos formando un sistema completamente coherente. En este artículo se intenta mostrar que la evolución natural de las propuestas de desarrollo Web debería pasar por asumir y adoptar las técnicas y mecanismos de separación de propósitos. El presente trabajo se centra en la definición Orientada a Aspectos del aspecto de navegación en los procesos de negocio Web. Dado que los sistemas de comercio electrónico requieren frecuentes modificaciones y adaptaciones rápidas a los cambios del negocio, se necesitan técnicas y conceptos de modelado flexibles que permitan construir diseños reutilizables y genéricos. Además, sería muy interesante proporcionar algún tipo de mecanismo automático para facilitar la unión de esos diseños genéricos con la aplicación de comercio electrónico base. De esta forma, los costes de adaptación de los sistemas pueden reducirse fácilmente. En este sentido, la comunidad OA facilita los mecanismos y técnicas necesarios para realizar esta unión. Así, se propone la utilización de una propuesta orientada a aspectos para enriquecer la definición de navegación de una aplicación Web. Este artículo se estructura en 7 secciones. En primer lugar, en la sección II se introducen los principios de AOSD y se muestra una panorámica de las principales propuestas de odelado OA con el Lenguaje de Modelado Unificado (Unified Modeling Language, UML) [20]. En la sección III, se analiza un ejemplo simple de aplicación de comercio electrónico que se centra en el aspecto de navegación. La sección IV presenta los Patrones de Composición Hipermedia para construir diseños hipermedia genéricos. En la sección V, se presenta el modelado de algunos procesos de negocio elementales con Patrones de Composición Hipermedia. La sección VI muestra los trabajos relacionados y finalmente en la sección VII, se presentan las conclusiones y trabajos futuros. 2. CONTRIBUCIONES PRINCIPALES DE AOSD Actualmente, la orientación a objetos constituye el paradigma dominante en el desarrollo de software. Así, se pueden encontrar distintas metodologías, herramientas de análisis y diseño y lenguajes de programación OO. La programación OO ha hecho posible el desarrollo de sistemas y aplicaciones de una cierta complejidad sin dejar de lado el mantenimiento de un código comprensible y estructurado. Sin embargo, la OO aún presenta algunas limitaciones. Los investigadores OO ven como ciertos aspectos de los sistemas que implementan no pueden ser separados de una manera clara en objetos. El código que implementa esos aspectos se encuentra esparcido y disperso en diferentes elementos o estructuras. Para los desarrolladores, resulta complicado centrarse en esos propósitos, de manera que el mantenimiento y la adaptabilidad del software de cierto tamaño se convierte en un proceso de una complejidad importante. Básicamente, AOSD reduce las principales limitaciones de la orientación a objetos con respecto a este problema de modularidad [1]. Desde el punto de vista del desarrollador, es evidente que algunas de las características más importantes del software son la facilidad de comprensión de su código y la flexibilidad del mismo para adaptarse a las extensiones y cambios que puedan producirse en los requisitos para los que fue diseñado. Para conseguir que el software presente estas características, es importante conseguir mantener una buena modularidad del mismo. Si se analiza un sistema OO, se pueden encontrar propósitos que entrecruzan el sistema, es decir, propósitos que no aparecen modelados en una sola entidad de primer nivel. Un ejemplo de este tipo de propósitos es el sistema de logging utilizado en Tomcat [1], donde dicha funcionalidad se encuentra esparcida a través de todo el sistema y no localizada en una única entidad del lenguaje. Se puede comprobar, por tanto, cómo en los sistemas OO de una cierta complejidad se encuentran a menudo con problemas de modularidad. En los últimos años, la comunidad AOSD ha propuesto diferentes alternativas para conseguir separar un sistema software en los diferentes propósitos que lo componen. Cada uno de estos propósitos debe quedar perfectamente localizado y modelado en una entidad de primer nivel dentro de la propuesta OA utilizada. Posteriormente, un proceso automático se encarga de componer todo el sistema final. Para ello, se hace necesario un mecanismo para definir las relaciones entre los diferentes propósitos, de manera que se puedan unir e integrar dentro del sistema final. Un ejemplo de este mecanismo son los join points de AspectJ [1]. El principal objetivo es conseguir sistemas software que presenten una buena modularidad. A. Modelado Orientado a Aspectos Una de las partes principales de AOSD es el Modelado Orientado a Aspectos (OA), que se centra en las técnicas para identificar, analizar, manejar y representar aspectos en el proceso de diseño del software. Así, el modelado OA trata de rellenar el hueco entre la ingeniería de requisitos OA [11] y la programación OA. El principal objetivo de esta comunidad consiste en la definición de técnicas, métodos y herramientas basadas en UML. A pesar de la gran cantidad de propuestas de modelado OA existentes actualmente, sólo un pequeño número de ellas pueden ser candidatas para ser adoptadas en el desarrollo de aplicaciones Web. Actualmente, la mayoría de las propuestas se encuentran en un proceso de maduración y están íntimamente relacionadas o acopladas al lenguaje de aspectos utilizado en la fase de implementación. Por ejemplo, la propuesta [8] se basa en AspectJ mientras que [16] presenta una clara dependencia del Modelo de Disfraces [17]. No obstante, existen ciertas propuestas genéricas que podrían ser buenas candidatas, tales como la propuesta presentada en [5] o la propuesta de Composition Patterns [7] o Themes [4]. En este artículo se ha seleccionado Composition Patterns (CP) por las siguientes razones: • Su estado de madurez. CP es una de las propuestas más maduras en el modelado OA. • Su independencia de la tecnología de aspectos final utilizada. • Su notación UML. Un patrón de composición consiste en un modelo que permite: especificar el diseño de un requerimiento de un sistema de forma independiente de cualquier diseño al que pudiera cortar o entrecruzar y cómo podemos reutilizar ese diseño en cualquier lugar que sea necesario. CP está basado en una combinación de Subject-Oriented Design Model (SODM) [6], que permite la descomposición y composición de diseños separados que pueden solaparse, y templates UML. El SODM proporciona modelos de diseño separados como vistas independientes llamadas design subjects, se notan como paquetes UML con el estereotipo <<subject>>. Dentro de estos paquetes se utiliza un diagrama de clases que captura la estructura del propósito que se está modelando con la particularidad de que puede contener clases patrón. Las clases patrón no son clases completas. Estas clases se utilizan en la composición con el fin de generar una clase completa a partir de los diferentes propósitos capturados en diferentes clases patrón. Además, se usa la notación de plantillas UML para indicar los parámetros del patrón de composición. 3. UNA APLICACIÓN DE COMERCIO ELECTRÓNICO En esta sección se analiza un sencillo ejemplo de aplicación de comercio electrónico, una tienda de ordenadores, para comprobar cómo se modelan los procesos de negocio. Dado que el presente trabajo se centra en el nivel de navegación de los sistemas web, se considera únicamente el modelo de navegación del ejemplo propuesto. Con respecto a los procesos de negocio, se ha escogido el proceso de registro en el sistema (SignIn) para llevar a cabo el análisis de modularidad del mismo. Este proceso de negocio está presente en todos los sistemas o aplicaciones de comercio electrónico, por lo que constituye un caso representativo para ser analizado.
Se ha utilizado la propuesta UML-Based Web Engineering (UWE) [9] para llevar a cabo el modelado del espacio de navegación y la estructura de la tienda de ordenadores. Se necesitaba una propuesta de modelado que cumpliera dos requisitos básicos: la utilización de orientación a objetos y de UML. En este sentido, UWE es una propuesta orientada a objetos, iterativa e incremental basada en UML y en el proceso de desarrollo de software unificado (Unified Software Development Process, UP). UWE proporciona un proceso de diseño sistemático seguido por una generación semiautomática de aplicaciones Web a través de un framework de publicación XML (UWEXML). UWE define un perfil UML propio que proporciona los elementos necesarios para el modelado de los diferentes spectos de una aplicación Web: la navegación, la presentación, etc. En concreto, para el modelado de la navegación propone dos diagramas diferentes: el modelo del espacio de navegación y el modelo de la estructura de navegación. El primero define los caminos de navegación (asociaciones de navegación directa) entre los diferentes objetos de la plicación (clases de navegación). Mientras que el segundo detalla las estructuras de acceso que se usan en la navegación, como son menús o índices. Además, UWE utiliza diagramas de estado para el modelado de escenarios Web que definen el comportamiento o los aspectos dinámicos de una aplicación Web. En la Figura 1 se presenta el modelo de la estructura de navegación de nuestro sistema de venta de ordenadores. Se trata de una estructura de navegación simple, que refleja los elementos necesarios para poder buscar y comprar los distintos productos. Básicamente, refleja que la clase de navegación Homepage posee un menú con tres items, cada uno de los cuales indica un camino de navegación distinto. El primero, notebooks, proporciona la navegación entre los diferentes productos de esta clase a través de la definición de una estructura de acceso índice, que definirá una relación de navegación para cada uno de estos productos. El segundo item, pcs, refleja un comportamiento idéntico al anterior pero para otro tipo de producto. Por su parte, el último item, shoppingCart, nos permite navegar a la clase que representa el carro de la compra. Esta clase definirá una estructura de acceso índice con una entrada por cada uno de los productos presentes en nuestro carro. Por otro lado, la Figura 2 introduce los elementos de navegación relacionados con el proceso de registro, mostrando las modificaciones que se han producido con respecto al modelo de estructura de navegación presentado anteriormente.
Como se muestra en la Figura 2, la realización del proceso de registro entrecruza las clases relacionadas con la navegación del sistema de venta de ordenadores. Los enlaces de navegación y el atributo correspondiente al nombre de usuario (username), relacionados con el proceso de registro, se encuentran repetidos dentro de todas las clases de navegación. Si se produce un cambio en un requerimiento de negocio relacionado con el proceso de registro, por ejemplo un cambio en los enlaces de navegación del proceso de registro o bien la adición de algún atributo nuevo, el desarrollador deberá adaptar todas las clases de navegación una por una a dichos cambios. De esta forma, un simple cambio puede producir un importante proceso de adaptación del sistema, debido principalmente a una mala modularización del propósito correspondiente al proceso de registro. De acuerdo a los principios OA, se puede concluir que el proceso de registro en un sistema de este tipo constituye un propósito que entrecruza el sistema. 4. PATRONES DE COMPOSICIÓN HIPERMEDIA Como ya se ha mencionado anteriormente, la comunidad AOSD cuenta con una importante experiencia en la identificación y manejo de aspectos que entrecruzan la funcionalidad básica del sistema. En base a dicha experiencia, en el presente trabajo se propone una nueva forma de modelar las partes recurrentes de un diseño que añaden cierta complejidad al sistema base, modularizándolas en entidades separadas del sistema. Para ello, en este trabajo, se ha intentado adaptar una propuesta reconocida de modelado orientada a aspectos, Composition Patterns, al dominio del modelado de procesos de negocio Web. Básicamente, el proceso ha consistido en modificar los elementos que conforman un patrón de composición para adaptarlo al nivel de navegación o hipermedia. Para modelar la estructura y el comportamiento en el nivel de navegación del patrón de composición adaptado se utilizan los elementos propuestos por UWE, obteniéndose un nuevo artefacto denominado Patrón de Composición Hipermedia (PCH). Para explicar los elementos y estructura del PCH se presenta un modelo propuesto para el patrón Opportunistic Link [14], un patrón hipermedia para aplicaciones Web de comercio electrónico, representado en la Figura 3. Los Patrones Hipermedia [15] pueden ser vistos como patrones de diseño especializados [3] que han sido adaptados a las características específicas del dominio hipermedia. El uso de patrones de diseño beneficia claramente el proceso del desarrollo de software, como mantiene la comunidad de ingeniería del software. Sin embargo, como afirma [8], el uso de ciertos patrones de diseño en el desarrollo de software produce esparcimiento y enmarañamiento en el código del software obtenido. Dichos problemas están también presentes en el ámbito del modelado Web. En este punto, se considera necesario definir el patrón Opportunistic Link separado en una entidad separada y bien modularizada, lo cual permite la aplicación de este patrón sobre el sistema base de manera que éste no tenga conocimiento de la aplicación de dicho patrón. En la Figura 3, se muestra el esqueleto de un patrón de composición hipermedia simple que captura la esencia de navegación del patrón hipermedia Opportunistic Link, definiendo un nuevo índice entre dos clases de navegación: Origin y Product. Este índice es generado dinámicamente y muestra una selección de producto de acuerdo con algunas decisiones de negocio, por ejemplo una línea de productos en oferta. Atendiendo a la parte derecha de la figura 3, las clases dentro del Patrón de Composición Hipermedia no son clases de navegación completas. Dichas clases pueden ser vistas como plantillas, definiendo de esta forma la parte esencial del propósito que queremos diseñar de forma modularizada. De esta manera, pueden ser fácilmente reutilizadas en diferentes sistemas. Mientras que en la parte izquierda se define el escenario Web relacionado con este patrón.
Para aplicar este Patrón de Composición Hipermedia sobre el sistema base es necesario especificar las relaciones de composición entre las plantillas y los elementos de dicho sistema base. En este caso, se utilizan las extensiones del mecanismo de enlace de UML Binding propuestas para los patrones de composición. La Figura 4 muestra como se especifica la aplicación dicho patrón entre las clases de navegación Homepage y Notebook.
En este ejemplo, cada clase de navegación definida dentro del Patrón de Composición Hipermedia es una clase patrón. Estas clases no introducen nuevas clases dentro del espacio del modelo de navegación, sino que se hacen corresponder con ciertas clases de navegación ya existentes. El objetivo principal de los PCH consiste en permitir diseñar modelos Web bien modularizados, simplificando de esta forma la adaptación necesaria ocasionada por cambios de negocio. De esta manera, se tiene localizada la estructura y el comportamiento del patrón Opportunistic Link en un único lugar, sin producirse la entremezcla ni el esparcimiento de código a lo largo del sistema base. Esto facilita la tarea que debe realizar el desarrollador para adaptar dicho patrón a nuevas decisiones de negocio y aplicarlo automáticamente sobre el sistema Web base. Como se puede observar, PCH trata de llevar a cabo el principio de la AOSD “cámbialo una vez y aplícalo en cualquier parte”. Es más, debido a su modularidad, este patrón hipermedia puede ser reutilizado en el modelado de diferentes sistemas de comercio electrónico. 5. MODELANDO PROCESOS DE NEGOCIO CON PATRONES DE COMPOSICIÓN HIPERMEDIA En esta sección se presenta un modelado orientado a aspectos del proceso de registro utilizando, como un ejemplo, la Tienda de Ordenadores presentada anteriormente. Para modelar dicho proceso de negocio se define un nuevo Patrón de Composición Hipermedia, mostrado en la Figura 5. En este caso, se define una clase patrón de navegación, SignedClass, la cual especifica los elementos que cada clase de navegación debe contener para soportar el proceso de registro: el menú SignIn y el atributo username. De ésta forma, los elementos involucrados en el proceso de registro se encuentran localizados en un único lugar y no están esparcidos a lo largo de la especificación de navegación. En el proceso de composición, el desarrollador especificará qué clases de navegación serán SignedClass.
Por otra parte, las clases de navegación que soportan el proceso de registro son clases de navegación normales las cuales serán introducidas dentro del modelo durante la composición. Dichas clases definen la estructura y el comportamiento de un proceso de registro genérico. Por su parte, el diagrama de estados define el escenario web básico que se da en este proceso de negocio. En el proceso de composición, las clases de navegación Homepage, Notebook y PC de nuestra tienda de ordenadores están ligadas a la definición de SignedClass. De esta forma, el proceso de composición modificará de manera automática dichas clases, introduciendo tanto el atributo username como el menú SignIn que establece las relaciones con las clases de navegación propias del proceso de negocio. La principal contribución de este enfoque consiste en el aumento de la modularidad del propósito de navegación implicado en el proceso de registro. Con una mejor modularidad, la adaptabilidad y reusabilidad del proceso de registro se ven incrementadas. Primero, el coste de modificación de dicho proceso se ve considerablemente disminuido – el desarrollador necesita tan solo cambiar la definición del Patrón de Composición Hipermedia, sin tener que preocuparse acerca de los cambios en el resto del modelo de navegación. Y segundo, la reusabilidad se reduce a un proceso de composición. 6. TRABAJOS RELACIONADOS Actualmente, el uso de métodos y herramientas orientados a aspectos ya ha alcanzado al mundo de las tecnologías de desarrollo Web a nivel de implementación. JBoss [19] permite el uso de AspectJ [1] para proporcionar los mismos servicios que los proporcionados por un contenedor EJB. Sin embargo, no sucede lo mismo a nivel de diseño. Con respecto a la comunidad de ingeniería Web, la propuesta de [12] hace énfasis en las interesantes posibilidades derivadas del uso de mecanismos orientados a aspectos en el desarrollo de aplicaciones Web. Sin embargo, dicha propuesta se centra en la especificación de la navegación en el nivel de implementación mediante tecnologías XML, XLink y XPointer. 7. CONCLUSIONES Y TRABAJO FUTURO En este trabajo se resaltan los beneficios de la adopción de técnicas y conceptos orientados a aspectos en el desarrollo de aplicaciones de comercio electrónico. El uso de modelos orientados a aspectos en el diseño del nivel de navegación decrementa la complejidad del sistema y favorece la reutilización del conocimiento de diseño. Este artículo presenta el uso de una nueva técnica de modelado, los Patrones de Composición Hipermedia, los cuales favorecen la adaptabilidad y reutilización de los modelos de navegación, por ejemplo modelando procesos de negocio Web reutilizables. Dicha técnica de modelado consiste en una adaptación de una técnica de modelado orientada a aspectos bien conocida llamada Patrones de Composición. Los Patrones de Composición Hipermedia permiten definir la estructura y comportamiento de navegación de un proceso de negocio Web junto con la especificación transparente de su integración con el sistema base. Además, el presente trabajo, establece un punto de partida para analizar como el desarrollo de aplicaciones de comercio electrónico puede ser mejorado mediante la adopción de métodos, principios y propuestas orientadas a aspectos. Con respecto a las líneas de trabajo futuro, por un lado, se pretende extender UWEXML publicando un framework que soporte Patrones de Composición Hipermedia y, por otro lado, siguiendo el trabajo presentado en [13], se plantea analizar la posibilidad de aplicar Patrones de Composición Hipermedia en el modelado de propósitos de personalización dinámica para desacoplar el sistema Web base del sistema de personalización, por ejemplo, en aplicaciones de comercio electrónico. 8 Referencias
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Técnica Administrativa, Buenos Aires http://www.cyta.com.ar - |
Volumen: 04 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Artículo publicado en la revista IEEE América Latina, http://www.ewh.ieee.org/reg/9/etrans/publicacoes.html |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
