Aplicación de MDA al Desarrollo de Aplicaciones Web en OOWS Ricardo Quintero1, Vicente Pelechano2, Joan Fons2, Oscar Pastor2 1

Departamento de Sistemas y Computación Instituto Tecnológico de Culiacán Juan de Dios Bátiz s/n, Col. Guadalupe, 80220 Culiacán, Sinaloa, México [email protected] 2 Departamento de Sistemas Informáticos y Computación Universidad Politécnica de Valencia Camino de Vera s/n, 46022 Valencia, España {pele, jjfons, opastor}@dsic.upv.es

Resumen. El presente trabajo propone una aplicación de la propuesta MDA (Model Driven Architecture) de OMG para el modelado y desarrollo de aplicaciones Web siguiendo el método OOWS. El trabajo introduce MDA, sus tecnologías fundamentales y los conceptos básicos que la soportan, incluyendo un modelo del proceso de desarrollo en MDA y su aplicación a OOWS. Esta propuesta define el metamodelo PIM-OOWS y propone un metamodelo PSM-OOWS basado en tecnología J2EE. Como resultado final se propone un conjunto de correspondencias entre artefactos PIM y artefactos PSM (J2EE) proporcionando una técnica de generación de código basado en modelos bien definida.

1. Introducción. En los últimos años se observa una tendencia importante a reconocer que las aplicaciones basadas en el Web deben expresarse a un nivel de abstracción mayor que aquél que ofrecen las primitivas propias de las plataformas tecnológicas. En esta dirección y en el contexto de la Ingeniería Web se están desarrollando propuestas de modelado de las cuales podemos destacar dos vertientes importantes: La que parte del modelado conceptual basado en modelos relacionales que no definen comportamiento, y que se extienden para la especificación de espacios hipermediales, tales como HDM, [6]; WebML, [2]; ADM, [1] y RMM, [13]; y la que parte de modelos orientados a objetos, cuya expresividad se extiende para la especificación de espacios hipermediales, tales como: OOHDM, [25]; OOWS, [23] y OO-H method, [22]. OMG en los últimos años ha reconocido que el enfoque de modelado es una forma potente de especificar sistemas y así lo demuestra su estrategia Model Driven Architecture (MDA) con la cual se busca ofrecer al diseñador la posibilidad de expresar la estructura, comportamiento y funcionalidad del sistema independientemente de los aspectos tecnológicos y lograr con ello además la posibilidad de fácil integración con otros sistemas. OOWS, definido como una extensión de OO-Method [20], ha sido concebido como una aproximación metodológica centrada en el modelado de aplicaciones web, por lo que puede ser un candidato idóneo para la aplicación de la propuesta MDA. Aprovechar lo mejor de los dos enfoques es ventajoso: Por un lado, la potencia expresiva de OOWS para modelar el Web; y por otro, las capacidades de integración e implementación multiplataforma que propone MDA, se pueden combinar y obtener soluciones que, tal como lo promete éste último, funcionen “hoy y en el futuro” y puedan ser más fáciles de verificar, integrar e implementar. El presente trabajo propone una aproximación a la aplicación de MDA para el desarrollo de aplicaciones Web en OOWS. Se organiza de la siguiente manera: en la sección 2 se ofrece una perspectiva de la estrategia de OMG para el desarrollo de aplicaciones basado en modelos. Se define MDA, sus tecnologías fundamentales y conceptos básicos sobre los que se soporta, incluyendo un modelo del proceso de desarrollo en MDA. La sección 3 muestra la estrategia de aplicación de MDA a OOWS definiendo el alcance del trabajo actual. Define lo que sería el metamodelo PIM-OOWS y propone un metamodelo PSM-OOWS basado en tecnología J2EE [9]. A su vez introduce las correspondencias desde artefactos PIM hacia PSM. Finalmente, la sección 4 ofrece conclusiones y trabajos de investigación futuros.

1

2. MDA. La estrategia de OMG para el desarrollo de aplicaciones basado en modelos. 2.1 Motivación. OMG (Object Management Group [18]) ha sido desde sus inicios una corporación que se ha comprometido en la creación de especificaciones “independientes del vendedor” para la industria del software. Básicamente la misión de OMG ha seguido siendo la misma a lo largo de los últimos años: “Resolver el problema de la integración e interoperabilidad”, [16]. CORBA [4] fue la primera propuesta para ello. Sin embargo a partir de 1997 OMG ha emitido un conjunto de especificaciones, no basadas en él, que amplían las posibilidades de la solución a la problemática planteada y que incluyen, en un principio, al Lenguaje de Modelado Unificado (UML), [26]; y a la Facilidad de Meta Objetos (MOF), [17]; y posteriormente, al Intercambio de Metadatos XML (XMI), [27] y el Metamodelo Común de Almacenes de Datos (CWM), [5]; dando a la propuesta original de solución una visión nunca antes abordada por el organismo: se introduce MDA con la intención de resolver el problema de la integración y la interoperabilidad a partir de un enfoque dirigido por modelos, en el cual el actor principal para lograrlo no sean interfaces estándar de componentes, sino modelos formales de sistemas, con lo cual se posibilita la independencia de la especificación del sistema de la implementación tecnológica o plataforma. Esto da origen a MDA (Model Driven Architecture). 2.2 Perspectiva del MDA. MDA puede explicarse a partir de las tecnologías que lo comprenden y sus interrelaciones. La Fig. 1 muestra su arquitectura, tal como la define la OMG.

Fig. 1. La Arquitectura Dirigida por Modelos de OMG

En la parte central se ubican las tecnologías estándar para modelado que introduce OMG: UML, MOF y CWM. En base a estos estándares se construyen los modelos centrales de las aplicaciones, los cuales comprenden aquellos que representan la Informática Empresarial así como los que representan la Informática de Tiempo Real. Estos modelos deben ser independientes de cualquier plataforma middleware y representan las características comunes de todas las plataformas en su categoría. En términos técnicos, deberán de ser un Metamodelo de la categoría y en términos de MDA se llaman perfiles UML. [16]. El siguiente anillo del modelo MDA muestra plataformas tecnológicas específicas. Estas plataformas también se modelan usando perfiles UML. Como se observa en la Fig. 1, se pueden tener perfiles para diversas plataformas middleware: CORBA, XMI/XML, .NET, Java, Web, etc. Una vez que se define la funcionalidad y el comportamiento de la aplicación mediante un modelo independiente de plataforma deberá transformarse a alguno de estos modelos de plataforma tecnológica. A continuación se genera el código de la aplicación. Esto se realiza a partir del modelo específico de la plataforma. Cuanto de forma más precisa sea modelada la semántica de la aplicación y más completo sea el perfil UML que refleja el ambiente de la plataforma, más completo será el código que se generará. El posterior anillo en el modelo son los servicios “Pervasive”. Éste es un conjunto de servicios esenciales disponibles para cualquier Computación Empresarial, de Internet o Incrustada, que incluye los de Directorios, Manejo de Eventos, Persistencia, Transacciones y Seguridad. Finalmente tenemos la estandarización de servicios y mercados verticales específicos en la cual han estado trabajando desde enero de 1996, para su definición los “Domain Task Forces (DTF)”. Para maximizar la utilidad e impacto de las facilidades de especificación de dominios en MDA, éstas se realizan mediante modelos UML independientes de plataforma junto con modelos específicos de plataforma y definiciones de interfaz para al menos una plataforma destino.

2

2.3 Conceptos básicos de MDA. 2.3.1 Modelo. En MDA un modelo es una representación de una parte de la función, estructura y/o comportamiento de un sistema, [19]. Para que un modelo sea determinado de forma precisa es necesario una especificación. La especificación de un modelo en MDA debe utilizar un lenguaje que posee una sintaxis (forma), que puede ser gráfica o textual; una semántica (significado) y posiblemente un conjunto de reglas de análisis, inferencia o prueba para sus elementos componentes. MDA aborda la especificación de sus modelos utilizando las facilidades que existen en el UML: su metamodelo, el lenguaje de restricciones para objetos (OCL) y las capacidades de extensión mediante estereotipos y valores etiqueta. 2.3.2 Metamodelos y el Marco de Trabajo de Metamodelos. Los modelos en sí mismos pueden ser considerados como un dominio cuyas características pueden abstraerse en otros modelos llamados metamodelos. Un metamodelo es un modelo cuyo dominio consiste de modelos. Los metamodelos describen la sintaxis y la semántica de los modelos. La ISO [14] y la CDIF [3] han definido arquitecturas organizadas en capas para el metamodelado las cuales son la base para la especificación MOF que se utiliza en MDA [17]. 2.3.3 Arquitectura de los modelos MDA. Una aplicación desarrollada con MDA se construye a partir de la definición de dos aspectos básicos: 1. 2.

La estructura y comportamiento del sistema. La plataforma tecnológica donde será implementada.

Ambos aspectos se especifican utilizando respectivamente un par de modelos: El Modelo Independiente de la Plataforma (PIM) y el Modelo Específico de Plataforma (PSM). Ambos se expresan mediante OCL y los mecanismos de extensión del UML. Las correspondencias entre estos modelos se establecen mediante técnicas de correspondencia entre los metamodelos que los definen. 2.3.4 Modelo de proceso de desarrollo de software MDA. OMG no propone un modelo estándar de desarrollo de software para MDA. Desde nuestra óptica tal modelo es necesario ya que permitirá organizar los pasos necesarios para el desarrollo del software de una forma definida, sistemática, y repetible. Previo a la definición del ciclo de desarrollo de software se deberían realizar las siguientes actividades: 1. Identificar los aspectos estructurales y de comportamiento del dominio de la aplicación y definir el perfil UML que permita expresar cualquier modelo del mismo en un PIM. Este perfil UML sería el metamodelo del dominio. 2. Identificar la plataforma –o plataformas- tecnológica destino y definir el perfil UML que permita expresar su posterior modelo en un PSM. 3. Definir las Técnicas de correspondencia entre los metamodelos PIM y PSM. Estás Técnicas de correspondencia se deben definir en términos de transformaciones de los elementos de los metamodelos más abstractos PIM hacia el metamodelo más concreto PSM. 4. Para cada una de las Técnicas de correspondencia definir los Modelos de Información complementaria Requeridos y Provistos, buscando, con el primero definir sin ambigüedades la correspondencia y preservar la semántica del nivel de abstracción más alto y proveyendo a los niveles más bajos de abstracción los aspectos necesarios para su final implementación. 5. Implementar las Técnicas de correspondencia ya sea manualmente o asistida mediante una herramienta CASE de soporte. El ciclo de desarrollo de software estaría definido, iteración a iteración, por los pasos definidos en el diagrama de actividad de la Fig. 2. Primero se diseña el PIM que expresa la estructura y comportamiento de la aplicación. Se aplica la técnica de correspondencia para transformar el PIM en el PSM. Si la técnica de correspondencia requiere información complementaria requerida o provista ésta se agrega. Una vez obtenido el PSM este pudiera estar o no lo suficientemente refinado para ser susceptible de implementación tecnológica. Si no es así, se busca volver a transformar para lograr lo mismo de lo contrario a la plataforma tecnológica, obteniendo el producto software final.

3

Diseñar el PIM de la Aplicación

Aplicar la Técnica de correspondencia PIM-PSM ¿Req uiere Información complementaria adicional?

Ag reg ar Información complementaria requerida al PIM ¿No req uiere Información complementaria adicional?

Obtener el PSM sin Información complementaria provista

¿Req uiere Información complementaria provista?

Agregar Información complementaria provista

¿No req uiere Información complementaria provista?

Obtener el PSM correspondiente al PIM

¿El PSM está lo suficientemente refinado para implementación tecnológica?

Hágase el PSM actual como el PIM del siguiente paso

¿El PSM no está lo suficientmente refinado para implementación tecnológica?

Refinese el PSM a la plataforma tecnológ ica

Fig. 2. El modelo del proceso de desarrollo de software de MDA

3. Aplicación de MDA a OOWS. 3.1 Motivación. Desde sus inicios, OO-Method, de quién proviene OOWS, se creó como un método de desarrollo basado en modelos, convencidos de que esta estrategia ofrece el nivel de abstracción adecuado para expresar los aspectos del dominio del problema. OOWS hereda esta filosofía y, extiende las técnicas de modelado conceptual de OOMethod con capacidades de expresión hipermedial para ofrecer al diseñador también un enfoque dirigido por modelos para el modelado conceptual de aplicaciones Web. Una vez que se ha definido el espacio del problema en términos de modelos, un conjunto de patrones de traducción permiten establecer correspondencias entre las primitivas conceptuales del espacio del problema a elementos software del espacio de la solución que definen la presentación de las aplicaciones Web. Lo que MDA define como el Modelo Independiente de la Plataforma (PIM) es, en esencia, lo que OOWS define como el Modelo conceptual del espacio del problema. Lo que MDA define como Técnicas de correspondencia, es lo que OOWS define como Patrones de traducción. Y lo que MDA define como el Modelo Específico de la Plataforma (PSM) se relaciona con los elementos software que OOWS define como parte del espacio de la solución. En definitiva, se considera factible establecer una aplicación de MDA para OOWS que proporcione una transición automatizable del espacio del problema al espacio de la solución. 3.2 Proceso básico para la aplicación de MDA a OOWS. Los pasos que comprenden la aplicación de MDA a OOWS son los siguientes: 1. 2. 3. 4.

Se diseña el metamodelo PIM-OOWS expresado como un perfil UML cuya semántica se amplia a través del mecanismo de extensión de estereotipos. Esto define el espacio del problema. Se diseña el metamodelo PSM-OOWS J2EE. Se ha seleccionado la plataforma tecnológica J2EE [Java2] para la definición de su perfil UML. Esto define el espacio de la solución. Se definen las correspondencias entre los metamodelos PIM OOWS y PSM J2EE. Esto define los patrones de traducción desde el espacio del problema hacia el espacio de la solución. Se define una Arquitectura software para la plataforma tecnológica.

4

A continuación se detallan cada uno de los metamodelos anteriores, ejemplificándolos con fragmentos del Mapa Navegacional que ha sido establecido para el caso de una venta de discos a través de Internet (“Disco Web”) de [21]. 3.3 El metamodelo PIM-OOWS. La Fig. 3 muestra el perfil UML que expresa el metamodelo PIM-OOWS. Se establece sobre la definición de las primitivas conceptuales que comprenden al Mapa navegacional de OOWS. 1

Agente

Mapa Nav egacional +Falso

+Destino +Verdadero 0..*

1..* Contexto de Nav egación

Vínculo de Nav egación

+Destino 0..1

Nombre

1

+Origen

0..*

Área de características Av anzadas

+Destino

1

Patrón de presentación Cardinalidad Campo de ordenación Tipo de ordenación

Área de def inición de contexto Tipo

1 Área de Nav egación

Restricción de Nav egación Condición 1

1..* Relación

0..*

Clase Nav egacional

*

Sin semántica navegacional

Vista de

0..* Relación de Contexto

1

0..*

/ Atributo de Contexto Atributo de Filtro Se define por Tipo de Filtro (E/R/A) / Atributo de rol Atributo de enlace

*

Clase Directora

Relación de Dependencia Contextual

Nombre Filtro

0..*

Clase Complementaria

0..*

Sin semántica navegacional

1

Se define sobre

0..*

Nombre

Con semántica navegacional

Clase OO-Method (from Metamodelo breve OO-Meth...

Nombre

1..*

1..*

Atributo

Operación

Nombre Tipo

Nombre Parametros

Relación Estructural (from Metamodelo breve OO-Meth...

1..*

Vista de

Vista de Atributo (from Metamodelo breve OO-Meth...

Nombre

0..*

Operación (from Metamodelo breve OO-Meth...

Nombre Parametros

0..*

Fig. 3. Metamodelo PIM-OOWS.

El metamodelo PIM-OOWS captura la definición del Mapa navegacional de OOWS [23]: 1. Por cada agente del espacio hipermedial se define un Mapa navegacional. 2. El Mapa navegacional está compuesto por uno o más Contextos de Navegación, que definen la vista hipermedial que el agente posee del Modelo conceptual. 3. Los Contextos de Navegación se componen por tres áreas: a. De Definición de contexto, cuyo tipo puede ser de Exploración o Secuencia. El primero puede ser alcanzado en cualquier momento independientemente del contexto actual; el segundo sólo a través de una secuencia de vínculos de navegación. b. De Navegación, donde se define la vista del modelo conceptual subyacente. c. De Características Avanzadas, donde se definen aspectos de presentación de la sociedad de objetos a través de los patrones de presentación Tabular, Maestro-Detalle y Registro. 4. El Área de Navegación está compuesta por Clases Navegacionales, que pueden ser Directora o Complementaria y por Relaciones, que pueden ser de Contexto o Dependencia Contextual. 5. Para cada Clase Navegacional se definen atributos y operaciones, que son vistas de atributos y operaciones de las Clases conceptuales. Las operaciones pudieran tener asociado algún Contexto de Navegación al que se navegaría una vez realizada la operación. 6. La Relación de Contexto puede tener definidos múltiples atributos: De Contexto, Filtro, Rol, Enlace y Restricción de Navegación. 7. Finalmente, las Clases conceptuales poseen atributos, operaciones y relaciones estructurales entre las mismas. 3.4 El metamodelo PSM OOWS-J2EE y su correspondencia con el PIM-OOWS. Cada elemento del metamodelo PIM-OOWS tiene correspondencia con uno o más de los elementos del metamodelo PSM-OOW-J2EE. Éste define un perfil inspirado en las tecnologías Java [8] J2EE: Java Server

5

Pages [10], Enterprise Java Beans [11] y JDBC [12], que se establece mediante estereotipos sobre los elementos de modelado UML. Partiendo de las primitivas conceptuales que se incluyen en el metamodelo Mapa navegacional PIM-OOWS se explica a continuación el metamodelo PSM-OOWS J2EE y las correspondencias respectivas entre ambos. 3.4.1 Del PIM-Contexto de navegación al PSM-Contexto Navegacional. Cada Contexto de navegación del Mapa se implementa como una página Web. En tal página se puede distinguir un componente estático que define el diseño artístico de la página y un componente dinámico que corresponde a los atributos y servicios de la sociedad de objetos subyacente. Así, cada PIM-Contexto de navegación tiene su correspondencia en un PSM-Contexto Navegacional. Cada uno de estos será una página servidora JSP con los componentes estático y dinámico mencionados. En particular, el componente dinámico se establece a partir de un metamodelo fabricación pura [15] , llamado PSM-Definición Dinámica, el cual se explica posteriormente. La Fig. 4 muestra el metamodelo PSM-Contexto Navegacional. La Fig. 5 muestra un ejemplo de página JSP con sus componentes estático y dinámico y que corresponde a la página “Home” de “Disco Web”. Esta página sería el resultado del refinamiento del PSM-Contexto Navegacional a la plataforma J2EE. Componente estático

Contexto Navegacional

1

1..* Etiqueta JSP Definición

Definición Dinámica Nombre Clase Definicion

Componente dinámico

Fig. 4. Metamodelo PSM-Contexto Navegacional Fig. 5 Ejemplo de página JSP PSM-Contexto Navegacional

3.4.2 El PSM-Contexto Navegacional “Home”. El punto de entrada al Mapa navegacional lo define el PIM-Contexto de Navegación “Home”. En el PSMOOWS, éste sería un tipo especial de PSM-Contexto navegacional de Exploración con dos componentes principales: Uno que incluye hiperenlaces al resto de los PSM-Contextos de Navegación de Exploración y otro en el que se incluye una vista del modelo conceptual, cuya organización está definida a partir del patrón de presentación del mismo y que se traducirá a un PSM-Definición dinámica, que se explica más adelante. Link “Categorías”

Definición Dinámica Nombre Clase Definicion

Contexto Navegacional Home

Link “Cesta”

Link “Registrarse”

Link “Autores”

1 1..* Opción Menú Identificador : String = "Link" Valor : String = "URL al "

Contexto Navegacional 1

Fig. 6. Metamodelo de la página PSM-Contexto Navegacional “Home”

Fig. 7. PSM-Contexto Navegacional “Home”

3.4.3 Técnica de correspondencia PIM-Contexto Navegacional “Home” al PSM-Contexto Navegacional “Home”.

6

La Técnica de correspondencia transformaría el PIM-Contexto de Navegación “Home” a un PSM-Contexto Navegacional “Home”, cuya definición es la de una página JSP cuya componente estática está previamente definida en una plantilla y cuya componente dinámica está definida a partir de un conjunto de variables Link que son inicializadas a partir de los valores URL que definen a los Contextos de exploración del Mapa navegacional. Para el caso de “Disco Web” la página “Home” sería generada incluyendo cuatro variables inicializadas de la siguiente manera, ilustrado en la Fig. 7. 1. LinkAutores, inicializado con el valor URL del contexto “Autores”. 2. LinkCategorías, inicializado con el valor URL del contexto “Categorías”. 3. LinkCesta, inicializado con el valor URL del contexto “Cesta”. 4. LinkRegistrarse, inicializado con el valor URL del contexto “Registrarse”. 3.4.4. El PSM-Definición Dinámica. Este PSM establece la definición de la componente dinámica de cada Contexto de Navegación. Para cada posible patrón de presentación se tiene un subtipo de Definición Dinámica: PSM-Definición Dinámica Tabular, PSMDefinición Dinámica Maestro-Detalle y PSM-Definición Dinámica Registro. La Fig. 8 muestra el metamodelo para las metaclases PSM-Definición dinámica que se han comentado. Por razones de espacio, solamente se expone el PSM-Definición Dinámica Tabular, las Definiciones Dinámicas restantes siguen una filosofía semejante. Definición Dinámica Nombre Clase Definicion

Definición Dinámica Tabular

Definición Dinámica Maestro-Detalle

Definición Dinámica Registro

Fig. 8. Metamodelo PSM-Definición dinámica de página JSP

3.4.5. El PSM-Definición Dinámica Tabular. Para el patrón de presentación tabular se define el PSM-Definición Dinámica Tabular. Un objeto PSMDefinición Dinámica Tabular, cuyo metamodelo se muestra en la Fig. 9, tendrá uno o más de los siguientes atributos: • Cardinalidad: que define el número de instancias de la Clase directora a mostrar en la página JSP. • Orden: el cual define el atributo de la sociedad de objetos sobre el que se realizará el ordenamiento de los objetos de la Clase Directora así como el tipo de ordenamiento: ascendente o descendente. • Filtro y Tipo de Filtro: atributo opcional que, si es incluido, especifica un filtro sobre la población de la clase destino de la Clase directora del Contexto actual. Puede incluir un Contexto Navegacional Destino donde la Clase complementaria actual es la Clase directora. • Detalle: representa el cuerpo del detalle de la información tabular, está compuesto a partir de una o más líneas de detalle –una para cada objeto mostrado- y estas a su vez por uno o más campos que pueden incluir valores de atributos o bien operaciones de la sociedad de objetos que se muestra. • Operación get-atributo: el cual ofrece una o más operaciones de consulta para los atributos que se hayan definido para la Definición Dinámica de la página JSP.

7

Definición Dinámica Tabular

1..* Tipo Filtro Nombre : String = "TipoFiltro" Tipo : String = "String" Valor : String = ""

Atributos de Definición Dinámica Tabular Orden

1 1..* Cardinalidad Nombre : String = "Cardinalidad" Tipo : String = "String" Valor : String = ""

Filtro Nombre : String = "Filtro" Tipo : String Campo Orden Nombre : String = "Campo Orden " Tipo : String = "String" Valor : String = ""

VistaOperación Nombre : String = "Operación" Tipo de valor de retorno : String = "" Código : String = "ObjVista.operación(Parametros)"

Modo Orden Nombre : String = "Tipo Orden " Tipo : STring = "String" Valor : String = "" 0..*

Detalle Nombre : String = "Detalle"

1

Parámetro Operación Vista Nombre : String = "" Tipo : String = "" 1

+Tipo Atributo

Clase Detalle Nombre : String = "Detalle"

Atributo Detalle Nombre : String = "Línea"

+Contexto Destino

Contexto Navegacional

1..* +Contexto Destino 1 Atributo Campo Nombre : String = "Campo"

1

1..*

+Tipo Atributo

1 0..1

+Contexto Destino

get Nombre : String = "get" Tipo de retorno : String = "String" Código : String = "return "

1..*

Clase Línea Nombre : String = "Línea"

+Tipo Atributo

Clase Campo Nombre : String = "Campo"

0..1

1

1 Valor Campo Nombre : String = "Valor" Tipo : String = "String"

Inicializa Valor Nombre : String = "getValor" Código : String = "Valor=ObjVista.getVal.Atributo( )"

1

Enlace Nombre : String = "Enlace" Tipo : String = "String" Valor : String = ""

1

Obtiene el valor desde

Hiperenlace del Campo

Fig. 9. El metamodelo PSM-Definición Dinámica Tabular

3.4.6 Técnica de correspondencia PIM-Área de Navegación y PIM-Área de características avanzadas al PSM-Definición Dinámica Tabular. Cada uno de los atributos del PSM-Definición Dinámica Tabular se corresponden con los PIM-Área de Navegación y PIM-Área de características avanzadas de la siguiente manera: • Cardinalidad: obtiene su valor a partir del atributo “cardinalidad” del PIM-Área de características avanzadas. • Orden: toma sus valores a partir de los atributos correspondientes en el PIM-Área de características avanzadas. • Filtro y Tipo de filtro: se inicializa a partir de los Atributos de Filtro y tipo de filtro (Exacto/Rango/Aproximado) del PIM-Relación de Contexto. • Detalle: A partir del PIM-Área de navegación y el PIM-Relación de contexto se define el atributo Valor de campo-i de contexto que es inicializado a partir los atributos de los objetos de las clases Directora y complementaria. Si el diseñador especifica un PIM-Atributo de enlace entre las clases directora y complementaria, se crea el atributo Enlace para incluir el hiperenlace al valor del PIMAtributo de contexto. Finalmente si se define una PIM-Operación se creará una PSM-Operación Vista. Se ilustra lo que sería la Definición Dinámica Tabular del PIM-Contexto Navegacional “Autor” en las Fig. 10 y 11. Def Dinámica Tabular "Autores" Cardinalidad : String = "300" FiltroAutores : String = "nombre" TipoFiltroAutores : String = "E" getCardinalidad() getFiltroAutores() getTipoFiltroAutores()

E

Autores

Relación de Contexto 1

Autor

nombre elementos

Línea "Autores"

Filtro Exacto

{nombre, E} nombre

Atributo de Enlace

1 1

[Detalles_Autor]

Campo "Autores-Nombre" ValorNombre : String Enlace : String:String = ""

Contexto Destino Presentación:Tabular

1..*

Detalle "Autores"

getValorNombre()

Cardinalidad:300

Campo "Autores-Elementos" ValorElementos : String getValorElementos()

Fig. 11. PSM-Definición Dinámica Tabular “Autores”

Fig. 10. PIM-Contexto Navegacional “Autores”

8

3.4.7 El PSM-Vista y el PSM-Gestor de la Vista de . Cada PIM- representan una vista de la sociedad de objetos y tienen su contraparte en el PSM- que se implementa como un J2EE Enterprise Java Beans tipo Entidad. Éste posee atributos y operaciones que se corresponden de forma directa con los atributos y operaciones del PIMClase Navegacional. Adicionalmente cada PSM- tiene asociado un PSM-Gestor de la Vista de que tiene como objetivo implementar las tareas de creación, destrucción, búsqueda –por diferentes criterios- y actualización. Este Gestor representa la implementación de la interfaz “Home” del J2EE EJB Entidad del PSM-. La Fig. 12 muestra el metamodelo PSMVista , incluyendo su Gestor. Para el Gestor también se define un metamodelo PSMGestor de la Vista +Complementaria

+Complementaria

0..* Vista +Directora

Nombre : Stri ng

+Complementaria

Gestor de la Vista de Nombre : Stri ng = "Gestor Vista "

0..* Gestiona la sociedad de objetos de

1 1..* Atributo Nombre : Stri ng Tipo : String

0..* Operación Nombre : Stri ng Parametros : String Tipo de retorno : String

0..1 Contexto Navegacional

Fig. 12. Metamodelo PSM- y su Gestor

3.4.8 Del PIM-Clase conceptual OO-Method al PSM-Clase Conceptual. Cada una de las PIM-Clases conceptuales se refina en un PSM-Clase Conceptual, incluyendo un PSM-Gestor de la Clase conceptual. Cada una de las Clases Navegacionales está relacionada con una y sólo una de las clases conceptuales y representa una vista de sus atributos y operaciones. De esta forma cualquiera de las operaciones que el internauta realiza sobre alguna clase navegacional, es a su vez realizada sobre la correspondiente de la clase conceptual y finalmente ésta afecta a la sociedad de objetos. Bajo esta perspectiva, el diseño del PSMModelo Conceptual OO-Method es semejante al de del PSM-Vista Clase Navegacional, con la diferencia de que el primero está relacionado directamente con la materialización en la base de datos de la sociedad de objetos y el segundo consulta o actualiza la sociedad de objetos del primero. Por esto también para la implementación del PSM-Modelo Conceptual OO-Method se ha decidido seguir la tecnología Enterprise Java Beans tipo entidad, con la diferencia de que los servicios de consulta y actualización tanto del Gestor como de la Clase conceptual invocan a operaciones de consulta y actualización de una base de datos relacional, apoyándose en el framework JDBC de Java. 3.5 Arquitectura software del PSM. Todos los componentes software que se modelan en el PSM OOWS-J2EE están organizados en un arquitectura software que implementa el patrón de diseño Model-View-Controller [7], organizada en las siguientes tres capas: 1. Presentación, que incluye los aspectos propios de solicitud, formación y respuesta de cada una de las páginas JSP. Esta capa se implementa tanto del lado del cliente, por medio de navegadores como del lado del servidor, por medio de un “servlet” controlador cuya responsabilidad es seleccionar la página JSP que atenderá a las peticiones HTML efectuadas por el navegador. 2. Lógica del negocio, la cual incluye la gestión de la sociedad de objetos del Modelo navegacional OOWS y el Modelo conceptual. Para su implementación se utiliza la tecnología Enterprise Java Beans, quién lleva a cabo esta tarea mediante Gestores de las sociedades de objetos mencionadas. Dichos Gestores tienen la responsabilidad de crear, remover, actualizar y consultar los objetos de las clases navegacional OOWS y conceptual. Los objetos OOWS se consideran vistas de los objetos

9

3.

OO-Method y su inicialización depende de estos últimos. La inicialización en memoria de los objetos, se hace a partir de su representación persistente en una base de datos relacional. Persistencia, que posee la materialización de los objetos del modelo conceptual. Para su gestión en la base de datos relacional, se diseñan las operaciones de creación, consulta y actualización del EJB correspondiente al objeto utilizando los servicios de acceso a bases de datos relacionales que ofrece el framework JDBC de J2EE. La Fig. 13 muestra la Arquitectura software descrita.

Fig. 13. Arquitectura software MDA-OOWS

4. Conclusiones y Trabajos Futuros Durante la aplicación de MDA a OOWS hemos encontrado mayores coincidencias que diferencias: su Modelo Navegacional es equivalente al modelo PIM de MDA y los patrones de traducción son equivalentes a las Técnicas de correspondencia PIM-PSM de MDA. Una de las diferencias notables que MDA ofrece respecto a la estrategia de OOWS es el modelado de la plataforma tecnológica a través de los PSM, algo que no se había realizado anteriormente. Es en esto último encontramos aspectos positivos y negativos. Por el lado positivo, el modelar la plataforma tecnológica desde un nivel de abstracción más alto que el que ofrece la tecnología en sí, nos centra en los conceptos esenciales de la misma y posterga los detalles de implementación para las etapas ulteriores de refinamiento. Por ejemplo en la solución propuesta se han omitido detalles de implementación tecnológica real que conllevan las tecnologías JSP, Enterprise Java Beans o JDBC, a favor de centrarse en la funcionalidad de la tecnología y no en los detalles de bajo nivel. El PSM expresa la esencia de la misma y permite abordar el problema de la traducción PIM a PSM de forma inmediata. Por el lado negativo, se observa que el modelado de la plataforma tecnológica implica un esfuerzo considerable dado que la misma suele ser compleja. Cuando ésta no se ha modelado, esta tarea representa una seria desventaja que elimina las bondades que el diseñador ha obtenido al modelar la estructura y comportamiento del sistema solamente desde el punto de vista del PIM. La opción más adecuada aquí es partir de modelos PSM predefinidos, los que lamentablemente no existen muchos disponibles para todas las tecnologías existentes. Si a esto le añadimos que tampoco existen Técnicas de refinamiento PSM para la mayoría de las plataformas tecnológicas reales existentes, la desventaja es aún mayor. Para el caso de OO-Method los modelos dinámico y funcional facilitarían esta tarea. MDA es prometedor, pero lo será aún más, cuando estos problemas se hayan resuelto y se encuentren disponibles perfiles UML para múltiples plataformas tecnológicas. Por lo pronto, deberá dedicarse un esfuerzo importante para cubrir esta carencia. Finalmente, habría que evaluar si más allá de las ventajas que se han considerado respecto al nivel de abstracción mayor que ofrece el PSM respecto de la tecnología, es válido realmente modelar la plataforma tecnológica. En avances próximos a esta investigación se considerará la evaluación de lo mismo y se buscarán elementos que nos permitan emitir un juicio confiable del papel real que juegan los PSM en el desarrollo de aplicaciones MDA. Si su presencia es realmente una ventaja. Si es necesaria o no. Como trabajos futuros se visualizan los siguientes:

10

• • • •

Extender el metamodelo PIM de OOWS, considerando las primitivas conceptuales de los Modelos de Navegación y el nuevo Modelo de Presentación. Extender el metamodelo PSM-OOWS, de acuerdo a los nuevos Modelos de Navegación y Presentación. Evaluar otra posibilidad de metamodelo PSM, tal como “Servicios web”, una posibilidad podría ser el “WebServices for Enterprise Collaboration (WSEC)” de OMG. Extender las Técnicas de correspondencia PIM a PSM a los nuevos metamodelos. Considerar aspectos arquitectónicos que guíen el proceso de correspondencia PIM a PSM, así como la definición precisa de tales correspondencias, no sólo en lenguaje natural. Definir el refinamiento entre el metamodelo PSM y la plataforma tecnológica real. Considerar los modelos dinámico y funcional de OO-Method para la definición precisa de tal refinamiento.

Referencias [1] Atzeni et al. To weave the Web. In International Conf. on Very Large Data Bases (VLDB ’97), Athens, Greece, August 26-29, pages 144-153, 1997. [2] Ceri et al. Web Modeling Language (WebML): a Modeling Language for Designing Web Sites. Computer Networks, 33, pp. 137-157. [3] CDIF Home Page. Home Page. http://www.eigroup.org/cdif/index.html [4] Welcome to The OMG’s CORBA WebSite. Home page. http://www.omg.org/corba [5] CWM. Home Page. http://www.omg.org/technology/documents/formal/cwm.htm [6] Garzotto, F.; Mainetti, L.; Paolini, P. Hypermedia design, analysis, and evaluation issues. In:Communications of the ACM 38-8, pp. 74-86. 1995. [7] Krasner & Pope. A cookbook for using the model-view controller user interface paradigm in Smalltalk-80. Journal of Object-Oriented Programming. 1(3):26-49, August/September 1988. [8] The Source for Java Technology. Home Page. http://www.javasoft.com. [9] Java 2Platform, Enterprise Edition. Home Page. http://java.sun.com/j2ee/ [10] Java Server Pages ™ Technology. Home Page. http://java.sun.com/products/jsp/ [11] Enterprise Java Beans ™ Technology. Home Page. http://java.sun.com/products/ejb/ [12] JDBC ™ Technology. Home Page. http://java.sun.com/products/jdbc/ [13] Isakowitz et al. RMM: a methodolgy for structured hypermedia design. In:Communications of the ACM, 38(8):3443, 1995. [14] International Organization for Standarization. Home page. http://www.iso.ch [15] Larman, C. Applying UML and Patterns. Prentice Hall, 2002. [16] Miller & Mukerji. Model Driven Architecture (MDA). Document number ormsc/2001-07-01. Architecture Borrad ORMSC. Julio 9 de 2001. [17] Meta-Object Facility (MOF), version 1.4. Home page. http://www.omg.org/technology/documents/formal/mof.htm [18] OMG Background information, Disponible en-línea: http://www.omg.org/news/about. [19] Model driven Architecture (MDA). Document number ormsc/2001-07-01. Architecture Board ORMSC. July 9, 2001. [20] Pastor O., Gómez J., Insfrán E., Pelechano V. The OO-Method Approach for Information Systems Modeling: From Object-Oriented Conceptual Modeling to Automated Programming. Information Systems Pergamon/Elsevier Science. INFORMATION SYSTEMS (ISSN 0306-4379) CLAVE:A. Volumen: 26/7 Páginas: 507-534. Año: 2001.

11

[21] Pastor O., Fons J., Abrahão S. & Ramón. Modelado Conceptual Orientado a Objetos para Aplicaciones Web. Ed. Centro de Información Tecnológica (CIT): Workshop Iberoamericano de Ingeniería de Requisitos y Ambientes Software (IDEAS’01). San José, Costa Rica. Ed. Centro de Información Tecnológica (CIT): Workshop Iberoamericano de Ingeniería de Requisitos y Ambientes Software (IDEAS ’01). San José, Costa Rica. 2001. [22] Pastor O., Gómez J. & Cachero C. Conceptual Modeling of Device-Indepent Web Applications. IEEE Multimedia April-June 2001. [23] Pastor O. et al An Object-Oriented Approach to Automate Web Applications Development. K.Bauknecht, S.K.Madria, G.Pernul (Eds.) EC-Web 2001, LNCS 2115, pp.16-28, 2001. Springer Verlag Berlin Heidelberg 2001. [24] RM-ODP, ISO Standard 10746-2 ISO/IEC DIS 10746-2 Basic interpretation concepts. Home page. http://www.joaquin.net/ODP/Part2/6.html [25] Schwabe, D. et al. Systematic Hypermedia Design with OOHDM. ACM International Conference on Hypertext’ 96. Washington, USA. 1996. [26]UML. Home page. http://www.uml.org. [27] XML Metadata Interchange. Home Page. http://www.omg.org/technology/documents/formal/xmi.htm.

12