WebSA (Web Software Architecture)

En los ltimos aos, dentro del desarrollo de aplicaciones web han surgido una gran variedad de metodologas basadas en UML que abordan con xito la especificacin de la navegacin y presentacin que dicho tipo de aplicaciones exige. Sin embargo, obligados por un mercado cada vez ms competitivo que exige una continua evolucin de las aplicaciones hipermedia y el aumento en la complejidad que implica su desarrollo, se hace necesario recoger requisitos de calidad que van a darnos la posibilidad de abordar con xito su desarrollo y posterior mantenimiento. Siguiendo una aproximacin DSSA (Domain-Specific Software Architecture) para abordar la especificacin de la arquitectura software de una aplicacin Web, vamos definir un conjunto de modelos basndonos en el estndar MDA (Model-Driven Architecture) que nos van a proporcionar diferentes vistas y niveles de abstraccin, para definir un proceso de refinamiento que va a permitirnos especificar casi por completo el cdigo de una aplicacin web requiere.

1. Introduccin
Actualmente en un mercado tan competitivo como es internet, nos encontramos con la necesidad de desarrollar las aplicaciones web cada vez ms complejas y en el menor tiempo posible. Adems dichas aplicaciones deben cumplir con una serie de requisitos de calidad como son el rendimiento, la usabilidad, la escalabilidad, el mantenimiento, etc. para poder satisfacer a unos usuarios muy exigentes. Esto conduce a que su desarrollo capture dichos requisitos y los incorpore en el resto de las fases del ciclo de vida. En los ltimos aos, dentro de la ingeniera del software ha nacido un nuevo paradigma como es el Web Engineering, en el cual se han definido una coleccin de metodologas cada una de las cuales especifica con mayor o menor acierto la problemtica que un desarrollo web exige. Sin embargo, salvo excepciones como [Conallen99], [Hassan02] las metodologas se preocupan en capturar los aspectos funcionales, navegacionales y de presentacin de una aplicacin, y olvidan los requisitos de calidad o no funcionales, que expresados mediante la arquitectura del software [Bass00] son capaces de completar las necesidades que dicha aplicacin requiere. Como indica Grady Booch [Booch01] refirindose a las aplicaciones web: En mi experiencia, la presencia (o ausencia) de una buena arquitectura es un elemento esencial para predecir el xito o fracaso de un proyecto. Por otro lado, existen una gran diversidad de aplicaciones web cada una de las cuales difiere tanto en nmero de clientes potenciales (desde pequeas intranets a grandes aplicaciones en internet), como en los mecanismos de seguridad que se requieren (desde aplicacin bancaria a una web de humor) , los cambios a los que est sujeta en un futuro (un sitio web contra una aplicacin de administracin), etc. Por todo ello basndonos en la experiencia en el desarrollo de aplicaciones para web, hemos planteado una aproximacin que capture a travs de un conjunto de modelos UML y siguiendo una aproximacin compatible MDA [OMG01], las diferentes vistas en las que se compondra una aplicacin web. Nuestra propuesta se basa en la definicin de una arquitectura software para web, utilizando una aproximacin del tipo DSSA (Domain-Specific Software Architecture), que se basa en el estudio de un dominio para restringir el espacio del problema y de la solucin.

En nuestro caso, centrados en el dominio especfico de las aplicaciones web a nuestra aproximacin le llamamos WebSA (Web Software Architecture). Para su definicin, se sigue un proceso de desarrollo que implica realizar inicialmente un proceso de recogida de requisitos de usuario, en el cual obtendremos tanto requisitos funcionales como los no funcionales. Estos ltimos expresados a partir de un conjunto de atributos de calidad claramente clasificados. A partir de dichos requisitos, se efecta la definicin de un conjunto de modelos expresados mediante UML y siguiendo el estndar MDA, cada uno de los cuales se encarga de recoger una vista diferente de la aplicacin. Adems, cada uno de los modelos se encuentran relacionados entre s, ya sea mediante la trazabilidad de cada una de las vistas, o mediante los procesos de mapeo de los modelos que se encuentran en diferentes niveles de abstraccin. Definimos por lo tanto un perfil UML a partir de la extensin conservadora del metamodelo UML, esto nos permitir formalizar sus relaciones y poder recoger de la forma ms completa una aplicacin web. Para la implementacin de las diferentes vistas, WebSA ha extendido la reconocida metodologa OO-H [Cachero00] definida para el desarrollo de una aplicaciones hipermedia en las fases de anlisis y diseo. Incorporndole por un lado la recogida de los requisitos no funcionales, a partir de los cuales se definirn nuevas vistas a la aplicacin, que van a aportar la informacin sobre la arquitectura software y la vinculacin de los aspectos funcionales y no funcionales. Dndonos as la definicin completa y necesaria de una aplicacin web, que nos va a permitir obtener un entorno de compilacin de modelos traslativos[Bell98] y generar el cdigo para cualquier tipo de aplicacin web. En los siguientes puntos vamos a especificar inicialmente una introduccin a la aproximacin WebSA en la que explicaremos en que se basa una arquitectura DSSA. Entraremos en la explicacin de la diferentes vistas en las que dividimos una aplicacin web, para posteriormente definir el metamodelo que va a formalizar nuestra aproximacin. Seguidamente vamos justificar el uso de la arquitectura del software, para entrar a explicar cada una de las fases en las que se compone las vistas de arquitectura. Para la arquitectura lgica veremos las diferentes fases en las que se compone, descomposicin en subsistemas, descomposicin en componentes abstractos y la integracin de componentes..

2. Introduccin a WebSA
Para entender que es WebSA, primero vamos a definir que significan las dos ltimas siglas, SA, es decir, la Arquitectura del Software que en ocasiones sigue siendo la gran desconocida dentro de la ingeniera del software, pero que en los ltimos aos est tomando una gran relevancia. Existen mltiples definiciones de arquitectura del software, pero de todas ellas vamos a quedarnos con dos definiciones que considero que ms han influido en este trabajo. Definicin de [Bass97]: La arquitectura del software de un programa o un sistema de computacin es la estructura o estructuras del sistema, las cuales comprenden componentes software, las propiedades visibles de estos componentes y las relaciones entre ellos. De esta definicin lo ms importante es el hecho que define claramente cuales son los elementos que ha de recoger la arquitectura. Sin embargo, otra definicin que aporta ms contenido al mencionar las propiedades no funcionales es la de [BMR+96]: Es la descripcin de los subsistemas y componentes de un sistema software y las relaciones entre ellos, tpicamente representado mediante vistas que muestran las propiedades funcionales y no funcionales ms relevantes. El intento de esta definicin es indicar que la arquitectura del software debe abstraerse de alguna informacin del sistema (de otra manera no estaramos apuntando a la arquitectura, estaramos viendo todo el sistema) y aun as proveer suficiente informacin para ser la base para el anlisis, toma de decisin, y por lo tanto reduccin de riesgos. Definicin de WebSA: WebSA es una metodologa para la definicin de arquitecturas software de las aplicaciones web, la cual se basa principalmente en 2 aspectos: 1. La definicin de la arquitectura a travs del paradigma DSSA (Domain Specific Software Architecture),es decir, de las arquitecturas software de dominio especfico, que en su caso fija el dominio en el desarrollo de aplicaciones web. 2. Dicha metodologa adems se basa en la definicin de arquitecturas mediante mltiples vistas concurrentes, para ello se vale de la utilizacin del estndar MDA, que nos permite definir un conjunto de modelos UML, dndole la formalidad necesaria con la utilizacin de estndares como MOF para la definicin de los elementos de modelado, y de OCL, para la definicin de restricciones. A continuacin vamos a entrar en ms detalle justificando el uso de dichos paradigmas.

2.1 Una aproximacin DSSA

Como indica el autor [Coglianese92], una arquitectura expresada mediante una aproximacin DSSA se basa en la siguiente asuncin: El desarrollo de sistemas en un dominio bien conocido es un proceso de emparejamiento de los requerimientos hacia aproximaciones conocidas para aportar soluciones en ese dominio. Como hemos comentado WebSA se especializa en un dominio de aplicacin especfico como son las aplicaciones web, que implica restringir tanto el espacio del problema como el espacio de la solucin, lo que lleva en muchos casos a que el desarrollo de diferentes sistemas software sea bastante similar. Como menciona [Nilson94], el desarrollo de una arquitectura DSSA se basa en el estudio de las propiedades comunes y diferencias entre las aplicaciones de un dominio. A este proceso se lo denomina ingeniera de dominio. Las propiedades ms importantes de una arquitectura DSSA [Hoffmann96] que deseamos cumplir con WebSA son: Trabajar en un espacio del problema y de la solucin restringidos. Genericidad, para poder adaptar el DSSA a un desarrollo en concreto. Un nivel de abstraccin adecuado para abarcar todo el dominio. Elementos de reuso dentro del proceso de desarrollo que son tpicos de cada dominio. Como veremos seguidamente, cada uno de estos puntos van a ser perseguidos, adems de pretender principalmente que WebSA defina correctamente el dominio de las aplicaciones web. Entre las propiedades anteriores destacamos principalmente el hecho de que trabajar en un espacio de solucin restringido nos facilitar la tarea de identificar la funcionalidad de ciertos componentes que en otras ocasiones sera imposible, por otro lado, tambin consideramos importante que el nivel de abstraccin adecuado nos va permitir recuperar elementos de reutilizacin. Siguiendo la definicin de una arquitectura DSSA, nuestra aproximacin parte inicialmente de una fase de recogida de requisitos en la que vamos a incorporar a los tradicionales requisitos funcionales recogidos mediante casos de uso, y de los requisitos no funcionales recogido a travs de escenario de calidad. Ambos conjuntos de requisitos van a ser el punto de partida para el posterior anlisis y diseo, donde como veremos aparece la especificacin tanto de los aspectos funcionales como los aspectos meramente arquitectnicos. Dichos mbitos van a estar especificados a travs de diferentes vistas interrelacionadas mediante relaciones de dependencia definidas en un metamodelo UML comn. A continuacin vamos a mostrar la otra parte principal de nuestra aproximacin que es el uso de MDA para la especificacin de los diferentes modelos especificados dentro de nuestra aproximacin.

2.2 Definicin de arquitectura web mediante MDA

Utilizando la definicin de arquitectura que menciona [Conallen99]: Mirar la descripcin de una arquitectura es como una versin condensada de todo el conjunto de artefactos de desarrollo. Nuestra aproximacin se basa en la separacin en diferentes vistas concurrentes de la representacin del todo el sistema web, para ello nos vamos a valer del estndar definido en la OMG llamado MDA. MDA [OMG2001] define una aproximacin para la especificacin de sistemas cuyo principio es la separacin de la funcionalidad del sistema de los aspectos dependientes de la plataforma destino. Esto lo realiza mediante una arquitectura de modelos que provee un conjunto de guas para estructurar las especificaciones expresadas como modelos. Como vemos en la definicin de MDA, existen dos aspectos diferenciados, la separacin con la plataforma destino, que en nuestro caso es importante, ya que la arquitectura la vamos a definir a un nivel de abstraccin donde la plataforma no se especifica, y adems nos va a facilitar el hecho de que proporcionan mapeos a plataformas como J2EE, .NET y CORBA. Y el siguiente aspecto y no menos importante es la aportacin de una arquitectura de modelos, la cual est definida a partir de los conceptos de vista, refinamiento y abstraccin que nos van a permitir definir un conjunto de modelos interrelacionados con diferentes vistas y en diferentes niveles de abstraccin que nos permitir realizar un seguimiento durante todo el ciclo de vida. Las principales ventajas que nos aporta la aproximacin MDA son: Integracin con sistemas legados . Utilizacin de estndares como UML, XMI, CWM que nos proporcionan la posibilidad de intercambiar nuestros modelos a cualquier herramienta que sea compatible UML. La formalizacin a travs MOF y OCL de todos los modelos definidos a partir de UML. Reduccin de costes durante todo el ciclo de vida de la aplicacin. Rpida inclusin de los beneficios de las tecnologas emergentes en sus sistemas existentes. Existen trabajos previos que han abordado con xito la especificacin de la arquitectura de una aplicacin tratando por separado las vistas que la constituyen, los ms importantes son los de [Kruchten95] el cual define 4+1 vistas concurrentes para definir un sistema, y posteriormente [Hofmeister99] que separa en 4 vistas la arquitectura software. Sin embargo, ambas aproximaciones se basan nicamente en UML, y se definen para expresar cualquier tipo de arquitectura, mientras que en nuestra aproximacin se hace uso de MDA y adems est fijada en el dominio de las aplicaciones web lo que nos va a permitir llegar a un nivel de detalle mucho mayor. A continuacin, vamos a definir el conjunto de vistas de WebSA. Entendiendo por vista, como un conjunto de artefactos creados en el proceso del desarrollo del software. Estas vistas se definen como una extensin de las vistas definidas en la metodologa OO-H. OO-H define las vistas existentes en la parte funcional de la aplicacin web, y 5

sobre dichas vistas vamos a incorporar aquellas que tratan los aspectos no funcionales, tanto en la parte de requisitos como en la arquitectura, adems de establecer la trazabilidad entre cada una de las partes lo que nos va a permitir expresar aspectos que nicamente se pueden tratar cuando la parte funcional y no funcional estn juntas. Adems, cada una de las vistas las vamos a agrupar dentro de lo que se denomina punto de vista (viewpoint). Un punto de vista es una coleccin de vistas que comparten un conjunto de asuntos. Los puntos de vista las vistas que contienen son las vistas definidas son las siguientes: Punto de Vista de Requisitos: Realizado durante la fase de requisitos, en el los analistas recogen la informacin necesaria a partir de la cual vamos a especificar el sistema. 1. Vista Requisitos Funcionales: En dicha vista se expresan mediante los casos de uso que recogeran los requisitos funcionales. 2. Vista Requisitos No Funcionales: En esta vista se expresan mediante escenarios de calidad los requisitos no funcionales. Punto de Vista Funcional: A partir de los requisitos de usuario especificados en la fase anterior se definen un conjunto de vistas que van a recoger la funcionalidad de un sistema web. Dichas vistas estn definidas en la metodologa OO-H: 3. Vista Conceptual: Expresa la funcionalidad del sistema de informacin sobre el que se define la aplicacin. 4. Vista de Presentacin: se preocupa de indicar cual va ser el aspecto de la aplicacin y la funcionalidad asociada a esta. 5. Vista de Navegacin: expresa cada una de las interacciones que el usuario realiza para transcurrir a travs de los diferentes escenarios de la aplicacin. 6. Vista Procesos: expresa cuales son las actividades de los procesos y el flujo de los procesos, estableciendo que actividades deben procesarse en secuencia o en paralelo. Punto de Vista de Arquitectura: A partir de los requisitos funcionales y no funcionales se definen las vistas que tradicionalmente se han denominado de arquitectura, y son la principal aportacin del este trabajo: 7. Vista de la Arquitectura Lgica: expresa cules son los componentes lgicos (subsistemas, mdulos o componentes software) que participan en nuestra solucin, y la relacin entre ellos. 8. Vista de la Arquitectura Fsica: expresa cules son los componentes fsicos que participan en nuestra solucin, y la relacin entre ellos (clientes, servidores, redes, BD, etc). Una vez hemos enumerado las vistas que constituyen una arquitectura WebSA, necesitamos indicar cuales son las relaciones que existen entre cada una de ellas. Esto lo vamos a formalizar mediante un metamodelo UML. Por metamodelo se definimos lo siguiente:

Metamodelo: Un metamodelo es una definicin precisa de los elementos de modelado, sus relaciones y de reglas bien formadas necesarias para crear modelos semnticos. En nuestra aproximacin, hemos utilizado UML para definir el metamodelo, esto nos va a permitir formalizar y relacionar cada unas de las vistas de la arquitectura WebSA, adems de poder establecer una trazabilidad entre los diferentes elementos de las vistas.
Requirements ViewPoint Functional Requirements View Non-Functional Requirements View

Functional ViewPoint

Architectural ViewPoint

Conceptual View

Presentation View

Logic A rchit ectural Vi ew

Process View

Navigational View

Physical Architectural View

Figura 1. Modelo de dependencia entre las vistas WebSA. Como se puede apreciar en la figura 1, el sistema se define inicialmente a travs de un punto de vista de requisitos que contiene las vistas de requisitos funcionales y no funcionales, que recogen la informacin necesaria a partir de la cual se van a constituir tanto la vista funcional, representados por las cuatro vistas de OO-H, como las vistas no funcionales que seran recogidos por las vistas de Arquitectura lgica y fsica. Conviene remarcar que existen dependencias a la hora de elaborar cada una de las vistas del sistema, as por ejemplo en el punto de vista funcional se hace necesario establecer las vistas de proceso y conceptual, para poder tener luego la vista navegacional y a continuacin la vista de presentacin. Adems, en el punto de vista arquitectnico, inicialmente definimos una vista de arquitectura lgica para posteriormente tener la correspondencia a nivel fsico en la vista de arquitectura fsica. Por otro lado existe una interdependencia mutua entre las vistas de la parte funcional y las vistas de la parte de arquitectura, es decir, ambas partes estn vinculadas por relaciones de dependencia, lo que nos va a permitir en muchas ocasiones tomar decisiones en la parte funcional en funcin de aspectos recogidos en la arquitectura, y viceversa. A continuacin vamos a entrar a describir una de las vistas descritas de la arquitectura, la arquitectura lgica, que como veremos se compone a su vez de un conjunto de modelos cada uno de los cuales va a estar localizado en diferentes niveles de abstraccin. En posteriores trabajos mostraremos el modelo de arquitectura fsica.

3. Arquitectura Lgica
Como hemos indicado anteriormente, dicha arquitectura se encarga de expresar cules son los componentes lgicos (subsistemas, mdulos o componentes software) que participan en nuestra solucin y la relacin entre ellos. Dicha arquitectura va a inferirse a partir de los requisitos funcionales y no funcionales definidos en fases anteriores. Para conseguir emparejar cada uno de los requisitos no funcionales recogido en la fase de requerimientos con el diseo arquitectnico especificado en las vistas de arquitectura, vamos a utilizar por un lado los patrones, definidos a diferentes niveles de abstraccin, que nos va a dar indicar cuales son los requisitos que cumplen en cada uno de los casos, y por otro, cuales son las operaciones unitarias que se estn realizando al aplicarse. Por otro lado, en el caso de los requisitos funcionales como veremos estos se van a intervenir a travs de un mapeo con los componentes de la arquitectura, y fijado a travs de las relaciones establecidas entre las diferentes vistas en el metamodelo de WebSA. Existen muchas tcnicas y lenguajes para especificar la arquitectura lgica de un sistema. Nosotros utilizaremos una nomenclatura basada en UML siguiendo otras aproximaciones como [Hofmeister99, Kruchten95] que nos aporta una serie de ventajas como la posibilidad de formalizar la aproximacin mediante un metamodelo estndar UML permitindonos la utilizacin de herramientas existentes, adems utilizando otros estndares OMG que nos proporciona MDA, para poder hacer mapeos entre las diferentes vistas. Nuestra aproximacin divide en 3 modelos cada uno correspondiendo a 3 fases dentro del diseo de la arquitectura lgica, cada una de estas fases va a estar situada en un nivel de abstraccin distinto, que nos va a permitir recoger diferentes aspectos de la arquitectura, y poder captar todos los requisitos especificados por el usuario: 1. Modelo de Subsistemas: Denominado tradicionalmente como diseo estructural, define cuales son los subsistemas que van a constituir nuestra aplicacin. 2. Modelo de Configuracin de Componentes Web: Consiste en refinar cada uno de los subsistemas descomponindolos en cada uno de los componentes abstractos propios de una aplicacin web, expresndose de forma independiente de dominio y de plataforma. 3. Modelo de Integracin de Componentes Web: Consiste en definir cuales son los componentes y mdulos concretos una vez est apareados con el dominio del problema. Como vemos cada uno de estos modelos tiene una dependencia de forma que el modelo de configuracin de componentes guarda las restricciones establecidas por el modelo de subsistemas, y de la misma manera, el modelo de integracin ha de mantener las relaciones establecidas con el modelo de configuracin. En los siguientes puntos vamos a definir detalladamente cada uno de estos modelos.

3.1

Modelo de Subsistemas (M.S.)

El modelo de subsistemas denominado tradicionalmente diseo estructural tiene que ver con el diseo de las macrocomponentes de nuestra aplicacin. Esta fase localizada en el nivel de abstraccin ms alto en el diseo arquitectnico, consiste en definir claramente cuales van a ser los subsistemas que van a constituir nuestra aplicacin. Cada uno de los subsistemas van a estar identificados con una capa lgica de la aplicacin. Dicha separacin por capas es un principio que nos va a ayudar a reducir la complejidad de los sistemas, basndose en el patrn layering approach[BMR+96]. La reduccin de las dependencias entre los mdulos y el tratamiento local de los cambios, la portabilidad y la reutilizacin son aspectos bien conocidos de una aproximacin estratificada por capas. Tradicionalmente se ha definido un modelo de arquitectura de 3 capas para las aplicaciones cliente/servidor [BMR+96]. Sin embargo, cada una de estas capas podran llegarse a refinar aun ms, el modelo Seeheim-model [NoSc99] distingue 6 capas diferentes una aplicacin, ver Figura 2. Modelo 3 Capas Modelo 6 Capas
Presentacin Interfaz de Usuario Control de Usuario

Control de procesos Lgica de Negocio Objetos de Negocio

Acceso a Datos Persistencia Fsica de Datos

Figura 2. Refinamiento del modelo de capas. Cada una de estas divisiones las vamos a realizar basndonos en unos patrones de arquitectura situados en este nivel de abstraccin llamados patrones de distribucin definidos por [ReWo97]. A continuacin definimos cual es la funcionalidad de cada una de las capas, cual es el patrn que se aplica para su divisin, y la explicacin de cada una de las capas. Seguidamente entraremos a explicar cada patrn ms detalladamente. Las capas son las siguientes:

Interfaz de Usuario: Capa encargada de dotar de la funcionalidad necesaria para la interaccin entre el usuario y la aplicacin, el patrn distribucin que divide ambas capas se denomina presentacin distribuida, y divide en el refinamiento en 2 subcapas: Presentacin: Se encarga de una capa distribuida que se encarga de dotar nicamente la funcionalidad de aspecto, y recibir las peticiones del usuario que en algunos casos sern validadas. Control de Usuario: Capa que se encarga de recibir las peticiones del usuario, gestionando la navegacin del interfaz de usuario, y redireccionando las peticiones a la lgica de negocio, la cual procesar la peticin y devolver un resultado al control de usuario. Lgica de Negocio: Esta es la parte del sistema que resuelve las reglas de negocio especificadas para el dominio del problema. Si aplicamos el patrn de distribucin Ncleo de Aplicacin distribuido podemos dividirla en dos subcapas: Procesamiento de Control: Esta parte del sistema se encarga de atender las peticiones que se reciben del cliente, convirtindolas en procesos que se realizar de forma transaccional o no, de forma sncrona o asncrona. Objetos de Negocio: En dicho subsistema residen los elementos que contienen la representacin de los objetos definidos en el dominio del problema Persistencia: Como su nombre indica, es la parte del sistema encargada del dotarle de persistencia al sistema de informacin. Dada la divisin marcada por la aplicacin del patrn Base de Datos Remota, la funcionalidad se distribuye en 2 subcapas: Acceso a Datos: Este subsistema se encarga de contener aquellos elementos que permiten el acceso a los datos fsicos desde la capa de lgica de negocio Capa Fsica de Datos: Este subsistema determina cuales van a ser las fuentes fsicas de datos que va a contener nuestro sistema. Como hemos indicado a este nivel de abstraccin vamos a recoger los patrones arquitectnicos de distribucin definidos por [ReWo97], cada uno de los cuales va a dividir la arquitectura en diferentes subsistemas cliente y servidor. La decisin de adoptar un estilo de distribucin particular va a estar dirigida por los requerimientos no funcionales. Cada uno de los patrones va a estar influenciado por un conjunto de fuerzas, cuya intensidad viene marcada por los requerimientos del sistema, e indicarn si finalmente aplicamos o no dicho patrn. A continuacin pasamos a explicar los patrones de distribucin identificados, y los motivos por los cuales se aplican: 1. Presentacin Distribuida: Este patrn separar el sistema de la componente de presentacin. Una parte de la componente de presentacin es una unidad distribuida y es procesada separadamente de la otra parte de la presentacin la cual puede ser empaquetada junto con otras capas de la aplicacin. Este patrn nos permite una fcil implementacin y clientes muy finos. Anteriormente eran los sistemas Host con sus terminales 3270 el ejemplo clsico. Pero hoy en da son los clientes ligeros web, html y flash los que mejores ejemplos de la aplicacin de este patrn.

10

2. Interfaz de Usuario Remoto: En lugar de distribuir cierta parte de la funcionalidad de la presentacin, en este caso todo el interfaz se convierte en una unidad de distribucin y acta como cliente del ncleo de la aplicacin en la parte servidora. 3. Ncleo de la Aplicacin Distribuido: Este patrn divide el ncleo de la aplicacin en dos partes las cuales son procesadas de forma separada. Este patrn se convierte realmente interesante cuando las transacciones expanden los lmites de los procesos (procesamiento de transacciones distribuidas). 4. Base de datos remota: La base de datos es el componente ms grande de un sistema de informacin con requerimientos especiales en la ejecucin de su entorno. A veces, algunas aplicaciones funcionan como una base de datos . Este patrn localiza el componente base de datos de forma separada al sistema. 5. Base de datos distribuida: Este patrn descomponen la base de datos en componentes separados los cuales interactuan por medio de interprocesos que comunican los servicios. Con una base de datos distribuida una aplicacin puede integrar los datos desde diferentes sistemas de base de datos o los datos pueden ser almacenados en una localizacin cercana a donde se estn procesando. Cada uno de los patrones se puede aplicar de forma ortogonal, es decir, no influye el hecho de aplicar un patrn a la hora de poder aplicar el siguiente. A continuacin en la figura 3 podemos ver como cada patrn de distribucin va dividiendo cada una de las capas.

Modelo 2 Capas
Interfaz de Usuario

Modelo 3 Capas
Interfaz de Usuario

Modelo 6 Capas
Presentacin

Presentacin Distribuida

Control de Usuario

Interfaz de usuario remoto

Lgica de Negocio

Ncleo Aplicacin Distribuido

Control de procesos Objetos de Negocio

Servidor

Base De Datos Remota

Persistencia

Acceso a Datos

Base de Datos Distribuidas

Fsica de Datos

Figura 3. Esquema de aplicacin de cada uno de los patrones de distribucin sobre las capas.

Una vez identificados los tipos de capas, cada uno de los cuales aporta un dominio del problema especfico, vamos a definir cuales van a ser los elementos del modelo de subsistemas.

11

Aparecen como elementos principales: Subsistema: Elemento de mayor granularidad en el diseo arquitectnico de una aplicacin. Define una agrupacin de componentes desarrollados para dotarle de la funcionalidad necesaria para cumplir con la tarea propia de una capa lgica. Por ello, vamos a distinguir tantos tipos de subsistemas como capas identificadas. o Representacin UML: Es un estereotipo de paquete que corresponde con el tipo de subsistema que estamos definiendo. Existen tantos tipos como capas y subcapas definidas. Es decir que definimos 9 tipos.

<<Tipo de subsistema>> Nombre de subsistema

Figura 4. Representacin de un subsistema. Relacin de dependencia: Se establece una relacin de dependencia entre cada uno de los subsistemas que viene marcada por las relaciones de uso. Utilizamos la dependencia de paquetes de UML. Por otro lado, en el metamodelo de WebSA, vamos a definir mediante el lenguaje de restriccin OCL [OMG] las posibles relaciones que se establecen entre los diferentes tipos de subsistemas, e indicar que elementos vamos poder descomponer segn el tipo de distribuciones posibles. En la siguiente figura se muestra un ejemplo de diagrama de diseo estructural de una aplicacin web de comercio electrnico llamada Telecomercio. Cabe resear que cuenta con dos interfaces de usuario, uno que sera el sitio web que colgaramos de internet, y el otro es una herramienta de administracin con la cual cargaramos informacin sobre personalizacin y contenido al sitio web.

12

<<Presentation>> W eb Site T elecomercio

<<Presen tation> > Administrador W eb Site

<<Dialog Control>> DC W eb Site

<<Dialog Control>> DC A dm inis trador

<<Business Logic>> T elecomercio

<<Persistence>> BDT elecomercio

Figura 5. Ejemplo de Telecomercio.

Una vez hemos divido del sistema en los subsistemas que lo consituyen el siguiente paso es adentrarnos en cada uno de ellos, y ver cuales son los componentes que lo componen. Dichos componentes deben definirse en armona respecto al esquema definido a este nivel, ya que las dependencias establecidas entre los diferentes subsistemas, nos indicarn si los componentes de estos podrn relacionarse o no.

13

3.2

Modelo de Configuracin de Componentes la Web

Una vez hemos fijado a travs de los requisitos no funcionales cuales van a ser la distribucin en subsistemas que va a tener nuestra aplicacin, el siguiente paso consiste en descomponer cada uno de dichos subsistemas en los componentes que van a constituir la arquitectura esttica de nuestra aplicacin. Bsicamente, el modelo de configuracin de componentes de web consiste en fijar la configuracin esttica de los diferentes subsistemas a travs de una coleccin de componentes del dominio web abstractos vinculados entre s a travs de diferentes tipos de relaciones de dependencia. Dentro de dicho diagrama, cada uno de dichos componentes web abstractos van a estar identificados por un tipo propio del subsistema en el que est ubicado, y adems tendr asociada una cardinalidad sobre la poblacin de dicho componente. Por otro lado, las relaciones igualmente vendrn a fijar el tipo y las cardinalidades entre los diferentes componentes del sistema. A este nivel de abstraccin, vamos a poder identificar otra serie de elementos de reutilizacin como son los patrones de arquitectura que nos van a permitir relacionar dicho modelo con los requisitos no funcionales. Como veremos en las fases posteriores, dichos patrones de arquitectura identificados por autores como [BMR+96] y [Conallen] sern aplicados a los componentes de las diferentes capas de la aplicacin web. Por otro lado, este modelo podemos considerarlo similar al que propone [Hassan2001] en su modelo ALS [Architecture Level Schema], pero a diferencia de este adems de expresar la relacin existente entre los componentes y los subsistemas, se intenta fijar el tipo y la cardinalidad de los componentes con lo cual se restringe la poblacin de los componentes concretos identificados en prximos refinamientos. Las propiedades principales de dicho diseo modular son: 1. Se define una ontologa de elementos localizados en el dominio de las aplicaciones web. 2. Proporciona un nivel de abstraccin que recoge los patrones arquitectnicos y frameworks, que posibilitan recoger nuevos requisitos de calidad. Eso s siempre restringidos a lo especificado en el diseo estructural. 3. Independiente de dominio, que nos aporta la posibilidad de reutilizar dicho modelo para ms de un sistema. 4. Independencia de lenguaje y de plataforma que no nos obliguen a tomar compromisos tecnolgicos en una fase temprana, y de esta manera poder especificar un abanico ms amplio de implementaciones. 5. Definicin y formalizacin de los elementos a travs del metamodelo WebSA en UML, lo que nos proporciona una trazabilidad de los elementos que aqu se incorporan. 6. Orientado a web, consecuencia del punto anterior, ya que los elementos que se manejan estn definidos para aplicaciones hipermediales.

14

Un componente a este nivel de abstraccin va a proporcionarnos una tarea concreta e identificada como comn dentro de la arquitectura de una aplicacin web. Para ello a cada uno de estos componentes vamos a dotarlos de dos propiedades comunes: 1. Un tipo: Nos va a indicar cual es la tarea a desempear dentro de la arquitectura de la aplicacin, y cual es la disposicin y relaciones que puede tener. Este tipo va a estar restringido a una aplicacin web y a la capa dentro del cual se define, con lo cual vamos a conseguir reducir el nmero de mapeos posibles a los elementos de diseo concretos. Como veremos en el prximo modelo, dicho tipo va a marcar el mapeo que se va a realizar con los elementos de las vistas funcionales de la aplicacin web. Cardinalidad de despliegue: Va a definir cual es el nmero de elementos concretos que se van a generar en las posteriores fases de diseo.

2.

3.2.1 Constructores del diseo modular Vamos a definir cuales van a ser los elementos y las propiedades que dichos elementos van a tener: a) Componente Abstracto Representa una abstraccin de uno o ms componentes software con una misma funcionalidad o tarea dentro de una aplicacin web. Adems, cada componente va a tener una relacin de dependencia con uno o ms componentes que estarn restringidas en funcin del tipo y del modelo de subsistemas definido en la fase anterior. Vemos la definicin dentro del metamodelo de dicho artefacto.
Class

WebApplicationComponent Cardi nality : String type : String

Client Page

Model

Session

...

Figura 6. Definicin de los componentes MCC dentro del metamodelo WSA. Propiedades: Cada componente va a tener un conjunto de atributos que indican su funcin dentro de la arquitectura de la aplicacin.

15

a. Tipo: Indica el tipo de tarea que dicho componente software va a representar en la aplicacin web. Un componente dentro del dominio de una aplicacin web podra ser desde una pagina , a un componente de servidor, a un componente de control, etc. b. Cardinalidad: Indica cual va a ser el conjunto de componentes software concretos que se van a generar a partir de este. c. Interfaz: Representa las operaciones que dicho componente oferta al resto del sistema para poder ser invocado. Dicho interfaz al estar definido a un nivel de abstraccin ms alto que los componentes software concretos, va a contener nicamente mtodos que sean comunes a todos los componentes generados posteriormente. A dicho interfaz vamos a representarlo mediante la notacin lollipop de UML.

Representacin UML-> El componente se representa mediante un estereotipo de clase. Segn el tipo que se defina podremos indicar el icono con el cual se representa, y en ltimo caso representarlo entre llaves como cualquier estereotipo.
<<Tipo de componente>> Nombre de componente Cardinalidad

Interfaz

Figura 7. Representacin de un componente. b) Conector Abstracto Relacin de dependencia establecida entre dos componentes del sistema. Adems, dicha relacin puede establecerse sobre el componente o sobre su interfaz, lo que indica un nivel de acoplamiento menor. Esta relacin expresa una dependencia entre los dos componentes, dependencia que va a venir expresada por el tipo del conector. Adems, al igual que los elementos, se va a definir una cardinalidad de despliegue que va a generar los elementos conectores que cumplan la condicin de despliegue. Propiedades: a. Tipo: Indica el tipo de relacin establecida entre los dos elementos arquitectnicos. Cada uno de estos tipos va a indicar si se trata de una tarea de invocacin, construccin (build), si es remota o local (admite llamadas entre dos nodos diferentes de la arquitectura fsica), etc. b. Cardinalidades: Indica cual va a ser el nmero de relaciones que se van a establecer entre los componentes relacionados. Puede ser 0-1, 1, *,+.

16

Representacin en UML: En este caso cada uno de los tipos va a venir representada por un estereotipo de la relacin de dependencia.
Componente A Card. A Card. B Componente B

<<Tipo dependencia>>

Figura 8.Representacin de la relacin de dependencia entre 2 componentes. 3.2.2 Clasificacin de los tipos de Componentes Vamos a realizar una clasificacin de los diferentes tipos de componentes que vamos a poder identificar en funcin del subsistema en el que nos encontremos dentro del diseo modular. Dichos tipos van a estar definidos dentro del dominio de las aplicaciones web y ms concretamente en cada una de las capas que por si mismas desempean una funcin diferente. Para la definicin de dichos tipos vamos a definir cual es su relacin dentro del metamodelo de WebSA, y su vinculacin la parte funcional de OO-H con el tipo genrico definido. Sin embargo, existen algunos componentes que son propios de las aplicaciones web y no estn vinculados con la parte funcional, p.e. el componente Explorador. Para dichos componentes no tienen un mapeo con la parte funcional pero si formar parte del metamodelo de WebSA. Para hacer la clasificacin de los tipos vamos a indicar cuales de ellos pueden definirse en cada una de las 10 capas identificadas en el modelo de Subsistemas. Existen tipos de elementos que por contener funcionalidad perteneciente a ms de una capa solo puedan definirse en una capa compuesta, por ejemplo, un applet contiene funcionalidad de la capa de presentacin y de la de control as que solo puede definirse en un subsistema de tipo interfaz de usuario. 3.2.2.1 Subsistemas de Interfaz de Usuario Capa encargada de dotar de la funcionalidad necesaria para la interaccin entre el usuario y la aplicacin. En funcin de la aplicacin del patrn de distribucin Presentacin Distribuida va a estar divida a su vez por dos subcapas: Presentacin y Control de Usuario. A la hora de elegir cuales son los elementos ms adecuados para cada una de las capas, nos hemos basado en los trabajos como [Conallen] que define un conjunto de elementos para especificar una aplicacin web en UML. Existen tipos de componentes que se solo se pueden ejecutar cuando presentacin y control no estn separados, son los siguientes: Objeto Web: Componente que es ejecutado en el cliente proporcionando la funcionalidad tanto de presentacin como de control de dilogo. Normalmente

17

se ejecuta en el browser mediante plugins, los ejemplos ms tpicos son los Applets Java, los componentes Flash, y los Actives. A continuacin indicamos los elementos que podemos identificar en cada una de las subcapas, que igualmente pueden utilizarse cuando ambas capas estn unidas. a) Subsistema de Presentacin. Este subsistema cuya principal funcin es la de mostrar e interactuar con el usuario de la aplicacin. En esta capa va a aparecer los siguientes tipos elementos (Componente): Explorador: Cualquier explorador HTML estandar, con soporte o no a plugins Flash, Java. Capaz de interpretar las pginas de presentacin, estilo y funcional, mostrrselas al usuario. Aparte de esto es capaz de aceptar y de devolver cookies. Pagina Cliente: Componente que contiene el contenido necesario para presentar la informacin al usuario, recibir la entrada de datos, validarlos si es necesario y adems realizar las invocaciones al servidor. (p.e. HTML, XML, pgina flash). Puede contener referencias a otros componentes cliente, estilo y funcional. Pagina Estilo: Componente que nicamente mantiene informacin referente al aspecto del interfaz de usuario (p.e. CSS, XSL). Puede ser referenciado por un componente cliente. Pagina Funcional : Componente que mantiene funcionalidad para la interaccin del usuario con el interfaz de la aplicacin. Dicha funcionalidad puede ser validacin, presentacin, navegacin, etc. (p.e. Javascript, ActionScript). Puede ser referenciado por un componente cliente. Almacn: Componente que mantiene a un mecanismo de almacenamiento localizado en la capa del cliente, que le va a permitir recuperar informacin entre sesiones. El ejemplo ms habitual es la cookie. b) Subsistema de Control de Dilogo Este subsistema llamado Control de dilogo o capa de presentacin se encarga de realizar el procesamiento de la funcionalidad de presentacin, tanto en lo que se refiere a su navegacin, a su presentacin, y en las invocaciones que se realicen a la capa de la lgica. Basndonos en la separacin funcional de procesamiento, entrada y salida que hace el patrn MVC [BMR+96], vamos a incorporar ciertos elementos comunes dentro de esta capa. Los principales tipos identificados son: Pgina Servidora: Componente que realiza el procesamiento de la pagina web mediante scripts ejecutados en la parte servidora, normalmente por un engine que ejecuta el cdigo de la pgina y le devuelve el contenido al servidor web. Dicho componente contiene la informacin referente a la presentacin y/o lgica en el servidor y genera uno o ms componentes de la capa de interfaz de usuario. (p.e. ASP, JSP, PHP, Coldfusion, etc).

18

Control: Componente que se encarga de recibir las peticiones realizadas por el usuario y establece la reaccin del interfaz. La funcionalidad que aporta es la de redireccionar las peticiones de servicios a la lgica de negocio o al componente modelo, y la de redireccionar las peticiones de navegacin a pginas servidoras. Representacin en Metamodelo: Para definir la reaccin obtendremos la informacin del modelo de navegacin (NAD). A partir del cual establecemos una relacin con la clase Navigational Link, el la cual control contendr la funcionalidad de n enlaces. Por otro lado, tendr una relacin de asociacin con la clase Operacin OO-H, definida a partir de la herencia de la clase Operacin del UML.
<<W ebApplicat ionComponent>> WAC1

<<NAD class>> NAD1

<<Operation>> ConceptualC1

1 target 0..n

1 sourc e 0..1 0..n 0..n <<ControlAWD>> CAWD1 0..1 0..n <<OperationOOH>> op1

<<Navigational Link>> NV1

Figura 9. Metamodelo del componente ControlAWD

Modelo: Componente que representa los datos y la funcionalidad del dominio de la aplicacin en la capa de presentacin. Est definido mediante el diagrama de clases de la vista conceptual. Vista: Componente obtiene la informacin del modelo, y muestra la informacin al usuario. La forma en que la muestra es independiente del dominio de la aplicacin. Viene definida por el CLD o modelo de presentacin. Sesin: Componente que mantiene la informacin durante la sesin de un determinado usuario. Aplicacin: Componente que mantiene la informacin comn para todos los usuarios. Cliente: Componente que mantiene la informacin para un determinado cliente. Legado: Componente que realiza una invocacin a la capa de control o que es demandado por la capa de control para que haga una determinada tarea. 19

Almacn: Componente que va a mantener informacin de forma persistente localizada en la capa de presentacin o control. Dicha informacin accesible nicamente por los componentes de esta capa almacena informacin referente a configuracin, idioma, personalizacin, etc. Un ejemplo puede ser un fichero properties de java, un xml, etc. 3.2.2.2 Subsistemas de Lgica de Negocio Esta es la parte del sistema que resuelve las reglas de negocio especificadas para el dominio del problema. Dicha capa puede estar o no divida por dos subcapas, procesos de negocio y por los objetos de negocio. Ambas partes aparecen especificadas por la vista conceptual de sistema, y se van a distribuir en un conjunto de componentes que en funcin de los requisitos de calidad van a sugerir la utilizacin de computacin distribuida, standalone, etc. Los componentes identificados en este subsistema estn basados en abstracciones del estndar EDOC (Enterprise Distributed Object Computing)[OMG02], esto nos va a permitir posteriormente obtener en el refinamiento a componentes concretos definidos en el estndar EDOC, para los cuales MDA nos proporcionar los mapeos a distintas plataformas. a) Subsistema de Procesamiento de Control Esta parte del sistema se encarga de atender las peticiones que se reciben del cliente, convirtindolas en procesos que se realizar de forma transaccional o no, de forma sncrona o asncrona. Aqu utilizaremos las siguientes combinaciones de componentes: Sesin Sin Estado: Componente que no mantiene estado de un determinado cliente, es decir, se crea un hilo de ejecucin nuevo por cada invocacin que se realice. Lo que le otorga la posibilidad de generar n hilos muy ligeros y atender a muchos clientes simultneamente. Se utiliza cuando el nmero de usuarios de la aplicacin es elevado. Sesin Con Estado: Componente que mantiene estado de un determinado cliente durante toda su interaccin. Lo que le obliga a establecer una instancia por cada cliente. Resultando ms til cuando se exigen altas prestaciones, a un nmero de usuarios no muy elevado. Sesin Asncronos: Componente que recibe invocaciones en modo asncrono de una lista de distribucin o de una pila de llamadas. Componente Por Lotes: Componente que realiza un conjunto de eventos no transaccionales. Componente Servidor Legado: Componente que realiza su tarea desde un sistema legado. Funcional: Componente que contiene una coleccin de funciones accesibles por el resto de elementos del subsistema. b) Subsistema de Objetos de negocio

20

En dicho subsistema residen los elementos que contienen la representacin de los objetos definidos en el dominio del problema. En nuestra aproximacin aparecen definidos en la vista conceptual. Dichos componentes pueden ser de estos tipos: Entidad Distribuida: Componente que representa una instancia de una o ms clases del modelo. Adems, mantiene la informacin del modelo en memoria de manera que previo un proceso de carga, se accede a esta informacin y posteriormente se actualiza dicha informacin en la capa de persistencia. Esto permite reducir el nmero de accesos a base de datos con la ventaja a nivel de rendimiento que supone. Entidad Local: Componente que representa una instancia de una o ms clases del modelo, pero que necesita acceder a la persistencia para realizar cualquier operacin. Es utilizada cuando no es necesario optimizar los accesos a BD. CAD (Componente de Acceso a Datos): Componente cuya funcionalidad es la de acceder a los datos independizando a las componentes del dominio del tipo de persistencia que el sistema utiliza. Est basado en el patrn de diseo DAO de Gamma. Funcional: Componente que contiene una coleccin de funciones accesibles por el resto de elementos del subsistema. Legado: Representa una instancia del modelo o de otro sistema que es mantenida por un sistema legado.

3.2.2.3 Subsistemas de Persistencia Parte del sistema encargada del dotarle de persistencia al sistema de informacin. Dada la divisin marcada por la aplicacin del patrn Base de Datos Remota, los componentes en cada una de las subcapas van a estar enfocados por un lado al acceso y por el otro a la gestin de dichos datos. a) Subsistema de acceso a datos. Este subsistema se encarga de contener aquellos elementos que permiten el acceso a los datos fsicos desde la capa de lgica de negocio. Adems provee de la funcionalidad necesaria para poder otorgar una serie de mejoras de rendimiento y escalabilidad como son la utilizacin de un pool de conexiones o la de disponer de bases de datos remotas. Pool: Componente que consiste en una coleccin de recursos que nos permiten reutilizar dichos recursos para un conjunto de usuarios elevados, y adems reducir drsticamente el tiempo necesario para crear y destruir cada conexin fsica. Fuente de Datos: Componente que nos proporciona la conexin lgica con la fuente de datos. Va a mantener una serie de propiedades como son la posibilidad de admitir transacciones, el usuario y password, etc.

21

CAD (Componente Acceso Datos): Componente que nos proporciona la posibilidad de realizar una conexin fsica con la fuente de datos. Dicho puente puede admitir conexiones remotas (TCP/IP...), ser estandar (JDBC,ODBC....), admitir BDOO o BDR o Legacy. b) Subsistema fsico de Datos Este subsistema determina cuales van a ser las fuentes fsicas de datos que va a contener nuestro sistema. Dichas fuentes son de diversa naturaleza, y pueden estar distribuidas de forma local o remota dependiendo del tipo de puente utilizado. Los elementos que nos podemos encontrar son los siguientes: Almacen: Gestor donde almacenamos la informacin de nuestro sistema de informacin. Puede ser de diferentes tipos: Relacional: Base de Datos Relacional, compuesta por un conjunto de tablas relacionadas y mediante un lenguaje de consulta SQL que nos facilita el acceso a los datos. Orientado Objetos: Base de Datos Orientada a Objetos, ms sofisticada que la relacional puesto que no solo permite el tratamiento de los datos, sino que proporcionan un lenguaje propietario que posibilita la definicin de lgica de negocio a este nivel. Ficheros Planos: Base de datos que gestiona ficheros fisicos, ya sea con un formato propio o estndar (XML). Legada: Sistema legado que nos proporciona datos de un sistema existente y sobre el cual vamos a acceder para el funcionamiento del sistema. Funcional: Funciones localizadas a un nivel dependiente del gestor de base de datos, pueden tratarse tanto de procedimientos almacenados en el lenguaje del propio gestor o en XML.

3.2.3 Definicin de los tipos de conectores Existen diferentes 3 tipos de conectores cada uno de los cuales indica una relacin diferente entre componentes o mdulos: Invocacin Remota: Llamada que realiza un componente a otro elemento del diagrama de forma remota, es decir, soporta una distribucin en nodos fsicos diferentes (HTTP,TCP/IP,SMTP). Invocacin Remota Segura: Llamada que realiza un componente a otro elemento del diagrama de forma remota y adems utilizando un protocolo seguro (p.e. HTTPS, IMAP/SSL, SMTP/SSL, etc.) Invocacin local: Llamada que realiza un componente a otro elemento del diagrama de forma local, es decir, dichos elementos han de residir en el mismo subsistema.

22

Construir (build):Identifica que componente pgina servidora es responsable de la creacin de uno o ms componentes pgina cliente, o funcional o estilo. Es una relacin direccional puesto que solo los componentes pgina servidora tiene conocimiento de los componentes cliente y no al contrario. Contiene (Include):Relacin que se establece entre dos componentes en el que el primer componente contiene al segundo. Relacin definida por [Conallen99] para vincular una pgina template con las pginas que referencia. 3.2.4 Ejemplo Diagrama del Modelo de Composicin de Componentes Web Una vez hemos definido cuales son los elementos que componen el diseo modular, a continuacin vamos a mostrar un ejemplo de un diagrama utilizando la notacin UML que hemos proporcionado para cada elemento.

<<Presentation>> P1 <<Browser>> 1..1 0..n B1 <<remote>> <<Cl ient PageWD>> PC1 1..n 1..n <<rem ote>> 1..n

<<Functional Page>> FP1

1.. 1 <<Style Page>> <<rem ote>> SP1 1..* 1..1 <<build>>

<<rem ote>>

1 <<ControlWD>> CWD1 1..1 <<local>> 1..n

<<Dialog Control>> D1 <<SessionWD>> S1 1..1 <<local>> 1.. n

1..1 <<Server PageWD>> SWD1

<<Model>> 1..n 1..n <<ViewWD>> M1 VWD1 <<local>> 1..n

1..n <<local>> 1..n

<<rem ote>> 1..n <<Session S tatel ess>> SS1 0..n

<<Business Logic>> BL1 <<Distributed Entity>> E1 <<BLFunc tional >> BLF1

0..*

0..*

0..n

0..1 <<local>>

<<local>> 0.. n <<DAC>> DAC2

<<local>>

<<DAC>> DAC1 1..n

<<remote>> 1..n <<Persistence>> Pers1 <<rem ote>> 1..1 <<Pool>> 1..1 1..1 1..n <<DataSource>> Pool1 DS1 <<local>> 1..n

1..1 <<remote>>

<<Relational DB>> DB1

Figura 10. Modelo de Composicin de componentes de la aplicacin de Telecomercio. 23

3.3 Diagrama de Integracin de Componentes

Una vez hemos identificado en los modelos anteriores la arquitectura de la aplicacin, se hace necesario vincular la parte no funcional recogida a travs de los diagramas de arquitectura anteriores con la parte funcional de la aplicacin, recogida a travs de los diagramas de procedentes de las fases de anlisis. Existen aproximaciones que defienden la idoneidad de esta aproximacin pues postulan que es la nica manera en la cual se puede recoger todos los requisitos que una aplicacin exige. Entre los componentes definidos en el DDC pertenecientes al dominio de las aplicaciones web, existen algunos que tienen una vinculacin estrecha con la parte funcional, el caso ms claro es el caso componente modelo de la parte de control de usuario, dicho componente contiene la funcionalidad de una o ms clases, las cuales estn expresadas en el modelo conceptual y de proceso de la aplicacin en la parte del cliente. Esta vinculacin de los componentes nos va a proporcionar un mapeo por defecto que dar como resultado un modelo sin refinar de la integracin de la arquitectura y funcionalidad expresada hasta este momento. Sin embargo, en muchas ocasiones esto no es suficiente, como hemos comentado anteriormente, existen requisitos que solamente podemos recogerlos cuando involucramos tanto a la arquitectura como a la funcionalidad. Por ejemplo, poder definir la granularidad de los componentes que se encuentran en la capa de la lgica de negocio, es decir, cual va a ser la funcionalidad que va a contener dichos componentes. Dicha propiedad va a influir enormemente en el rendimiento de la aplicacin, y solo lo podramos fijar correctamente si integramos ambas partes. En resumen, el diagrama de integracin presenta las siguientes propiedades: 1. Recoge requisitos que implican tanto aspectos funcionales como no funcionales. 2. Es dependiente de aplicacin, ya que representa los componentes del dominio de las aplicaciones web para una aplicacin en concreto. 3. Es independiente de plataforma de manera que dicho modelo puede servir para generar cdigo sobre diversas implementaciones. Es segn la especificacin MDA un modelo PIM (Platform-Independent-Model). 4. Reduce drsticamente el tiempo de modelado ya que se nos proporciona un modelo por defecto gracias al mapping que nosotros debemos refinar. 5. Respecta las restricciones establecidas por los modelos de arquitectura abstractos. 3.3.1 Constructores En este diagrama nos vamos a encontrar con los siguientes constructores: a) Componente Concreto (CCAW) Unidad ms pequea dentro del modelo de integracin, y representa a un componente software dentro del dominio una aplicacin web. Es la instanciacin de un componente abstracto del tipo definido en el modelo de composicin de componentes y recoge la funcionalidad completa que dicho componente aportar al sistema. Se encuentra al mismo nivel de abstraccin que un componente del perfil EDOC.

24

A diferencia de los componentes abstractos definidos en el modelo MCC donde los componentes de diferentes tipos nicamente realizaban tareas identificadas como comunes en el dominio de las aplicaciones web, un componente de este nivel contiene toda la funcionalidad del componente software. Adems presenta la caracterstica fundamental de ser independiente de dispositivo, es decir, soporta n implementaciones, tantas como plataformas sean capaces de reproducir su funcionalidad, lo que nos otorga un mayor nivel de reutilizacin, y por otro lado, dota de mayor portabilidad a un sistema.

Propiedades: a) Tipo: Al igual que en nivel abstracto dicho tipo sigue representando la tarea que dicho componente software realiza en la aplicacin web. Un componente dentro del dominio de una aplicacin web podra ser desde una pagina, a un componente de servidor, a un componente de control, etc. b) Servicios: Son aquellas operaciones ofertadas por el componente definidos por el tipo del componente y por el dominio de la aplicacin. Dichos servicios son obtenidos a travs del mapeo con la parte funcional del sistema. c) Interfaz: Representa un subconjunto de los servicios pblicos definidos por el componente dentro del dominio de la aplicacin, que dicho componente oferta al resto del sistema para poder ser invocados. Se reduce as el nivel de dependencia entre un componente y otro cuando la relacin se establece a travs de su interfaz y no del mismo componente. A dicho interfaz vamos a representarlo mediante la notacin lollipop de UML.

Representacin UML: El componente concreto de aplicacin web se representa tambin como un estereotipo de la clase UML. Dicha clase va a contener un conjunto de servicios que va a ofertar el componente, dichos servicios va a ser operaciones de la clase que van a poder ser invocadas desde otros componentes. Un ejemplo del componente carrito de nuestra aplicacin de telecomercio: <<MODEL>>
CARRITO Interfaz

S1. AadirItem (articulo) S2. BorrarItem (articulo) S3. MostrarTodosItems

Figura 11. Ejemplo del componente concreto del tipo Model.

25

b)Mdulo (MAW): Es el conjunto de uno o ms elementos concretos del mismo tipo dentro de una aplicacin web, dichos elementos son mdulos, componentes y conectores. Su funcionalidad es la de agrupar la funcionalidad de un conjunto de elementos reduciendo as la complejidad de modelado. Se genera a partir del proceso de refinamiento de un componente abstracto cuya cardinalidad es mayor que 1, que al realizarse la integracin da lugar a un conjunto de componentes del mismo tipo, los cuales sern contenidos por dicho mdulo. Representacin UML: Se especifica mediante un estereotipo de paquete UML llamado <<ModuleMIC>>, de manera que es modulo puede ser utilizado para contener componentes de cualquier tipo definido.

c) Conector Concreto (CCWA) Relacin establecida entre dos componentes o mdulos concretos del sistema. Es la instanciacin de una relacin de dependencia definida en el modelo abstracto de arquitectura. Influyendo en el mapeo la cardinalidad definida en el conector abstracto y las relaciones establecidas en el metamodelo entre los tipos de los componentes abstractos y la parte funcional, obteniendo as un conector perteneciente al del dominio de la aplicacin. Por ltimo indicar que dicha relacin cuando representa una invocacin, se establece con un determinado servicio pblico del componente destino, ya sea sobre el mismo componente o sobre su interfaz lo que indicara un nivel de acoplamiento menor. Propiedades: c. Tipo: Indica el tipo de relacin establecida entre los dos componentes o mdulos concretos. Cada uno de estos tipos va a indicar si se trata de una tarea de invocacin, construccin (build), si es remota o local (admite llamadas entre dos nodos diferentes de la arquitectura fsica), etc. d. Servicio: En aquellas relaciones del tipo invocacin local o remota que representan invocaciones de uno a otro componente dicho conector puede identificar el servicio que invoca en el componente destino. Representacin en UML: En este caso cada uno de los tipos va a venir representada por un estereotipo de la relacin de dependencia.

26

3.3.2 Mapeo por defecto del modelo Abstracto de Componentes al modelo Concreto de Componentes. Derivado de las relaciones de dependencia establecidas en el metamodelo entre los componentes abstractos del dominio de las aplicaciones web con los elementos de la parte funcional definidos en OO-H, viene representado en la figura 2. Vamos a obtener un mapeo por defecto, basndonos en aproximacin que propone MDA, en el cual vamos a indicar cuales son los elementos concretos que obtendramos de forma automtica sin hacer ningn tipo de refinamiento. Dicha propuesta viene definida adems por un conjunto de reglas de transformacin que van a proponer un mapeo de la funcionalidad dentro del componente, dichas reglas de transformacin van a intentar basarse en patrones de arquitectura de cada una de las capas, y de esta manera puede servir como punto de referencia para personas poco expertas en el diseo de aplicaciones web. Esta propuesta por defecto nos va ayudar fundamentalmente a acelerar el proceso de modelado del software, de manera que nos concentraremos fundamentalmente en recoger aquellos requisitos que se localizan en esta capa y que implican que las partes funcional y no funcional del sistema estn integradas.

Vista Funcional Modelo Subsistemas Modelo Proceso Modelo NAD Modelo Conceptual

Modelo Presentacin

Modelo MCC

Modelo Integracion de Componentes

Figura 12. Modelo dependencia entre los diferentes modelos. Una de las caractersticas claves de MDA es la nocin de mapeo. Un mapeo es un conjunto de reglas y tcnicas usadas para modificar un modelo de manera que obtengamos otro modelo. Uno de los mapeo definidos en MDA son los usados para transformar, PIM a PIM, es decir cuando dos modelos independientes de plataforma se encuentran en diferentes niveles de abstraccin, y el segundo es mejorado, filtrado o especializado durante el ciclo de vida del desarrollo del software. Este es el caso de

27

nuestro mapeo en el cual estamos mapeando entre varios modelos los cuales se encuentran en diferentes niveles de abstraccin y uno deriva de los otros. 3.3.3 Proceso del Mapeo Partiendo del modelo abstracto de componentes web, vamos a analizar cada uno los componentes, que tienen una relacin con la parte funcional del sistema, p.e. pagina cliente, control, y expresar cual sera su mapeo dentro del modelo concreto de componentes web. Siguiendo el ejemplo del modelo de Telecomercio, vamos a tomar el componente Control para ver como sera su refinamiento por defecto. Si considerbamos que dicho componente control tiene una cardinalidad de 1 dentro del modelo, eso quiere decir que va a convertirse en un componente concreto directamente. El diagrama de refinamiento sera el siguiente:
<<Navigational Link>> NewClass4 0..n 0..n 0..1

<<OperationOOH>> NewClass 2 <<ControlAWD>> Control1

0..n

0..1

0..n

{derived}

<<refine>>

{derived}

0..1

<<ControlCWD>> Control2

0.. 1

Figura 13. Ejemplo de refinamiento del Componente Concreto Control. Para este componente definimos las siguientes reglas de transformacin: 1. Para las operaciones OO-H defino un servicio en el componente CWD llamado recibirPeticionServicio. 2. Para los link navegacionales defino un servicio en el componente CWD llamado recibirPeticionNavegacion. 3. Para cada operacin realizo una llamada local al componente modelo (si existe) o sesion o entitad. De forma que establezco la prioridad en este orden. 4. Para cada link navegacional realizar una llamada a una pgina servidora o cliente que sea el destino navegacional. En nuestro caso de ejemplo de Telecomercio, vamos a ver como se mapean del modelo abstracto de componentes al modelo de integracin de componentes, la capa de control de dilogo. En la figura XXX, vemos como siguiendo las reglas de mapeo vamos a obtener los diferentes elementos:

28

<<ControlACW>> CWD1 {card=1} 1..1 <<local>>

1..1

<<Dialog Cont rol>> D1 <<local>> <<WebSessionACW>> S1 {card=1}

1..n <<local>> 1..n 1..1

<<Server PageACW>> SWD1 {card=*} 1..n <<local>> 1..n <<ViewACW >> VWD1 {card =1}

0..1 1..n 0..n <<local>> <<ModelA CW>> 1.. n M1 {card=*}

1..n <<local>>

<<Dialog Cont rol>> <<ControlCCW>> CCW 1 recibirPeticionServicio() recibirPeticionNavegacion() <<local>> <<W ebS essionCCW>> S11 AnyadirObjeto() BorrarObjeto() ObtenerObjeto() <<local>> <<ModuleMIC>> ModuleM odel1 <<ViewCCW>> VCCW1 <<local>> Server Page Module WebSite

<<local>>

<<local>>

Figura 14. Mapeo entre el MDC y el MIC. Como vemos cuando realizamos el mapeo, las cardinalidades de los componentes concretos se pierden ajustndose a la funcionalidad, y en el caso de que se presenten ms de un componente del mismo tipo, dichos componentes se renen en un modulo de dicho tipo. Viendo con ms detalle el mapeo realizado en dicha capa, vamos a ver el contenido del modulo de componentes Model figura 13, esterotipado con el nombre <<ModuleMIC>>, indicando que se trata de un mdulo del diagrama de integracin de componentes. Como vemos establecen las relaciones entre cada uno de los componentes que integran el paquete Model, y con los componentes de los dems paquetes con los cuales se ha establecido igualmente una relacin de dependencia.

29

<<ControlCCW>> CCW 1
(from Logical Vie w)

recibirPeticionServicio() recibirPeticionNavegacion()

<<local>> validarCliente <<ModelWeb>> Cliente CrearCliente() BorrarClient e() ValidarCliente() Obt enerCliente()

Nuevo Carrito <<local>> <<local>> GenerarPedido <<ModelWeb>> Carrito Nuevo Carrito() AnyadirItem() BorrarItem() MostrarTodosItems() GenerarPedido() <<local>> Anyadir Objeto

CrearPedido

<<ModelWeb>> Pedido CrearPedido()

<<WebSessionCCW>> S11
(from Logical Vie w)

AnyadirObjeto() BorrarObjeto() ObtenerObjeto()

Figura 15. Contenido del modulo Model del modelo MIC.

3.3.4 Proceso de refinamiento El proceso de mapeo automtico nos a generado un modelo que en algunos casos podramos considerar vlido, pero en otras ocasiones puede resultarnos insatisfactorio. Por ejemplo, el hecho de que generemos en el mapeo por defecto en un componente entidad una operacin por cada operacin OO-H definida en la clase conceptual, puede ser poco recomendable en aquellos casos donde se trate de un alto nmero de servicios y obtuviramos as un componente demasiado pesado que afectara al rendimiento del sistema. Se hace necesario en la mayora de los casos un proceso de refinamiento en el cual se capturen aquellos requisitos de usuario que no hemos podido recoger en fases anteriores. Los procedimientos ms tpicos de refinamiento que podremos realizar con este modelo son los siguientes: 1. Integracin de funcionalidad en componentes: Integramos la funcionalidad que estaba repartida en 2 o ms componentes, en un solo componente reduciendo as el nmero de invocaciones entre componentes. 2. Divisin de funcionalidad de componentes: Dividimos la funcionalidad localizada en un solo componente y la repartimos en 2 o ms componentes. 3. Cambios de invocacin de componentes: Puede venir consecuencia de otros cambios de refinamiento, o puede derivarse de un cambio de la arquitectura en algunos casos particulares del dominio del problema. Por ejemplo, si queremos

30

que para la clase carrito, el componente model en lugar de llamar a la lgica de negocio, resuelva la operacin en la capa de control de dilogo. 4. Supresin de componentes: Queremos que un componente concreto no nos parezca adecuado para nuestra arquitectura ya sea porque no es necesario, p.e. el componente entidad de carrito, o porque se deriva de un cambio de integracin. 5. Creacin de nuevos componentes concretos: Queremos crear un componente ya sea porque necesitamos aumentar la funcionalidad o porque simplemente se deriva de un cambio de divisin.

31

5. Referencias
[Bass97] Bass, Clements, and Kazman. Software Architecture in Practice, AddisonWesley 1997. [Bass00] Bass, L., Klein, M., Bachmann, F. Quality Attribute Design Primitives CMU/SEI-2000-TN-017, Carnegie Mellon, Pittsburgh, December, 2000 [Bell98] Bell R.(1998) Code Generation from Object Models. Embedded Programming Systems Journal, March, 1998. [BMR+96] Frank Buschman, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal: Pattern-Oriented Software Architecture A System of Patterns; John Wiley & Sons Ltd. Chichester, England, 1996 [Booch01] Grady Booch: The Architecture of Web Applications. DeveloperWorks: IBM developer solutions. June 2001. [Coglianese92] L. Coglianese, W. Tracz: Architecture-Based Development Process Guidelines for Avionics Software, Technical Report ADAGE-IBM-92-02, IBM Federal Systems Company, Dec. 1992. [Conallen99] Jim Conallen. Building Web Applications with UML. Adisn Wesley Longman. December 1999. [Dun90] R. H. Dunn: Software Quality - Concepts and Plans, Prentice-Hall, 1990. [Hassan02] Admed E Hassan, R.C. Holt. Architecture Recovery of Web Applications. ICSE02, May 2002. [Hoffmann96] Christoph Hofmann, Eckart Horn, Wolfgang Keller, Klaus Renzel, Monika Schmidt. The field of software architecture. November 96. [Hofmeister99] C. Hofmeister, R. L. Nord, D. Soni. Siemens Corporate Research, Princeton, New Jersey, USA.. 1999 [Kruchten95] Kruchten, P. (1995) The 4+1 View Model of Architecture, IEEE Software. [OMG01] Model-Driven Architecture (MDA) Home Page: http://www.omg.org/mda/index.htm [OMG02] UML Profile for Enterprise Distributed Object Computing Specification. Febrary 2002. [Nilson94] Nilson, Roslyn; Kogut, Paul; & Jackelen, George Component Provider's and Tool Developer's Handbook Central Archive for Reusable Defense Software (CARDS). STARS Informal Technical Report STARS-VC-B017/001/00. Unisys Corporation , March 1994.

32

[NoSc99] J. Noack, B. Schienmann: Introducing Object Technology in a Large Banking Organization, IEEE Software, May 1999, 71-81 [Schwabe99] Schwabe, D., Almeida, R., & Moura, I. 1999a. Leveraging Templatebased Website Implementations Using Design Methods. In: 8th International World Wide Web Conference. [UML 2003] UML 1.5 Standard, OMG (2003). www.omg.org

33